Task Performer Skill | Agent Skills

Task Performer

引数

[タスクファイルパス] [--commit | --commit-push | --commit-push-pr] [--no-agent] [--auto] [--wip]

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

| オプション | Phase 8 で実行する操作 | |---|---| | 指定なし | ステージングとコミットログファイル出力 | | --commit | 上記 + commit | | --commit-push | 上記 + commit・push | | --commit-push-pr | 上記 + commit・push・PR作成（同じhead/baseのOpen PRがない場合のみ） |

各オプションは単独で指定できる。複数指定時は --commit-push-pr > --commit-push > --commit の順で最も広い実行範囲を採用する。

--autoと--wipは各後処理オプションおよび--no-agentと併用できる。--wip指定時は後続実装を続けられる大枠を作り、Lintと必要なビルドだけを実行する。本スキルからテストコマンドを直接実行しない。

スコープ

含むもの

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

含まないもの

新規プロジェクトのタスク分割（→ task-starter）。ただし実行中に派生した追加タスクは 1xx 番台で起票する（上記「含むもの」）
指定オプションで許可されていないcommit・push・PR作成、およびPRのmerge・closeやCI監視
既存コードのリファクタリング（タスク要件に含まれない限り）
インフラ構築・デプロイ作業

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

いかなる開発タスクでも、以下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: 要件外の汎用性は「想像上の未来」のために今コストを払う行為で、多くの場合その未来は来ない。読み手・レビュワーが理解すべき情報量を最小化することが、長期的な保守性・可読性に直結する。

テスト実行方針

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

--wip指定時はこの分類による直接実行を行わない。テストは必要に応じて実装してよいが、軽量・単体テストを含め、本スキルからテストコマンドを直接実行しない。commit hookや、push・PR作成で起動するCIがテストを自動実行する場合は抑止せず、取得できた結果をWIPの検証状況として報告する。

軽量テスト = 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文字以内のルールに従う
commit・push・PR作成: Low freedom — 「引数」の実行範囲に従う。commitには出力したコミットログファイルを使い、push・PR作成はPhase 8の手順に従う。
pre-commitフックの事前実行: Low freedom — git add 実行前に必ず .git/hooks/pre-commit / .githooks/pre-commit の存在を確認し、存在すれば定義された処理を先に実行してエラーが無い状態にしてから git add 以降に進む。省略しない
テスト分類: Medium freedom — 通常実装では、軽量テストか重いテスト（DB/integration）かを「テスト実行方針」のシグナルに基づき判断する。判別がつかない場合はユーザーに確認する。--wip指定時は分類しない
テストの直接実行: Low freedom — 通常時は軽量テストを自動実行し、失敗時は修正→再実行を繰り返してパスさせる。重いテストはローカル実行をSKIPしCIへ委譲するのが既定で、ローカル実行前に必ずユーザーへ確認する。--wip指定時は軽量・重いを問わず本スキルから直接実行しない
Lint実行: Low freedom — 失敗時は修正→再実行を繰り返し、パスするまで完了としない
WIPビルド: Low freedom — --wip指定時は言語やシステム構成上ビルド工程がある場合だけ実行する。テストを安全に除外できなければ実行しない
実装原則の遵守: Low freedom — 上記「実装原則」の3項目は常に遵守し、逸脱する場合はユーザー承認を必須とする

ワークフロー

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

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

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

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

commit・push・PR作成オプションの認識

「引数」の表に従って実行範囲を記録する。オプション指定をその範囲の操作への明示的な許可として扱い、同じ操作の許可を再確認しない。Phase 3・7のレビューは --auto の指定に従う。pushを含む場合は作業ブランチと送信先remote、PR作成を含む場合はbaseと既存PRを確認し、対象が確定できない場合だけ必要な判断を求める。PR作成には ../pr-creator/SKILL.md を読み、main/master上ならcommit前に作業ブランチを用意する。

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

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

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

タスク指示に --auto が含まれる場合、Phase 3 は計画提示後の承認待ちを省略する。Phase 7 は、通常実装では全受け入れ条件が 充足、WIPでは実行したLint・ビルドに失敗がなければ、作業結果報告後の承認待ちを省略する。安全性やスコープに影響しない選択は推奨案または最も安全で可逆な既定値を採用し、Phase 7 で報告する。commit・push・PR作成は暗黙に有効化せず、併用されたオプションの範囲で実行する。

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

指定オプションで許可済みのpush・PR作成は再確認の対象外。既存PRの説明更新は別操作として従来の確認手順に従う。

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

タスク指示に --wip が含まれる場合、実装の大枠を作るモードとして記録する。Phase 2・3では、実装する大枠、意図的に後回しにする詳細、実行するLint・ビルド、直接実行しないテストを区別する。未実装部分を推測で埋めず、大枠を成立させるために判断が必要な要件の曖昧さは通常どおり確認する。

--wipは実装完成度と検証の完了判定だけを緩和する。変更対象の分離、権限、送信先、pre-commit hook、各後処理の成功条件は通常どおり適用する。

WIPとして意図的に後回しにした内容は元のタスクの残作業として扱い、それだけを理由に1xxの追加・申し送りタスクを起票しない。当初スコープ外で新たに判明した作業だけを通常どおり起票候補とする。

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 で追加取得する。

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

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

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

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

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

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

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

Phase 2: 作業計画の立案

リファレンス確認: task-starterプロジェクトの場合は Phase 1 で task-reader から受領した構造化サマリを使用（再読込不要）。それ以外の場合は計画立案に参照するリファレンスの有無を、推奨案を含む複数の選択肢を提示してユーザーに確認する。--auto 指定時は関連する既存リファレンスを自動選択する
タスク分析:
- 影響範囲の特定（DB / Backend / Frontend 等）
- task-starterプロジェクトの仕様・調査資料・README・TODOを作成または更新する場合は、../_shared/references/document-writing-guide.md を編集前に読む。作業中に文書更新が必要と分かった場合も同じガイドを適用する（Phase 4-3参照）
- 実装ステップの洗い出し
- 必要なテストの特定
- リスクと注意点の識別
- 開発原則の点検（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）。task-starter生成タスクは todos/{ID}/README.md の「開発原則チェック」を起点に具体化。該当しない原則は N/A 理由を添える
- --wip指定時は、後続実装を続けられる大枠と意図的に後回しにする詳細を分離し、Lint・必要なビルド・直接実行しないテストを特定する

Phase 3: 計画レビュー依頼

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

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

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

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

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

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

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

### WIP範囲（`--wip`指定時）
- 今回実装する大枠: {後続実装を続けられる状態}
- 意図的に後回しにする詳細: {未実装部分}
- 検証: {実行するLint・必要なビルド・直接実行しないテスト}

フィードバックがあれば修正して再提示し、承認後に次へ進む。--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変更が発生する場合:

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

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

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

既存コードのスタイル（命名規則、インデント、ディレクトリ構成）に合わせる
変更は計画で承認された範囲に限定し、関連箇所の「ついで修正」は避ける
--wipを指定しない場合、テストコードはメインコードと同時に実装する（後回しにしない）
--wip指定時は後続実装を続けられる大枠にスコープを限定する。テストコードは大枠に必要なら実装してよいが、詳細とともに後回しにしてもよい

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

4-3. 計画文書の作成・更新（該当する場合）

task-starterプロジェクトの specs/・references/・ルートREADME・TODOを依頼範囲内で作成または更新するときは、共有の執筆ガイドに従う。ガイドは文書の書き方を定めるもので、タスクの範囲や要件を変更する許可にはしない。
目的・範囲・段階・完了条件の変更が許可されている場合は、その変更を実施する担当がルートREADMEと関連文書を同期する。通常の進捗だけが変わる場合はREADMEを更新しない。記録先と更新時の整理方法はガイドの「実行中の作成・更新」に従う。
TODO本文への進捗の書き戻しは行わない。依頼に定義変更が含まれる場合は共有保存契約に従い、対応する PROGRESS.md と進捗一覧も整合させる。

Phase 5: テスト実行

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

--wip指定時は以下の手順によるテストコマンドの確認・分類・直接実行を行わず、直接実行しなかったテストと理由をPhase 7へ記録する。commit hookやCIが自動実行したテストは、その結果を取得できた範囲で記録する。

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

Phase 6: Lint・WIPビルド実行

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

--wip指定時は、言語やシステム構成上ビルド工程がある場合だけ、Phase 1で特定したビルドコマンドを実行する。ビルドがテストを含む場合は、テストを除外できるターゲットまたはオプションを使う。安全に分離できなければビルドを実行せず、その理由をPhase 7へ記録する。Lintまたは実行したビルドが失敗したままPhase 7の承認やPhase 8へ進まない。

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

計画文書を作成・更新した場合は、共有の執筆ガイドの「提示前の確認」を行い、ルートREADMEと詳細文書の整合性も確認してから提示する。未確定事項は確定した計画や実施済みの結果として扱わない。

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

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

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

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

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

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

### ビルド結果（`--wip`指定時）
- 実行コマンド: `{buildコマンド}` / SKIP
- 結果・SKIP理由: {PASS / テストを安全に分離できないため未実行 / ビルド工程なし}

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

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

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

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

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

### WIPの残作業（`--wip`指定時）
- 意図的な未実装部分: {内容}
- 次に必要な作業: {内容}

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

--wip指定時は、意図した未実装部分、直接実行していないテスト、AC-IDの未充足・未確認を明示したうえで、WIP成果としての承認を求める。これらはPhase 8への進行を妨げない。--autoとの併用時は、実行したLint・ビルドに失敗がなければ承認待ちを省略できる。

通常モードでは、作業結果の承認に加えて**「追加・申し送りタスク（1xx）をファイルとして起票するか」**も確認する。--auto 指定時は、通常実装では全 AC-ID が 充足、WIPでは実行したLint・ビルドに失敗がなければ作業結果の承認待ちを省略するが、タスク起票はスコープ拡張に当たるため確認する。

Phase 8: 承認後の処理

承認されたら以下を実施する。--auto 指定時は、通常実装ではPhase 7で全 AC-ID が 充足、WIPでは実行したLint・ビルドに失敗がないことを承認相当として扱う:

pre-commitフックによる事前整形（git add 実行前に必ず行う）
- .git/hooks/pre-commit と .githooks/pre-commit の存在を確認する
- いずれかが存在する場合、git add より前にフックへ処理を委ねず、フックスクリプトの中身を確認したうえでそこに定義されている処理（フォーマッタ・Lintコマンド等）を直接実行する
- --wip指定時にフックがテストを含む場合、テストコマンドは事前に直接実行せず、フォーマッタ・Lintだけを分離して実行する。安全に分離できなければフック全体の事前実行を省略し、commit時の自動実行に任せる。自動実行されたテストを抑止せず、結果をWIPの検証状況へ記録する
- 実行結果がエラーの場合: エラー内容を確認 → 修正 → 再実行を繰り返し、エラーが無くなるまで完了としない（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}/ 配下。それ以外は推奨案を含む複数の選択肢を提示してユーザーに確認。--auto 指定時はリポジトリルートへ出力する
- 形式:
```
{Conventional Commits形式のメッセージ}

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

commitを含むオプション指定時のコミット実行: --commit・--commit-push・--commit-push-pr のいずれかを認識していた場合、ステージ済み差分にタスク外の変更が含まれないことを確認し、出力したコミットログファイルを使って以下を実行する。
```
git commit -F {出力したコミットログファイルのパス}
```
オプション未指定の場合はログファイル出力に留め、コミットは実行しない。コミット実行後はハッシュを記録する。コミット対象の差分がない場合は空コミットを作らず、その旨を記録して指定された後続操作の要否を確認する。

push・PR作成:
- --commit-push・--commit-push-pr では、送信先remote・branchと未pushコミット全体を確認して提示し、確定した対象へ通常のpushを行う。今回のタスク外のコミットが含まれ、送信が許可されているか不明な場合は確認する。必要ならupstreamを設定し、送信済みなら再pushは不要。
- --commit-push-pr では pr-creator の手順でタイトル・本文を準備して提示し、push成功後にPRを作成する。既存PRのstateとhead/base（リポジトリ・ブランチ）を照合し、一致するOpen PRがある場合はURLを報告して新規作成を省略する。Closed/Mergedの履歴だけでは作成を止めない。既存PRの照会失敗を「PRなし」と扱わない。既にpush済みであることと、許可された実行範囲を pr-creator に引き継ぐ。
- --wipとの併用時は、pr-creatorへ--draftと、PRタイトルの先頭に[WIP] を付ける形式指定を渡す。タイトルに同じprefixを重複させず、作成後にDraft状態とタイトルを確認する
- commit失敗時はpushへ、push失敗時はPR作成へ進まない。通信エラーで成否が不明ならリモートの状態を確認してから再試行を判断する。force pushや別remoteへの切り替えを自動で行わない。
- コミットハッシュ・push先・PR URL（作成/既存）を報告する。失敗・保留があれば未完了の操作を明記し、進捗正本にも残作業・ブロッカーとして反映する。指定操作が未完了のままタスク全体を完了扱いにしない。
進捗正本の更新（task-starter形式のファイルパスで提供された場合）
- 指定されたTODOタスクファイルには進捗を書き戻さない。旧形式のチェックボックスも更新しない。依頼に含まれる定義変更は Phase 4-3 と共有保存契約に従う
- progresses/NNN-{task}/PROGRESS.md の全 AC-ID を Phase 7 の判定と根拠で更新する。TODOに存在しないID、重複ID、欠落IDがあれば完了にせず修正する
- --wipを指定せず、全 AC-ID が 充足 で承認済み（--auto では承認相当）の場合だけ、状態を 完了 に更新し、最終更新・完了した作業・残作業・ブロッカー・成果を共有契約の必須形式に揃える
- --wip指定時は状態を完了にせず進行中のままにし、完了・未完了のW-ID、実装済みの大枠、意図的な未実装部分、次に必要な作業、全AC-IDの判定と根拠を更新する
- 個別正本の更新直後に同期スクリプトを実行し、progresses/README.md の該当行が個別正本と同じ状態・最終更新を示すことを確認する。個別正本と一覧の更新を同じ処理として扱う
- 旧形式では PROGRESS.md の既存形式を維持して状態と成果を更新し、TODOのチェックボックスは読み取り専用として扱う。移行は別途提案し、自動実行しない
- progresses/NNN-{task}/ には PROGRESS.md 以外を出力しない。コミットログ・レビュー結果・テスト成果物・調査メモ・コマンド出力・試行記録は logs/NNN-{task}/ に置く
追加・申し送りタスクの起票（Phase 7 で承認された場合のみ）
- 1xx 番台で連番フォルダを作成（既存の最大 1xx 番号 +1。最初は 101）
- task-starterプロジェクトの場合: todos/1xx-{kebab-name}/README.md を task-starter の todo-template 形式（フロントマター + 開発原則チェック含む）で作成し、depends_on に当該タスクIDを設定。文書の作成と提示前の確認は Phase 4-3 の共有の執筆ガイドに従う
- 同じ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プロジェクトでない場合: 起票先・形式を推奨案を含む複数の選択肢を提示してユーザーに確認
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説明は実装と整合しています」と報告して完了

ガイドライン

不明点の確認

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

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

情報収集

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

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

エラーハンドリング

共通方針:

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

推測での修正は避ける。

個別パターン:

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

前提条件

対象プロジェクトがgit管理下にあること
通常実装では軽量テストの実行環境がセットアップ済みであること（未設定の場合はPhase 5をスキップ）。--wip指定時と重いテスト（DB/integration）はローカルのテスト実行環境を前提としない
Lint実行環境がセットアップ済みであること（未設定の場合はPhase 6をスキップ）

禁止事項

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

--wip指定時はタスクの完成を報告せず、実装済みの大枠、意図的な未実装部分、直接実行しなかったテスト、hook・CIで自動実行された検証、Lint・ビルド結果、次に必要な作業を明記する。

Agent Skills: Task Performer

Install this agent skill to your local

Skill Files