GitHubの「Spec Kit」を試してみた ─ 仕様駆動開発で始める新しい開発フロー

curl -LsSf <https://astral.sh/uv/install.sh> | sh

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 新規で作成
specify init <PROJECT_NAME>

# 既存プロジェクトで作成
$ specify init --here

# 自動で設定されるgitの設定を無視したい場合
$ specify init <project-name> --no-git

-- セキュリティ --
プロジェクトの準備が整いました。一部のエージェントは、プロジェクト内のエージェントフォルダに認証情報、認証トークン、その他の識別情報や秘密の成果物を保存する場合があります。
認証情報の漏洩を防ぐために、.github/（またはその一部）を .gitignore に追加することを検討してください。

--- 次のステップ --
1. プロジェクトフォルダへ移動: cd speckit-project │
2. AIエージェントでスラッシュコマンドを使い始めましょう: │
   2.1 /constitution - プロジェクトの原則を確立 │
   2.2 /specify - ベースライン仕様を作成 │
   2.3 /plan - 実装計画を作成 │
   2.4 /tasks - 実行可能なタスクを生成 │
   2.5 /implement - 実装を実行 │

 --- 拡張コマンド --
 ○ /clarify（任意） - 曖昧な部分をリスク回避するための構造化された質問を行う（使用する場合は /plan の前に実行）
 ○ /analyze（任意） - 成果物間の一貫性と整合性のレポートを生成（/tasks の後、/implement の前に実行）

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

tree -a -I '.git|node_modules' -L 4
.
├── .github
│   └── prompts # プロンプト
│       ├── analyze.prompt.md
│       ├── clarify.prompt.md
│       ├── constitution.prompt.md
│       ├── implement.prompt.md
│       ├── plan.prompt.md
│       ├── specify.prompt.md
│       └── tasks.prompt.md
└── .specify
    ├── memory # AI の行動規範を定義
    │   └── constitution.md
    ├── scripts
    │   └── bash # プロジェクト運営の自動化スクリプト
    │       ├── check-prerequisites.sh
    │       ├── common.sh
    │       ├── create-new-feature.sh
    │       ├── setup-plan.sh
    │       └── update-agent-context.sh
    └── templates # 仕様・計画・タスクを文書化するための雛形
        ├── agent-file-template.md
        ├── plan-template.md
        ├── spec-template.md
        └── tasks-template.md

/constitution コード品質、テスト標準、UX、パフォーマンス要件、セキュリティ、ドキュメント整備の原則の作成

1. コード品質
- すべてのコードは、定められたスタイルガイドとリンティングルールに従うこと。
- すべてのプルリクエストにはコードレビューを必須とする。
- 可読性と拡張性を維持するため、必要に応じてリファクタリングを優先する。

2. テスト基準
- 各機能には、エッジケースを含むユニットテストを必ず実装する。
- 重要な処理フローには統合テストを実施する。
- コアモジュールのテストカバレッジは常に85%以上を維持する。

3. UXの一貫性
- UIは共通のデザインシステムに準拠すること。
- アクセシビリティ基準（WCAG 2.1 AA以上）を必ず満たす。
- リリース前にクロスデバイス・クロスブラウザの動作検証を行う。

4. パフォーマンス要件
- ページの読み込み時間は標準的なデバイスで2秒以内を目標とする。
- API応答時間は通常負荷下で300ms以内を目標とする。
- 各スプリントごとにパフォーマンス監査を実施する。

5. セキュリティ
- すべての依存ライブラリは定期的に更新し、脆弱性をチェックする。
- 機密情報（APIキー、パスワードなど）はコードベースに含めない。
- OWASP Top 10を意識したセキュリティレビューを行う。

6. ドキュメント整備
- 日本語で記載する。
- 新機能や重要な変更点には、必ず開発者向けドキュメントを更新する。
- README・セットアップ手順・API仕様は常に最新状態を維持する。
- ユーザー向けガイドやチュートリアルはリリースと同時に公開・更新する。

/specify シンプルなリアルタイムチャットの作成

1. 認証システム
- Google アカウントでログイン
- 自動ユーザー情報同期
- セッション管理

2. リアルタイムチャット
- 即座のメッセージ送受信
- WebSocket による双方向通信
- 30分間のメッセージ履歴
- 自動メッセージクリーンアップ（30分経過後）

3. ユーザビリティ機能
- PC、スマホを配慮
- 入力中表示（タイピングインジケーター）
- オンライン参加者一覧（アイコン表示）
- 100文字制限＋文字数カウンター
- Enter キーでの送信、Shift+Enter での改行
- 色はモノクロでコントラスを高めに
- テキストは全ての環境で見えやすい大きさに
- レスポンシブデザイン

4. パフォーマンス＆保守性
- Error Boundary によるエラーハンドリング

未確定事項（Clarification 必須）

- タイピングインジケーター消去までの X 秒（提案: 3 秒維持後フェードアウト）
- タイピングイベント送信スロットル間隔（提案: 500ms）
- 再接続時一括同期の最大メッセージ件数（提案: 200 件）
- 重複メッセージ（内容・タイムスタンプ近接）の抑制要/不要（現行は許容設計）
- 複数タブ/複数デバイス同時接続の扱い（PresenceSession モデル 1:1 制約を緩めるか）
- オフライン復帰時のバッチサイズ上限（提案: 200 件 or 30 分期間内全件）

/clarify 仕様の不足、不明点の確認

Presence（在席）判定のためのハートビート間隔とタイムアウト閾値を選んでください。
(定義: クライアントは一定間隔で heartbeat を送信。サーバは最終受信時刻との差分が閾値を超えたら「離脱」とみなす)

Option	Description
A	10s 間隔 / 25s で離脱 (2連続欠損＋猶予)
B	15s 間隔 / 45s で離脱 (3連続欠損)
C	5s 間隔 / 15s で離脱 (3連続欠損) / 反応性優先
D	8s 間隔 / 24s で離脱 (3連続欠損, 中庸)
E	Short

これ以上 Clarification は上限到達のため終了です。
次ステップとして /plan 実行を推奨します。進めてよければ「/plan 実行」や「plan」と返信してください。

/plan 技術スタックは以下を採用

- フロントエンド：Next.js 15 (App Router)
- スタイリング：TailwindCSS
- 状態管理：Zustand
- 認証：Clerk (Google OAuth)
- バックエンド、データベース：Convex (リアルタイムデータベース)
- Typeセーフティ: TypeScript
- 単体テスト: Vitest
- UIテスト: React Testing Library

.
├── contracts # 各モジュール・エージェント間の通信仕様を格納
│   ├── heartbeat.json # システムの生存確認やヘルスチェック用の通信仕様。エージェントが動作しているか確認
│   ├── message.json # 一般的なメッセージ送受信の仕様。送信者・受信者・本文・タイムスタンプなどを定義
│   ├── presence.json # エージェントの「オンライン／オフライン」状態など、プレゼンス情報を扱う契約
│   └── typing.json # 「入力中（typing）」などリアルタイムな状態を通知する契約。チャットや共同編集系で利用
├── data-model.md # データ構造・スキーマ定義
├── plan.md # 実装計画・進行方針
├── quickstart.md # 初期セットアップガイド
├── research.md # 調査・検討記録
└── spec.md # 2. 仕様の作成：`/specify` で生成

/tasks

## Phase 3.1: Setup
- [ ] T001 Initialize project manifest & tooling (Node 22.16.0 via .nvmrc, package.json with Next.js 15.5.4, React 19, TypeScript, Tailwind, shadcn/ui, Zustand, Convex, Clerk, ESLint, Prettier, Vitest, React Testing Library). Files: `.nvmrc`, `package.json`, `.eslintrc.cjs`, `tsconfig.json`, `vitest.config.ts`, `.prettierrc`.
- [ ] T002 Configure Tailwind & shadcn/ui (generate config, add base styles). Files: `tailwind.config.ts`, `postcss.config.js`, `app/globals.css`.

/analyze

A) 今すぐ修正タスクを実装する（推奨：コーディング前）
B) 現在のタスクをそのまま進める（リスク：「全ての機能テスト」ゲートを満たせない可能性あり）

logging.md # 新規追加
spec.md # 更新
tasks.md # 更新

/implement

/implement Phase 3.1: Setup
/implement contract の拡張 (T064, T069)
/implement T012 → (並行) T013, T014, T015, T016, T017, T018 を順次追加
/implement T060 群の追加
/implement 残りのリメディエーション系統合テスト骨組み追加 (T060–T068) も先に failing で用意

## Phase 3.1: Setup
- [x] T001 Initialize project manifest & tooling (Node 22.16.0 via .nvmrc, package.json with Next.js 15.5.4, React 19, TypeScript, Tailwind, shadcn/ui, Zustand, Convex, Clerk, ESLint, Prettier, Vitest, React Testing Library). Files: `.nvmrc`, `package.json`, `.eslintrc.cjs`, `tsconfig.json`, `vitest.config.ts`, `.prettierrc`.
- [x] T002 Configure Tailwind & shadcn/ui (generate config, add base styles). Files: `tailwind.config.ts`, `postcss.config.js`, `app/globals.css`.