Grill → Issue → SpecKit: 仕様を先に確定してから実装する開発手法

Claude Code はリクエストされた瞬間に実装を始めようとする。その結果、用語の解釈がずれたまま実装が進み、完成後に「それじゃなかった」が発生して手戻りが生まれる。このワークフローは「仕様の確定」を実装の必須前工程として強制する。

As-Is と To-Be

😩 As-Is（現状）

💬 「〇〇を実装して」

↓ 即座に

🤖 Claude が解釈して実装開始

↓ 完成後に発覚

❌ 「それじゃなかった」

↓ 繰り返す

🔁 やり直し・手戻り

根本問題: 「何を作るか」が曖昧なまま「どう作るか」に入る

✅ To-Be（このワークフロー）

💬 「〇〇を実装して」

↓ まず

📋 GitHub Issue で目的を確立

↓ 次に

🔍 Grill で用語・スコープを合意

↓ それから

📄 仕様書作成 → 人間が承認

↓ ようやく

🚀 実装（仕様通りに一発で完成）

改善の本質: 「何を作るか」を先に合意してから「どう作るか」に入る

1. アクター一覧

このワークフローに登場する人・ツール・システムの一覧。

👤

Human（開発者）

要件を提示し、Grill の質問に回答し、仕様書を承認する。意思決定はすべて人間が行う。Claude は提案するだけ。

判断承認回答

🤖

Claude Code

スキルを実行し、質問を生成し、仕様書・コードを出力する AI。スキル（Grill・SpecKit）を組み合わせて動作する。

質問生成仕様書作成実装

🔍

Grill スキル

/fj-s-grill-with-docs で起動。Claude に面接官ロールを与え、1問1答で要件・用語・スコープを確定させるスキル。

Stage 2 で使用

📐

GitHub Spec Kit

/speckit-* コマンド群。specify CLI を使って仕様書を段階的に生成し、人間の承認を経て実装まで進める SDD フレームワーク。

Stage 3 で使用

🐙

GitHub（Issues / PR）

作業の目的・追跡・完了を管理する外部システム。Issue にコミットを紐付けることで変更の背景が永続的に残る。

Step 1 で登録実装完了でクローズ

📁

ローカルリポジトリ

CONTEXT.md・docs/adr/・specs/・Git 履歴を保持するリポジトリ。仕様・設計・実装の「なぜ」がすべてここに残る。

プロジェクト共有資産

2. システム構成図

アクター・スキル・データストアの関係を示す。

アクター層

👤 Human

🤖 Claude Code

↓ 呼び出し

スキル層

🔍 Grill
/fj-s-grill-with-docs

/speckit-specify

/speckit-plan

/speckit-tasks

/speckit-implement

↓ 読み書き

データストア層

🐙 GitHub Issues

📖 CONTEXT.md

🏛️ docs/adr/

📄 specs/N/

💻 Git commits

参照関係: Grill は CONTEXT.md・docs/adr/ を読み込んでから質問を開始する。既存の設計判断と矛盾する提案を検知するため。
SpecKit の各コマンドは前段階の出力（specify.md → plan.md → tasks.md）を読み継ぎながら次の文書を生成する。

3. 作業フロー

📋

Step 1

GitHub Issue 登録

gh issue create で目的・スコープを記録

👤 Human が実行

↓

🔍

Stage 2

Grill with Docs

/fj-s-grill-with-docs を実行 → 1問1答で用語・スコープを確定

👤 Human が回答 → CONTEXT.md・ADR へ

↓

📐

Stage 3 — ① 仕様化

specify → plan → tasks

Claude が仕様書を段階的に生成

→ specs/N/ へ

↓

⛔

承認ゲート

Human が tasks.md をレビュー

ここを通過しないと実装に入れない

👤 Human が承認

↓ 承認後

🚀

Stage 3 — ② 実装

speckit-implement

tasks.md に沿って実装 → Git commits → Issue クローズ

4. シーケンス図

時系列で Human・Claude Code・データストアの間でどんなやり取りが起きるかを示す。

👤 Human

🤖 Claude Code

📁 Data Stores

STEP 1 — Issue 登録

gh issue create
目的・スコープを記入

—

→ GitHub Issues #N 作成

STAGE 2 — Grill with Docs

/fj-s-grill-with-docs

← スキル起動、CONTEXT.md・ADR を読み込み

CONTEXT.md / ADR を参照

← 「account は Customer・User どちら？」

質問を生成（1問1答）

—

「Customer です」 →

回答を評価・記録

→ CONTEXT.md 更新

… 繰り返し …

… 追記 …

合意完了 →

設計判断があれば ADR を提案

→ docs/adr/ 作成（任意）

STAGE 3 — ① 仕様化

/speckit-specify →

要件定義を生成

→ specs/N/specify.md

/speckit-plan →

技術設計を生成

→ specs/N/plan.md

/speckit-tasks →

タスクリストを生成

→ specs/N/tasks.md

⛔ 承認ゲート（Human のみ通過できる）

← tasks.md をレビュー

待機

—

✅ 承認 →

実装フェーズへ移行

—

STAGE 3 — ② 実装

/speckit-implement →

tasks.md を順に処理・実装

→ Git commits (#N)

—

PR マージ後に Issue を参照

→ Issue #N クローズ

各ステップの詳細

Step 1: GitHub Issue 登録

Issue を作らずに作業を始めると、後から「なぜその変更をしたか」が追跡できなくなる。

Issue なしの場合

✗コミット履歴だけ残り「なぜ変えたか」が不明

✗スコープが曖昧で作業が広がりやすい

✗レビューのたびに文脈を毎回説明する

Issue ありの場合

✓コミットに #N を付けて自動リンク

✓Issue 本文でスコープの境界が明確

✓未来の自分・チームが経緯を辿れる

gh issue create --title "タイトル" --body "内容"

Stage 2: Grill with Docs

Claude が面接官となり、実装前に1問1答で仕様の曖昧さを排除する。CONTEXT.md・ADR を先に読み込んでから質問するため、既存の設計判断との矛盾を検知できる。

ADR を作成する3条件（すべてを満たす場合のみ）：

後で変更するコストが大きい
将来の読者が「なぜこうしたのか？」と疑問に思う
具体的な代替案があり、理由を持って選択した

Stage 3: GitHub Spec Kit

/speckit-specify → 「何を・なぜ・どの範囲で」を文書化

↓

/speckit-plan → 変更対象ファイル・アーキテクチャを設計

↓

/speckit-tasks → 1コミット単位のチェックリストに分解

↓

👤

⛔ 承認ゲート → Human が tasks.md を確認・承認

↓

/speckit-implement → チェックボックスを順に処理して実装

生成されるファイル構造

project/
├── CONTEXT.md              # ドメイン用語集（Grill が管理・継続更新）
├── docs/adr/
│   └── 0001-*.md           # 設計判断の記録（条件を満たす場合のみ）
├── specs/
│   └── <n>-<feature>/
│       ├── specify.md      # 要件定義
│       ├── plan.md         # 技術設計
│       └── tasks.md        # 実装チェックリスト
└── .claude/
    └── CLAUDE.md           # ワークフロー必須ルール

このワークフローの導入方法

新しいプロジェクトへの導入は /fj-s-grill-speckit-onboarding スキルが一括で行う：

specify init を実行
.claude/CLAUDE.md にワークフロールールを追記
CONTEXT.md のスタブを作成

Claude Code でこのスキルを呼び出すだけで、プロジェクトがこのワークフローに対応した状態になる。