Implement ExecPlan
Use the ExecPlan as the implementation contract for delivering both the intended behavior and the intended simplification of the system.
Preferred Input Resolution
Preferred target resolution order:
- explicit work-item path supplied by the user
- explicit
execplan.mdpath supplied by the user .agent/activewhen it points to a work item with:stage="plan"andstate="completed", orstage="implementation"andstate="blocked"
- the most recently updated work item under
.agent/work/matching those same rules - legacy fallback:
.agent/execplan-pending.md
If no supported plan exists, stop and tell the user.
Work Item Responsibilities
If operating on a work item, read:
meta.jsondecision.mdwhen presentexecplan.md
This skill owns execution-state transitions in meta.json:
- when starting work:
stage="implementation",state="active" - when blocked or only partially complete:
stage="implementation",state="blocked" - when implementation completes:
stage="implementation",state="completed"
Do not rename plans or move directories to represent lifecycle state.
Ousterhout Lens
When the plan leaves room for judgment:
- prefer deep modules over shallow wrappers
- prefer interfaces that hide sequencing and policy
- prefer fewer concepts, fewer knobs, and fewer special cases
- prefer simple mental models over clever decomposition
Workflow
- Read the ExecPlan in full, then read
.agent/PLANS.md. - Reconstruct the intended behavior, target boundary, and complexity dividend.
- If available, read
decision.mdso the implementation stays aligned with the original decision rationale. - Before coding, update
meta.jsontostage="implementation"andstate="active". - Inspect the relevant code paths before editing.
- Implement milestone by milestone.
- Keep the ExecPlan's
Progress,Surprises & Discoveries,Decision Log, andOutcomes & Retrospectivesections up to date as you go. - After each meaningful slice, run the plan's validation steps or the nearest targeted verification.
- If you finish the implementation, set
state="completed". - If you cannot finish safely in the current turn, record the blocker in the plan, set
state="blocked", and stop cleanly.
Implementation-First Rule
This skill is for execution, not more planning.
You may update the ExecPlan during implementation only to:
- record progress actually made
- record discoveries from code already inspected
- tighten milestones or acceptance criteria to match current repo reality
- document design decisions that unblock the next implementation step
Do not turn an implementation turn into another plan-improvement pass.
Anti-Patterns
- satisfying the letter of the plan while preserving the same interface burden
- adding wrappers, adapters, or helper layers that hide little
- pushing sequencing or policy outward to callers
- finishing with only ExecPlan edits when implementation work remains
- using file moves or renames as the primary state transition
Source: grp06/useful-codex-skills — distributed by TomeVault.