| name | acceptance-check |
| description | GitHub issue 本文の `## 受け入れ条件` セクションを抽出し、各項目を自動検査して結果を ✓ / ✗ / ? で報告する read-only skill。`issue-implement` cycle 内で実装・commit 後・cross-review 前に呼び出して受け入れ条件確認を標準化する。 |
| version | 1.0.1 |
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-implement cycle) の責任とする。
## 受け入れ条件 以外のセクション検証: 検証可能な完了条件は ## 受け入れ条件 のみと定義されているため、背景・スコープ外等は対象外。
依存
gh CLI: issue 本文取得に使用する。Codex CLI 等の外部 AI ツールには依存しない。
入力
実行手順
1. issue 本文の取得
ISSUE_NUMBER=<issue 番号>
gh issue view "$ISSUE_NUMBER" --json body --jq '.body'
2. ## 受け入れ条件 セクションの抽出
issue 本文から ## 受け入れ条件 の見出し以降〜次の ## 見出し直前までを取り出し、- [ ] または - [x] で始まるチェックリスト項目をすべて抽出する。
該当セクションが存在しない、または空の場合は「受け入れ条件が定義されていない」旨を報告して終了する（フォーマット不備の可能性があるので、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 が成功する」 | コマンド実行 + $? |
| 要人間判定 | 「呼び出し元 agent から認識される」「UI が崩れていない」など | 自動化困難な項目はマーク |
自動化困難の判断基準:
- 主観的評価（「使いやすい」「自然な挙動」等）
- 外部システム / ツールでの認識（呼び出し元 agent が skill を読み込めるか、IDE が拡張を認識するか等）
- ブラウザ・GUI での目視確認
- ユーザー対話を伴う動作確認
これらは ? (要人間判定) としてマークし、検査者（呼び出し側）に判断を委ねる。可能であれば「動作確認方法の提示」（例: 「呼び出し元 agent を再起動して /help で skill 一覧に現れるか確認」）も併記する。
4. 結果報告
以下の形式で結果を出力する。
## 受け入れ条件チェック結果 (issue #<N>)
- ✓ <項目 1>
- 検査方法: <test -f / grep / ... の具体的内容>
- ✗ <項目 2>
- 検査方法: <内容>
- 失敗理由: <なぜ失敗したか>
- ? <項目 3> (要人間判定)
- 自動化困難な理由: <主観的 / 外部システム認識 / ...>
- 動作確認方法: <呼び出し側に提示する確認手順>
サマリー: ✓ <X> 件 / ✗ <Y> 件 / ? <Z> 件
✗ が 1 件でもある場合は、呼び出し側 (issue-implement cycle 等) に「受け入れ条件未達」として明示的に伝える。
利用タイミング
issue-implement cycle 内: 実装・commit 後、cross-review より前に呼び出す。✗ がある場合は実装に戻り 追加 commit で修正する（履歴整形はしない）。? のみであれば呼び出し側で人間判定を経て進む。- 手動呼び出し: 実装完了後にユーザーが受け入れ条件のチェックを依頼した場合。
失敗時の対応
gh issue view が失敗する（issue が存在しない / 認証エラー等）場合は、その旨を報告して終了する。## 受け入れ条件 セクションが空 / 存在しない場合は、issue-refine skill での整理を案内する。
やらないこと
- issue body や code への書き込み: 本 skill は read-only。チェックリストの
- [ ] を - [x] に書き換える等もしない。
- failed 項目の自動修正: 報告のみ行い、修正は呼び出し側の責任。
## 受け入れ条件 以外のセクションの検証: 背景・スコープ外などは対象外。- 動作確認の代行: 確認方法の提示は行うが、実際の確認は呼び出し側に委ねる。
