hirokisakabe Acceptance Check Skill
GitHub issue の ## 受け入れ条件 セクションを機械的に抽出し、各項目について自動検査を試みて結果をレポートする read-only skill。issue-driven cycle における「受け入れ条件確認」を skill 化し、抜け漏れを防ぐ。
スコープ
- 含む:
## 受け入れ条件セクションの抽出、各項目の自動検査、✓ / ✗ / ? 形式での結果報告。 - 含まない:
- 自動修正: failed 項目を自動で直さない。report のみに留める（scope creep 防止）。
- issue body / code の変更: 本 skill は完全に read-only であり、
gh issue editや code への書き込みは一切行わない。 - 動作確認 (verify-implementation): UI / CLI / library / config 等で検証方法が大きく異なるため、本 skill では扱わない。受け入れ条件項目ごとに「動作確認方法を提示する」ところまでは行うが、実際の動作確認は呼び出し側 (人間 or
issue-implementcycle) の責任とする。 ## 受け入れ条件以外のセクション検証: 検証可能な完了条件は## 受け入れ条件のみと定義されているため、背景・スコープ外等は対象外。
依存
ghCLI: issue 本文・コメント取得に使用する。Codex CLI 等の外部 AI ツールには依存しない。
入力
- issue 番号
- 結果コメントを条件として検査する場合:
--result-comment <コメント URL または ID>。issue-investigateが今回投稿した単一コメントを渡す。
実行手順
1. issue 本文とコメントの取得
ISSUE_NUMBER=<issue 番号>
gh issue view "$ISSUE_NUMBER" --json body,comments
2. ## 受け入れ条件 セクションの抽出
issue 本文から ## 受け入れ条件 の見出し以降〜次の ## 見出し直前までを取り出し、- [ ] または - [x] で始まるチェックリスト項目をすべて抽出する。
コメント完結型 issue では comments も検査根拠として保持する。--result-comment が渡された場合は URL または ID が一致する単一コメントを抽出し、その本文だけを今回の結果コメントとして扱う。本文のチェック状態は完了判定に使わず、各条件と repo 状態・指定コメントの実体を照合する。
結果コメントを要求する受け入れ条件があるのに --result-comment がない場合は、過去コメントを横断検索して推測せず ? とする。指定された URL / ID に一致するコメントがなければ ✗ とする。再投稿時は呼び出し側が新しい識別子を渡し、古い結果コメントと内容を合成しない。
該当セクションが存在しない、または空の場合は「受け入れ条件が定義されていない」旨を報告して終了する（フォーマット不備の可能性があるので、issue-refine skill での整理を案内してよい）。
3. 各項目の自動検査
抽出した各項目について、以下のいずれかの方法で検査を試みる。
| 検査タイプ | 例 | 手段 |
|---|---|---|
| file existence | 「packages/.../SKILL.md が追加されている」 |
test -f <path> |
| symlink existence | 「Stow で ~/.claude/skills/.../ にリンクされている」 |
test -L <path> / readlink |
| 文言チェック | 「SKILL.md に〜と明記されている」「〜の手順が追記されている」 |
grep / rg |
| command exit code | 「make help が成功する」 |
コマンド実行 + $? |
| issue comment | 「調査結果コメントに結論・根拠・検証内容がある」 | comments[].body の見出し・内容を照合 |
| 要人間判定 | 「呼び出し元 agent から認識される」「UI が崩れていない」など | 自動化困難な項目はマーク |
自動化困難の判断基準:
- 主観的評価（「使いやすい」「自然な挙動」等）
- 外部システム / ツールでの認識（呼び出し元 agent が skill を読み込めるか、IDE が拡張を認識するか等）
- ブラウザ・GUI での目視確認
- ユーザー対話を伴う動作確認
これらは ? (要人間判定) としてマークし、検査者（呼び出し側）に判断を委ねる。可能であれば「動作確認方法の提示」（例: 「呼び出し元 agent を再起動して /help で skill 一覧に現れるか確認」）も併記する。
コメントを検査する場合は、--result-comment で指定された単一コメントについて、要求された見出し（例: ## 調査結果、### 結論、### 根拠、### 検証内容、### Blocker、### 却下案、### 後続候補）と各見出し配下の内容を照合する。見出しや必須内容が明確に欠ければ ✗、存在はするが内容の妥当性が自動判定できなければ ? とする。コメントの編集やチェックリスト更新は行わない。
4. 結果報告
以下の形式で結果を出力する。
## 受け入れ条件チェック結果 (issue #<N>)
- ✓ <項目 1>
- 検査方法: <test -f / grep / ... の具体的内容>
- ✗ <項目 2>
- 検査方法: <内容>
- 失敗理由: <なぜ失敗したか>
- ? <項目 3> (要人間判定)
- 自動化困難な理由: <主観的 / 外部システム認識 / ...>
- 動作確認方法: <呼び出し側に提示する確認手順>
サマリー: ✓ <X> 件 / ✗ <Y> 件 / ? <Z> 件
✗ が 1 件でもある場合は、呼び出し側 (issue-implement cycle 等) に「受け入れ条件未達」として明示的に伝える。
利用タイミング
issue-implementcycle 内: 実装・commit 後、cross-reviewより前に呼び出す。✗がある場合は実装に戻り 追加 commit で修正する（履歴整形はしない）。?のみであれば呼び出し側で人間判定を経て進む。issue-investigatecycle 内: 構造化した結果コメントの投稿後、issue close より前に呼び出す。✗があれば調査またはコメントを補い、未解決の?があれば close しない。- 手動呼び出し: 実装完了後にユーザーが受け入れ条件のチェックを依頼した場合。
失敗時の対応
gh issue viewが失敗する（issue が存在しない / 認証エラー等）、またはコメントを取得できない場合は、その旨を報告して終了する。--result-commentの形式を解釈できない場合は入力エラーとして終了する。一致するコメントが取得結果にない場合は、結果コメント存在条件を✗として報告する。## 受け入れ条件セクションが空 / 存在しない場合は、issue-refineskill での整理を案内する。
やらないこと
- issue body や code への書き込み: 本 skill は read-only。チェックリストの
- [ ]を- [x]に書き換える等もしない。 - コメントの投稿・編集・削除: コメントは検査根拠として読むだけで変更しない。
- failed 項目の自動修正: 報告のみ行い、修正は呼び出し側の責任。
## 受け入れ条件以外のセクションの検証: 背景・スコープ外などは対象外。- 動作確認の代行: 確認方法の提示は行うが、実際の確認は呼び出し側に委ねる。