Spec Kitty — Prompts
Prompt 1: /spec-kitty.specify (Discovery-First Spec Creation)
Source: src/specify_cli/missions/software-dev/command-templates/specify.md
Technique: Mandatory discovery interview with WAITING_FOR_DISCOVERY_INPUT blocking guard.
---
description: Create a mission specification
---
# /spec-kitty.specify - Create Mission Specification
## Primary Invariant: What Are We Building?
This workflow answers "What are we building?" before it creates artifacts. The
raw invocation text is only a starting point for discovery, not the final truth.
Before `mission create`, before writing `spec.md`, and before committing
anything, you **MUST** have one of these:
- A completed discovery interview with an acknowledged Intent Summary.
- A brief-intake summary and extracted requirement set explicitly confirmed by
the user.
- An explicit user instruction to minimize or skip discovery; even then, record
the minimal confirmed scenario and assumptions in the Intent Summary.
For non-trivial work, the confirmed Intent Summary must cover the primary actor,
trigger, desired outcome, one rule or invariant, and any canonical domain term
## 📍 WORKING DIRECTORY: Stay in the repository root checkout
**IMPORTANT**: Specify works in the repository root checkout. NO worktrees are created.
Worktrees are created later during `/spec-kitty.implement`, after task finalization
computes execution lanes.
Notable technique: Pre-implementation discovery gate with explicit blocking condition (WAITING_FOR_DISCOVERY_INPUT) — no spec is created until the agent has confirmed understanding of intent.
Prompt 2: Spec Kitty Delta Philosophy (from spec-driven.md)
Source: spec-driven.md
Technique: Doctrinal manifesto that redefines what a spec IS — establishing the conceptual frame all agents operate within.
## The Spec Kitty Philosophy: Code as Source of Truth
**This is where Spec Kitty diverges from traditional spec-driven development.**
In Spec Kitty, **CODE IS THE SOURCE OF TRUTH** - it represents what exists NOW.
The specification is NOT a comprehensive digital twin of the codebase. Instead,
specifications are **CHANGE REQUESTS** that describe the DELTA between current
reality and desired future state.
**For LLMs working with Spec Kitty:**
- **Always read the code** to understand current implementation
- The specification tells you WHAT TO CHANGE, not what currently exists
- Don't assume the spec documents the entire system
- Code truth > spec documentation
**Example:**
**Traditional approach:**
Specification: "The system has user authentication with email/password,
session management, and password reset... [500 lines documenting entire auth system]"
**Spec Kitty approach:**
Specification: "Add OAuth2 social login (Google, GitHub) alongside
existing email/password authentication. Keep current JWT session
management unchanged."
Notable technique: Explicit comparative framing ("Traditional approach" vs. "Spec Kitty approach") that calibrates the LLM's interpretation of what a spec means in this context.
Prompt 3: REASONS Doctrine Block (in specify.md)
Source: src/specify_cli/missions/software-dev/command-templates/specify.md
Technique: Doctrine injection via conditional comment block — the template includes guidance that activates only when the charter selected SPDD/REASONS.
<!-- spdd:reasons-block:start -->
### REASONS Guidance — Specify
This project's charter selected the SPDD/REASONS doctrine pack. While capturing
the spec, populate or update these REASONS canvas sections:
- **Requirements** — problem statement, acceptance criteria, definition of done.
- **Entities** — domain concepts, relationships, canonical glossary terms.
Reference: `kitty-specs/<mission>/reasons-canvas.md` if present.
<!-- spdd:reasons-block:end -->
Notable technique: Template regions with start/end comment markers that can be conditionally included or excluded during template rendering.