Exec-Plans Standard
This is a meta-skill: a rule that applies to a specific, recurring document type — the ExecPlan — used across this knowledge base's Design, Implementation, and other stages whenever a change is complex enough to need a persistent, revisable plan. The rules below are read live from this plugin's own skills/exec-plans-standard/exec-plans-standard.md every time this skill runs, so there is no separate paraphrased copy anywhere for this content to drift against.
Exec-plans standard (live)
!cat "${CLAUDE_PLUGIN_ROOT}/skills/exec-plans-standard/exec-plans-standard.md"
Instructions
- When authoring a new ExecPlan, start from the Skeleton Of A Good ExecPlan above and flesh out every section with real content — do not skip a section because it feels premature; an ExecPlan without
Progress, Surprises & Discoveries, Decision Log, and Outcomes & Retrospective is not a valid ExecPlan under this standard, per the Living Plans And Design Decisions section above.
- Treat self-containment as non-negotiable: a reader with only the current working tree and this one file, no memory of prior conversation, must be able to follow it end-to-end. Define every term of art in plain language the first time you use it; do not write "as defined previously" or point to an external doc for meaning that must live in the plan itself.
- When executing or continuing work under an existing ExecPlan, do not stop to ask "what's next" — proceed to the next milestone, and update the living-document sections (Progress with a timestamp, Surprises & Discoveries with evidence, Decision Log with rationale, Outcomes & Retrospective at completion of a major task or the whole plan) as you go, per the Living Plans And Design Decisions and Milestones sections above.
- When you change course mid-implementation, record why in the Decision Log and reflect the implication in Progress — a plan that silently changed direction without a recorded reason has failed this standard's own "always possible to restart from only the ExecPlan" requirement.
- Apply the Formatting rules exactly: when the ExecPlan is handed off as a standalone artifact separate from the file itself, wrap it in one single fenced
md code block with no nested triple-backtick fences inside (use indentation for embedded commands/diffs/code instead); when the file itself is the ExecPlan (the normal case, a .md file whose content is only the plan), omit the triple backticks — the file itself is the ExecPlan. Prefer prose over lists outside the mandatory checklist sections.
- Anchor every acceptance claim to observable behavior a human can verify (a command and its output, an HTTP request/response, a UI action and what appears) rather than an internal attribute like "added a struct" — per the Guidelines section above.
- If you are re-reading this skill after
skills/exec-plans-standard/exec-plans-standard.md changed, trust what you just read above over any memory of a previous run — that live content is always the current source of truth for how ExecPlans in this knowledge base are authored, executed, and maintained.
1---2name: exec-plans-standard3description: Use when authoring a new ExecPlan (a self-contained, novice-followable execution plan for a feature or system change), when executing or continuing work under an existing ExecPlan and updating its Progress/Surprises & Discoveries/Decision Log/Outcomes & Retrospective sections, when checking whether an ExecPlan is genuinely self-contained and formatted correctly (single fenced `md` block when handed off as a standalone artifact, prose-first narrative, mandatory living-document sections), or when discussing what an ExecPlan requires. Distinct from the `documentation-standards` meta-skill, which governs ordinary Markdown documents in this knowledge base (metadata, diagrams, links, tables) — this skill governs the ExecPlan document type specifically: its skeleton, its living-document discipline, and its formatting envelope.4---56# Exec-Plans Standard78This is a meta-skill: a rule that applies to a specific, recurring document type — the ExecPlan — used across this knowledge base's Design, Implementation, and other stages whenever a change is complex enough to need a persistent, revisable plan. The rules below are read live from this plugin's own `skills/exec-plans-standard/exec-plans-standard.md` every time this skill runs, so there is no separate paraphrased copy anywhere for this content to drift against.910## Exec-plans standard (live)1112!`cat "${CLAUDE_PLUGIN_ROOT}/skills/exec-plans-standard/exec-plans-standard.md"`1314## Instructions15161. When authoring a new ExecPlan, start from the Skeleton Of A Good ExecPlan above and flesh out every section with real content — do not skip a section because it feels premature; an ExecPlan without `Progress`, `Surprises & Discoveries`, `Decision Log`, and `Outcomes & Retrospective` is not a valid ExecPlan under this standard, per the Living Plans And Design Decisions section above.172. Treat self-containment as non-negotiable: a reader with only the current working tree and this one file, no memory of prior conversation, must be able to follow it end-to-end. Define every term of art in plain language the first time you use it; do not write "as defined previously" or point to an external doc for meaning that must live in the plan itself.183. When executing or continuing work under an existing ExecPlan, do not stop to ask "what's next" — proceed to the next milestone, and update the living-document sections (Progress with a timestamp, Surprises & Discoveries with evidence, Decision Log with rationale, Outcomes & Retrospective at completion of a major task or the whole plan) as you go, per the Living Plans And Design Decisions and Milestones sections above.194. When you change course mid-implementation, record why in the Decision Log and reflect the implication in Progress — a plan that silently changed direction without a recorded reason has failed this standard's own "always possible to restart from only the ExecPlan" requirement.205. Apply the Formatting rules exactly: when the ExecPlan is handed off as a standalone artifact separate from the file itself, wrap it in one single fenced `md` code block with no nested triple-backtick fences inside (use indentation for embedded commands/diffs/code instead); when the file itself is the ExecPlan (the normal case, a `.md` file whose content is only the plan), omit the triple backticks — the file itself is the ExecPlan. Prefer prose over lists outside the mandatory checklist sections.216. Anchor every acceptance claim to observable behavior a human can verify (a command and its output, an HTTP request/response, a UI action and what appears) rather than an internal attribute like "added a struct" — per the Guidelines section above.227. If you are re-reading this skill after `skills/exec-plans-standard/exec-plans-standard.md` changed, trust what you just read above over any memory of a previous run — that live content is always the current source of truth for how ExecPlans in this knowledge base are authored, executed, and maintained.
BhangeeF16