Task Starter Skill | Agent Skills

Task Starter

ソフトウェア/Web開発プロジェクト・タスクの標準ドキュメント構造を生成し、依存関係を分析した上で、最速完了に向けたロードマップと推奨ワークロードまで提示する。

スコープ

含むもの

プロジェクトフォルダ構造の新規生成
ドキュメント形式の選択（Markdown / 自己完結HTML）
仕様書・TODOタスク・現状分析ドキュメントの作成
タスク分割（依存メタ情報付き）と計画策定
依存DAG・クリティカルパス・並行可能タスク群の特定
Claude Code 最新機能（Subagents並列・/goal・worktree・/batch等）を活用した推奨ワークロードの提示

含まないもの

既存TODOタスクの実行・進捗管理（→ task-performer）
コードの実装作業
既存ドキュメントの更新・メンテナンス

開発原則（タスク設計の必須観点）

いかなる開発タスクでも、以下4原則をこの優先順位で意識してタスクを設計・分割・計画する。仕様・受け入れ条件・分割粒度を決める際、まずこの観点で漏れがないか点検する。設計段階で考慮しておくと、後工程での手戻り（特にセキュリティと耐障害性は後付けが極めて高コスト）を防げる。

セキュリティ（最優先） — 認証・認可、入力検証、機密情報の扱い、依存ライブラリの脆弱性。脅威を設計段階で洗い出し、対策自体を独立タスクとして起票する。他の原則とトレードオフが生じたら常にセキュリティを優先する。
耐障害性 (Fault Tolerance) — 障害発生を前提に、リトライ・タイムアウト・graceful degradation・ロールバック手順を設計へ織り込む。単一障害点で全体が止まらないかを点検する。
高可用性 (High Availability) — 稼働継続性。冗長化・ヘルスチェック・無停止デプロイの余地を設計時に確保する。
スケーラビリティ (Scalability) — 負荷増大への追従。状態の持ち方・ボトルネック・水平/垂直スケールの前提を早期に固める。

柔軟適用: 全タスクに4原則の検討を課すが、対象タスクに本質的に関係しない原則は「N/A（理由）」と明記してよい（例: 純粋なドキュメント整備タスクで高可用性は N/A）。目的は形式的チェックではなく、なぜ該当/非該当かを言語化し、考慮漏れを無くすこと。考慮結果は各 todos/{ID}/README.md の「開発原則チェック」セクションと specs/ の非機能要件へ反映する。

TODOタスク番号規約

todos/ 配下のタスク番号は用途で番号帯を分ける:

新規作成タスク = 0xx 番台（001〜099） — task-starter がプロジェクト初期に分割するタスクはすべてこの帯で連番。3桁ゼロ埋め。
1xx 番台（101〜199）は予約 — task-performer によるタスク実行中に発生した「追加タスク」「申し送りタスク」用。task-starter の新規作成では使わない。

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

成功基準

Phase 1 でユーザーに選択させたドキュメント形式（Markdown / HTML）で全ドキュメントが一貫して生成されている（拡張子は .md または .html）
指定ディレクトリに YYYYMMDD-{name}/ フォルダ構造が生成されている
specs/ に要件・技術仕様を含む仕様書が作成され、非機能要件にセキュリティ・耐障害性・高可用性・スケーラビリティの方針が記載されている
todos/ に1-2時間粒度のタスクが**0xx 番台（001〜099）**で依存順に配置され、各TODOに依存メタ（depends_on / parallel_group）が明記されている（Markdownはフロントマター、HTMLは <script type="application/x-task-meta">。1xx 番台は予約のため未使用）
progresses/ と logs/ が生成され、成果・進捗管理ドキュメントとその他の作業ログの出力先が分離されている
各TODOに「開発原則チェック」（4原則の該当 or N/A理由）が記載されている
ロードマップ（todos/README.*）に Mermaid DAG・タスク表・クリティカルパス・並行可能タスク群・推奨ワークロードが記載されている（HTML時は Mermaid が <pre class="mermaid"> で描画される）
ユーザーが Phase 5 のレビューで承認している

ワークフロー

Phase 1: 情報収集

プロジェクト基本情報を収集 $ARGUMENTS が指定されている場合はプロジェクト名として使用。

推奨案を含む複数の選択肢を提示してユーザーに確認（$ARGUMENTSで既知の項目はスキップ）:
- プロジェクト/タスク名（$ARGUMENTSがあれば確認のみ）
- 出力先ディレクトリ
- 概要と目的
- 新規開発 or 既存コード改修

ドキュメント形式を確認（必須） 生成ドキュメントを Markdown と HTML のどちらにするか、選択肢を提示してユーザーに確認する。
- Markdown（既定）: .md で生成。task-performer での実行や git 差分レビューに向く
- HTML: 自己完結HTML（.html）で生成。ブラウザで開くだけで体裁・Mermaid図が表示され、共有・閲覧に向く選択結果（md / html）を以降の Phase 2〜4 で一貫して使う。HTML を選んだ場合は 必ず references/html-output-guide.md を読んでから ドキュメントを生成する。
既存コード改修の場合、現状を分析
- 対象範囲が広い（複数モジュール・多数ファイルにまたがる）場合は、この調査をサブエージェントに委譲し、アーキテクチャ・処理フロー・課題のサマリだけをメインに戻させる。対象が数ファイルに絞られている場合は、委譲せず関連ファイルをファイル名検索・内容検索・読み込みで直接調査してよい
- アーキテクチャと処理フローを把握
- 課題・改善点を特定

Phase 2: 構造生成

プロジェクトフォルダを作成 --format には Phase 1 で選んだ形式（md / html）を渡す。

python3 scripts/init_project.py "{プロジェクト名}" --path "{出力先}" --description "{概要}" --format {md|html}

生成される構造（拡張子は選択形式に従う。以下は Markdown 選択時の例）:

YYYYMMDD-{kebab-case-name}/
├── README.md           # 概要と目的（HTML選択時は README.html）
├── references/         # 現状分析資料
├── files/              # 参考データ・ファイル
├── specs/              # 要件・仕様書
├── todos/              # タスクドキュメント（新規は 0xx 番台。1xx は実行中追加用に予約）
│   ├── README.md       # タスクロードマップ（Phase 4で内容を埋める。HTML選択時は README.html）
│   └── 001-{task-name}/
├── progresses/         # タスク成果・進捗管理ドキュメント置き場
│   └── 001-{task-name}/
└── logs/               # 上記以外の作業ログ置き場
    └── 001-{task-name}/

progresses/NNN-{task}/ には、タスクの成果ドキュメントと PROGRESS.md 等の進捗管理ドキュメントだけを置く。コミットログ・調査メモ・コマンド出力・試行記録など、それ以外はすべて logs/NNN-{task}/ に置く。

参考ファイルの有無を確認
- ユーザーに参考データ・ファイルがあるか選択肢を提示して確認
- あれば files/ にコピーまたはリンク

Phase 3: ドキュメント生成

各ドキュメントは references/templates/*.md のテンプレートをベースに生成する。HTML を選んだ場合は、テンプレートの構造を references/html-output-guide.md のルールに従って自己完結HTMLに変換して書き出す（共有シェル references/templates/html-shell.html を使用、Mermaid は <pre class="mermaid">、TODOの依存メタは <script type="application/x-task-meta"> に埋め込む）。テンプレートの各セクション・コメントの意図は形式を問わず維持する。

references/ - 現状分析（既存コード改修時のみ）
- references/templates/reference-template.md をベースに作成
- 現状のアーキテクチャ、主要コンポーネント、処理フローを記載
- 不明点は選択肢を提示して随時確認
specs/ - 仕様書
- references/templates/spec-template.md をベースに作成
- 要件、技術仕様、UI/UX、依存関係を記載
- 非機能要件には「開発原則」（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）の方針を必ず記載。プロジェクト特性上 N/A の原則は理由を添えて明記する
- 「完了条件 / 成功の定義」セクションは必ず埋める。ここの内容は Phase 4 で /goal コマンドにそのまま渡せる形式で書く必要がある:
  - /goal の評価モデルは「Claude が会話に表示した出力」のみで判定する（ファイル直接読取・コマンド実行は不可）
  - 条件は会話上で実証可能な事実に落とし込む（例: <テストコマンド> の exit 0、Lint エラー 0 件、TODO チェック完了など）
  - 「ユーザー満足」「品質が高い」等の主観表現や、会話で実証できない条件（本番安定稼働等）は避ける
  - 詳しい書き方ルールは references/templates/spec-template.md の「完了条件 / 成功の定義」コメントと references/templates/roadmap-template.md の「Step 4」セクションを参照
- ユーザーとの相談で曖昧な条件しか得られなかった場合は、検証可能な代替指標（コマンド出力等）を提案して合意を取る
todos/ - タスク分割（依存メタ付き）
- references/templates/todo-template.md をベースに作成
- 1-2時間で完了し、エラー無しでコミット可能な粒度に分割
- 連番フォルダは 0xx 番台で付与: 001-setup/, 002-implement-xxx/, ...（1xx 番台は実行中の追加タスク用に予約。「TODOタスク番号規約」参照）
- 各 README.md 冒頭にYAMLフロントマターで以下を必ず明記:
  - id: タスクID
  - estimated_time: 推定時間
  - depends_on: 前提タスクIDの配列（無ければ []）
  - parallel_group: 並行可能なグループ名（無ければ null）
  - parallelizable: subagentで並行実行を推奨するか
- 各タスクで「開発原則」（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）を点検し、テンプレートの「開発原則チェック」セクションに該当原則の対応方針 or「N/A（理由）」を記載する。セキュリティ対応は分量が大きければ独立タスクとして起票する
- 不明点は選択肢を提示して随時確認

Phase 4: 依存分析とロードマップ生成（新設）

このフェーズで「並行実行可能 vs 直列必須」の分類と、最速完了のための作業ロードマップ・推奨ワークロードを生成する。

依存関係の整理 各 TODO の依存メタ（depends_on, parallel_group）を集約し、以下を算出する。メタの所在は形式で異なる:
- Markdown時: todos/{ID}/README.md 冒頭の YAML フロントマター
- HTML時: todos/{ID}/README.html の <script type="application/x-task-meta"> ブロック（内部はYAML）
- 依存DAG: タスク間の有向グラフ
- クリティカルパス: 推定時間の合計が最大となる経路（全体所要時間を決定する経路）
- 並行グループ: 同じ前提を持ち、編集ファイルが独立しているタスク群
並行可能性の判定基準 2タスクA, Bが「並行実行可能」とみなせる条件:
- AとBの間に依存関係がない（DAG上で互いに到達不能）
- 編集対象ファイルが重複しない （重複する場合は worktree 隔離が必要 → 推奨ワークロードで明示）
- 共通の状態（DB、外部リソース等）への破壊的変更がない
todos/README.md を生成 references/templates/roadmap-template.md をベースに以下を埋める:
- タスク一覧表: ID/概要/前提/並行グループ/推定時間/並行推奨フラグ
- Mermaid 依存DAG: graph TD 記法で可視化、並行グループは classDef で色分け
- クリティカルパス: 経路と合計時間
- 並行グループ詳細: 各グループに属するタスクと「非干渉性の根拠」
- 推奨ワークロード: 後述の「推奨ワークロード設計指針」に従う

Phase 5: レビューと確定（旧Phase 4）

生成結果を一覧表示

📁 YYYYMMDD-project-name/
├── 📄 README.md
├── 📁 references/
│   └── 📄 current-state.md
├── 📁 files/
├── 📁 specs/
│   └── 📄 feature-spec.md
├── 📁 todos/
│   ├── 📄 README.md          ← ロードマップ + 推奨ワークロード
│   ├── 📁 001-setup/
│   │   └── 📄 README.md      ← フロントマター付き
│   └── 📁 002-implement/
│       └── 📄 README.md
├── 📁 progresses/
│   ├── 📁 001-setup/
│   └── 📁 002-implement/
└── 📁 logs/
    ├── 📁 001-setup/
    └── 📁 002-implement/

ユーザーレビューを依頼
- todos/README.md の DAG・クリティカルパス・推奨ワークロードを重点的に確認してもらう
- フィードバックに基づき修正
承認後、完了メッセージを表示

推奨ワークロード設計指針

todos/README.md の「推奨ワークロード」セクションは、Claude Code の以下の機能をプロジェクト特性に応じて組み合わせて提示する。テンプレートをそのまま貼るのではなく、実プロジェクトの依存DAGに応じて具体的なAgent呼び出し例まで書き起こすこと。

機能ごとの使い分け表

| 機能 | 適用条件 | 役割 | | --- | --- | --- | | Subagents 並列実行（1メッセージで複数Agent呼び出し） | 並行可能タスクが2-5個 | 同一セッション内で並列化、結果はメインに集約 | | isolation: worktree オプション | 並行Agentが同じファイルを触る可能性 | git worktreeで隔離 | | /batch | 5-30個の機械的に類似した独立変更 | 自動的にworktree-isolated subagentに分散しPRを作成 | | Agent View (claude agents) | 長時間バックグラウンド実行が複数 | バックグラウンドセッションをダッシュボードで管理 | | /goal | 検証可能な完了条件がある（テストpass等） | 条件達成までターン継続、ユーザー操作不要 | | task-performer スキル | 個別タスクを順次実行 | 1タスクずつ確実に進める | | Hooks (Stop / PostToolUse) | 完了通知・自動lint等 | 各タスク終了時の自動アクション |

推奨ワークロードの構成テンプレート

todos/README.md の「推奨ワークロード」セクションでは、以下の順で具体例を書く:

Step 1: 直列必須タスク — 順次実行する初期タスク（例: 001-setup）
Step 2: 並行可能タスクの並列実行 — 1メッセージで複数 Agent ツール呼び出しする具体例。subagent_type, description, prompt, isolation まで明記
Step 3+: 統合・後続タスク — 並行終了後に走るタスク
オプション: /goal 全自動化 — 完了条件（specsから引用）を提示
オプション: 完了通知Hook — Stop hookでの通知例（必要なら）

Subagent 並列呼び出しの注意点

1メッセージ内に複数の Agent 呼び出しを並べることで並列実行される（順次呼び出しではない）
isolation: worktree 指定時は、Agent終了後に変更内容のmerge手順も明記する
prompt には「todos/{ID}/README.md の作業内容を完了させ、受け入れ条件を全て満たす」と明記し、自己完結させる

TODOタスク分割ガイドライン

粒度の基準

目安: 1-2時間で完了
明確なゴール: 完了条件が明確
独立性: 並行可能性を最大化するため、編集ファイル領域が分離されるよう分割を工夫する

ソフトウェア/Web開発での典型的な分割パターン（並行性込み）

フロントエンド機能追加:

001-design-component (順次)
002-implement-ui (Group A・001完了後)
003-add-state-management (Group A・001完了後・別ファイル)
004-integrate-api (002, 003完了後)
005-add-tests (004完了後)

→ Group A の002と003は別ファイル領域なら並行可能

API開発:

001-design-api (順次)
002-implement-endpoint (Group B・001完了後)
003-add-validation (Group B・001完了後・別ファイル)
004-add-error-handling (002完了後)
005-add-tests (004完了後)

リファクタリング:

001-analyze-current (順次)
002-design-new-structure (順次)
003-extract-xxx (Group C・002完了後)
004-extract-yyy (Group C・002完了後・別領域)
005-update-references (003, 004完了後)
006-verify-behavior (005完了後)

実装スタイル

自由度: Medium

テンプレートは固定だが、内容はプロジェクトに応じてカスタマイズ
フォルダ構造は標準化、ドキュメント内容は柔軟に対応
specドキュメントにはmermaid形式の図も積極的に記載する

ユーザーインタラクション

Phase 1: 必須（プロジェクト情報収集 + ドキュメント形式の確認）
Phase 4: 並行可能性の判定で曖昧な場合は選択肢を提示して確認
Phase 5: 必須（レビューと承認）
途中キャンセル: 生成途中のファイルは削除またはユーザーに確認

エラーハンドリング

| エラー | 対応 | | ---------------------------- | ---------------------------------------------- | | フォルダが既に存在 | エラーメッセージを表示し、別名を提案 | | 権限不足でファイル作成不可 | エラーを報告し、別の出力先を提案 | | 情報収集中にキャンセル | 確認後、生成済みファイルを削除するか選択させる | | Python 3が未インストール | 手動でフォルダ構造を作成する代替手順を案内 | | 循環依存を検出 | エラー報告し、依存定義の見直しを依頼 | | HTMLシェルが見つからない | init_project.py が明示エラーで停止。references/templates/html-shell.html の存在を確認 |

前提条件

Python 3.x（scripts/init_project.pyの実行に必要）
出力先ディレクトリへの書き込み権限

リソース

scripts/

scripts/init_project.py - プロジェクトフォルダ構造を生成（Python 3必須）
- 入力: プロジェクト名(必須), --path(出力先), --description(概要), --format(md / html、既定 md)
- 出力: YYYYMMDD-{kebab-case-name}/ ディレクトリ + README + サブフォルダ群 + todos/README 雛形（拡張子は形式に従う）
- 参照頻度: 毎回（Phase 2で必ず実行）

references/

references/html-output-guide.md - HTML形式選択時の生成ルール（Phase 1でHTMLを選んだら必ず参照）。シェル使用法・Mermaid・依存メタ埋め込み・拡張子規約・task-performer互換注記

references/templates/

以下のテンプレートはPhase 3〜4で参照する。ドキュメント生成のベースとして使用。

references/templates/spec-template.md - 仕様書テンプレート（Phase 3で毎回参照）
references/templates/todo-template.md - TODOタスクテンプレート（Phase 3で毎回参照、依存メタ必須）
references/templates/reference-template.md - 現状分析テンプレート（既存コード改修時のみ）
references/templates/roadmap-template.md - タスクロードマップテンプレート（Phase 4で毎回参照）
references/templates/html-shell.html - 自己完結HTMLの共有シェル（HTML形式選択時にスクリプト/Claude双方が使用）

Agent Skills: Task Starter

Install this agent skill to your local

Skill Files