Task Performer Skill | Agent Skills

Task Performer

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

スコープ

含むもの

タスクドキュメント（task-starter生成 or 直接指示）に基づくコード実装
テスト・Lintの実行と修正
変更ファイルのステージングとコミットログファイルの出力（--commit オプション指定時は、そのログファイルでの git commit 実行まで）
タスクドキュメントへの完了状態の反映
実行中に発生した追加・申し送りタスクの 1xx 番台での起票（「TODOタスク番号規約」参照。ユーザー承認後に作成）
PR修正作業時のPR説明整合性チェックと更新（「PR説明の整合性チェック」参照）

含まないもの

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

ユースケース

ユースケース: TODOタスクの実装
トリガー: 「このタスクを実装して」「task-performer スキルで docs/tasks/todos/001-setup/README.md を実行して」
          「TODOを実行して」「このタスクドキュメントに基づいて実装して」
手順:
1. タスク情報を受け取る（ファイルパスまたは直接指示）
2. 影響範囲を分析し、実装計画を立案
3. ユーザー承認後、コード実装・テスト・Lintを実行
4. 作業結果を報告し、承認後にステージング・コミットログ出力（`--commit` オプション指定時はコミット実行まで）
成功基準:
- タスクで定義された要件がすべて実装されていること
- 開発原則（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）が点検され、対応結果がPhase 7報告に含まれていること
- 軽量テスト（DBアクセス・外部依存のない高速テスト）が全件パスしていること。DB/integration等の重いテストはローカル実行をSKIPしCIへ委譲し、その旨がPhase 7報告に明記されていること（「テスト実行方針」参照）
- Lintエラーがゼロであること
- 変更ファイル（タスクドキュメントを除くコード・テスト等）がgit addされ、コミットログは `logs/`、成果・進捗管理ドキュメントは `progresses/` に出力されていること（`--commit` オプション指定時は、そのログファイルでの `git commit` が実行されていること）
- 実行中に派生した追加・申し送りタスクがあれば 1xx 番台で起票（または報告）されていること

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

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

セキュリティ（最優先） — 認証・認可、入力検証、機密情報（APIキー・パスワード・トークン）の扱い、依存ライブラリの脆弱性。他原則とトレードオフが生じたら常にセキュリティを優先する。シークレットのハードコードは絶対に行わない（「禁止事項」参照）。
耐障害性 (Fault Tolerance) — 外部依存の失敗を前提に、リトライ・タイムアウト・graceful degradation・ロールバックを実装へ織り込む。エラーは握り潰さず、早期チェック・早期リターンで扱う。
高可用性 (High Availability) — 稼働継続性。冗長性・ヘルスチェック・無停止デプロイの妨げにならない実装を選ぶ。
スケーラビリティ (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（作業結果レビュー）での、推奨案を含む複数の選択肢を提示してのユーザー確認は必須。省略しない
コミットログ形式: 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: タスク情報の受け取り

タスク情報を以下のいずれかで受け取る:

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

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

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

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

`--no-agent` オプションの認識

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

PR修正作業の自動認識

タスク指示にPR番号（#123）・PR URL・「PRの修正」「レビュー指摘対応」等のキーワードが含まれる場合、PR修正作業と判定して対象PR番号を記録する。明示的な指定がない場合でも、作業ブランチに紐づくオープンなPRがあれば gh pr view --json number で番号を取得し、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/NNN-{task}/ の成果・進捗管理ドキュメントは常に必要なため、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/NNN-{task}/ の成果・進捗管理ドキュメントのサマリが返る。logs/ の過去ログは含まれない。

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

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

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

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

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

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

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

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

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

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

メインスレッドでの直接読込（--no-agent 指定時）:

タスクファイルパスの todos/ の親をプロジェクトルートとして特定し、指定タスクファイルを全文で読み込む
README.md、todos/README.md、specs/**/*.md、references/**/*.md、progresses/NNN-{task}/**/* をファイル名検索で列挙して読み込む。ディレクトリ自体は読み込まない
大きなファイル（目安: 500行超）は関連キーワードで内容検索してから部分読込する。ただし指定タスクファイルは常に全文を保持する
上記の構造化サマリと同じ8項目に整理する。情報不足の場合に限り、該当タスクの logs/ を追加で読み込む

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

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

Phase 2: 作業計画の立案

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

Phase 3: 計画レビュー依頼

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

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

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

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

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

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

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

フィードバックがあれば修正して再提示。承認されたら次へ進む。

Phase 4: 実装

承認された計画に基づき以下の順序で進める:

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

DB変更が発生する場合:

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

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

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

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

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

Phase 5: テスト実行

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

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

Phase 6: Lint実行

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

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

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

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

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

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

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

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

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

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

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

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

報告後の選択肢提示では、作業結果の承認に加えて**「追加・申し送りタスク（1xx）をファイルとして起票するか」**も確認する。

Phase 8: 承認後の処理

承認されたら以下を実施:

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 の前に整形処理を完了させておくことで、ステージング内容とコミット内容と作業ツリーの内容を一致させ、コミット後の差分再発生を防ぐ。
git管理されている変更ファイルのステージング
```
git add {変更したファイル}
```
対象は実装で変更したコード・テスト等のみ。タスクドキュメント（todos/・progresses/・logs/ 配下等、手順4で更新するファイル）は、それがgit管理下にあってもgit add/git commitの対象に含めない（下記手順4参照）。
コミットログファイルの出力
- "commit-{date +'%Y%m%d%H%M%S' コマンドの実行結果}-{title}.txt" というファイル名でファイルに書き出す（git commit -F で使用）
- 出力先: task-starterプロジェクトの場合は logs/NNN-{task}/ 配下。それ以外は推奨案を含む複数の選択肢を提示してユーザーに確認
- 形式:
```
{Conventional Commits形式のメッセージ}

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

--commit オプション指定時のコミット実行: Phase 1 で --commit を認識していた場合、出力したコミットログファイルを使って以下を実行する。
```
git commit -F {出力したコミットログファイルのパス}
```
オプション未指定の場合はログファイル出力のみで完了とし、コミットは実行しない（git push はオプション有無にかかわらず実行しない）。コミット実行後は、コミットハッシュを含めて実行結果をユーザーへ報告する。
タスクファイル更新（ファイルパスで提供された場合）
- タスクの作業ログや完了状態を、指定されたTODOタスクファイルにも反映
- 成果ドキュメントや PROGRESS.md 等の進捗管理ドキュメントをファイル出力する場合は progresses/NNN-{task}/ に置く
- コミットログ・調査メモ・コマンド出力・試行記録など、上記2種類以外は logs/NNN-{task}/ に置く
追加・申し送りタスクの起票（Phase 7 で承認された場合のみ）
- 1xx 番台で連番フォルダを作成（既存の最大 1xx 番号 +1。最初は 101）
- task-starterプロジェクトの場合: todos/1xx-{kebab-name}/README.md を task-starter の todo-template 形式（フロントマター + 開発原則チェック含む）で作成し、depends_on に当該タスクIDを設定
- todos/README.md（ロードマップ）が存在すれば、タスク一覧表の末尾に 1xx タスクを追記
- task-starterプロジェクトでない場合: 起票先・形式を推奨案を含む複数の選択肢を提示してユーザーに確認
PR説明の整合性チェックと更新（PR修正作業の場合のみ。「PR説明の整合性チェック」参照）

PR説明の整合性チェック

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

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

対象判定: 以下のいずれかに該当する場合にこのステップを実行する:

タスク指示にPR番号・PR URLが含まれている
タスク指示が「PRのレビュー指摘対応」「PRの修正」など既存PRへの作業であることが明示されている
作業対象ブランチに紐づくオープンなPRが存在する（gh pr view で確認）

手順:

現在のPR説明を取得

gh pr view {PR番号} --json body,title --jq '.title + "\n---\n" + .body'

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

ガイドライン

不明点の確認

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

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

情報収集

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

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

エラーハンドリング

共通方針:

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

推測での修正は避ける。

個別パターン:

| エラー | 対応 | |--------|------| | タスクファイルが存在しない | エラーを報告し、正しいパスを推奨案を含む複数の選択肢を提示してユーザーに確認。todos/**/README.md パターンでファイル名検索して候補を提示 | | ディレクトリを直接読み込もうとした（EISDIR） | todos/NNN-{task}/ 等はディレクトリ。読む対象は内部のファイル（README.md 等）。ファイル名検索で配下を特定してから読む。実装中もソースのディレクトリパスを直接読み込まない | | task-starterプロジェクト構造が不完全 | specs/やreferences/が空でも続行。読み込めたファイルのみで計画を立案し、不足情報は推奨案を含む複数の選択肢を提示してユーザーに補完 | | 軽量テスト環境が未設定 | 推奨案を含む複数の選択肢を提示してユーザーに確認後、環境がない場合はPhase 5の軽量テスト実行をスキップ。スキップした旨をPhase 7の報告に記載（重いテストは元よりCI委譲のため影響なし） | | Lint環境が未設定 | 推奨案を含む複数の選択肢を提示してユーザーに確認後、Lint環境がない場合はPhase 6をスキップ。スキップした旨を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のタイミングの最終判断をユーザーに委ねるため

Agent Skills: Task Performer

Install this agent skill to your local

Skill Files

Task Performer

スコープ

含むもの

含まないもの

ユースケース

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

実装原則

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

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

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

テスト実行方針

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

TODOタスク番号規約

Degrees of Freedom

ワークフロー

Phase 1: タスク情報の受け取り

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

`--no-agent` オプションの認識

PR修正作業の自動認識

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

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

Phase 2: 作業計画の立案

Phase 3: 計画レビュー依頼

Phase 4: 実装

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

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

Phase 5: テスト実行

Phase 6: Lint実行

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

Phase 8: 承認後の処理

PR説明の整合性チェック

ガイドライン

不明点の確認

情報収集

エラーハンドリング

前提条件

禁止事項

Agent Skills: Task Performer

Install this agent skill to your local

Skill Files

Task Performer

スコープ

含むもの

含まないもの

ユースケース

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

実装原則

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

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

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

テスト実行方針

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

TODOタスク番号規約

Degrees of Freedom

ワークフロー

Phase 1: タスク情報の受け取り

--commit オプションの認識

--no-agent オプションの認識

PR修正作業の自動認識

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

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

Phase 2: 作業計画の立案

Phase 3: 計画レビュー依頼

Phase 4: 実装

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

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

Phase 5: テスト実行

Phase 6: Lint実行

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

Phase 8: 承認後の処理

PR説明の整合性チェック

ガイドライン

不明点の確認

情報収集

エラーハンドリング

前提条件

禁止事項

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

`--no-agent` オプションの認識