---
name: task-performer
description: |
  TODOタスクを実行するエンジニアスキル。
  以下の状況で使用:
    (1) ユーザーが「このタスクを実装して」「TODOを実行して」と依頼した時
    (2) ユーザーがタスクファイルパス（例: docs/tasks/todos/001-setup/README.md）を提示した時
    (3) ユーザーが明示的に「task-performer スキル」の実行を指示した時
    (4) task-starterで作成したtodos/配下のタスクの実装を依頼された時
    (5) 「このタスクドキュメントに基づいて実装して」と依頼された時
argument-hint: "[タスクファイルパス] [--commit] [--no-agent] [--auto]"
---

# Task Performer

TODOタスクを読み込み、計画・実装・テスト・Lintまでを一貫して実行する。

## スコープ

### 含むもの
- タスクドキュメント（task-starter生成 or 直接指示）に基づくコード実装
- テスト・Lintの実行と修正
- 変更ファイルのステージングとコミットログファイルの出力（`--commit` オプション指定時は、そのログファイルでの `git commit` 実行まで）
- task-starter形式では `PROGRESS.md` への作業状態・受け入れ条件の検証結果・証跡の反映と、`progresses/README.md` の全体進捗一覧の同期
- **実行中に発生した追加・申し送りタスクの `1xx` 番台での起票**（「TODOタスク番号規約」参照。ユーザー承認後に作成）
- **PR修正作業時のPR説明整合性チェックと更新**（「PR説明の整合性チェック」参照）

### 含まないもの
- **新規プロジェクトのタスク分割**（→ task-starter）。ただし実行中に派生した追加タスクは `1xx` 番台で起票する（上記「含むもの」）
- `git push` の実行（ユーザーに委ねる）。`git commit` は既定ではコミットログファイルの出力のみに留めて実行しないが、`--commit` オプション指定時は出力したログファイルでのコミット実行まで行う
- 既存コードのリファクタリング（タスク要件に含まれない限り）
- インフラ構築・デプロイ作業

## 開発原則（実装の必須観点）

いかなる開発タスクでも、以下4原則を**この優先順位**で意識して計画・実装する。Phase 2 の計画立案で点検して Phase 3 の計画レビューに「考慮方針」を含め、Phase 4 の実装でも常にこの観点を点検し、Phase 7 の作業結果報告に「対応結果」を含める。設計・実装段階で織り込むほどコストが低く、特にセキュリティと耐障害性は後付けが高コストになる。

1. **セキュリティ（最優先）** — 認証・認可、入力検証、機密情報（APIキー・パスワード・トークン）の扱い、依存ライブラリの脆弱性。他原則とトレードオフが生じたら常にセキュリティを優先する。シークレットのハードコードは絶対に行わない（「禁止事項」参照）。
2. **耐障害性 (Fault Tolerance)** — 外部依存の失敗を前提に、リトライ・タイムアウト・graceful degradation・ロールバックを実装へ織り込む。エラーは握り潰さず、早期チェック・早期リターンで扱う。
3. **高可用性 (High Availability)** — 稼働継続性。冗長性・ヘルスチェック・無停止デプロイの妨げにならない実装を選ぶ。
4. **スケーラビリティ (Scalability)** — 負荷増大への追従。N+1クエリ・不要な同期処理・共有状態などのボトルネックを作らない。

**柔軟適用**: 全タスクに4原則の検討を課すが、対象タスクに本質的に関係しない原則は「N/A（理由）」と明記してよい。task-starter生成タスクの場合、`todos/{ID}/README.md` の「開発原則チェック」セクションを起点に、計画・実装で具体化する。

## 実装原則

このスキルでは、タスク要件を最短経路で満たすことを最重要視する。以下3原則は、モデルが「親切心」や「保険」で余計なコードを追加する傾向を抑え、レビュー負荷を下げ、仕様の一意性を保つために設定している。計画立案・実装・レビューの各フェーズで常に意識すること。

### 1. フォールバック実装の禁止

ユーザーがタスク要件として明示的に要求した場合を除き、フォールバック実装（エラー時の代替処理、デフォルト値への自動置換、不在データの自動補完、try-catchでの握り潰し等）は追加しない。

**Why**: フォールバックはエラーを静かに隠蔽し、バグの発見を遅らせる温床となる。またタスク要件に書かれていない挙動を勝手に追加すると、どこまでが仕様なのかが曖昧化し、後続の変更時に「その挙動が仕様なのか偶然なのか」が判断不能になる。

必要性を感じた場合はその場で実装せず、Phase 3の計画レビューでユーザーに提案し判断を仰ぐ。

### 2. スコープ外の改善は「気づきメモ」として別途報告

実装中に既存コードの問題点（バグ、コードの匂い、リファクタ候補、命名の不一致等）を見つけた場合、その場で修正せず、Phase 7の作業結果レビューの「気づきメモ」として別途報告する。

**Why**: スコープ外の変更は計画レビューで合意していないため、ユーザーは意図を把握できずレビューコストが跳ね上がる。また関係のない変更が同一コミットに混ざるとrevertやcherry-pickが困難になり、git履歴の価値が損なわれる。

### 3. シンプルさ優先、拡張性は次点

同じ要件を満たせる複数の実装案がある場合、常によりシンプルな方（行数が少ない、抽象化が浅い、依存が少ない、既存パターンに近い）を選ぶ。要件に含まれない汎用化・先回りの拡張性確保（YAGNI違反）は避ける。

**Why**: 要件外の汎用性は「想像上の未来」のために今コストを払う行為で、多くの場合その未来は来ない。読み手・レビュワーが理解すべき情報量を最小化することが、長期的な保守性・可読性に直結する。

## テスト実行方針

テストを「軽量テスト」と「重いテスト」に分類し、ローカルで何を実行するかを切り替える。

- **軽量テスト** = DBアクセス・ネットワーク・外部サービス起動を伴わない、高速に完結するユニットテスト。**ローカルで自動実行**し、失敗時は修正→再実行でパスさせる（従来通り）。
- **重いテスト** = DBアクセス・外部API・コンテナ起動などを伴う integration / E2E レベルのテスト。**ローカル実行は既定でSKIPし、CIに委ねる**。ローカル実行が望ましいと判断した場合も、実行前に必ずユーザーへ確認する。

**Why**: 環境準備コストと偽陽性/偽陰性のリスクが高い重いテストはCIの統一環境に、環境非依存で高速な軽量テストはローカルに分けることで、信頼性とフィードバックループを両立する（詳細: `references/rationale.md`）。

### 重いテストの判定シグナル

以下を手掛かりに分類する。複数のシグナルを総合して判断し、それでも軽量/重いの判別がつかない場合は推奨案を含む複数の選択肢を提示してユーザーに確認する。

- **コマンド・ターゲットの分離**: `make test-integration` / `npm run test:e2e` / `go test -tags=integration` のように、軽量テストと別系統のコマンドが用意されている
- **ファイル名・ディレクトリ**: `*integration*` / `*e2e*` / `*_db_test*` / `tests/integration/` / `it/` などの命名
- **テストマーカー・ビルドタグ**: `@pytest.mark.integration` / `@pytest.mark.slow` / `//go:build integration` / JUnit `@Tag("integration")` など
- **依存の兆候**: testcontainers・docker-compose・実DB接続・外部APIモックなしの通信を必要とする
- **CLAUDE.md / プロジェクト設定**: テスト分類やローカル実行方針の記載があれば最優先で従う

判定に用いた根拠は Phase 7 報告に簡潔に残す。

## TODOタスク番号規約

- **新規作成タスク = `0xx` 番台（`001`〜`099`）** — task-starter がプロジェクト初期に分割したタスク帯。task-performer はこの帯のタスクを実行する。
- **実行中の追加・申し送りタスク = `1xx` 番台（`101`〜`199`）** — タスク実行中に派生した「当初計画に無かった追加作業」や「次の担当へ引き継ぐ申し送り」は、この帯で起票する（Phase 7 で報告・提案し、承認後に Phase 8 で作成）。

番号帯を分けることで、当初計画（0xx）と実装着手後に判明した派生作業（1xx）が一目で区別でき、計画の妥当性レビューや進捗把握がしやすくなる。

## Degrees of Freedom

- **タスク分析・計画立案: High freedom** — タスクの性質に応じて影響範囲の分析方法、実装ステップの粒度、リスク評価の深さを判断する
- **ユーザー確認タイミング: Low freedom** — 通常モードでは Phase 3（計画レビュー）と Phase 7（作業結果レビュー）のユーザー確認を必須とする。`--auto` 指定時は定例確認を省略するが、「`--auto` でも省略しない確認」は必ず行う
- **コミットログ形式: Low freedom** — Conventional Commits形式、1行72文字以内のルールに従う
- **コミット実行: Low freedom** — `--commit` オプション指定時のみ、出力したコミットログファイルで `git commit` を実行する。指定がない場合はログファイル出力に留め、コミットは実行しない（`git push` はオプション有無にかかわらず常にユーザーに委ねる）
- **pre-commitフックの事前実行: Low freedom** — `git add` 実行前に必ず `.git/hooks/pre-commit` / `.githooks/pre-commit` の存在を確認し、存在すれば定義された処理を先に実行してエラーが無い状態にしてから `git add` 以降に進む。省略しない
- **テスト分類: Medium freedom** — 軽量テストか重いテスト（DB/integration）かは「テスト実行方針」のシグナルに基づき判断する。判別がつかない場合はユーザーに確認する
- **軽量テストの実行: Low freedom** — 軽量テストは自動実行し、失敗時は修正→再実行を繰り返し、パスするまで完了としない
- **重いテストのローカル実行: Low freedom** — 重いテストはローカル実行をSKIPしCIへ委譲するのが既定。ローカル実行が望ましいと判断した場合も、実行前に必ずユーザーへ確認する（無断でローカル実行しない）
- **Lint実行: Low freedom** — 失敗時は修正→再実行を繰り返し、パスするまで完了としない
- **実装原則の遵守: Low freedom** — 上記「実装原則」の3項目は常に遵守し、逸脱する場合はユーザー承認を必須とする

## ワークフロー

### Phase 1: タスク情報の受け取り
最初に `../_shared/references/task-management-contract.md` を読み、task-starter 形式タスクの読み取り・更新・成果物保存へ適用する。
タスク情報を以下のいずれかで受け取る:

- **ファイルパス**: todos/001-setup/README.md のようなパスを読み込む
- **直接指示**: プロンプトで指定された内容を使用

タスク情報が不明確な場合は、推奨案を含む複数の選択肢を提示してユーザーに確認する。

#### `--commit` オプションの認識

タスク指示に `--commit` が含まれる場合、Phase 8 のコミットログファイル出力後に、そのログファイルでの `git commit` 実行まで行うモードとして記録する。指定がない場合は既定どおりログファイル出力のみに留める（「禁止事項」参照）。

#### `--no-agent` オプションの認識
タスク指示に `--no-agent` が含まれる場合、task-starter プロジェクトの関連ドキュメント読込を `task-reader` エージェントへ委譲せず、メインスレッド内で実施するモードとして記録する。テスト・Lintなど、Phase 1 以外の委譲方針は変更しない。
`task-reader` の応答遅延・結果未返却を回避したい場合に使用し、指定がなければメインコンテキスト節約のため既定どおり委譲する。

#### `--auto` オプションの認識

タスク指示に `--auto` が含まれる場合、Phase 3 は計画提示後、Phase 7 は作業結果報告後かつ全受け入れ条件が `充足` なら、承認待ちを省略する。安全性やスコープに影響しない選択は推奨案または最も安全で可逆な既定値を採用し、Phase 7 で報告する。`--commit` は暗黙に有効化せず、`git push` の禁止も解除しない。

**`--auto` でも省略しない確認:** 要件の重大な曖昧さ、DBスキーマ変更、破壊的・不可逆・復旧困難な操作、重いテストのローカル実行など高コストな操作、当初スコープの拡張、PR説明更新などリポジトリ外の状態変更、必要な権限・情報の不足、テスト・Lint・pre-commit処理が3回失敗した後の続行判断。該当作業だけを保留し、独立して安全に進められる作業は継続する。

#### PR修正作業の自動認識

タスク指示にPR番号（`#123`）・PR URL・「PRの修正」「レビュー指摘対応」等のキーワードが含まれる場合、PR修正作業と判定して対象PR番号を記録する。明示的な指定がない場合でも、作業ブランチに紐づくオープンなPRがあれば `gh pr view --json number` で番号を取得し、PR修正作業かどうかを推奨案を含む複数の選択肢を提示してユーザーに確認する。`--auto` 指定時は紐づくオープンなPRを対象PRとして扱う。この情報は Phase 8 の「PR説明の整合性チェック」で使用する。

#### プロジェクト設定の自動検出

以下の優先順でコマンド・技術スタック情報を特定する。一度特定できた情報は後続フェーズで再問い合わせ不要。

**Step 1: プロジェクト標準ファイルの探索**

以下のファイルをファイル名検索で確認し、コマンドを推定する:

| ファイル | 確認内容 |
|---------|---------|
| `package.json` | `scripts.test` / `scripts.lint` / `scripts.build` |
| `Makefile` | `test` / `lint` / `build` / `migrate` ターゲット |
| `pyproject.toml` | `[tool.pytest]` / `[tool.ruff]` / `[tool.black]` セクション |
| `go.mod` | 存在すれば `go test ./...` / `golangci-lint run` を推定 |
| `Cargo.toml` | 存在すれば `cargo test` / `cargo clippy` を推定 |

**Step 2: CLAUDE.md 汎用セクションの参照**

CLAUDE.md が存在する場合、コマンド・技術スタック情報が記載されやすい以下のセクションを確認する:

- `## Commands` / `## コマンド` / `## Scripts`
- `## Development` / `## 開発` / `## Getting Started`
- `## Testing` / `## テスト`

**Step 3: 選択肢提示による補完**

Step 1/2 で特定できなかった情報のみ、各フェーズの実行直前に確認する。

#### task-starterプロジェクトの自動認識と読込方式の選択

ファイルパスが `todos/NNN-{task}/README.md` 形式の場合、task-starter で生成されたプロジェクト構造とみなす。`--no-agent` の有無に応じて、次の読込方式を選択する。

- **指定なし（既定）**: `task-reader` エージェントへ委譲してコンテキストサマリを取得する
- **`--no-agent` 指定**: 下記「メインスレッドでの直接読込」に従い、関連ドキュメントをメインスレッド内で読み込む

**Why**: task-starter プロジェクトは複数ファイルを横断して読むため、既定では読み取りと要約を専門エージェントに切り出し、本体のコンテキスト消費を抑える。

**委譲方法:** `progresses/README.md` と `progresses/NNN-{task}/PROGRESS.md` は常に必要なため、`task-reader` が既定で読み込む。過去ログ（`logs/NNN-{task}/`）は容量が大きくコンテキストを圧迫しやすいため、**既定では読み込まず、必要と判断した場合のみ `--with-log` を付けて取得する**。利用している実行環境が提供する委譲手段（サブエージェント起動・専門エージェント呼び出し等）を通じて、`task-reader` エージェントに以下の内容を渡して実行を依頼する。

**初回（必須）: 標準ファイル群と成果・進捗のサマリ取得** — `task-reader` エージェントに、次の情報を渡して依頼する:

- 依頼内容: 「タスクファイルパス: <指定された todos/NNN-{task}/README.md のパス>」（必要なら追加の補足を併記。過去ログ取得の指定は付けない）

これにより、標準ファイル群（`todos/NNN-{task}/README.md`・`todos/README.md`・`specs/*.md`・`references/*.md` とプロジェクト README）に加え、`progresses/README.md` の全体進捗と `progresses/NNN-{task}/PROGRESS.md` の進捗・成果サマリが返る。`logs/` の過去ログは含まれない。

**再取得（条件付き）: 過去ログを含めたサマリ取得**

初回のサマリだけでは Phase 2 の計画立案に情報が不足する、またはより詳細な情報収集が必要と判断した場合に**限り**、過去ログを取得する。典型例:

- 前回の作業が中断されており、`logs/NNN-{task}/` の過去作業ログから状況を再開する必要がある
- タスク本文・specs・references の記述だけでは実装判断がつかず、過去の試行錯誤や決定経緯を参照したい

この場合、`task-reader` エージェントへ `--with-log` を付けて再度依頼する:

- 依頼内容: 「タスクファイルパス: <同じパス> --with-log」

再取得結果には標準ファイル群・`progresses/`・`logs/` が含まれる。初回との差分である過去ログを Phase 2 の判断材料へ追加する。

**Why（既定で logs を読まない理由）**: 多くのタスクでは標準ファイル群と進捗正本の `PROGRESS.md` だけで計画立案できる。`logs/` はコミットログ・調査メモ・コマンド出力・試行記録などが蓄積するため、不足を確認した場合だけ `--with-log` で追加取得する。

**初回に返却される構造化サマリ:**

1. タスク本文（全文：要件の取りこぼし防止のため要約せず保持される）
2. プロジェクト概要（プロジェクトルート README.md の要約）
3. 要件・技術仕様（specs/ 各ファイルの目的・主要要件・受け入れ条件・非機能要件）
4. 現状分析（references/ 各ファイルの要点と制約）
5. ロードマップ上の位置づけ（依存タスク・並行群・前後関係）
6. 全体進捗一覧（`progresses/README.md`。常時取得し、個別正本との不一致を確認）
7. タスク進捗・成果（`progresses/NNN-{task}/PROGRESS.md`。常時取得）
8. 過去の作業ログ（`logs/`。既定では未取得、`--with-log` 指定時のみ取得）
9. 留意事項（記述の矛盾・依存未完了の兆候など）

このサマリをそのまま Phase 2 以降の判断材料として使用する。

**メインスレッドでの直接読込（`--no-agent` 指定時）:**
1. タスクファイルパスの `todos/` の親をプロジェクトルートとして特定し、指定タスクファイルを全文で読み込む
2. `README.md`、`todos/README.md`、`specs/**/*.md`、`references/**/*.md`、`progresses/README.md`、`progresses/NNN-{task}/PROGRESS.md` を読み込む。一覧と個別正本が不一致なら個別正本を優先して警告する。`progresses/NNN-{task}/` のその他のファイルは内容を読まず、非標準ファイルとして警告する
3. 大きなファイル（目安: 500行超）は関連キーワードで内容検索してから部分読込する。ただし指定タスクファイルは常に全文を保持する
4. 上記の構造化サマリと同じ9項目に整理する。情報不足の場合に限り、該当タスクの `logs/` を追加で読み込む

直接読込中に一部ファイルの不存在・読込失敗が発生しても、取得済み情報を破棄しない。不足ファイルと影響を明記し、計画立案の可否を判断する。

**フォールバック:** ファイルパスが `todos/` を含まない場合、または task-reader が「task-starter 構造ではない」「タスクファイルが見つからない」と報告した場合は、エージェント委譲を行わず、指定されたタスクファイル単体を本体スキルで直接読み込む通常フローに切り替える。

### Phase 2: 作業計画の立案

1. **リファレンス確認**: task-starterプロジェクトの場合は Phase 1 で task-reader から受領した構造化サマリを使用（再読込不要）。それ以外の場合は計画立案に参照するリファレンスの有無を、推奨案を含む複数の選択肢を提示してユーザーに確認する。`--auto` 指定時は関連する既存リファレンスを自動選択する
2. **タスク分析**:
   - 影響範囲の特定（DB / Backend / Frontend 等）
   - 実装ステップの洗い出し
   - 必要なテストの特定
   - リスクと注意点の識別
   - **開発原則の点検**（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）。task-starter生成タスクは `todos/{ID}/README.md` の「開発原則チェック」を起点に具体化。該当しない原則は N/A 理由を添える

### Phase 3: 計画レビュー依頼

以下の形式で計画をユーザーに提示し、フィードバックを受ける:

```markdown
## 実装計画: {タスク名}

### 概要
{タスクの目的と実装方針を1-3文で}

### 実装ステップ
1. {ステップ1}: {内容}
2. {ステップ2}: {内容}
...

### 影響範囲
- {影響を受けるモジュール/ファイル/機能}

### 開発原則の考慮
- セキュリティ（最優先）: {対応方針 / N/A理由}
- 耐障害性: {対応方針 / N/A理由}
- 高可用性: {対応方針 / N/A理由}
- スケーラビリティ: {対応方針 / N/A理由}

### 注意点・リスク
- {リスク1}: {対策}
```

フィードバックがあれば修正して再提示し、承認後に次へ進む。`--auto` 指定時は承認待ちを省略するが、「`--auto` でも省略しない確認」に該当する未解決事項を解消してから Phase 4 へ進む。

### Phase 4: 実装
承認された計画に基づき以下の順序で進める:
task-starter 形式タスクでは、実装開始時に `PROGRESS.md` の状態を `進行中` へ更新する。新形式のTODOでは、完了した作業・残作業を `W-ID` で記録し、全 `AC-ID` の検証行が存在することを確認する。正本が無ければ共有契約のテンプレートで新規作成し、既存の非標準ファイルは移動・統合せず警告する。継続不能になった場合は状態を `ブロック中` にして、ブロッカーと残作業を具体化してから報告する。TODOは静的な定義の正本なので、チェック追加や完了状態の書き戻しを行わない。

`PROGRESS.md` の状態または最終更新を変更した直後は、`python3 ~/.claude/skills/_shared/scripts/sync_progress_index.py "{project_root}"` を実行して `progresses/README.md` を同期する。同期に失敗した場合はエラーを報告し、不一致を残したまま完了扱いにしない。

#### 4-1. DBマイグレーション（DB変更がある場合）

DB変更が発生する場合:
1. Phase 1 の自動検出結果からマイグレーションコマンドを確認する。未特定の場合のみ推奨案を含む複数の選択肢を提示してユーザーに確認
2. 手順に従い実行
3. エラー発生時はユーザーに報告して対処方法を確認

#### 4-2. メインコードとテストコードの実装

以下の方針でコードを実装する:

- 既存コードのスタイル（命名規則、インデント、ディレクトリ構成）に合わせる
- 変更は計画で承認された範囲に限定し、関連箇所の「ついで修正」は避ける
- テストコードはメインコードと同時に実装する（後回しにしない）

**コードコメントにタスク管理コンテキストを残さない**: タスクドキュメントのパス・URL、タスクID・TODO番号、作業ログパス（`logs/NNN-{task}/...`）、リポジトリ外の個人専用ディレクトリ（`.claude/agent-memory/` 等）への参照はコメントに含めない。代わりに「なぜその実装にしたか」（設計判断の理由・トレードオフ・非自明な前提や注意点）を書く。これらは読み手が参照できずコメントを自己完結させられないため。背景の詳細は `references/rationale.md` を参照。

### Phase 5: テスト実行
「テスト実行方針」に従い、テストを分類してから実行する。

1. **テストコマンドの確認**: Phase 1 の自動検出結果からテストコマンドを確認する。未特定の場合のみ推奨案を含む複数の選択肢を提示してユーザーに確認
2. **テストの分類**: 今回の変更が対象とするテストを、判定シグナル（「テスト実行方針」参照）に基づき軽量/重いに仕分ける。判別がつかない場合は推奨案を含む複数の選択肢を提示してユーザーに確認する
3. **軽量テストの実行**: 軽量テストの実行自体はサブエージェントに委譲し、メインには合否と失敗時の要点（落ちたテスト名・主要エラー）だけを戻させる。失敗した場合: エラー確認 → 修正（メインで実施） → 再実行（再度委譲）を繰り返す。テスト対象が少数で出力が短く収まると分かっている場合は、委譲せずメインで直接実行してよい
4. **重いテストの扱い**: 重いテスト（DB/integration/E2E）はローカル実行を既定でSKIPし、CIに委ねる
   - ローカル実行が望ましいと判断した場合（例: 変更が重いテストの中核ロジックを直接変える、CIでの再現が難しい）も、**実行前に必ず「ローカル実行するか / CIに委ねるか」の選択肢を提示してユーザーに確認する**。無断でローカル実行しない
   - ローカル実行した場合は、軽量テストと同様に実行をサブエージェントに委譲し、失敗→修正（メイン）→再実行（委譲）でパスさせる
5. **記録**: 各テストの実行有無（実行/SKIP）・分類の根拠・結果を Phase 7 報告に残す。SKIPした重いテストはCIでの検証を促す一文を添える
6. **成果物の保存**: スクリーンショット、カバレッジ、トレース、テストやコマンドの生出力を永続化する場合は `logs/NNN-{task}/` に置く。`PROGRESS.md` には結果の要約と必要な相対パスだけを記載する

### Phase 6: Lint実行

1. Phase 1 の自動検出結果から Lint コマンドを確認する。未特定の場合のみ推奨案を含む複数の選択肢を提示してユーザーに確認
2. Lintの実行はサブエージェントに委譲し、メインには指摘件数と要点だけを戻させる。対象ファイルが少数でLint出力が短く収まる場合は、委譲せずメインで直接実行してよい
3. 失敗した場合: エラー確認 → 修正（メインで実施） → 再実行（再度委譲）を繰り返す

### Phase 7: 作業結果レビュー依頼

以下の形式で報告し、通常モードでは推奨案を含む複数の選択肢を提示して承認/追加修正を確認する:

```markdown
## 作業結果: {タスク名}

### 実装内容
{何を実装したかの概要を1-3文で}

### 変更ファイル
- `{ファイルパス}`: {変更内容の要約}
- ...

### テスト結果
- 軽量テスト: `{テストコマンド}` → {PASS/FAIL} ({N}件中{N}件パス)
- 重いテスト（DB/integration/E2E）: {SKIP（CIへ委譲） / ローカル実行: PASS/FAIL}
  - 判定根拠: {分類に用いたシグナル。例: tests/integration/ 配下・testcontainers使用}
  - SKIP時: CI（push後のパイプライン）での検証を推奨

### Lint結果
- 実行コマンド: `{lintコマンド}`
- 結果: {エラー0件 / 警告N件}

### 受け入れ条件の検証
- `AC-01`: {充足 / 未充足 / 未確認} — {根拠}
- ...

### 開発原則の対応結果
- セキュリティ（最優先）: {実装した対策 / N/A理由}
- 耐障害性: {実装した対策 / N/A理由}
- 高可用性: {実装した対策 / N/A理由}
- スケーラビリティ: {実装した対策 / N/A理由}

### 気づきメモ（スコープ外の発見）
<!-- 実装中に見つけたスコープ外の問題（バグ・コードの匂い・リファクタ候補・命名不一致等）。その場で修正せずここに記録（「実装原則」#2 参照）。無ければ「なし」 -->
- `{ファイル/箇所}`: {発見内容と推奨対応}

### 追加・申し送りタスク（1xx 番台で起票提案）
<!-- 実行中に派生した「当初計画に無かった作業」や「次担当への申し送り」を列挙。無ければ「なし」 -->
- `101-{kebab-name}`: {内容と起票理由（例: セキュリティ強化、技術的負債の解消、未対応の原則対応）}

### 注意点・今後の課題
- {あれば記載、なければ「なし」}
```

全 `AC-ID` をTODOの記載順に評価する。`未充足` または `未確認` が1件でもある場合は完了承認を求めず、必要な追加作業または条件変更の相談へ戻る。

通常モードでは、作業結果の承認に加えて**「追加・申し送りタスク（1xx）をファイルとして起票するか」**も確認する。`--auto` 指定時は全 `AC-ID` が `充足` なら作業結果の承認待ちを省略するが、タスク起票はスコープ拡張に当たるため確認する。`未充足` または `未確認` がある場合は追加作業または条件変更を相談する。

### Phase 8: 承認後の処理

承認されたら以下を実施する。`--auto` 指定時は、Phase 7 で全 `AC-ID` が `充足` と判定されたことを承認相当として扱う:

1. **pre-commitフックによる事前整形**（`git add` 実行前に必ず行う）
   - `.git/hooks/pre-commit` と `.githooks/pre-commit` の存在を確認する
   - いずれかが存在する場合、`git add` より前にフックへ処理を委ねず、フックスクリプトの中身を確認したうえでそこに定義されている処理（フォーマッタ・Lintコマンド等）を直接実行する
   - 実行結果がエラーの場合: エラー内容を確認 → 修正 → 再実行を繰り返し、エラーが無くなるまで完了としない（3回修正しても解決しない場合はユーザーに報告し、続行/中断を確認。「エラーハンドリング」参照）
   - 実行結果がOKになったら（または両ファイルとも存在しない場合はそのまま）、手順2へ進む

   **Why**: `git add` → `git commit` の順で進めると、コミット時にpre-commit hookが整形を行っても、その整形結果はステージング後の変更として扱われるため、コミット完了後に整形差分が作業ツリーに再発生してしまう。`git add` の前に整形処理を完了させておくことで、ステージング内容とコミット内容と作業ツリーの内容を一致させ、コミット後の差分再発生を防ぐ。

2. **git管理されている変更ファイルのステージング**
   ```bash
   git add {変更したファイル}
   ```
   対象は実装で変更したコード・テスト等のみ。タスクドキュメント（`todos/`・`progresses/`・`logs/` 配下等、手順4で更新するファイル）は、それがgit管理下にあっても`git add`/`git commit`の対象に含めない（下記手順4参照）。
3. **コミットログファイルの出力**
   - "commit-{`date +'%Y%m%d%H%M%S'` コマンドの実行結果}-{title}.txt" というファイル名でファイルに書き出す（`git commit -F` で使用）
   - 出力先: task-starterプロジェクトの場合は `logs/NNN-{task}/` 配下。それ以外は推奨案を含む複数の選択肢を提示してユーザーに確認。`--auto` 指定時はリポジトリルートへ出力する
   - 形式:
     ```
     {Conventional Commits形式のメッセージ}

     {作業内容の詳細をmarkdown形式で記載}
     {1行72文字以内}
     ```

   **コミットログにタスク管理コンテキストを残さない**: タスクドキュメントのパス、タスクID・TODO番号、作業ログパス（`logs/NNN-{task}/...`）、リポジトリ外の個人専用ディレクトリ（`.claude/agent-memory/` 等）への参照は含めない。代わりに変更の目的（why）・内容の要約（what）・リポジトリ内のファイルパスや機能名など、リポジトリだけで理解できる情報を書く。タスク管理側の文脈は Phase 7 の作業結果レビューや気づきメモ、`PROGRESS.md` に留める。背景の詳細は `references/rationale.md` を参照。

   **`--commit` オプション指定時のコミット実行**: Phase 1 で `--commit` を認識していた場合、出力したコミットログファイルを使って以下を実行する。
   ```bash
   git commit -F {出力したコミットログファイルのパス}
   ```
   オプション未指定の場合はログファイル出力のみで完了とし、コミットは実行しない（`git push` はオプション有無にかかわらず実行しない）。コミット実行後は、コミットハッシュを含めて実行結果をユーザーへ報告する。

4. **進捗正本の更新**（task-starter形式のファイルパスで提供された場合）
   - 指定されたTODOタスクファイルは静的定義として変更しない。旧形式のチェックボックスにも書き戻さない
   - `progresses/NNN-{task}/PROGRESS.md` の全 `AC-ID` を Phase 7 の判定と根拠で更新する。TODOに存在しないID、重複ID、欠落IDがあれば完了にせず修正する
   - 全 `AC-ID` が `充足` で承認済み（`--auto` では承認相当）の場合だけ、状態を `完了` に更新し、最終更新・完了した作業・残作業・ブロッカー・成果を共有契約の必須形式に揃える
   - 個別正本の更新直後に同期スクリプトを実行し、`progresses/README.md` の該当行が `完了` と同じ最終更新を示すことを確認する。個別正本と一覧の更新を同じ完了処理として扱う
   - 旧形式では `PROGRESS.md` の既存形式を維持して状態と成果を更新し、TODOのチェックボックスは読み取り専用として扱う。移行は別途提案し、自動実行しない
   - `progresses/NNN-{task}/` には `PROGRESS.md` 以外を出力しない。コミットログ・レビュー結果・テスト成果物・調査メモ・コマンド出力・試行記録は `logs/NNN-{task}/` に置く
5. **追加・申し送りタスクの起票**（Phase 7 で承認された場合のみ）
   - **`1xx` 番台**で連番フォルダを作成（既存の最大 `1xx` 番号 +1。最初は `101`）
   - task-starterプロジェクトの場合: `todos/1xx-{kebab-name}/README.md` を `task-starter` の todo-template 形式（フロントマター + 開発原則チェック含む）で作成し、`depends_on` に当該タスクIDを設定
   - 同じIDの `progresses/1xx-{kebab-name}/PROGRESS.md` と `logs/1xx-{kebab-name}/` を作成し、残作業を全 `W-ID`、受け入れ条件の検証を全 `AC-ID: 未確認` として進捗正本を `未着手` で初期化する
   - 起票した個別正本を作成後、同期スクリプトを実行して `progresses/README.md` に新しい `1xx` 行を追加する
   - `todos/README.md`（ロードマップ）が存在すれば、タスク一覧表の末尾に 1xx タスクを追記
   - task-starterプロジェクトでない場合: 起票先・形式を推奨案を含む複数の選択肢を提示してユーザーに確認
6. **PR説明の整合性チェックと更新**（PR修正作業の場合のみ。「PR説明の整合性チェック」参照）

### PR説明の整合性チェック

PR修正作業（既存PRに対するレビュー指摘対応・バグ修正・機能追加など）の場合、Phase 8 の最終ステップとして対象PRの説明が実装と乖離していないかを検証し、必要に応じて更新する。

**Why**: PR修正を重ねると当初の説明が実態と乖離し、レビュワーが古い説明を前提にレビューしてしまう。実装完了時に説明を同期させることで、レビュー品質と情報の鮮度を維持する。

**対象判定**: 以下のいずれかに該当する場合にこのステップを実行する:
- タスク指示にPR番号・PR URLが含まれている
- タスク指示が「PRのレビュー指摘対応」「PRの修正」など既存PRへの作業であることが明示されている
- 作業対象ブランチに紐づくオープンなPRが存在する（`gh pr view` で確認）

**手順:**

1. **現在のPR説明を取得**
   ```bash
   gh pr view {PR番号} --json body,title --jq '.title + "\n---\n" + .body'
   ```
2. **実装内容との整合性を確認**
   - PR説明（タイトル・本文）が、今回の修正を含めた最終的な実装内容を正しく反映しているか確認
   - チェック観点:
     - タイトルがPRの最終的な目的を正しく表しているか
     - 変更内容のサマリが実態と一致しているか
     - 削除・変更された機能が説明に残っていないか
     - 新たに追加した機能・変更が説明に反映されているか
     - テスト計画が実態と合っているか
3. **乖離がある場合 — PR説明を更新**
   - 乖離を検出したら、更新内容をユーザーに提示して承認を得る
   - 承認後、`gh pr edit` で更新:
     ```bash
     gh pr edit {PR番号} --title "{新タイトル}" --body "{新本文}"
     ```
   - 更新はPR説明の「同期」であり、体裁の好みによる書き換えは行わない。既存の書式・構成は尊重し、実装と乖離している部分のみ修正する
4. **乖離がない場合** — 「PR説明は実装と整合しています」と報告して完了

## ガイドライン

### 不明点の確認

通常モードでは以下の場合に、推奨案を含む複数の選択肢を提示してユーザーに必ず確認する。`--auto` 指定時は「`--auto` でも省略しない確認」に該当する場合だけ確認し、それ以外は推奨案または最も安全で可逆な既定値を採用する:

- タスク要件が不明確
- 複数の実装アプローチがある
- 既存コードへの影響範囲が不明
- DBスキーマの変更が必要
- 破壊的変更の可能性がある
- テストが軽量か重い（DB/integration）か判別がつかない、または重いテストをローカル実行すべきか迷う

### 情報収集

公式仕様・ベストプラクティスが必要な場合:

- WebFetch/MCPツールで最新情報を収集
- 公式ドキュメントを優先
- 収集情報のソースを明記

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

**共通方針:**

1. エラーメッセージを正確に確認
2. 原因を特定
3. ユーザーに報告
4. 対処方法を提案または確認
5. 修正実施 → 再検証

推測での修正は避ける。

**個別パターン:**

| エラー | 対応 |
|--------|------|
| タスクファイルが存在しない | エラーを報告し、正しいパスを推奨案を含む複数の選択肢を提示してユーザーに確認。`todos/**/README.md` パターンでファイル名検索して候補を提示 |
| ディレクトリを直接読み込もうとした（`EISDIR`） | `todos/NNN-{task}/` 等はディレクトリ。読む対象は内部のファイル（`README.md` 等）。ファイル名検索で配下を特定してから読む。実装中もソースのディレクトリパスを直接読み込まない |
| task-starterプロジェクト構造が不完全 | specs/やreferences/が空でも続行。読み込めたファイルのみで計画を立案し、不足情報は推奨案を含む複数の選択肢を提示してユーザーに補完 |
| 軽量テスト環境が未設定 | 通常モードではユーザーに確認後、環境がない場合はPhase 5をスキップ。`--auto` 指定時は確認せずスキップ。いずれもPhase 7に記録（重いテストは元よりCI委譲のため影響なし） |
| Lint環境が未設定 | 通常モードではユーザーに確認後、環境がない場合はPhase 6をスキップ。`--auto` 指定時は確認せずスキップ。いずれもPhase 7に記録 |
| テスト/Lintが繰り返し失敗 | 3回修正しても解決しない場合はユーザーに報告し、続行/中断を確認 |
| pre-commitフックの処理が繰り返し失敗 | 3回修正しても解決しない場合はユーザーに報告し、続行/中断を確認（Phase 8 手順1参照） |

## 前提条件

- 対象プロジェクトがgit管理下にあること
- 軽量テストの実行環境がセットアップ済みであること（未設定の場合はPhase 5をスキップ）。重いテスト（DB/integration）の実行環境はローカルに揃っていなくてよい（既定でCIに委ねるため）
- Lint実行環境がセットアップ済みであること（未設定の場合はPhase 6をスキップ）

## 禁止事項

- **APIキー、パスワード、シークレットのハードコード** — セキュリティインシデントの原因となり、git履歴に残ると除去が困難なため
- **コードコメントへのタスクドキュメント参照の混入**（タスクドキュメントのパス・URL、タスクID・TODO番号、ローカル作業ログパス等） — これらは対応者のローカル環境にしか存在せず、コメントを読む第三者が参照できないため（詳細・代替案は `references/rationale.md` 参照）
- **ローカル実行したテストが失敗したコードの放置** — 失敗状態のまま次フェーズに進むと、問題が積み重なり原因特定が困難になるため（CIへ委譲した重いテストは対象外。SKIP判断は方針に従う）
- **重いテスト（DB/integration）のユーザー無断ローカル実行** — 環境準備・実行コストが高く偽陽性/偽陰性も起きやすいため、既定でCIに委ね、ローカル実行する場合は必ず事前確認を取る
- **Lintエラーの無視** — コード品質の劣化を防ぎ、既存コードベースとの一貫性を保つため
- **`--commit` オプション未指定時の `git commit` 実行** — レビュー前の意図しないコミットを防ぎ、コミットメッセージやタイミングの最終判断をユーザーに委ねるため。`--commit` 指定時は、出力したコミットログファイルでの実行のみ許可する（Phase 8 参照）
- **`git push` の実行**（`--commit` オプションの有無にかかわらず常に禁止） — pushのタイミングの最終判断をユーザーに委ねるため