📝

Spec Kitのコマンド備忘録

に公開

Spec Kit の使い方

Spec Kitは、構造化された開発ワークフローを提供するAIコーディングエージェントのためのツールセットです。
specify initを実行すると、以下のスラッシュコマンドが利用可能になります。
コマンドの順番や意味を毎回忘れてしまうので、備忘としてまとめています。

コアコマンド

コマンド 説明
/speckit.constitution プロジェクトの原則と開発ガイドラインを作成または更新(通常はプロジェクト開始時に1回作成し、その後は必要に応じて更新)
/speckit.specify 構築したいものを定義(要件とユーザーストーリー)
/speckit.plan 選択した技術スタックで技術実装計画を作成
/speckit.tasks 実装のための実行可能なタスクリストを生成
/speckit.implement 計画に従ってすべてのタスクを実行し、機能を構築

オプションコマンド

品質向上と検証のための追加コマンド:

コマンド 説明
/speckit.clarify 未指定の領域を明確化(/speckit.planの前に実行することを推奨。旧/quizme
/speckit.analyze 成果物間の一貫性と網羅性の分析(/speckit.tasksの後、/speckit.implementの前に実行)
/speckit.checklist 要件の完全性、明確性、一貫性を検証するカスタム品質チェックリストを生成(例:「英語のユニットテスト」)

推奨ワークフロー

プロジェクト全体の初期設定

  1. 初期設定: /speckit.constitution でプロジェクトの原則を定義
    • : 通常はプロジェクト開始時に1回実行して作成します
    • プロジェクトの原則や開発ガイドラインを変更する必要がある場合は、再度実行して更新できます
    • バージョン管理されており、変更時にはバージョン番号が自動的に更新されます

要件ごとの開発サイクル(繰り返し実行)

各フィーチャー/要件ごとに以下のコマンドを順番に実行します:

  1. 要件定義: /speckit.specify でビルドしたいものを定義
  2. 明確化: /speckit.clarify で不明確な点を明確化(オプション)
  3. 計画作成: /speckit.plan で技術実装計画を作成
  4. タスク生成: /speckit.tasks で実行可能なタスクリストを生成
  5. 分析: /speckit.analyze で一貫性と網羅性を確認(オプション)
  6. 実装: /speckit.implement でタスクを実行し、機能を構築

重要: ステップ2〜7は、新しいフィーチャーや要件ごとに繰り返し実行します。各要件は独立したディレクトリ(例: requirements/0000_initial-mvp/)に整理され、そのディレクトリ内でplan.mdtasks.mdなどの成果物が生成されます。

ワークフローチャート

以下のMermaidチャートは、Spec Kitのコマンド使用順序を可視化しています:

凡例:

  • 🟣 紫色: プロジェクト全体で1回のみ実行(/speckit.constitution
  • 🟢 緑色: 要件ごとのコアコマンド(必須)- 各要件に対して実行
  • 🟠 橙色: 要件ごとのオプションコマンド(推奨)
  • 🔵 青色(破線): 任意のタイミングで使用可能なコマンド
  • ⬜ 灰色: ループ判定(要件の繰り返し処理)

おまけ:日本語での生成方法

CLAUDE.mdなど、AIへの指示に追加することで日本語での出力を矯正することができます。

### Language Requirements

**CRITICAL**: All SpecKit command outputs (`/speckit.specify`, `/speckit.plan`, `/speckit.tasks`, `/speckit.analyze`, etc.) **MUST be generated in Japanese**. This includes:
- All generated markdown files (spec.md, plan.md, tasks.md, research.md, data-model.md)
- All analysis reports and recommendations
- All task descriptions and acceptance criteria
- All error messages and validation feedback

When generating specifications and plans, use natural Japanese business/technical writing. Code comments and OpenAPI schemas should remain in English for technical compatibility.

Discussion