sdd-refine

Place a request.md in a cycle folder and invoke the refine phase. It reads the request, capability constraints, spec docs, and code, asks all open questions in one message, then drafts plan.md, scenarios.feature, tasks.md, and spec-delta.md for your review.

Each observable behavior gets three checklist lines: a RED task naming the rule and expected failure, a GREEN task for the minimal passing change, and a REFACTOR task that is never omitted. Small and Medium cycles use a flat triad list; Large cycles group triads under Stage sections.

Write scenarios answering what the user experiences, never how it is built — a scenario should survive a complete rewrite of the implementation. Cover the happy path, empty state, failure state, and permission boundaries, typically 5 to 12 scenarios for a Medium cycle.

Use caracterizacao when the cycle touches existing code with no test coverage: first pin current behavior in a golden-master test, then refactor. The default estrito requires every new behavior to be born from a failing test; dispensado requires a written justification.

The human approval gate is the only review point where changes are cheap — fixing a 40-line plan costs far less than fixing implemented code. The Skill records status: approved and approved_at in plan.md frontmatter so the approval survives across sessions.

The Skill classifies the cycle size itself as a fallback and says so explicitly. If the cycle looks Large, it notes that the capability phase would normally have run first and offers to run it before drafting the plan.