| name | implementation-plan |
| description | Create or re-baseline lean, repository-grounded implementation plans and persistent dev docs when users ask for an implementation plan, technical plan, feature plan, refactor plan, or dev-docs workstream. |
| type | workflow |
| enforcement | block |
| priority | high |
Purpose
Create the operational source of truth that future implementation agents use before editing code. The skill investigates current repository reality, designs executable slices, and writes a resumable three-file workstream under dev/active/ that implementation agents maintain progressively without repeated full rereads.
When to Load
- Keywords: implementation plan, technical plan, plan this feature, refactor plan, create dev docs, dev-docs workstream.
- A complex change needs repository investigation and executable sequencing before implementation.
- Work is likely to span layers, multiple sessions, multiple contributors, or more than two hours.
- An existing
dev/active/<task-name>/ workstream needs re-baselining after scope or repository changes.
- A handoff requests persistent planning artifacts for future implementation agents.
When NOT to Load
- Not for a simple bug fix, single-file edit, quick update, or other atomic task that can be safely implemented now.
- Not for product discovery or requirements elicitation without an implementation focus; use the PRD workflow instead.
- Not for reviewing an existing completed plan; use
senior-cto-feedback for critique and approval readiness.
- Not for executing an approved plan; load the plan's implementation skills and rules instead.
- Not for claiming implementation has started or runtime behavior has changed.
Must-Read Docs
Top 5 Invariants
- Investigate and plan only; do not edit runtime code or claim implementation has started.
- Verify every claimed existing path, symbol, test, contract, and configuration key from repository evidence before naming it as current state.
- Classify the requested implementation work against every relevant intent and carry its docs, skills, rules, scope, tests, acceptance criteria, and forbidden moves into the plan.
- Treat
tasks.md as the hot progress ledger by checking substantial tasks immediately and all remaining completed tasks by phase end, while updating context only for meaningful state changes and the plan only for strategy changes.
- Run verification once at each phase end using exactly one Release
dotnet build command and at most one dotnet test --project command for the fastest relevant non-browser test project.
Top 5 Anti-Patterns
- Memory-based planning, which turns assumptions about the repository into false implementation facts.
- Future-state-first planning, which designs changes before reporting what exists, what is missing, and what evidence supports those conclusions.
- Verification sprawl, which wastes implementation time on per-task checks, multiple test commands, app startup, browser automation, Playwright, Chrome DevTools MCP, Aspire, Docker, or live-service smoke tests.
- Stale checkbox debt, which postpones task updates until a separate refresh command and leaves completed implementation appearing unfinished.
- Repetitive rereading, which reloads unchanged plan/context files after every task instead of using
tasks.md as the current execution ledger.
Minimal Examples
Request: "Create an implementation plan for event RSVP."
Output:
dev/active/event-rsvp/event-rsvp-plan.md
dev/active/event-rsvp/event-rsvp-context.md
dev/active/event-rsvp/event-rsvp-tasks.md
Planning sequence:
classify intents -> load rules/skills/docs -> inspect related work ->
verify code/tests/contracts -> report current state -> design slices ->
write and cross-check plan/context/tasks
Phase-end verification only:
dotnet build --configuration Release --verbosity quiet
dotnet test --project <one-relevant-project>.csproj --configuration Release --verbosity quiet
Progress cadence:
start/resume -> read once
substantial task done -> check it immediately
small tasks done -> reconcile no later than phase end
strategy changed -> update plan
decision/blocker/handoff -> update context
Verification Hooks
dotnet test --project tests/Event.Architecture.Tests/Event.Architecture.Tests.csproj --configuration Release --verbosity quietgit diff --check -- .agents/skills/implementation-plan dev/active
Related Skills
