---
name: task-artifact-reviewer
description: |
  task-performer スキルで実装されたタスクの成果物（コミット or PR）を、元タスク要件と突き合わせてレビューするスキル。
  pr-reviewer スキルの汎用レビュー（コード品質・セキュリティ・規約・ベストプラクティス）に加え、
  「タスク要件との整合性」と「退行リスク（既存機能への影響）」を独立セクションで詳細検証する。
  以下の状況で使用:
    (1) 「タスク 001 のPRをレビューして」「このタスクの成果物をチェックして」と依頼された時
    (2) task-performer で完了したタスクの妥当性検証を依頼された時
    (3) task-starter プロジェクト配下のタスクに紐づくPR/コミットを評価したい時
    (4) 「実装が要件を満たしているかレビューして」「受け入れ条件を検証して」と依頼された時
    (5) 「task-artifact-reviewer スキル」の実行を指示された時
  必ず使用すべき場面: タスクドキュメント（todos/NNN/README.md や独立todoファイル）と、
  そのタスクに対する成果物（PR・ブランチ・コミット）の両方が示されたレビュー依頼。
  単純なPRレビューだけなら pr-reviewer を直接使う方が軽量。
argument-hint: "[タスクファイルパス] [PR番号/URL or ブランチ名 or コミットハッシュ] [--base ベースブランチ] [--outline 概要] [--output file,pr-comment] [--rule ルールファイル,...]"
---

# Task Artifact Reviewer

task-performer の成果物（コミット or PR）を、その元となったタスク要件と突き合わせてレビューする。

pr-reviewer スキルの汎用レビューを呼び出しつつ、「タスク要件との整合性」と「退行リスク」を本スキル固有の最重要軸として独立検証する。

## スコープ

### 含むもの
- タスクドキュメントの読み込み（task-reader エージェント委譲 or 直接読み込み）
- レビュー対象成果物の特定と diff 取得（PR / ブランチ / コミット）
- タスク要件と diff の突き合わせ（受け入れ条件・開発原則・スコープ・退行リスク）
- pr-reviewer スキル呼び出しによる汎用レビュー
- タスク整合性レビューと汎用レビューを統合した最終レポート
- レビュー結果の Markdown ファイル出力（`logs/{todoタスク番号}/ta-review-{YYYYmmddHHMMSS}-{commit-hash}.md`）

### 含まないもの
- 指摘内容のコード修正・生成（→ task-performer または手動修正）
- テストの実行（`npm test`, `go test`, `pytest` 等）
- Lint / フォーマットの実行（`eslint`, `golangci-lint`, `black` 等）
- ビルドの実行（`npm run build`, `make` 等）
- PRのマージ・クローズ操作
- `git commit` / `git push` の実行
- task-performer / pr-reviewer のワークフロー自体の上書き

## Degrees of Freedom

- **入力解析: Low freedom** — 「引数の解析」セクションのパターンに厳密に従う。不明確な場合は推奨案を含む複数の選択肢を提示してユーザーに必ず確認
- **タスクコンテキスト取得経路: Low freedom** — `todos/NNN-{task}/README.md` パターンは必ず task-reader へ委譲する。task-reader は `progresses/README.md` と個別 `PROGRESS.md` を常に読み、`logs/` はデフォルトで読み込まないため、レビュー用途では `--with-log` を付けずに呼ぶ。それ以外は直接読み込む
- **pr-reviewer 呼び出し方式: Low freedom** — Skill ツールで `pr-reviewer` スキルを呼び出す。本スキル内で独自にレビュー手順を再実装しない
- **要件整合性レポートの粒度: Medium freedom** — 受け入れ条件・開発原則・スコープ逸脱・退行リスクの4観点は必須。各観点の深掘り度合いはタスクの規模に応じて調整可
- **最終レポート構造: Low freedom** — 「最終レポート形式」セクションのテンプレートに従う
- **レポート出力の公開性: Low freedom** — 「レポート出力原則（第三者可読性）」セクションに厳密に従う。レビュー結果は PR コメント等に転記されうる対外公開ドキュメントとして扱い、タスクドキュメントのパス・gitignore 対象・レビュー対象リポジトリ外パスへの言及を含めない
- **レビュー結果の出力先: Low freedom** — task-starter 形式タスクの場合、進捗正本ではない作業成果物としてデフォルトで `{project_root}/logs/{todoタスク番号}/ta-review-{YYYYmmddHHMMSS}-{commit-hash}.md` へ出力する。タスク番号が複数指定された場合は最も数値が大きい（最新の）番号のディレクトリへ出力する。task-starter 形式でない場合はファイル出力をスキップし会話内のみで報告する

## 引数の解析

`$ARGUMENTS` を以下のパターンでパースする。順序は問わない（タスクファイルパスは `todos/` または `.md` を含むことで識別、成果物はその他のトークン）。

| 成果物パターン | 例 | 取得方法 |
|---|---|---|
| `https://github.com/{owner}/{repo}/pull/{num}` | `https://github.com/goldeneggg/dotfiles/pull/123` | GitHub PR（URL） |
| `{owner/repo} {PR番号}` | `goldeneggg/dotfiles 123` | GitHub PR |
| `{ブランチ名}` | `feature/foo` | ローカルブランチ（base: main） |
| `{ブランチ名} --base {ベース}` | `feature/foo --base develop` | ローカルブランチ（base 指定） |
| `{コミットハッシュ}` または `HEAD` | `abc1234` / `HEAD` | 単一コミット |
| `{範囲}` (`a..b` 形式) | `abc1234..def5678` | コミット範囲 |

| タスクパターン | 例 | 取得方法 |
|---|---|---|
| `**/todos/NNN-{task}/README.md` | `docs/tasks/20251201-foo/todos/001-setup/README.md` | task-reader 委譲 |
| 任意の `.md` ファイル | `~/notes/my-task.md` | 直接読み込み |

**パース失敗時**: タスク・成果物のいずれかが特定できなければ推奨案を含む複数の選択肢を提示してユーザーに確認する。両方未指定なら最初に両方を尋ねる。

### pr-reviewer への転送引数

以下のオプションは本スキルで解釈したうえで、指定されたオプション名・値を変更せず Phase 5 の `pr-reviewer` 呼び出しへ渡す。指定順は問わない。

| オプション | 例 | 扱い |
|---|---|---|
| `--base` | `--base develop` | ブランチの差分取得に使用し、明示指定時は同じ指定を転送 |
| `--outline` | `--outline "認証変更のレビュー"` | 指定値を転送し、自動生成のタスク要約は追加しない |
| `--output` | `--output file,pr-comment` | `file` / `pr-comment` の指定値をそのまま転送 |
| `--rule` | `--rule rules/security.md,rules/api.md` | カンマ区切りのルールファイルパスをそのまま転送 |

`--outline` が指定されていない場合のみ、タスク要約を自動生成して `--outline` に渡す。`--base` が未指定の場合は、差分取得・`pr-reviewer` ともに既定値 `main` を使用する。`pr-reviewer` が受け付けないオプションは本スキル独自に処理せず、引数解析失敗としてユーザーに確認する。

## ワークフロー

### Phase 1: 入力の確定

最初に `../_shared/references/task-management-contract.md` を読み、レビュー結果を進捗正本と分離する保存契約を適用する。

1. `$ARGUMENTS` を「引数の解析」に従ってパースし、以下を確定:
   - タスクファイルパス（`{task_path}`）
   - 成果物指定（`{artifact}` と種別: PR / branch / commit / range）
   - ベースブランチ（branch モード時のみ。未指定なら `main`）
   - `pr-reviewer` 転送引数（`--base` / `--outline` / `--output`。指定されたもののみ）
2. いずれかが不明なら推奨案を含む複数の選択肢を提示してユーザーに確認する。推測で進めない。
3. **作業ディレクトリの git リポジトリ確認**: `git rev-parse --show-toplevel` で確認。branch / commit モードはリポジトリ内である必要がある。
4. **レビュー結果の出力先を確定**: `{task_path}` が `todos/NNN-{task}/README.md` パターンに合致する場合、以下の手順で出力先を決定する:
   - `{task_path}` から `todos/` の親ディレクトリ（= project_root）を特定する
   - タスク番号（NNN 部分の数値）が複数指定されている場合、最も数値が大きいタスクの `NNN-{task}` を採用する（例: `001-setup` と `003-api` なら `003-api`）
   - 出力先: `{project_root}/logs/{NNN-{task}}/ta-review-{YYYYmmddHHMMSS}-{commit-hash}.md`
   - task-starter 形式でないタスクファイルの場合、ファイル出力はスキップする

### Phase 2: タスクコンテキストの収集

`{task_path}` が `todos/NNN-{task}/README.md` パターンに合致する場合:

- **task-reader エージェントへ委譲**する（`subagent_type: task-reader`）
- 委譲時 `prompt` には以下を含める（`--with-log` は付けない）:

  ```
  タスクファイルパス: {task_path}
  ```

- task-reader は `progresses/README.md` と `progresses/NNN-{task}/PROGRESS.md` を常に読み、一覧と個別正本の不一致を留意事項として返す。`logs/NNN-{task}/` の過去作業ログはデフォルトで読み込まない（`--with-log` を付けないこと）
- 返却される構造化サマリ（タスク本文全文・プロジェクト概要・specs・references・ロードマップ・全体進捗一覧・成果/進捗・留意事項。過去ログは「（`--with-log` 未指定のため過去ログは取得していません）」と記載される）をそのまま Phase 4 の判断材料に使う

それ以外（独立 markdown / 任意の todo ファイル）:

- 指定ファイルを直接読み込んで全文取得する
- 隣接ファイル（同階層の `README.md` や `specs/` 等）が自然にあれば軽く参照する程度に留め、無ければそれで進める

**Why（委譲する理由 / `--with-log` を付けない理由）**: task-starter プロジェクトは README / specs / references / todos / progresses / logs を横断するため、本体スキルで全文展開するとコンテキストが逼迫する。読み取りと要約を専門エージェントに切り出すことで、本体は構造化サマリのみを保持し、Phase 4 の整合性検証に集中できる。レビュー判断に必要な進捗と成果の要約は `PROGRESS.md` から常時取得できる一方、`logs/` の過去作業ログやレビュー結果は容量が大きく基本的に不要なため、レビュー用途では `--with-log` を付けない。

**ログを読みたい例外ケース**: ユーザーがレビュー依頼時に「実装中の試行錯誤や中断履歴も踏まえてレビューしてほしい」と明示的に依頼した場合に限り、`--with-log` を付けて呼ぶか、Phase 2 とは別に必要なログファイルだけを個別に読み込んで取得する。デフォルトでは決して `--with-log` を付けない。

### Phase 3: 成果物の差分情報収集

成果物種別ごとに以下を**並列**で実行する（実行可能なものは1ターンで一括発行）:

#### 3-A. GitHub PR モード

```bash
# 並列実行1: diff
gh pr diff {pr_num} --repo {owner/repo}

# 並列実行2: PR 説明
gh pr view {pr_num} --repo {owner/repo} --json title,body,headRefName,baseRefName,commits --jq '{title, body, head: .headRefName, base: .baseRefName, commit_count: (.commits | length)}'
```

#### 3-B. ローカルブランチモード

```bash
# 並列実行1: diff（base..target）
git diff {base}..{target}

# 並列実行2: 含まれるコミット一覧
git log --oneline {base}..{target}

# 並列実行3: 変更ファイルリスト
git diff --name-status {base}..{target}
```

#### 3-C. 単一コミット / コミット範囲モード

```bash
# 単一コミット
git show {hash}

# コミット範囲
git diff {range}
git log --oneline {range}
```

**差分サイズの確認**: diff 行数が 10,000 行を超える場合、ユーザーに「全体レビューに時間がかかる。ファイル単位での段階的レビュー or 重要ファイル絞り込み」を提案する（pr-reviewer の方針と整合）。

### Phase 4: タスク要件整合性レビュー（本スキル固有の最重要工程）

Phase 2 のタスクコンテキストと Phase 3 の差分情報を突き合わせ、以下4観点を**順番に**検証する。各観点の検証結果は Phase 6 の最終レポート用に構造化して保持する。

#### 4-1. 受け入れ条件の充足度

タスクファイル本文（および specs/）の受け入れ条件を列挙し、新形式では `AC-ID` を維持して各条件を判定する。`PROGRESS.md` に既存の検証状態と根拠があっても結論を流用せず、差分から独立に再評価する。旧形式では記載順に一時的な `旧形式-01` 形式の識別子を付け、移行が必要であることを注記する。

- ✅ **充足**: 差分内に対応する実装が確認できる（ファイルパス・関数名・該当行を根拠として記載）
- ⚠️ **部分充足**: 一部のみ実装、または関連はあるが完全ではない
- ❌ **未充足**: 差分から実装の痕跡が見つからない
- ❓ **判定不能**: テスト実行や動作確認が必要で diff だけでは判定できない（その旨を明示）

判定根拠は必ず「diff の該当箇所」として `path:line` 形式で示す。
レビュー結果は `logs/` の証跡であり、このスキルからTODOや `PROGRESS.md` の状態を更新しない。`PROGRESS.md` の既存判定とレビュー結果が矛盾する場合は、統合レポートで明示する。

#### 4-2. 開発原則の対応状況

task-starter 由来のタスクには「開発原則チェック」セクションがある。各原則について:

| 原則 | チェック内容 |
|------|------------|
| セキュリティ | 認証/認可・入力検証・シークレット管理・依存脆弱性。タスクで N/A 宣言済みなら理由を確認 |
| 耐障害性 | リトライ・タイムアウト・graceful degradation・エラー握り潰しの有無 |
| 高可用性 | 冗長性・ヘルスチェック・無停止デプロイへの影響 |
| スケーラビリティ | N+1 / 不要な同期処理 / 共有状態 / ボトルネック |

タスク側で N/A とされている原則は「N/A 維持で妥当か」のみ点検する。

#### 4-3. スコープ整合性

- **要件外の変更が混入していないか** — task-performer の実装原則「スコープ外の改善は気づきメモ」に反していないか
- **要件で求められたファイル/機能が漏れていないか** — specs 記載の影響範囲と diff の対象範囲の照合
- **タスク 1xx 番台への分割漏れ** — 本来別タスクで起票すべき変更が混入していないか

スコープ逸脱は最終レポートで明示し、対処方針（別コミット分離 / 別タスク起票 / 受け入れ）を提案する。

#### 4-4. 退行リスクの検証

diff の変更内容が既存機能に意図しない影響を及ぼさないかを検証する。タスク要件の充足だけでなく「壊していないか」を確認する観点であり、受け入れ条件の充足度（4-1）とは独立した検証軸として扱う。

以下の検出パターンを diff に対して順に適用し、該当箇所ごとにリスク影響度（🔴 高 / 🟠 中 / 🟡 低）を判定する:

| 検出パターン | チェック内容 | 影響度目安 |
|---|---|---|
| インターフェース変更 | 関数シグネチャ・エクスポート・API エンドポイント・型定義・設定キーの変更 → 呼び出し側が追従済みか | 🔴〜🟠 |
| 削除・リネーム | コード・ファイル・変数・定数の削除やリネーム → リポジトリ内で参照が残っていないか（`rg` / `grep` で確認） | 🔴〜🟠 |
| 振る舞いの変更 | 条件分岐の追加・変更・削除、デフォルト値の変更、戻り値の変更、エラーハンドリングの変更 → 既存の呼び出し側が前提としていた動作が壊れないか | 🟠〜🟡 |
| 依存関係の変更 | パッケージの追加・削除・メジャーバージョン変更 → 破壊的変更や互換性の問題がないか | 🟠〜🟡 |
| 共有リソースの変更 | 設定ファイル（CI/CD、ビルド、lint 等）・共有ユーティリティ・共通型定義の変更 → 他機能への波及 | 🟠〜🟡 |

**検証手順**:

1. Phase 3 の diff から上記パターンに該当する変更箇所を抽出する
2. 各該当箇所について、リポジトリ内での参照・依存関係を `rg`（または `grep`）で調査し、影響範囲を特定する
3. 影響範囲に対して、変更が安全であることを確認できる根拠（呼び出し側も同一 diff 内で追従済み、影響を受ける呼び出し元が存在しない、等）を探す
4. 安全確認ができない箇所をリスクとして報告する

**判定根拠**: リスク報告時は必ず `path:line` で変更箇所を示し、影響を受ける可能性のある参照元も `path:line` で列挙する。diff だけでは影響の有無を確定できない場合は ⚠️ として「動作確認が必要」と明示する。

**影響度の判定基準**:
- 🔴 **高**: 公開インターフェースの破壊的変更、参照元が追従していない削除/リネーム、既存テストが通らなくなる可能性が高い変更
- 🟠 **中**: 振る舞いの変更があるが影響範囲が限定的、または呼び出し側の追従が diff 内で部分的に確認できる
- 🟡 **低**: 内部実装の変更で外部インターフェースに影響なし、または影響が軽微

### Phase 5: pr-reviewer による汎用レビュー

Skill ツールで `pr-reviewer` スキルを呼び出す。`args` には Phase 1 で確定した成果物指定を使用し、Phase 1 で指定された転送引数を同じオプション名・値で追加する。ユーザー指定の `--outline` がある場合は自動生成のタスク要約を追加せず、指定値をそのまま使用する。

**呼び出し例:**

| Phase 1 で確定した指定 | Skill 呼び出し時の args |
|---|---|
| GitHub PR (`owner/repo 123`) | `owner/repo 123` に指定された `--base` / `--outline` / `--output` を追加。`--outline` 未指定時は `--outline "{タスク要約 1-3文}"` を追加 |
| GitHub PR URL | `{URL}` に指定された `--base` / `--outline` / `--output` を追加。`--outline` 未指定時は `--outline "{タスク要約}"` を追加 |
| ローカルブランチ + base | `{branch}` に指定された `--base` / `--outline` / `--output` を同じ値で追加 |
| 単一コミット / 範囲 | `pr-reviewer` スキルは単一コミット/範囲を直接サポートしないため、**ブランチ名へ変換**（`git rev-parse --abbrev-ref HEAD` で現在ブランチを取得し、指定された転送引数を維持したうえで `--base {親コミット}` 相当を使うか、本スキル内で代替レビューを行う） |

**Why（pr-reviewer を呼ぶ理由）**: コード品質・セキュリティ・規約・ベストプラクティスの汎用レビュー軸は pr-reviewer に既にカプセル化されている。本スキルで再実装すると同期負担と差異が生じるため、必ず Skill 呼び出しで委譲し、戻り値（重要度別の指摘リスト + 総合判定）をそのまま Phase 6 に統合する。

**outline の扱い**: `--outline` がユーザー指定されていない場合に限り、タスク要約を渡して変更の目的を補足する。ユーザー指定時はその内容を優先し、値の結合や上書きを行わない。

**コミットモードの扱い**: `pr-reviewer` スキルがブランチ/PR 前提の場合、コミット範囲は以下のいずれかで対応:

1. **対応するブランチが特定できる場合**: そのブランチで pr-reviewer を呼ぶ
2. **特定できない場合**: pr-reviewer 呼び出しをスキップし、本スキル内で「コード品質・セキュリティ・規約準拠・ベストプラクティス」の4観点を Phase 3 の diff に対して直接検証する（その旨をレポートに明記）

### Phase 6: 統合レポートの生成

タスク整合性レビュー（Phase 4）と pr-reviewer の汎用レビュー（Phase 5）を統合し、以下のテンプレートで報告する。

**生成前に**「レポート出力原則（第三者可読性）」セクションを再読し、その「報告前チェック」をレポート出力直前に必ず実施する。タスクドキュメントのパス・サブエージェント返却内のローカルパス・gitignore 対象パスをレポート本文へ転記してはならない。

**ファイル出力**: Phase 1 で確定した出力先パスが存在する場合（task-starter 形式タスクの場合）、報告前チェック完了後に以下を実行する:

1. 出力先ディレクトリ（`{project_root}/logs/{NNN-{task}}/`）が存在しなければ作成する（`mkdir -p`）
2. レポート全文を `{project_root}/logs/{NNN-{task}}/ta-review-{YYYYmmddHHMMSS}-{commit-hash}.md` に書き出す
3. 会話内でも同じレポートを表示し、ファイル出力先パスを併記する（例: `レビュー結果を logs/003-api/ta-review-20260716123000-a1b2c3d.md に出力しました`）

レビュー結果の生成だけでは `PROGRESS.md` も `progresses/README.md` も更新しない。レビューは進捗状態の正本ではなく、後続作業が参照する作業成果物だからである。

task-starter 形式でないタスクの場合はファイル出力をスキップし、会話内のみでレポートを表示する。

## 最終レポート形式

**重要**: このテンプレートは第三者（PR 作成者・他レビュアー）がそのまま読める形を前提とする。タスクファイルパス（`docs/tasks/...`, `todos/...`）は本文に書かない。受け入れ条件は条件文を直接記載し、ファイルパス参照はレビュー対象 diff 内のものに限る。

**タイトルはタスクID/タスク番号で表さない**: タイトルは成果物の内容を表す自然文（例: `ユーザー認証機能の追加`）にする。`001-setup` のようなタスクID・`タスク 001` のようなタスク番号は、対応者のローカル環境にしか存在せず第三者には何を指すか分からないため、タイトルにも本文にも一切書かない。タスクを呼びたい場合は「本タスク」「親タスク」のように内部参照に閉じた語を使う。

```markdown
# タスク成果物レビュー: {成果物の内容を表す自然文タイトル}

## 📋 レビュー対象

- **タスク概要**: {タスク内容を1〜3文で要約。タスクファイルのパスは書かない}
- **成果物**: {PR #N / branch {name} / commit {hash}}
- **差分規模**: {N} files, +{追加行} -{削除行}

## 🎯 タスク要件整合性（本スキル固有レビュー）

### 受け入れ条件の充足度

| ID | 受け入れ条件 | 判定 | 根拠 |
|---|---|---|---|
| AC-01 | {条件文をそのまま記載} | ✅/⚠️/❌/❓ | `src/foo.ts:42` {コメント} |
| AC-02 | ... | ... | ... |

**充足率**: {N/M} 件充足、{X} 件部分充足、{Y} 件未充足、{Z} 件判定不能

**重要**: 本文中では `AC-01` のようなIDで参照する。旧形式は「旧形式-01」のように記載し、`#1`, `#2` のような `#` プレフィックスは絶対に使わない（GitHub では Issue/PR への自動リンクへ変換されてしまう）。

### 開発原則の対応状況

| 原則 | タスク側宣言 | 実装状況 | コメント |
|------|---|---|---|
| セキュリティ（最優先） | 対応 / N/A | ✅/⚠️/❌ | {根拠と所見} |
| 耐障害性 | 対応 / N/A | ✅/⚠️/❌ | ... |
| 高可用性 | 対応 / N/A | ✅/⚠️/❌ | ... |
| スケーラビリティ | 対応 / N/A | ✅/⚠️/❌ | ... |

### スコープ整合性

- **要件外の変更**: {あれば列挙、なければ「検出なし」}
- **要件のうち未実装**: {あれば列挙}
- **派生タスク化を推奨する変更**: {あれば列挙}

### 退行リスク

| No. | リスク箇所 | 影響度 | 検出パターン | 影響を受ける参照元 | 詳細 |
|---|---|---|---|---|---|
| 1 | `src/foo.ts:42` | 🔴/🟠/🟡 | {パターン名} | `src/bar.ts:10` 等 | {説明} |

**検出件数**: 🔴 高 {X}件、🟠 中 {Y}件、🟡 低 {Z}件（検出なしの場合は「退行リスクは検出されませんでした」）

## 🔍 汎用レビュー

- 🔴 Critical: X件
- 🟠 High: X件
- 🟡 Medium: X件
- 🟢 Low: X件

{pr-reviewer の指摘詳細をそのまま転記}

## 📊 総合判定

**判定**: ✅ 承認可能 / ⚠️ 条件付き承認 / ❌ 要修正

**判定根拠**:
- タスク整合性: {充足率と未充足項目の有無で判断}
- 退行リスク: {🔴 高リスクが0件かつ🟠 中リスクが対処可能な範囲なら承認可能}
- 汎用レビュー: 汎用レビューの判定（Critical 0 かつ High 2以下なら承認可能）

**三軸の合成ルール**:
- いずれかが「要修正」なら全体「要修正」
- 退行リスク 🔴 高が1件でもあれば全体「要修正」
- 退行リスク 🟠 中のみの場合は全体「条件付き承認」（確認・テスト実施を条件とする）
- 上記に該当しない場合、すべて「承認可能」なら全体「承認可能」
- いずれかが「条件付き承認」かつ他が「承認可能以上」なら全体「条件付き承認」

## 🛠️ 推奨アクション

1. {具体的な次のステップを優先度順に}
2. ...

## 📝 補足

{あれば: テスト実行による動作確認が必要な項目 / レビュー時の前提や制約 / 留意事項}
```

## レポート出力原則（第三者可読性）

**前提**: このレビュー結果は PR コメント・Issue・Slack・メール等に転記される可能性のある「対外公開ドキュメント」として扱う。レビュー対象リポジトリの第三者（PR 作成者・他のレビュアー）が読んでも、参照されているファイル・概念がすべて当該リポジトリ内で完結することが必要。

特に本スキルは task-performer 由来のタスクドキュメント（`docs/tasks/...`, `todos/...`）や task-reader 返却の specs/references パスを参照する性質上、**意図せずレビュー対象外のパスをレポートに書いてしまうリスクが高い**。最終レポート生成前に必ずチェックする。

### 参照可能なファイル

- ✅ レビュー対象 diff に含まれるファイルパス（例: `src/foo.ts:42`）
- ✅ レビュー対象リポジトリで git 管理されている公開ファイル（例: `README.md`, `package.json`, `CLAUDE.md`）
- ✅ 公開 URL（公式ドキュメント、RFC、CVE 等）

### 参照禁止のファイル・識別子

- ❌ タスクID・タスク番号そのもの（`001`, `001-setup`, `タスク 001`, `NNN-{task}` 等）— パスでなく単独の語であっても、第三者には何を指すか分からないため本文・タイトル・テーブルのいずれにも書かない
- ❌ タスクドキュメントのパス／URL（`docs/tasks/`, `todos/`, `todos/NNN-{task}/README.md` 等。ローカルファイルパスもURL表記も同様に禁止）
- ❌ task-reader が返却したサマリ内の specs/references パス
- ❌ gitignore 対象のローカルファイル（`.env`, `tmp/`, `progresses/`, `logs/`, ローカルキャッシュ）
- ❌ レビュー対象リポジトリ外のローカルパス（`~/notes/`, `/Users/xxx/`, `/tmp/`）
- ❌ レビュー担当者のホームディレクトリやマシン固有の絶対パス
- ❌ レビュー対象リポジトリで git ignore されているプロジェクト管理ドキュメント

### 「外部不可視リソース」の扱い

タスクドキュメントは推論材料として参照する（むしろ本スキルの主目的）が、レポート本文では:

1. **受け入れ条件は条件文を直接記載** — 「タスクファイル参照」ではなく、条件そのものを引用する。本文中で条件を再参照する場合は「受け入れ条件 1」「項目 2」のように記載する
2. **タスク要約はインライン文** — 「タスク概要」欄はパスではなく1〜3文の自然言語サマリ
3. **番号・記号での間接参照を避ける** — 「タスク要件 番号 3」「仕様書 §2」のような外部資料への番号参照は、第三者が確認できないうえ、後述の通り GitHub auto-link を招く危険な記法（`#3` 等）と紛らわしい。要件内容そのものを本文に書く
4. **task-reader 返却の引用元パスを書かない** — task-reader の出力には specs/references パスが含まれることがあるが、レポートには内容のみ取り込み、出典パスは省く

### GitHub auto-link を発火させない記法ルール

本スキルのレポートは PR コメント・Issue 本文に貼られる前提のため、GitHub の自動リンク機能で**全く無関係のIssue/PR/ユーザーへ誘導されてしまう**パターンを絶対に出力しない。

| パターン | GitHub での解釈 | 代替表現 |
|---|---|---|
| `#数字` (例: `#3`, `#42`) | 同リポジトリの Issue/PR #N へのリンク | 「受け入れ条件 3」「項目 3」「タスク内項目 3」のように `#` を外して書く |
| `GH-数字` | Issue/PR への代替リンク | 「項目 N」のように一般語で記載 |
| `org/repo#数字` | 他リポジトリの Issue/PR | 「外部要件 N」のように記載 |
| `@username` | ユーザーへのメンション通知 | 「担当者」「実装者」のように役割名で記載 |
| `@org/team` | チームへのメンション通知 | チーム名は通常文で記載（例: `バックエンドチーム`） |
| `タスク NNN` を `#NNN` と記載 | Issue/PR #NNN への誤リンク | 「本タスク」「親タスク」のように相対参照、または「タスク内項目 N」と記載 |

**特に注意**: 本スキルは task-starter のタスク番号（例: `001-setup`）を扱う性質上、AI が「タスク番号 3」を `#3` と省略表記しがちであり、それが PR コメントへ転記されると無関係のIssue/PR #3 へリンクされてしまう。タスク番号は `#` を絶対に付けず、必要なら「本タスク」「親タスク」「タスク内項目 N」のように内部参照に閉じた語で表現する。

### 報告前チェック

最終レポート出力直前に、レポート本文に対して以下を点検する:

- [ ] タイトル・本文・テーブルにタスクID／タスク番号（`001`, `001-setup`, `タスク 001` 等）が混入していないか（タイトルは成果物内容の自然文になっているか）
- [ ] タスクドキュメントのパス／URL（ローカルファイルパス・URL 表記の双方）が混入していないか
- [ ] パス参照がすべて Phase 3 で取得した diff のファイルパスに対応しているか（`git ls-files` 相当）
- [ ] `todos/`, `docs/tasks/`, `progresses/`, `logs/`, `tmp/`, `.env`, `specs/`, `references/`, `~/`, `/Users/`, `/home/` などレビュー対象外パターンを含む参照がないか
- [ ] 「タスク概要」「受け入れ条件」「コメント」欄にタスクファイルパスの引用が紛れ込んでいないか
- [ ] task-reader から得たサマリの出典パスを引用していないか
- [ ] `#数字`, `GH-数字`, `org/repo#数字`, `@username`, `@org/team` といった GitHub auto-link を発火させるパターンがレポート本文・テーブル・引用箇所に含まれていないか（含まれていれば必ず代替表現へ置換）
- [ ] 汎用レビューの指摘内にも上記禁止パスや auto-link 発火パターンが含まれていないか（含まれていれば該当部分を抽象化して転記）
- [ ] レポート本文（セクション見出し・テーブル・コメントを含む）に、本スキルや内部で使用したサブエージェントの名称が含まれていないか（含まれていれば削除または汎用語に置換）

問題がある記載は削除または抽象化してから報告する。**チェックは報告前に必ず実施**する。

## ガイドライン

### 不明点の確認

以下は必ず推奨案を含む複数の選択肢を提示してユーザーに確認:

- タスクファイルパス・成果物指定のいずれかが特定できない
- タスクファイルの場所と成果物の対応関係が曖昧（複数候補がある）
- コミット範囲モードで pr-reviewer 呼び出し方針が決まらない
- diff が 10,000 行超で段階的レビュー方針の合意が必要

### 情報収集

- タスク文書中の用語・略語が不明な場合は specs/references の該当記述を参照
- ライブラリ固有の慣習が不明な場合は WebSearch / context7 で公式仕様を確認（pr-reviewer 側でも実施されるが、整合性判定で必要なら本スキルでも積極的に調べる）

### エラーハンドリング

| エラー | 対応 |
|--------|------|
| タスクファイル不在 | `**/todos/*/README.md` パターンでファイル名検索し候補を提示。見つからなければ選択肢提示で確認 |
| PR/ブランチ/コミット不在 | gh / git のエラーメッセージをそのまま提示し、正しい指定を再確認 |
| task-reader が「task-starter 構造ではない」と返却 | フォールバックして直接読み込みに切り替え。Phase 2 後半の手順に従う |
| pr-reviewer 呼び出し失敗 | エラー内容を報告し、本スキル内で汎用4観点を直接検証して継続。レポートにその旨を明記 |
| gh 認証エラー | `gh auth status` 確認を促す。`gh auth login` の案内 |
| diff が空 | 「変更が検出されません」と報告し、指定の妥当性を再確認 |

## 前提条件

- 対象プロジェクトが git 管理下にあること（branch / commit モード）
- GitHub PR モードでは `gh` CLI が認証済みであること
- task-reader エージェントが利用可能であること（task-starter 形式タスクの場合）
- pr-reviewer スキルが利用可能であること（Skill ツール経由で呼び出し）

## 禁止事項

- **コード修正・生成の実施** — レビュー結果に基づく修正は task-performer や手動で行う。本スキルでは指摘のみ。コードを書いたり変更したりしない
- **テスト・Lint・ビルドの実行** — `npm test`, `go test`, `pytest`, `eslint`, `golangci-lint`, `make` 等のコマンドは実行しない。diff の静的読解だけでレビューを完結させる
- **PR/ブランチへの破壊的操作** — マージ・クローズ・force push・ブランチ削除は行わない
- **タスク要件整合性レビューのスキップ** — pr-reviewer の汎用レビューだけで済ませない。本スキルの存在意義はタスク要件との突き合わせにある
- **diff を読まずに pr-reviewer 結果だけで判定すること** — Phase 4 の整合性検証は必ず diff を読んで根拠を `path:line` で示す
- **レビュー対象外パスのレポート記載** — タスクドキュメントパス・task-reader 返却の specs/references パス・gitignore 対象・ホームディレクトリ等を最終レポートに書かない。「レポート出力原則」と「報告前チェック」を必ず遵守する
- **GitHub auto-link 発火パターンのレポート記載** — `#数字`, `GH-数字`, `org/repo#数字`, `@username`, `@org/team` 等は、レビュー結果が PR コメントへ転記された際に無関係のIssue/PR/ユーザーへ誤誘導する。タスク番号・受け入れ条件番号を表現する際は `#` を絶対に付けない（「タスク内項目 3」「本タスク」のように内部参照に閉じた語へ置換する）