plan

Files (1)

• SKILL.md

SKILL.md (first lines)

# /sdlc:plan — plan before code

Read `sdlc-loop`. Design review happens here, while changing course is still a matter of editing a document.

## Preconditions

1. Resolve the change from `$ARGUMENTS` (or list changes with an accepted `spec.md` and no `plan.md`).
2. `spec.md` must be `status: accepted`. If not, name the product owner and stop, unless `--no-spec` or an
   explicit override is given (record `override:` in the plan frontmatter). Small changes without an intent
   may run with `--no-spec`; still write a plan.
3. **Enter plan mode now** (call `EnterPlanMode`). You may read the codebase freely and must not edit files
   until the engineer accepts the plan. Write `.sdlc/current` with the change id (allowed: it is a marker,
   not code) once the plan is accepted, not before.

## Interview, then draft

Read `intent.md`, `spec.md`, `CLAUDE.md`, and the code the spec names. Then interview the engineer briefly:
- Which files change, and is there existing code to reuse rather than add?
- What order minimises risk (behind auth first, UI last, migrations separately)?
- Which tests prove each acceptance criterion? What is the quantifiable "done"?
Draft `plan.md` from `sdlc/changes/_template/plan.md`, setting `spec_commit` to the accepted spec SHA.

## Interrogate the plan (mandatory, before asking for approval)

Answer these in the plan itself:
1. What could this change break? (Risks)
2. Which step is the riskiest, and how is it made safe?
3. What other options did you choose not to do, and why? (Options not taken)
4. Could an engineer who never saw this conversation implement it from the plan alone? Iterate until yes.
5. Can the work be split into independent tasks that touch different files? Mark them; the engineer may run
   them as parallel sessions in worktrees (`claude --worktree <task>`). Tasks sharing files stay in one session.

## Accept and commit

- Present the plan for approval (ExitPlanMode). Routine changes are accepted by the engineer. If `risk: high`,
  say a tech lead or architect must also approve before build, and stop after committing the draft.
- On acceptance: set `status: accepted`, write `.sdlc/current` = change id, commit `plan: <title>` with trailer
  `SDLC-Change: <id>` on the working branch `sdlc/<change-id>`.
- Report: path, the proof statement, the parallelisable tasks, and the next step: `/sdlc:build`.

## Rules

- Never write application code in this skill. Plan mode enforces it; respect it.
- The plan is the contract review checks against (Stage 5). Be exact about paths and tests.
- With a solid plan, implementation is usually a single pass. Spend the time here.

From bibutikoley/ai-sdlc-claude, MIT.

More from bibutikoley/ai-sdlc-claude