acceptance-check

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

入力

• issue 番号

実行手順

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 項目の自動修正: 報告のみ行い、修正は呼び出し側の責任。
• ## 受け入れ条件 以外のセクションの検証: 背景・スコープ外などは対象外。
• 動作確認の代行: 確認方法の提示は行うが、実際の確認は呼び出し側に委ねる。