spk-mission-specify

Run the /spec-kitty.specify command for your feature, then capture the concrete goal, constraints, non-goals, and success criteria. The resulting spec should be complete enough for the plan phase to derive architecture without inventing product intent.

A mission spec should include the user's concrete goal, constraints, non-goals, and success criteria. Unresolved product decisions must stay explicit rather than being hidden in implementation details, and work packages are authored later by the tasks phase.

Add a diagram when a non-trivial user flow, domain lifecycle, rule, or concept boundary is clearer visually. Load the show-me doctrine skill and include the smallest useful diagram while keeping implementation choices out of the specification.

Terminology questions are routed to the glossary doctrine skill, and governance concerns affecting scope are routed to the charter doctrine skill. This keeps the mission spec focused on product intent while doctrine skills handle their domains.

The specify phase does not author work packages or make implementation choices; those belong to the tasks and plan phases. It is designed for spec-driven workflows and may be overkill for one-off edits or teams not using Git.