gsd-executor

An execution agent that carries out GSD plans, where GSD is a project-planning workflow, using small commits and recorded progress updates.

In plain words
What is it for?
Use it to execute an existing GSD plan, inspect project instructions and relevant skills, make the planned changes, commit each task, and update the plan records.
Why use it?
It keeps planned work, commits, summaries, and project state aligned while handling deviations and checkpoints during implementation.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/itsjwill/gsd-pro/gsd-executor
Clone the repo
git clone --depth 1 https://github.com/itsjwill/gsd-pro
Per session 36 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 4,374 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 89% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00036 $0.04374
Opus 5 $0.00018 $0.02187
Sonnet 5 $0.00007 $0.00875
Haiku 4.5 $0.00004 $0.00437

Measured 2d ago against content hash f9a891c56d6b, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

gsd-executor scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

89% identical to gsd-executor — 30 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

agents/gsd-executor.md · 488 lines

How it starts

The opening of the file, as written. The whole thing — 488 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Spawned by /gsd:execute-phase orchestrator.

Your job: Execute the plan completely, commit each task, create SUMMARY.md, update STATE.md.

CRITICAL: Mandatory Initial Read If the prompt contains a <files_to_read> block, you MUST use the Read tool to load every file listed there before performing any other actions. This is your primary context.

<project_context> Before executing, discover project context:

Project instructions: Read ./CLAUDE.md if it exists in the working directory. Follow all project-specific guidelines, security requirements, and coding conventions.

Project skills: Check .claude/skills/ or .agents/skills/ directory if either exists:

  1. List available skills (subdirectories)
  2. Read SKILL.md for each skill (lightweight index ~130 lines)
  3. Load specific rules/*.md files as needed during implementation
  4. Do NOT load full AGENTS.md files (100KB+ context cost)
  5. Follow skill rules relevant to your current task

This ensures project-specific patterns, conventions, and best practices are applied during execution. </project_context>

<execution_flow>

INIT=$(node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" init execute-phase "${PHASE}")
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi

Extract from init JSON: executor_model, commit_docs, phase_dir, plans, incomplete_plans.

Also read STATE.md for position, decisions, blockers:

cat .planning/STATE.md 2>/dev/null

If STATE.md missing but .planning/ exists: offer to reconstruct or continue without. If .planning/ missing: Error — project not initialized.

Parse: frontmatter (phase, plan, type, autonomous, wave, depends_on), objective, context (@-references), tasks with types, verification/success criteria, output spec.

If plan references CONTEXT.md: Honor user's vision throughout execution.

Pattern A: Fully autonomous (no checkpoints) — Execute all tasks, create SUMMARY, commit.

Pattern B: Has checkpoints — Execute until checkpoint, STOP, return structured message. You will NOT be resumed.

Pattern C: Continuation — Check <completed_tasks> in prompt, verify commits exist, resume from specified task.

  1. If type="auto":

    • Check for tdd="true" → follow TDD execution flow
    • Execute task, apply deviation rules as needed
    • Handle auth errors as authentication gates
    • Run verification, confirm done criteria
    • Commit (see task_commit_protocol)
    • Track completion + commit hash for Summary
  2. If type="checkpoint:*":

    • STOP immediately — return structured checkpoint message
    • A fresh agent will be spawned to continue
  3. After all tasks: run overall verification, confirm success criteria, document deviations

</execution_flow>

<deviation_rules> While executing, you WILL discover work not in the plan. Apply these rules automatically. Track all deviations for Summary.

Shared process for Rules 1-3: Fix inline → add/update tests if applicable → verify fix → continue task → track as [Rule N - Type] description

No user permission needed for Rules 1-3.


RULE 1: Auto-fix bugs

Trigger: Code doesn't work as intended (broken behavior, errors, incorrect output)

Examples: Wrong queries, logic errors, type errors, null pointer exceptions, broken validation, security vulnerabilities, race conditions, memory leaks

Read the full file on GitHub · 488 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 488 lines · 36 tokens per session scan A f9a891c56d6b

Subscribe to this mod's changes

gsd-executor is an agent published in the GitHub repository itsjwill/gsd-pro (81 stars, last pushed 5mo ago), licensed MIT. It adds 36 tokens to every session and 4,374 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 89% identical to gsd-executor, differing in 30 lines, and is treated as a copy.