# Spec Kit

Track requirements through a specification, plan, tasks, and implementation checks when shared rules need durable agreement.

ID: spec-kit
Language: en
Revision: 1
Translation source revision: 1
Canonical: https://kickoff.jujin.dev/en/catalog/spec-kit/

## Why: the goal or problem

A concert booking service lets fans reserve seats and join a waitlist. Separate booking and notification changes must follow one release rule. Its developers need traceable agreement; an isolated label correction would need less structure.

## How: work toward a solution

Specify when a released seat goes to the waitlist, plan the boundary, and link implementation tasks to that rule. Check the code against the artifacts and resolve gaps. Reuse confirmed answers.

## What: the concept

Spec Kit provides agent workflows, templates, and setup tools for specification-driven development. It also offers optional repair and idea-assessment processes. Choose by coordination and risk; size alone does not justify installation.

[Source](https://github.github.io/spec-kit/quickstart.html)

---

# Go further

Optional reading · separate from the overview

## Selection & comparison

This example prioritizes a shared rule that affects booking and notification work. Spec Kit carries requirements through planning, tasks, implementation, and convergence. Starting without extra skills may fit adequate existing practices. Superpowers emphasizes repeatable development skills; OpenSpec records current requirements and change deltas. These tools can overlap or combine, but one artifact set should own each plan, task list, and requirement. No package guarantees assistant compliance.

## Applications

The example rule is: after a cancellation, notify the next eligible fan before offering the seat publicly. Record eligibility and timeout decisions rather than inventing them. Review the specification, technical plan, and tasks; map checks to the agreed rule. Convergence inspects implementation against those artifacts and may add remaining tasks. A small access-control change can merit this discipline even with few files.

## Implementation & cautions

In the external agent, inspect the current runtime, installed Spec Kit, project files, and official installation guide. Select the supported integration for that agent; reuse an existing installation. With installation authority, install the reviewed release and initialize the intended project scope, then inspect generated files and invocation support. Terminal setup and agent skill invocation are separate. In Codex the skills use names such as `$speckit-specify`; confirm the installed form. Existing-project initialization can replace conflicting managed files, so preserve local work and review the diff. Begin implementation only within approved scope. Reuse its specification, plan, and tasks for kickoff’s records rather than maintaining duplicate plans.

## Evidence

- [Spec Kit SDD quickstart](https://github.github.io/spec-kit/quickstart.html) — Specifications, plans, tasks, implementation, and convergence form the SDD workflow; optional quality gates are available. (Checked: 2026-10-08)
- [Spec Kit installation](https://github.github.io/spec-kit/installation.html) — Installation and project initialization have runtime and integration requirements and are separate from agent invocation. (Checked: 2026-10-08)
- [Spec Kit integrations](https://github.github.io/spec-kit/reference/integrations.html) — Invocation syntax and installed locations depend on the selected agent integration. (Checked: 2026-10-08)
- [Spec Kit existing projects](https://github.github.io/spec-kit/guides/existing-projects.html) — Initialization in an existing project may replace conflicting managed paths and should start from a reviewable baseline. (Checked: 2026-10-08)
- [Spec Kit README](https://github.com/github/spec-kit) — SDD, bug repair, and idea assessment are separate entry points; the latter two are opt-in extensions. (Checked: 2026-10-08)