Use when creating an implementation plan, breaking down tasks, estimating effort, or planning sprints. Also triggers on 'how do we build this', 'task breakdown', 'development roadmap', 'sprint planning', or 'implementation plan'.
From pmnpx claudepluginhub etusdigital/etus-plugins --plugin pmThis skill uses the workspace's default tool permissions.
knowledge/template.mdSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides implementation of event-driven hooks in Claude Code plugins using prompt-based validation and bash commands for PreToolUse, Stop, and session events.
Reference: .claude/skills/orchestrator/dependency-graph.yaml
BLOCKS (must exist — auto-invoke if missing):
docs/ets/projects/{project-slug}/planning/user-stories.md — Needed for US-# to decompose into impl-# tasks.docs/ets/projects/{project-slug}/architecture/tech-spec.md — Needed for NFR-# targets and technical constraints.ENRICHES (improves output — warn if missing):
docs/ets/projects/{project-slug}/implementation/api-spec.md — API design informs implementation sequence.docs/ets/projects/{project-slug}/architecture/architecture-diagram.md — System structure informs task grouping.Resolution protocol:
dependency-graph.yaml → implementation-plan.requires: [user-stories, tech-spec]BLOCKS (must exist — auto-invoke if missing):
docs/ets/projects/{project-slug}/features/{feature-slug}/user-stories.md — Scoped user stories (FB-# → US-#) to decompose into impl-# tasks.docs/ets/projects/{project-slug}/features/{feature-slug}/design-delta.md — Technical changes and constraints for this feature. Replaces tech-spec as upstream.ENRICHES (improves output — warn if missing):
docs/ets/projects/{project-slug}/features/{feature-slug}/feature-brief.md — Original feature scope and problem statement.docs/ets/projects/{project-slug}/features/{feature-slug}/solution-discovery.md — Chosen solution direction and four-risk assessment for this feature.docs/ets/projects/{project-slug}/features/{feature-slug}/feature-status.md — Canonical feature state.docs/ets/projects/{project-slug}/architecture/tech-spec.md — Broader system constraints (if exists).docs/ets/projects/{project-slug}/architecture/architecture-diagram.md — System structure context (if exists).Resolution protocol:
docs/ets/projects/{project-slug}/state/project-status.yaml or infer from $ARGUMENTS (if path contains features/)dependency-graph.yaml → Feature mode: implementation-plan.requires: [features/{feature-slug}/user-stories.md, features/{feature-slug}/design-delta.md]Determine mode using this priority:
$ARGUMENTS contains a features/ path → Feature modedocs/ets/projects/{project-slug}/state/project-status.yaml exists with "mode": "feature" → Feature modedocs/ets/projects/{project-slug}/features/*/user-stories.md exists but docs/ets/projects/{project-slug}/planning/user-stories.md does not → Feature modeUse full version when:
Use short version when:
MANDATORY: This skill MUST write its artifact to disk before declaring complete.
mkdir -p if neededIf the Write fails: Report the error to the user. Do NOT proceed to the next skill.
This skill follows the ETUS interaction standard. Your role is a thinking partner, not an interviewer — suggest alternatives, challenge assumptions, and explore what-ifs instead of only extracting information.
One question per message — Never batch multiple questions. Ask one, wait for the answer, then ask the next. Use the AskUserQuestion tool when available for structured choices.
3-4 suggestions for choices — When the user needs to choose a direction, present 3-4 concrete options with a brief description of each. Highlight your recommendation.
Propose approaches before generating — Before generating any content section, propose 2-3 approaches with tradeoffs and a recommendation.
Present output section-by-section — Don't generate the full document at once. Present each major section, ask "Does this capture it well? Anything to adjust?" and only proceed after approval.
Track outstanding questions — If something can't be answered now, classify it:
Multiple handoff options — At completion, present 3-4 next steps as options.
Resume existing work — Before starting, check if the target artifact already exists at the expected path. If it does, ask the user: "I found an existing implementation-plan.md at [path]. Should I continue from where it left off, or start fresh?" If resuming, read the document, summarize the current state, and continue from outstanding gaps.
Assess if full process is needed — If the user's input is already detailed with clear requirements, specific acceptance criteria, and defined scope, don't force the full interview. Confirm understanding briefly and offer to skip directly to document generation. Only run the full interactive process when there's genuine ambiguity to resolve.
This skill reads and writes persistent memory to maintain context across sessions.
On start (before any interaction):
docs/ets/.memory/project-state.md — know where the project isdocs/ets/.memory/decisions.md — don't re-question closed decisionsdocs/ets/.memory/preferences.md — apply user/team preferences silentlydocs/ets/.memory/patterns.md — apply discovered patternsOn finish (after saving artifact, before CLOSING SUMMARY):
project-state.md is updated automatically by the PostToolUse hook — do NOT edit it manually.python3 .claude/hooks/memory-write.py decision "<decision>" "<rationale>" "<this-skill-name>" "<phase>" "<tag1,tag2>"python3 .claude/hooks/memory-write.py preference "<preference>" "<this-skill-name>" "<category>"python3 .claude/hooks/memory-write.py pattern "<pattern>" "<this-skill-name>" "<applies_to>"The .memory/*.md files are read-only views generated automatically from memory.db. Never edit them directly.
Generate a comprehensive implementation-plan.md that translates design and architecture documents into an executable development plan. This document decomposes user stories and features into concrete implementation tasks (impl-#), maps dependencies, estimates effort, sequences work across sprints, and identifies risks.
The implementation plan is the bridge between design completion and development execution. It ensures nothing falls through the cracks and provides visibility into what gets built, when, and by whom.
[upstream-path] provided, load that documentdocs/ets/projects/{project-slug}/planning/user-stories.md (stories to implement) and design documentsdocs/ets/projects/{project-slug}/architecture/tech-spec.md (architecture tasks), docs/ets/projects/{project-slug}/implementation/api-spec.md (API work)Load the following sections from upstream:
features/ path provided, load that documentdocs/ets/projects/{project-slug}/features/{feature-slug}/user-stories.md + docs/ets/projects/{project-slug}/features/{feature-slug}/design-delta.mddocs/ets/projects/{project-slug}/features/ for matching slug filesLoad the following sections from upstream:
user-stories.mddesign-delta.md (architecture/data/API deltas)feature-brief.md for contextsolution-discovery.mdDocument structure:
state/execution-status.yaml.Generate impl-# identifiers for all implementation tasks:
impl-1 (Backend: User registration endpoint) → US-3Refer to docs/ets/projects/{project-slug}/implementation/template-implementation-plan.md for:
Execution instruction: Load context, decompose stories into tasks, estimate effort, map dependencies, sequence into sprints, identify risks, establish DoD criteria, and output implementation-plan.md to docs/ets/projects/{project-slug}/implementation/.
user-stories.md (BLOCKS):
tech-spec.md (BLOCKS):
api-spec.md (ENRICHES):
features/{feature-slug}/user-stories.md (BLOCKS):
features/{feature-slug}/design-delta.md (BLOCKS):
features/{feature-slug}/feature-brief.md (ENRICHES):
Before marking this document as COMPLETE:
If any check fails → mark document as DRAFT with <!-- STATUS: DRAFT --> at top.
After saving and validating, display:
✅ implementation-plan.md saved to `docs/ets/projects/{project-slug}/implementation/implementation-plan.md`
Status: [COMPLETE | DRAFT]
IDs generated: [list impl-# IDs, e.g., impl-1 through impl-N]
→ Next step: validate or hand off to execution
Run: /validate or proceed in your chosen execution system
Do NOT proceed to the next skill without displaying this summary first.
After saving the artifact and displaying the CLOSING SUMMARY, offer optional execution adapter projection:
"Implementation plan saved with N tasks. Would you like me to project these tasks into an execution adapter?"
If the user says yes:
Check which execution_adapter is active in state/project-status.yaml.
If execution_adapter = none, stop after explaining that execution projection is optional and disabled for this project.
If an adapter is active:
docs/ets/projects/{project-slug}/state/project-status.yamldocs/ets/projects/{project-slug}/state/execution-sync.yamldocs/ets/projects/{project-slug}/state/execution-status.yamlmemory-write.py linear ...If the user says no, skip silently.
Product mode:
user-stories.md, tech-spec.md (BLOCKS), api-spec.md, architecture-diagram.md (ENRICHES)Feature mode:
Input: features/{feature-slug}/user-stories.md, features/{feature-slug}/design-delta.md (BLOCKS), features/{feature-slug}/feature-brief.md, features/{feature-slug}/solution-discovery.md, tech-spec.md (ENRICHES)
Action: Extract scoped US-#, technical deltas, feature constraints
Output: Feature-scoped implementation requirements bundle
Why this matters: The implementation plan translates all upstream decisions into executable tasks. Loading the full context ensures nothing is missed.
quality-checklist and may be projected into state/execution-status.yaml when an execution adapter is enableddocs/ets/projects/{project-slug}/implementation/ — create if missingdocs/ets/projects/{project-slug}/implementation/implementation-plan.md using the Write tooldocs/ets/projects/{project-slug}/features/{feature-slug}/ — create if missingdocs/ets/projects/{project-slug}/features/{feature-slug}/impl-plan.md using the Write tooldocs/ets/projects/{project-slug}/implementation/implementation-plan.md) + paths to upstream documents (BLOCKS: docs/ets/projects/{project-slug}/planning/user-stories.md, docs/ets/projects/{project-slug}/architecture/tech-spec.md)"Document saved to
docs/ets/projects/{project-slug}/implementation/implementation-plan.md. The spec reviewer approved it. Please review and let me know if you want any changes before we proceed." Wait for the user's response. If they request changes, make them and re-run the spec review. Only proceed to validation after user approval.
| Error | Severity | Recovery | Fallback |
|---|---|---|---|
| BLOCKS dep missing | Critical | Auto-invoke upstream skill | Block execution |
| US-# has no clear implementation path | Medium | Ask user to clarify story | Create placeholder impl-# with TODO |
| Team capacity unknown | Low | Ask user or use default (1 dev, 10pts/sprint) | Note assumption |
| Output validation fails | High | Mark as DRAFT | Proceed with DRAFT status |