| name | adr-ship |
| description | This skill should be used when the user wants to "implement an ADR", "ADRを実装して", "ADR-012 を実装して", "ADR-012 を完了させて", "受け入れ条件を満たすまで実装して", "受け入れ条件を検証して修正して", "adr-ship", or provides an ADR number/name to implement. Runs the implement→verify→fix loop for a specific ADR until all acceptance criteria in docs/issues.md pass. |
| version | 0.1.0 |
adr-ship
指定された ADR を読み込み、受け入れ条件をすべて満たすまで「実装 → 検証 → 修正」のループを回す。
目的
- ADR に定義された設計を実装し、
docs/issues.md の受け入れ条件を自動検証する
- 条件未達の場合は修正して再検証することでサイクルを自動化する
- 完了時に ADR・issues.md のステータスを更新してコミットする
ステップ
Step 1: ADR の特定
args が指定されている場合（例: ADR-012、012、12）
- 番号を3桁にゼロ埋めして
$PWD/docs/adr/NNN-*.md を Glob で特定する
- 該当ファイルが存在しない場合はエラーを報告して終了する
- ADR ファイルの
## ステータス が Spike中 または Spike完了 の場合は以下のメッセージを表示して終了する：
「ADR-NNN は Spike中/Spike完了 ステータスです。Spike ADR は adr-ship の対象外です。
設計を確定させる場合は create-adr で新 ADR を作成してください。」
args が空の場合
$PWD/docs/adr/*.md を Glob で全ファイル取得- 各ファイルを Read して
## ステータス セクションが Draft のものを抽出
- Draft ADR が0件の場合は「実装対象の Draft ADR が見つかりません」と報告して終了
- AskUserQuestion で「実装する ADR を選んでください」と番号・タイトルの一覧を提示
Step 2: コンテキスト収集（並列実行）
以下を並列で実行する：
- ADR ファイルを Read し、
## コンテキスト・## 設計案・## 決定 セクションの内容を把握する
$PWD/docs/issues.md を Read して該当 ADR セクション（ADR-NNN への言及がある箇所）の受け入れ条件（- [ ] 行）を抽出する
受け入れ条件が見つからない場合は AskUserQuestion でユーザーに確認し、必要に応じて docs/issues.md に追記するか中断するかを選択させる。
Step 3: 実装
3-1: 実装方針の確定
ADR には設計の合意が既に記録されているため、Plan Mode は使用しない。
## 決定 が空または （未定） かつ ## 設計案 に複数案が列挙されている場合のみ、AskUserQuestion でユーザーに案を選択させる- それ以外は
## 決定（または ## 設計案）の内容をそのまま実装方針とする
- 実装タスクを 独立して並列実行できる単位 に分割し、依存関係を整理する
- 例: 「設定ファイル A の追加」「設定ファイル B の追加」は並列 / 「シンボリックリンク作成」は A・B の完了後
- ファイル削除が含まれる場合は削除対象を設計案から特定して
git rm を使用する
- 設計に「移動」操作が含まれる場合、移動元の削除タスクと移動先の作成タスクが両方含まれていることを確認する
3-2: 並列実装
3-1 で策定した計画に従い、独立したタスクを並列実行する：
- タスクが 4 件未満: 複数の Edit / Write / Bash ツールを同一メッセージで並列呼び出しする（TeamCreate 不要）
- タスクが 4 件以上かつ独立: TeamCreate で agent team を編成して並列実行する
- 各 agent に担当タスクと操作対象ファイルを明示して割り当てる
- 依存関係のあるタスクは前段の agent 完了後に次の agent を起動する
- 実装は
$PWD 配下のファイルのみを対象とする
Step 4: 受け入れ条件の検証ループ
4-0: 設計完全性チェック（subagent）
受け入れ条件の検証前に、subagent（subagent_type=Explore）を起動して設計の実装漏れを確認する。
subagent への指示内容:
- ADR の
## 設計案 / ## 決定 / 変更が必要なファイル テーブルを読み取る
- 各行の意図（作成・削除・移動・修正）に対して実際のファイル状態を確認する
- 移動: 移動元が削除済み かつ 移動先が存在する — 両方を確認
- 削除:
git ls-files に含まれない
- 新規作成: ファイルが存在する
- 修正: 設計に記載の変更内容が反映されている
- 漏れがある場合は「何が・どのリポジトリで・どの操作が未完了か」を具体的に報告する
subagent が漏れを報告した場合は Step 3-2 に戻って修正する。漏れがなければ 4-1 へ進む。
4-1: 受け入れ条件の検証
以下のループを受け入れ条件がすべて満たされるまで繰り返す：
docs/issues.md の対応する受け入れ条件（- [ ] 行）を1つずつ検証する- 検証方法は条件の文言に応じて決定する
- ファイルの存在確認: Glob / Read
- コードの内容確認: Grep / Read
- 「動作する」「実行できる」「起動する」「配置できる」「作成される」などの文言を含む条件: Bash でテスト実行する
- setup script の実行など、システム状態を変える操作も検証に含めてよい（冪等なものに限る）
- ネットワーク通信を伴うコマンドは使用しない（aws, curl, terraform 等）
- 未達の条件があれば修正して Step 4 の先頭に戻る（最大 5 回まで）
- 5回試みても未達の条件が残る場合は AskUserQuestion でユーザーに確認する
- すべての条件が通過したらループ終了
Step 5: 完了処理
Step 4 のループ完了後にのみ以下を順番に実行する（Step 4 ループ中は一切変更しない）：
$PWD/docs/issues.md の該当 ADR の - [ ] をすべて - [x] に更新するdocs/issues.md のサマリ表で該当 ADR を含む行の「対応済み」列を - から ✔ に更新する
（1行に複数 ADR が記載されている場合は、その行の全 ADR が完了済みのときのみ ✔ に更新する）- ADR ファイルの
## ステータス を 採用済み に更新する
docs/reference.md の ADR 一覧セクションに新規 ADR のリンクを追記する（既にリンクが存在する場合はスキップ）- 変更ファイルを
git add してコミットする
コミットメッセージ:
feat: ADR-NNN 受け入れ条件を達成
（NNN は対象 ADR の番号）
制約
- 操作対象は常に
$PWD 配下（worktree 対応）
docs/issues.md の - [ ] → - [x] 更新と ADR ステータス更新は Step 5 でのみ行う（Step 4 ループ中は変更しない）- このリポジトリはリモートなしのため
git commit までで完了（git push・PR 作成は不要）
rm -rf は使用禁止。ファイル削除が必要な場合は git rm または rm（単体ファイル指定）を使用する
ユーザーが実装を先行させた場合の回復手順
ユーザーが adr-ship を通さず実装を完了させた後にこのスキルを呼び出した場合（「チェックを入れて」「Step 5 だけ実行して」など）:
- Step 2 でコンテキスト収集を行い、受け入れ条件を把握する
- Step 4 の検証ループを実行して条件の充足を確認する
- 検証が通れば Step 5 の完了処理を実行する（コミットまで）
- 検証が通らなければ Step 3-2 から修正実装を行う
