| name | sdlc-plan |
| description | Use at the START of any coding task, feature, or project - before design or code. Turns a rough idea or request into a clear, testable spec that clarifies real intent, surfaces edge cases, and deliberately hunts for the simplest path to the same outcome (fewest steps, least complexity). Make sure to use this whenever you say "let's build", "I want to add", "new feature/project", "plan this out", or hands over a vague coding request - even if he doesn't say the word "plan". First step of the SDLC loop. |
sdlc-plan - turn intent into a simple, testable spec
This is the first beat of the SDLC loop (plan -> design -> test -> implement -> review -> learn). The paper's lesson: generation is cheap, so the bottleneck is specification quality. A vague request becomes expensive rework; a sharp spec makes everything downstream cheap. Your job here is to think before the agent builds.
Why this matters
Most agent failures trace to under-specification, not the model. "The remaining 20% - edge cases, error handling, integration points - demands deep contextual knowledge models lack." That 20% is decided here, not in code. The other high-leverage move is simplification: the best plan often reaches the same outcome with fewer moving parts.
Procedure
- Clarify real intent. Restate what the user actually wants in one or two sentences. If the request is ambiguous, ask 1-3 sharp questions - do not fill gaps with assumptions.
- Define success criteria. Write the concrete, checkable conditions for "done." These become the contract
sdlc-test turns into tests.
- Surface edge cases. List the realistic ways this breaks or gets weird: empty/malformed input, auth/permission, concurrency, failure of an external call, the unhappy path. Name them now so they're not discovered in production.
- Hunt for the simpler path. Before accepting the obvious approach, ask: is there a way to the same outcome with fewer steps, less code, or fewer dependencies? Propose the leanest version that still meets the criteria. Complexity is a cost, not a feature.
- Decompose. Break the work into small slices that can each be checked after completion.
- State the verification gate. Say how this will be verified before any code is written (per AGENTS.md).
Output
A short spec note:
## <feature> - spec
Intent: <1-2 sentences>
Success criteria: <checkable conditions>
Edge cases: <list>
Chosen approach: <leanest option that meets criteria> - why simpler than alternatives
Slices: <ordered, checkable units>
Verification gate: <how each slice is checked>
Open questions: <or "none">
Gate
Do not move to design or code until you approve the spec. Then hand to sdlc-design (if there are real structural trade-offs) or straight to sdlc-test.
Feeds the loop
If planning revealed a recurring miss (e.g., "I keep under-specifying acceptance criteria"), note it so sdlc-learn can encode it as a rule.
References
Load these as needed:
