Acceptance check

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 ツールには依存しない。

入力

• 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-implement cycle 内: 実装・commit 後、cross-review より前に呼び出す。✗ がある場合は実装に戻り 追加 commit で修正する（履歴整形はしない）。? のみであれば呼び出し側で人間判定を経て進む。
• issue-investigate cycle 内: 構造化した結果コメントの投稿後、issue close より前に呼び出す。✗ があれば調査またはコメントを補い、未解決の ? があれば close しない。
• 手動呼び出し: 実装完了後にユーザーが受け入れ条件のチェックを依頼した場合。

失敗時の対応

• gh issue view が失敗する（issue が存在しない / 認証エラー等）、またはコメントを取得できない場合は、その旨を報告して終了する。
• --result-comment の形式を解釈できない場合は入力エラーとして終了する。一致するコメントが取得結果にない場合は、結果コメント存在条件を ✗ として報告する。
• ## 受け入れ条件 セクションが空 / 存在しない場合は、issue-refine skill での整理を案内する。

やらないこと

• issue body や code への書き込み: 本 skill は read-only。チェックリストの - [ ] を - [x] に書き換える等もしない。
• コメントの投稿・編集・削除: コメントは検査根拠として読むだけで変更しない。
• failed 項目の自動修正: 報告のみ行い、修正は呼び出し側の責任。
• ## 受け入れ条件 以外のセクションの検証: 背景・スコープ外などは対象外。
• 動作確認の代行: 確認方法の提示は行うが、実際の確認は呼び出し側に委ねる。