spec-kitty-mission-system

Solid

Understand how Spec Kitty missions work: the 4 built-in mission types, how they define workflows via step contracts and action indices, how missions and work packages relate, how templates are resolved through the 5-tier chain, and how doctrine artifacts (procedures, tactics, directives) compose mission behavior. Triggers: "what missions are available", "how do missions work", "which mission should I use", "explain the mission system", "what is a mission", "change the mission", "mission templates", "step contracts", "action index", "mission procedures". Does NOT handle: runtime loop advancement (use runtime-next), setup or repair (use setup-doctor), governance (use charter-doctrine), or glossary curation (use glossary-context).

AI & Automation 1,449 stars 131 forks Updated today MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%

100

Recency 20%

100

Frontmatter 20%

Documentation 15%

100

Issue Health 10%

License 10%

100

Description 5%

100

Skill Content

# spec-kitty-mission-system Understand how missions structure work in Spec Kitty. A mission is a domain-specific workflow blueprint that defines what steps you go through, the template each step provides, what artifacts you produce, and how to validate success. --- ## How Missions Work ### The Core Concept A mission answers: "What process should we follow to achieve this goal?" Different goals need different processes. Building a software component is different from conducting research or writing documentation. Each mission provides domain-appropriate: - **Steps** — the ordered phases of work (specify → plan → implement → review); each step provides the prompt/content **template** agents follow - **Artifacts** — expected outputs (spec.md, plan.md, tasks.md) - **Guards** — conditions that must be met before advancing (e.g., spec.md must exist before planning) - **Validation** — checks that verify the output quality - **Agent context** — personality and instructions for the AI agent ### The Hierarchy: Mission Type → Mission → Work Package → Workspace ``` Mission Type (e.g., software-dev) └── Mission (kitty-specs/042-auth-system/) ├── meta.json ← links mission to mission type + target branch ├── spec.md ← what we're building ├── plan.md ← how we'll build it ├── tasks.md ← WP breakdown └── tasks/ ├── WP01.md ← work package prompt ├── WP02.md ...