plan-implementation

Solid

Builds a feature implementation plan from an existing feature specification (or equivalent context) through a project-manager-led team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified — including requests like "plan the implementation of X", "how do we build this", "turn this spec into an implementation plan", or "figure out how we'd actually ship this". Launches a team of specialist sub-agents sized to the feature, always including `project-manager` as coordinator and `junior-developer` as generalist stress-tester, and iterates rounds of discussion until the project-manager confirms the plan is ready or only user input remains. Produces three cross-referenced files in the same folder as the source feature specification: feature-implementation-plan.md (the primary plan), implementation-decision-log.md (every committed decision with rationale and evidence), and implementation-iteration-history.md (round-by-round record of speciali

Code & Development 66 stars 5 forks Updated today MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
61
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

## Project Context - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` ## Operating Principles - **The feature specification is the ground truth for *what*.** This skill plans *how*. Do not re-open behavioral decisions the specification already settled; flag contradictions as Open Questions for the user. - **The project-manager is the coordinator, not the author of every section.** It facilitates rounds of discussion among specialists, tracks claims and evidence, and decides when the plan is ready. Specialists own their domains. - **Always include `junior-developer` on the team.** When decisions lack strong evidence, the junior-developer reframes the issue in plain terms first — that frequently unlocks a resolution without needing the user. - **Escalate to the user only when evidence and reframing have both failed.** Every escalation surfaces with a full description, the evidence considered, and a recommended answer. - **Done is when the project-manager says so.** The loop exits when the project-manager reports the plan is ready to commit, or that only user-input items remain. The user is not asked to keep iterating past that point. - **YAGNI is a first-class operating principle, applied to *implementation* choices.** The implementation plan inherits the spec's behavioral commitments but applies the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yag...

Details

Author
testdouble
Repository
testdouble/han
Created
3 weeks ago
Last Updated
today
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

plan-a-feature

Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation — including requests like "help me plan X", "spec out this feature", "design the Y flow", or "let's figure out what it should do". Explores the codebase, project documentation, coding standards, and ADRs to resolve questions before asking the user, and always offers a recommended answer when questions must be surfaced. Produces a feature-specification.md focused on system behaviors, coordinations, processes, and user interactions — not implementation detail. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not investigate bugs or failures — use investigate. Does not analyze existing architecture — use architectural-analysis. Does not document already-built features — us

66 Updated today
testdouble
AI & Automation Listed

plan-feature

This skill should be used when the user asks to "plan feature", "design feature", or wants to plan and design a new feature before implementation.

18 Updated yesterday
Mr-DooSun
AI & Automation Listed

plan-feature

Plan a new feature with analysis, design, and implementation steps. Use when the user asks to plan a feature or run /plan-feature.

335 Updated today
aiskillstore
Data & Documents Listed

writing-plans

Use when you have a spec or requirements for a multi-step task, before touching code

1 Updated 4 days ago
amarbel-llc
AI & Automation Listed

plan-feature

Create complete development plan with parallel exploration

0 Updated today
Kamixon131