Task Performer Skill | Agent Skills

Task Performer

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

スコープ

含むもの

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

含まないもの

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

ユースケース

ユースケース: TODOタスクの実装
トリガー: 「このタスクを実装して」「/task-performer docs/tasks/todos/001-setup/README.md」
          「TODOを実行して」「このタスクドキュメントに基づいて実装して」
手順:
1. タスク情報を受け取る（ファイルパスまたは直接指示）
2. 影響範囲を分析し、実装計画を立案
3. ユーザー承認後、コード実装・テスト・Lintを実行
4. 作業結果を報告し、承認後にステージング・コミットログ出力
成功基準:
- タスクで定義された要件がすべて実装されていること
- 開発原則（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）が点検され、対応結果がPhase 7報告に含まれていること
- テストが全件パスしていること
- Lintエラーがゼロであること
- 変更ファイルがgit addされ、コミットログファイルが出力されていること
- 実行中に派生した追加・申し送りタスクがあれば 1xx 番台で起票（または報告）されていること

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

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

セキュリティ（最優先） — 認証・認可、入力検証、機密情報（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 8の作業結果レビューの「気づきメモ」として別途報告する。

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

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

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

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

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（作業結果レビュー）でのAskUserQuestion実行は必須。省略しない
コミットログ形式: Low freedom — Conventional Commits形式、1行72文字以内のルールに従う
テスト・Lint実行: Low freedom — 失敗時は修正→再実行を繰り返し、パスするまで完了としない
実装原則の遵守: Low freedom — 上記「実装原則」の3項目は常に遵守し、逸脱する場合はユーザー承認を必須とする

ワークフロー

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

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

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

タスク情報が不明確な場合はAskUserQuestionで確認する。

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

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

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

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

| ファイル | 確認内容 | |---------|---------| | 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: AskUserQuestion による補完

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

task-starterプロジェクトの自動認識（task-reader エージェントへ委譲）

ファイルパスが todos/NNN-{task}/README.md 形式の場合、task-starter で生成されたプロジェクト構造とみなし、task-reader エージェントへ委譲してコンテキストサマリを取得する。これによりスキル本体のコンテキスト消費を抑えつつ、Phase 2 の計画立案に必要な情報を網羅的に得られる。

Why: task-starter プロジェクトは README / specs / references / todos / logs と複数ファイルを横断して読む必要があり、スキル本体で全て展開するとメインコンテキストが逼迫する。読み取りと要約を専門エージェントに切り出すことで、本体は構造化サマリのみを保持して Phase 2 以降に集中できる。

委譲方法:

Task ツールで以下のように呼び出す:

subagent_type: task-reader
prompt: タスクファイルパス: <指定された todos/NNN-{task}/README.md のパス>（必要なら追加の補足を併記）

エージェントから返却される構造化サマリ:

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

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

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

Phase 2: 作業計画の立案

リファレンス確認: task-starterプロジェクトの場合は Phase 1 で task-reader から受領した構造化サマリを使用（再読込不要）。それ以外の場合は計画立案に参照するリファレンスの有無を AskUserQuestion で確認
タスク分析:
- 影響範囲の特定（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 の自動検出結果からマイグレーションコマンドを確認する。未特定の場合のみ AskUserQuestion で確認
手順に従い実行
エラー発生時はユーザーに報告して対処方法を確認

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

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

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

Phase 5: テスト実行

Phase 1 の自動検出結果からテストコマンドを確認する。未特定の場合のみ AskUserQuestion で確認
テストを実行
失敗した場合: エラー確認 → 修正 → 再実行を繰り返す

Phase 6: Lint実行

Phase 1 の自動検出結果から Lint コマンドを確認する。未特定の場合のみ AskUserQuestion で確認
Lintを実行
失敗した場合: エラー確認 → 修正 → 再実行を繰り返す

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

以下の形式で報告し、AskUserQuestionで承認/追加修正を確認する:

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

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

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

### テスト結果
- 実行コマンド: `{テストコマンド}`
- 結果: {PASS/FAIL} ({N}件中{N}件パス)

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

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

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

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

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

Phase 8: 承認後の処理

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

git管理されている変更ファイルのステージング
```
git add {変更したファイル}
```
コミットログファイルの出力
- "commit-{date +'%Y%m%d%H%M%S' コマンドの実行結果}-{title}.txt" というファイル名でファイルに書き出す（git commit -F で使用）
- 出力先: task-starterプロジェクトの場合は logs/NNN-{task}/ 配下。それ以外はAskUserQuestionで確認
- 形式:
```
{Conventional Commits形式のメッセージ}

{作業内容の詳細をmarkdown形式で記載}
{1行72文字以内}
```
コミットログに含めてはいけない情報:
- タスクドキュメントのファイルパス（例: docs/tasks/todos/001-setup/README.md 等）
- タスクプロジェクトルートやタスクID・TODO番号への言及（例: 「タスク001対応」「TODO-123対応」「YYYYMMDD-{name} プロジェクト」等）
- セッション内の作業ログファイルパス（例: logs/NNN-{task}/...）
- その他、当該リポジトリ外にある個人専用ディレクトリ（.claude/agent-memory/ 等）への参照
Why: コミットログは git log として永続化され、リポジトリを参照する第三者（将来の自分・新規参画者・OSS閲覧者を含む）が変更経緯を辿る唯一の履歴となる。個人環境にしか存在しないタスクドキュメントや、ローカルでしか意味を持たないタスクIDを含めても、読み手はそれらを参照できず、むしろ「どこを見ればよいか」という誤った期待を生み、混乱の原因になる。コミットログは「このコミットでリポジトリに何を、なぜ加えたか」だけで自己完結させ、タスク管理側の文脈はPhase 8の作業結果レビューや気づきメモ、タスクファイル更新側に留める。

代わりに書くべき内容: 変更の目的（why）・変更内容の要約（what）・リポジトリ内のファイルパスや関連機能名など、リポジトリだけを見て理解できる情報。
タスクファイル更新（ファイルパスで提供された場合）
- タスクの作業ログや完了状態を、指定されたTODOタスクファイルにも反映
追加・申し送りタスクの起票（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プロジェクトでない場合: 起票先・形式をAskUserQuestionで確認

ガイドライン

不明点の確認

以下の場合はAskUserQuestionで必ず確認:

タスク要件が不明確
複数の実装アプローチがある
既存コードへの影響範囲が不明
DBスキーマの変更が必要
破壊的変更の可能性がある

情報収集

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

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

エラーハンドリング

共通方針:

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

推測での修正は避ける。

個別パターン:

| エラー | 対応 | |--------|------| | タスクファイルが存在しない | エラーを報告し、正しいパスをAskUserQuestionで確認。Globで todos/**/README.md を検索して候補を提示 | | task-starterプロジェクト構造が不完全 | specs/やreferences/が空でも続行。読み込めたファイルのみで計画を立案し、不足情報はAskUserQuestionで補完 | | テスト環境が未設定 | AskUserQuestionで確認後、テスト環境がない場合はPhase 5をスキップ。スキップした旨をPhase 7の報告に記載 | | Lint環境が未設定 | AskUserQuestionで確認後、Lint環境がない場合はPhase 6をスキップ。スキップした旨をPhase 7の報告に記載 | | テスト/Lintが繰り返し失敗 | 3回修正しても解決しない場合はユーザーに報告し、続行/中断を確認 |

前提条件

対象プロジェクトがgit管理下にあること
テスト実行環境がセットアップ済みであること（未設定の場合はPhase 5をスキップ）
Lint実行環境がセットアップ済みであること（未設定の場合はPhase 6をスキップ）

禁止事項

APIキー、パスワード、シークレットのハードコード — セキュリティインシデントの原因となり、git履歴に残ると除去が困難なため
テストが失敗したコードの放置 — 失敗状態のまま次フェーズに進むと、問題が積み重なり原因特定が困難になるため
Lintエラーの無視 — コード品質の劣化を防ぎ、既存コードベースとの一貫性を保つため
git commit と git push の実行 — レビュー前の意図しないコミットを防ぎ、コミットメッセージやタイミングの最終判断をユーザーに委ねるため

Agent Skills: Task Performer

Install this agent skill to your local

Skill Files