# Acceptance Check

> GitHub issue 本文の `## 受け入れ条件` セクションを抽出し、repo 状態や issue コメントを根拠に各項目を ✓ / ✗ / ? で報告する read-only skill。`issue-implement` と `issue-investigate` の受け入れ条件確認を標準化する。

- Skill: `hirokisakabe/acceptance-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add hirokisakabe/acceptance-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hirokisakabe/acceptance-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: hirokisakabe (https://skillmd.com/u/hirokisakabe)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hirokisakabe/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 本文とコメントの取得

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