---
name: task-starter
description: |
  ソフトウェア/Web開発プロジェクト・タスクの開始時に、標準フォルダ構造・仕様書・TODOタスクのドキュメント群を生成し、
  さらに「並行実行可能なタスクの分類」「依存DAGとクリティカルパスを含むロードマップ」「Claude Code最新機能を活用した推奨ワークロード」までを一括生成するスキル。
  入力テンプレートを利用し、情報が不足している場合は必要事項を段階的に収集してから生成する。
  以下の状況で使用:
    (1) 「新しいプロジェクトを始めたい」「タスクを開始したい」「プロジェクトをセットアップして」
    (2) 明示的に「task-starter スキル」の実行を指示された時
    (3) 新機能開発・リファクタリング・バグ修正で計画・ドキュメント整備が必要な時
    (4) 「ドキュメント構造を作って」「プロジェクトの骨組みを用意して」
    (5) 「タスク管理用のフォルダを作成して」「開発の準備をして」
    (6) 「仕様書のテンプレートが欲しい」「タスク分割を手伝って」
    (7) 「作業計画をゼロから立てたい」「新規タスクの計画書を作って」
    (8) 「並行で進められるタスクを整理して」「最速で完了させる作業計画を立てて」
    (9) 「タスクのDAG/ロードマップを作って」「クリティカルパスを出して」
  注意: 既存TODOの実行・進捗管理はtask-performerの担当。このスキルは「新規作成」と「ロードマップ設計」に特化。
argument-hint: "[プロジェクト名]"
---

# Task Starter

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

## スコープ

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

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

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

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

1. **セキュリティ（最優先）** — 認証・認可、入力検証、機密情報の扱い、依存ライブラリの脆弱性。脅威を設計段階で洗い出し、対策自体を独立タスクとして起票する。他の原則とトレードオフが生じたら常にセキュリティを優先する。
2. **耐障害性 (Fault Tolerance)** — 障害発生を前提に、リトライ・タイムアウト・graceful degradation・ロールバック手順を設計へ織り込む。単一障害点で全体が止まらないかを点検する。
3. **高可用性 (High Availability)** — 稼働継続性。冗長化・ヘルスチェック・無停止デプロイの余地を設計時に確保する。
4. **スケーラビリティ (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` 番台は予約のため未使用）
- 各TODOの作業項目と受け入れ条件が、チェックボックスを使わず `W-ID` / `AC-ID` 付きの静的定義として記載されている
- `progresses/README.md` に全TODOの状態一覧があり、各TODOに対応する `progresses/{ID}/PROGRESS.md` と `logs/{ID}/` が生成され、進捗正本・集約ビュー・その他の作業成果物が分離されている
- 各TODOに「開発原則チェック」（4原則の該当 or N/A理由）が記載されている
- ロードマップ（`todos/README.*`）に Mermaid DAG・タスク表・クリティカルパス・並行可能タスク群・推奨ワークロードが記載されている（HTML時は Mermaid が `<pre class="mermaid">` で描画される）
- ユーザーが Phase 5 のレビューで承認している

## ワークフロー

### Phase 1: 情報収集

1. **入力テンプレートを読み、既知情報を整理**
   - Phase 1 の開始時に必ず `references/prompt-template.md` を読む
   - `../_shared/references/task-management-contract.md` を読み、進捗正本とログの保存契約を以降の生成へ適用する
   - ユーザーの依頼と `$ARGUMENTS` をテンプレートの項目へ対応付ける。`$ARGUMENTS` が指定されている場合はプロジェクト名として扱う
   - テンプレートが未記入でも実行を止めず、「生成開始条件」と照合して不足項目を特定する
   - 回答済みの情報や、対象コードから確認できる情報を再質問しない

2. **既存コード改修の場合、現状を分析**
   - 対象リポジトリ/ディレクトリが不明な場合は、最初に確認する
   - 対象範囲が広い（複数モジュール・多数ファイルにまたがる）場合は、この調査をサブエージェントに委譲し、アーキテクチャ・処理フロー・課題のサマリだけをメインに戻させる。対象が数ファイルに絞られている場合は、委譲せず関連ファイルをファイル名検索・内容検索・読み込みで直接調査してよい
   - アーキテクチャ、処理フロー、課題・改善点を把握する
   - 調査で判明した情報を入力項目へ反映し、技術的な質問は調査後に絞り込む

3. **不足情報を段階的に収集**
   - `references/prompt-template.md` の「不足情報の質問順」に従い、重要な項目から1回1〜3問ずつ質問する
   - 選択可能な質問には推奨案と判断材料を添える
   - 任意項目は合理的な案で補い、成果物が大きく変わる場合だけユーザーへ確認する

4. **ドキュメント形式を確定（必須）**
   未指定の場合は、生成ドキュメントを **Markdown** と **HTML** のどちらにするか、選択肢を提示してユーザーに確認する。すでに明示されている場合は再質問しない。
   - **Markdown（既定）**: `.md` で生成。`task-performer` での実行や git 差分レビューに向く
   - **HTML**: 自己完結HTML（`.html`）で生成。ブラウザで開くだけで体裁・Mermaid図が表示され、共有・閲覧に向く
   選択結果（`md` / `html`）を以降の Phase 2〜4 で一貫して使う。HTML を選んだ場合は **必ず `references/html-output-guide.md` を読んでから** ドキュメントを生成する。

5. **収集結果を確認**
   - 「生成開始条件」が揃ったことを確認する
   - 収集結果と採用する前提を要約し、ユーザーの確認を得てから Phase 2 へ進む

### Phase 2: 構造生成

1. **プロジェクトフォルダを作成**
   `--format` には Phase 1 で選んだ形式（`md` / `html`）を渡す。
   ```bash
   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/         # タスク進捗の正本置き場
   │   ├── README.md       # 全タスクの進捗一覧（HTMLプロジェクトでもMarkdown固定）
   │   └── 001-{task-name}/
   │       └── PROGRESS.md # HTMLプロジェクトでもMarkdown固定
   └── logs/               # 進捗正本以外の作業成果物置き場
       └── 001-{task-name}/
   ```

   保存先の分類、`PROGRESS.md` と `progresses/README.md` の必須形式は、Phase 1 で読んだ共有契約に従う。

2. **参考ファイルを配置**
   - Phase 1 で確認した参考データ・ファイルがあれば `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">` に埋め込む）。テンプレートの各セクション・コメントの意図は形式を問わず維持する。

1. **references/ - 現状分析（既存コード改修時のみ）**
   - `references/templates/reference-template.md` をベースに作成
   - 現状のアーキテクチャ、主要コンポーネント、処理フローを記載
   - 不明点は選択肢を提示して随時確認

2. **specs/ - 仕様書**
   - `references/templates/spec-template.md` をベースに作成
   - 要件、技術仕様、UI/UX、依存関係を記載
   - **非機能要件には「開発原則」（セキュリティ最優先・耐障害性・高可用性・スケーラビリティ）の方針を必ず記載**。プロジェクト特性上 N/A の原則は理由を添えて明記する
   - **「完了条件 / 成功の定義」セクションは必ず埋める**。ここの内容は Phase 4 で `/goal` コマンドにそのまま渡せる形式で書く必要がある:
     - `/goal` の評価モデルは「Claude が会話に表示した出力」のみで判定する（ファイル直接読取・コマンド実行は不可）
     - 条件は**会話上で実証可能な事実**に落とし込む（例: `<テストコマンド>` の exit 0、Lint エラー 0 件、`PROGRESS.md` の全 `AC-ID` が充足済みなど）
     - 「ユーザー満足」「品質が高い」等の主観表現や、会話で実証できない条件（本番安定稼働 等）は避ける
     - 詳しい書き方ルールは `references/templates/spec-template.md` の「完了条件 / 成功の定義」コメントと `references/templates/roadmap-template.md` の「Step 4」セクションを参照
   - ユーザーとの相談で曖昧な条件しか得られなかった場合は、検証可能な代替指標（コマンド出力等）を提案して合意を取る

3. **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（理由）」を記載する。セキュリティ対応は分量が大きければ独立タスクとして起票する
   - 作業項目には `W-01`、受け入れ条件には `AC-01` のようなタスク内で一意かつ安定したIDを付ける。TODOには進捗を表すチェックボックスを置かない
   - 各TODOの生成時に同じIDの `progresses/{ID}/PROGRESS.md` と `logs/{ID}/` を作成する。`PROGRESS.md` は共有契約のテンプレートを使用し、状態を `未着手`、残作業を全 `W-ID`、受け入れ条件の検証を全 `AC-ID: 未確認`、その他の空項目を `なし` で初期化する。条件本文は転記しない
   - 全TODOと個別 `PROGRESS.md` の生成後、`python3 ~/.claude/skills/_shared/scripts/sync_progress_index.py "{project_root}"` を実行し、`progresses/README.md` に全タスクをID昇順で反映する。個別正本を一覧から上書きしない
   - 不明点は選択肢を提示して随時確認

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

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

1. **依存関係の整理**
   各 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. **並行可能性の判定基準**
   2タスクA, Bが「並行実行可能」とみなせる条件:
   - AとBの間に依存関係がない（DAG上で互いに到達不能）
   - **編集対象ファイルが重複しない** （重複する場合は worktree 隔離が必要 → 推奨ワークロードで明示）
   - 共通の状態（DB、外部リソース等）への破壊的変更がない

3. **`todos/README.md` を生成**
   `references/templates/roadmap-template.md` をベースに以下を埋める:
   - **タスク一覧表**: ID/概要/前提/並行グループ/推定時間/並行推奨フラグ
   - **Mermaid 依存DAG**: `graph TD` 記法で可視化、並行グループは `classDef` で色分け
   - **クリティカルパス**: 経路と合計時間
   - **並行グループ詳細**: 各グループに属するタスクと「非干渉性の根拠」
   - **推奨ワークロード**: 後述の「推奨ワークロード設計指針」に従う

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

1. **生成結果を一覧表示**
   ```
   📁 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/
   │   ├── 📄 README.md          ← 全タスクの進捗一覧
   │   ├── 📁 001-setup/
   │   │   └── 📄 PROGRESS.md
   │   └── 📁 002-implement/
   │       └── 📄 PROGRESS.md
   └── 📁 logs/
       ├── 📁 001-setup/
       └── 📁 002-implement/
   ```

2. **ユーザーレビューを依頼**
   - `todos/README.md` の DAG・クリティカルパス・推奨ワークロードを重点的に確認してもらう
   - フィードバックに基づき修正

3. **承認後、完了メッセージを表示**

---

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

`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` の「推奨ワークロード」セクションでは、以下の順で具体例を書く:

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

### Subagent 並列呼び出しの注意点

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

---

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

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

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

**フロントエンド機能追加**:
1. 001-design-component (順次)
2. 002-implement-ui (Group A・001完了後)
3. 003-add-state-management (Group A・001完了後・別ファイル)
4. 004-integrate-api (002, 003完了後)
5. 005-add-tests (004完了後)

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

**API開発**:
1. 001-design-api (順次)
2. 002-implement-endpoint (Group B・001完了後)
3. 003-add-validation (Group B・001完了後・別ファイル)
4. 004-add-error-handling (002完了後)
5. 005-add-tests (004完了後)

**リファクタリング**:
1. 001-analyze-current (順次)
2. 002-design-new-structure (順次)
3. 003-extract-xxx (Group C・002完了後)
4. 004-extract-yyy (Group C・002完了後・別領域)
5. 005-update-references (003, 004完了後)
6. 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` 雛形（拡張子は形式に従う）+ `progresses/README.md` 雛形
  - 参照頻度: 毎回（Phase 2で必ず実行）

### references/

- `references/prompt-template.md` - **Phase 1で毎回参照する入力テンプレート**。生成開始条件、不足判定、段階的な質問順を定義
- `references/html-output-guide.md` - **HTML形式選択時の生成ルール（Phase 1でHTMLを選んだら必ず参照）**。シェル使用法・Mermaid・依存メタ埋め込み・拡張子規約・task-performer互換注記
- `../_shared/references/task-management-contract.md` - **Phase 1で毎回参照する共有保存契約**。`PROGRESS.md`、`progresses/README.md` の固定スキーマと `logs/` への振り分けを定義
- `../_shared/scripts/sync_progress_index.py` - **Phase 3で全TODO生成後に実行する同期スクリプト**。個別 `PROGRESS.md` から全体進捗一覧を生成

### 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双方が使用）**