executing-plans
executing-plans
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
executing-plansUse when executing an existing implementation plan, tracking dependencies, adapting outdated steps, and verifying acceptance checks.
Independent GitHub snapshot · Automated classification · Original documentation governs
Load plan, review critically, execute all tasks, report when complete.
Announce at start: "I'm using the executing-plans skill to implement this plan."
Use subagents only when supported, permitted, and useful for independent tasks. Otherwise execute the plan directly; no extra runtime setup is needed.
For each task:
After all tasks complete and verified:
STOP executing immediately when:
Investigate test failures and missing local dependencies first; repair routine blockers within scope. Ask for the specific missing input only when it is necessary.
Return to Review (Step 1) when:
Don't force through blockers - stop and ask.
Track results against the actual work revision:
Task: Implement retry policy
Input: Existing plan, current error contract, caller tests
Files: Client implementation and focused retry tests
Acceptance: Bounded attempts; cancellation propagates
Evidence: Test command, exit status, revision
Next: Integration check after the dependent caller changes
Reuse passing evidence while its relevant inputs are unchanged. Invalidate the affected check when a dependency or implementation changes. Keep failed checks visible until their causes are resolved. A skipped external integration is not a passing integration test.
Compare each step with current repository files before executing it. When a command or file moved, update the plan from observed evidence. Keep unfinished user tasks separate from newly discovered follow-up work. For an unavailable dependency, complete independent tasks first. Report the precise missing access or decision needed for blocked work.
Implemented: Tasks 1-4, with dependency order preserved.
Validated: Focused tests and required repository checks.
Delivery: PR created and merged when that was requested.
Unverified: External staging flow requires a configured environment.