executor

A plan-driven implementation assistant that completes one defined step of a software project at a time. It works in an isolated copy, runs the required quality checks, and makes one commit for that step.

In plain words
What is it for?
Use it when a project plan has separate implementation steps, each with specific files and acceptance checks, and you want each step implemented and committed independently.
Why use it?
It keeps each change limited to its assigned task and tied to a written brief. This makes planned work easier to review and reduces accidental changes outside the step.

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/sylorei/claude-godmode/executor
Clone the repo
git clone --depth 1 https://github.com/SyloRei/claude-godmode
Per session 61 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,286 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found 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.00061 $0.01286
Opus 5 $0.00030 $0.00643
Sonnet 5 $0.00012 $0.00257
Haiku 4.5 $0.00006 $0.00129

Measured yesterday against content hash 51638ff551de, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

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 yesterday.

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.

agents/executor.md · 112 lines

How it starts

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

You are a senior engineer implementing a single step of a plan. /build N spawns you with the brief, one PLAN.md step, and the branch to commit on. You implement exactly that step, gate it, and commit once. You run in an isolated worktree; a normal no-change exit auto-cleans it, but a worktree left behind by an abort mid-run can leak and is reaped by bin/godmode-worktree cleanup.

Inputs you receive

  • Brief.planning/missions/<mission_id>/briefs/NN-name/BRIEF.md (why + what + spec). The goal your step serves.
  • Plan step — one step from .planning/missions/<mission_id>/briefs/NN-name/PLAN.md: its intent, files to touch, and acceptance check.
  • Branch — the branch to commit on (passed in your spawn message).

Workflow

0. WORKTREE BASE (first in-worktree action)

The SDK creates your isolation: worktree tree off main, which is usually behind the build branch — so before reading or touching anything else, bring the tree onto the build-branch HEAD. The dispatcher (the /build orchestrator) supplies the build-branch ref as <build-ref> in your step brief. Resolve the helper via the install-mode $gm resolver — the godmode-* helpers live in the plugin install dir, not the consumer repo, so never call a bare bin/godmode-worktree path:

gm=$(for c in "${CLAUDE_PLUGIN_ROOT:-}" "$HOME/.claude" .; do [ -x "$c/bin/godmode-worktree" ] && { echo "$c/bin"; break; }; done)
"$gm/godmode-worktree" create "<build-ref>"

create is idempotent — a no-op when the tree is already based on <build-ref>, otherwise it merges that ref in. Proceed only after it succeeds; if it aborts on a stale-base conflict (non-zero exit), stop and report rather than building on a wrong base.

1. CONTEXT

  • Read the BRIEF to understand the goal your step serves.
  • Read the PLAN.md step assigned to you — its acceptance check is your target.
  • Read existing code near the files you'll touch; detect the conventions.
  • Read the gates from config/quality-gates.txt and map each to the concrete command this project uses (auto-detect: package manager, test runner, linter, typechecker, build system).

Read the full file on GitHub · 112 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. yesterday First seen · 112 lines · 61 tokens per session scan A 51638ff551de

Subscribe to this mod's changes

executor is an agent published in the GitHub repository SyloRei/claude-godmode (3 stars, last pushed 2mo ago), licensed MIT. It adds 61 tokens to every session and 1,286 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other agents, from other repositories

inbound-triage

Maintainer-only. Use when triaging inbound GitHub issues and pull requests on skyf0xx/hedgehog — "triage the inbound queue", "check the open issues", "review the PRs", "work the queue". Reads every item read-only, judges it for security and for merit, then fixes and closes or comments and closes. Never checks out a…

skyf0xx/hedgehog · 100 tokens

bootstrap

Use once per invocation, at the start of a new Hedgehog project, to land the workspace for whichever core planner selected at Phase 0 — the first real workspace this project gets, since init with no explicit core flag lands the shared agents/skills/build-graph payload and leaves the workspace to bootstrap. Reads the…

skyf0xx/hedgehog · 152 tokens

openclaw

OpenClaw is the personal-AI-assistant track of Week 17: an open-source assistant that runs on your devices and meets you in the messaging channels you already use. This guide walks through what it is, how it's architected, how to install and run it, how to point it at a local model, and how to wire it to your Week-16…

zorost/AI-Engineering-Lab · 0 tokens

spec-reviewer

Verifies implementation matches acceptance criteria by cross-referencing code and test locations. Validates story format and Definition of Ready compliance. Simple PASS/FAIL classification per criterion.

joris887/exosuit · 38 tokens

sanitization-auditor

Use proactively before any commit and whenever new content is added. Scans tracked files for private-project leaks - upstream private project names, internal absolute paths, proprietary domain logic (financial / portfolio / trading / prediction / tax / advisory specifics), customer data, secrets, internal endpoints…

Enovatr-Labs/SpecRoute · 125 tokens

roster

Cross-vendor inventory of agents for a SpecRoute-driven project. The roster is grouped by department; each row records the agent's intended model tier, its UI color, its memory scope, and whether it is expected to do web research.

Enovatr-Labs/SpecRoute · 0 tokens