spec-impl について
spec-impl は、リポジトリ内の承認済み仕様を段階的に実装するスキルです。仕様の状態を確認し、設定に応じてブランチを扱い、各実装ステップの後にレビューを待ちます。
主な機能
- 01番号・slug・完全名で仕様を検索
- 02仕様が承認済みであることを確認
- 03設定に応じたブランチの作成・切り替え
- 04範囲・計画・受け入れ条件の整理
- 05各ステップ後にレビューを待機
活用シーン
- 01承認済み機能仕様の実装
- 02既存の仕様ブランチで作業を再開
- 03計画した変更を段階的にレビュー
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/spec-implを入力して読み込まれたか確認します。
詳細
/spec-impl — 承認済み仕様の実装者
セッションコンテキスト
現在のリポジトリの状態：
!git status --short
現在のブランチ：
!git branch --show-current
このフォルダーで利用可能な仕様：
!ls specs/ 2>/dev/null || echo "The specs/ folder does not exist"
ブランチ作成の設定：
!cat specs/.spec-config.yml 2>/dev/null || echo "AutoCreateBranch: true (default, no config file)"
手順
次の4つのフェーズを、必ずこの順序で実行してください。前のフェーズが正しく完了していない場合は、次のフェーズに進まないでください。
フェーズ1 — 仕様を特定する
受け取った引数は次のとおりです：$ARGUMENTS
$ARGUMENTS が空の場合：
specs/で利用可能なファイルを一覧表示します（上記ですでに確認済みです）。- 仕様の正確な名前を指定するようユーザーに尋ねます。
- 停止して回答を待ちます。先に進まないでください。
$ARGUMENTS に値がある場合：
specs/内のファイルを探します。ユーザーは完全な名前（01-mvp-arkanoid）、番号のみ（01）、またはスラッグのみ（mvp-arkanoid）を入力している可能性があります。いずれの場合も、正しいファイルを探してください。- ファイルが見つからない場合は、利用可能な仕様を表示して、名前を修正するようユーザーに尋ねます。
- 見つかった場合は、フェーズ2に進みます。
フェーズ2 — 仕様の状態を検証する
フェーズ1で特定した仕様ファイルを、Read ツールまたは cat を使って読み込みます。
ファイルの内容から、仕様の状態を示す行を探します。ヘッダーラベルは通常 **Status:**（英語）または **Estado:**（スペイン語）ですが、ほかの言語の場合もあります。正確なラベルだけで判断せず、仕様の上部にある状態行の位置と、周囲の状態遷移を手がかりにしてください。
絶対ルール： 状態が「承認済み」を意味する場合にのみ続行できます。使用言語は問いません。
次のいずれか（およびほかの言語での同等表現）を「承認済み」状態として扱い、続行してください。
- 英語：
Approved - スペイン語：
Aprobado - ポルトガル語：
Aprovado - フランス語：
Approuvé - ドイツ語：
Genehmigt - イタリア語：
Approvato - …または、ほかの言語で明らかに「承認済み」を意味する語
それ以外（Draft / Borrador、In review / En revisión、Implemented / Implementado、Obsolete / Obsoleto、または認識できない値）はすべて、停止して以下のエラーメッセージを表示してください。
| 状態カテゴリ | 例（言語は問いません） | 対応 |
|---|---|---|
| 承認済み | Approved、Aprobado、Aprovado、Approuvé、… | フェーズ3に進みます。 |
| ドラフト | Draft、Borrador、… | 停止します。以下のエラーメッセージを表示します。 |
| レビュー中 | In review、En revisión、… | 停止します。以下のエラーメッセージを表示します。 |
| 実装済み | Implemented、Implementado、… | 停止します。以下のエラーメッセージを表示します。 |
| 廃止済み | Obsolete、Obsoleto、… | 停止します。以下のエラーメッセージを表示します。 |
| 状態行がない／認識できない値 | — | 停止します。ファイルが想定される形式に従っていないことをユーザーに伝えます。 |
値が「承認済み」を意味するかどうか判断できない場合は、そうだと決めつけないでください。停止して、ユーザーに確認するか、仕様を正式な表記に更新するよう依頼してください。
状態が「承認済み」を意味しない場合の標準エラーメッセージ：
❌ I cannot implement this spec.
Current state: [STATE FOUND]
I only work with specs whose state means "Approved" (e.g. `Approved`, `Aprobado`,
or the equivalent in another language).
To continue you have two options:
1. If the spec is ready to be implemented, open it and change the state
to "Approved" (or the equivalent term your team uses) manually.
That change is made by the human, not the agent.
2. If the spec still needs work, use /spec [name] to resume it.
別の方法を提示したり、「希望があればそれでも開始できます」と提案したりしないでください。このブロックは意図的なものです。
フェーズ 3 — git ブランチを作成して切り替える
状態が Approved であることを確認したら：
-
まず作業ツリーを確認します。 上のセッションコンテキストにある
git status --shortの出力を確認します。空でない場合は、そこで止まり、保留中の変更を表示してから、次のように尋ねます。⚠️ There are uncommitted changes in the working tree. Switching branches would carry them over. What do you want to do? 1. Commit or stash them yourself, then re-run this command (recommended) 2. Continue anyway — the changes travel to the new branch回答を待ちます。ユーザーが明示的に依頼しない限り、ユーザーに代わって stash やコミットを行わないでください。作業ツリーがクリーンな場合は、そのことに触れず、手順 1 に進みます。
-
拡張子を除いた仕様ファイルの完全な名前から、ブランチ名を導き出します。形式：
spec-NN-slug。例：01-mvp-arkanoid.md→ ブランチspec-01-mvp-arkanoid02-powerups.md→ ブランチspec-02-powerups
-
上のセッションコンテキストに示された ブランチ作成設定 から
AutoCreateBranchフラグを読み取ります。- 設定ファイルが存在しない場合、値がない場合、または値が認識できない場合は、
true（デフォルト）として扱います。 - 明示的に
false（大文字・小文字は問いません）と指定されている場合のみ、自動ブランチ作成を無効にします。
AutoCreateBranchがtrue（デフォルト）の場合： 尋ねずに進めます。- ブランチが存在しない場合：
git checkout -b spec-NN-slugで作成します。 - ブランチがすでに存在する場合：以前の作業を再開していることを意味します。そのブランチに切り替え、ブランチ上で
git log --onelineを読み取り、計画のどの手順が完了しているように見えるか、どの手順から再開することを提案するかをユーザーに伝えます。実装を始める前に、再開する箇所について確認を待ちます。 - どちらの場合も、
git checkout spec-NN-slugでブランチに切り替え、続行する前に切り替えが成功したことを確認します。
AutoCreateBranchがfalseの場合： git に触れる前に尋ねます。次のように表示します。AutoCreateBranch is set to false. Create and switch to the branch spec-NN-slug? [y/N]- ユーザーがはいと回答した場合：
trueの場合と同じ手順でブランチを作成／切り替えます。 - ユーザーがいいえと回答した場合、または空欄のままの場合：ブランチを作成しません。 上のセッションコンテキストに表示された現在のブランチで実装すると伝え、そのブランチで続行することへの明示的な確認を求めます。勝手に判断せず、回答を待ちます。
- 設定ファイルが存在しない場合、値がない場合、または値が認識できない場合は、
-
仕様の準備ができていることと、現在のブランチをユーザーに目で見て確認できる形で伝えます。
✅ Ready to implement. Spec: specs/NN-slug.md Branch: spec-NN-slug (active) (← or the current branch, if no new branch was created) State: Approved (← echo back the actual value found in the spec) -
まだ実装を始めないでください。 まず、内容を把握しやすいよう仕様の概要をユーザーに示します。次の項目を抽出して表示します。
- 目的（
**Objective:**／**Objetivo:**／同等のラベルの次の行）。 - スコープ（
## Scope／## Alcance／同等のセクション）。 - 実装計画（番号付き手順のあるセクション：
## Implementation plan／## Plan de implementación／同等のセクション）。 - 受け入れ条件（チェックリスト：
## Acceptance criteria／## Criterios de aceptación／同等のセクション）。
- 目的（
セクション見出しは、完全に同じ文言かどうかではなく、意味に基づいて特定してください。仕様はどの言語で書かれていてもかまいません。
フェーズ 4 — ステップごとに実装する
仕様の概要を表示した後、ユーザーに次のように伝えます。
I am going to implement the spec following the implementation plan exactly.
I will pause after each step so you can review the diff.
Shall we start with Step 1?
明示的な確認（「yes」「go ahead」「go」または同等の返答）を待ちます。確認を得る前に開始してはいけません。
確認を得たら、実装全体を通して次のルールに従います。
自動でコミットしてはいけません。 ステップごとにも、最後にもコミットしてはいけません。コードを書いて差分を表示します。コミットするかどうかはユーザーが決め、ユーザーがコマンドを実行します。ユーザーから明示的に依頼された場合に限り、コミットしてください。
何よりも優先するルール：仕様に記載された内容を実装します。 仕様に最適でないと思われる点があれば、所見として伝えますが、合意された内容を実装します。仕様の変更は仕様に反映し、予告なくコードを変更してはいけません。
作業の進め方：
- 計画のステップを1つ実装します。
- 変更したファイルと実施内容の概要を表示します。
- 次のように伝えます：
Step N completed. Could you review the diff and let me know if I continue with Step N+1? - 続ける前に確認を待ちます。
実装中に仕様で解決されていない曖昧な点が見つかった場合：
- 作業を止めます。
- 曖昧な点を正確に説明します。
- 具体的な選択肢を2つまたは3つ提示します。
- ユーザーの決定を待ちます。
- 独自に判断して進めてはいけません。
ユーザーから仕様の範囲外の依頼があった場合：
- その依頼がこの仕様の範囲外であることを伝えます。
- 次の仕様に記録することを提案します。
- このブランチでは実装してはいけません。
最後のステップを終えるとき：
✅ All steps of the plan are implemented.
Next step: verify the spec's acceptance criteria one by one.
If they all pass, update the spec's state to "Implemented" (or the equivalent
in your repo's language) and make the final commit before merging this branch.
期待される動作の概要
/spec-impl 01-mvp-arkanoid
Phase 1 → Finds specs/01-mvp-arkanoid.md
Phase 2 → Reads the state → "Approved" (or "Aprobado", etc.) → ✅ continues
Phase 3 → git checkout -b spec-01-mvp-arkanoid → git checkout spec-01-mvp-arkanoid
Shows objective, scope, plan and criteria
Phase 4 → Implements step by step with pauses
Ends by reminding to verify the acceptance criteria
/spec-impl 02-powerups (state: Draft / Borrador)
Phase 1 → Finds specs/02-powerups.md
Phase 2 → Reads the state → "Draft" → ❌ stops
Shows the standard error message
Does not create branch, does not touch code
ブランチの作成は、specs/.spec-config.yml の AutoCreateBranch フラグで制御されます。 デフォルトは true です（上記のとおり、ブランチを自動的に作成します）。false に設定すると、フェーズ 3 でブランチの作成前に [y/N] を確認します。