Design the central contract
Read specification, artifacts, memory, and safety before designing.
Entry gate
Require approved requirements or an equivalent user-approved contract. If requirements are missing, contradictory, or materially open, stop and recommend $flow-discover rather than inventing them.
Procedure
- Read requirements, project context, applicable repository instructions, current architecture, and relevant decisions or conventions.
- Identify consequences for components, interfaces, data, permissions, compatibility, failures, operations, and tests.
- Present consequential architecture choices with viable alternatives, trade-offs, and one recommendation. Obtain user approval before locking each decision.
- Create
.planning/flow/phases/<slug>/spec.md with all eight required sections from specification.
- Record approved choices in
decisions.md; capture only genuinely durable decisions through $flow-memory semantics.
- Check every requirement has a specification clause and every definition-of-done item has executable evidence.
- Scan for ambiguous language, hidden scope, unresolved placeholders, and contradictions.
- Present the specification for approval. Do not continue to planning in the same step unless the user has explicitly approved it.
Boundaries
- Keep implementation work out of design.
- Prefer established repository patterns unless the approved requirement demands a departure.
- Return to discovery when a proposed design would change product scope.
Output
Return STATUS, specification path, decisions path, unresolved risks, gate result, and NEXT. Recommend $flow-plan only after the design gate is APPROVED.
1---2name: flow-design3description: Designs an approval-gated feature specification from approved requirements, covering architecture decisions, component boundaries, quality constraints, and definition of done.4---56# Design the central contract78Read [specification](../../references/specification.md), [artifacts](../../references/artifacts.md), [memory](../../references/memory.md), and [safety](../../references/safety.md) before designing.910## Entry gate1112Require approved requirements or an equivalent user-approved contract. If requirements are missing, contradictory, or materially open, stop and recommend `$flow-discover` rather than inventing them.1314## Procedure15161. Read requirements, project context, applicable repository instructions, current architecture, and relevant decisions or conventions.172. Identify consequences for components, interfaces, data, permissions, compatibility, failures, operations, and tests.183. Present consequential architecture choices with viable alternatives, trade-offs, and one recommendation. Obtain user approval before locking each decision.194. Create `.planning/flow/phases/<slug>/spec.md` with all eight required sections from [specification](../../references/specification.md).205. Record approved choices in `decisions.md`; capture only genuinely durable decisions through `$flow-memory` semantics.216. Check every requirement has a specification clause and every definition-of-done item has executable evidence.227. Scan for ambiguous language, hidden scope, unresolved placeholders, and contradictions.238. Present the specification for approval. Do not continue to planning in the same step unless the user has explicitly approved it.2425## Boundaries2627- Keep implementation work out of design.28- Prefer established repository patterns unless the approved requirement demands a departure.29- Return to discovery when a proposed design would change product scope.3031## Output3233Return `STATUS`, specification path, decisions path, unresolved risks, gate result, and `NEXT`. Recommend `$flow-plan` only after the design gate is `APPROVED`.
pwdev-solucoes