spec-kit-generate-spec

Generate Spec — SPDD REASONS Specification Skill

Purpose

Turn business input into one governed, versionable specification that can be reviewed before code is generated. The input may be:

• Free-form text written by the user.
• One or more PRDs, user stories, RFCs, briefs, diagrams, contracts, or other documents.
• File or folder references, including @path references when the host supports them.
• A combination of text and referenced documents.
• An existing specification plus requested changes.

The output is a REASONS Canvas: Requirements, Entities, Approach, Structure, Operations, Norms, and Safeguards. It must capture intent, design, execution, and governance in a single artifact.

This skill generates or updates the specification and its quality checklist. It does not implement product code.

User Input

$ARGUMENTS

Always consider the complete user message and any files or attachments available in the current conversation, even when $ARGUMENTS appears literally or is empty.

Core Principle

Align intent, establish abstractions, and define boundaries before generating code.

Treat the specification as a first-class delivery artifact:

• Keep it in version control with the code.
• Review intent before implementation details.
• Trace meaningful decisions to their source.
• When a requirement or observable behavior changes, update the specification first.
• When behavior-preserving code refactoring changes the documented structure, synchronize the specification afterward.
• Never allow chat history to become the only record of a decision.

Non-Negotiable Rules

1. Do not invent facts. Never fabricate business rules, domain entities, fields, APIs, file paths, dependencies, architecture, compliance obligations, metrics, or code signatures.
2. Preserve source intent. Read referenced sources before deriving requirements from them. Do not silently weaken, expand, or reinterpret their meaning.
3. Separate facts from assumptions. Every unsupported but reasonable choice must be recorded explicitly as an assumption or proposed decision.
4. Surface conflicts. If sources disagree, report the conflict and its impact. Do not silently select the most convenient interpretation.
5. One bounded specification per invocation. A PRD may describe many independently deliverable capabilities. Do not compress unrelated features into one Canvas merely because they share a document.
6. Abstraction before operations. Complete and validate Requirements, Entities, Approach, and Structure before deriving Operations.
7. No code before approval. Do not implement, refactor, or generate product code as part of this skill.
8. No hollow Canvas. All seven REASONS sections must contain specific, useful content. Do not leave placeholders, TODOs, or template instructions in a final specification.
9. Use verified project context. In an existing codebase, inspect relevant implementation and contracts before naming concrete components or signatures.
10. Keep scope controlled. Do not add adjacent features, speculative extensibility, or unnecessary refactors.
11. Make every requirement verifiable. Requirements, acceptance criteria, operations, and safeguards must have observable completion conditions.
12. Never claim readiness without validation. A specification is READY only after its checklist passes and no blocking decisions remain.
13. Generate portable agent pairs. If this workflow creates a support agent, it must generate and validate both a Kiro CLI JSON definition and a Claude Code Markdown definition with equivalent intent and least-privilege capabilities.