Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Executing Plans
Execute the plan yourself, task by task, in this session: no implementer
subagent per task, no reviewer per task. One fresh-context review of the
whole branch at the end.
**Why inline:** Subagent-driven development pays for a fresh implementer
and a fresh reviewer on every task, each re-reading the codebase from zero.
Inline execution pays for one context (yours) plus one reviewer at the end.
What it gives up is a fresh context per task and a second pair of eyes per
task. This skill keeps what those two things bought, by other means: the
brief is the spec, the ledger is your memory, TDD is the per-task gate, and
the final reviewer is the second pair of eyes.
**Core principle:** The plan already did the thinking. Execute it exactly,
prove each step with a test you watched fail and then pass, and leave a
record that survives your own forgetting.
**Narration:** between tool calls, narrate at most one short line — the
ledger and the tool results carry the record.
**Continuous execution:** Do not pause to check in with your human partner
between tasks. They chose inline execution to spend less, not to answer
…
The line at the top of this page pins the label v1.0.1, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_lzawskbjwkn6kr7x
GET https://markdownregistry.com/api/v1/resolve?ref=sodiumjoe/dotfiles/executing-plans
GET https://markdownregistry.com/api/v1/blob/6278e4361a0739b6d1c708eb1de4420390d2f92cc2f6336705892431c782be77
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
sodiumjoe/dotfiles · home/.agents/skills/brainstorming/SKILL.md · You MUST use this before any creative work - creating features, building components, adding functionality, or modifying…
sodiumjoe/dotfiles · home/.agents/skills/dispatching-parallel-agents/SKILL.md · Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
sodiumjoe/dotfiles · home/.agents/skills/finishing-a-development-branch/SKILL.md · Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
sodiumjoe/dotfiles · home/.agents/skills/neovim-review/SKILL.md · Use when the user invokes /neovim-review for a pull request or a local :Review session in Neovim.
sodiumjoe/dotfiles · home/.agents/skills/neovim/SKILL.md · Interact with a running neovim instance over RPC — open files, show diffs, execute Lua. Use when you need to open a…
sodiumjoe/dotfiles · home/.agents/skills/receiving-code-review/SKILL.md · Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or…
sodiumjoe/dotfiles · home/.agents/skills/requesting-code-review/SKILL.md · Use when completing tasks, implementing major features, or before merging to verify work meets requirements
sodiumjoe/dotfiles · home/.agents/skills/subagent-driven-development/SKILL.md · Use when executing implementation plans with independent tasks in the current session
sodiumjoe/dotfiles · home/.agents/skills/systematic-debugging/SKILL.md · Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
sodiumjoe/dotfiles · home/.agents/skills/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code
sodiumjoe/dotfiles · home/.agents/skills/using-git-worktrees/SKILL.md · Use when starting feature work that needs isolation from current workspace or before executing implementation plans -…
obra/superpowers · skills/executing-plans/SKILL.md · Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose…
a5c-ai/babysitter · library/methodologies/superpowers/skills/executing-plans/SKILL.md · Use when you have a written implementation plan to execute in a separate session with review checkpoints between…
ganyuanran/aegis · skills/executing-plans/SKILL.md · Use when executing a written implementation plan across sessions or with review checkpoints. Small or single-slice…
coco-research/coco · skills/executing-plans/SKILL.md · Use when you have a written implementation plan to execute in a separate session with review checkpoints
xu123-bob/baize · agent/skills/superpowers/5.1.0/skills/executing-plans/SKILL.md · Use when you have a written implementation plan to execute in a separate session with review checkpoints
jamditis/claude-skills-journalism · superjawn/skills/executing-plans/SKILL.md · Use when you have a written implementation plan to execute in a separate session with review checkpoints
ibrahim-3d/orchestrator-supaconductor · skills/executing-plans/SKILL.md · Use when you have a written implementation plan to execute in a separate session with review checkpoints
