Agent-Skills.md

Agent Skills: Task Starter

|

UncategorizedID: goldeneggg/dotfiles/task-starter

Repository

goldeneggg/dotfiles
goldeneggg
1

Install this agent skill to your local

pnpm dlx add-skill https://github.com/goldeneggg/dotfiles/tree/HEAD/ai-linux/.claude/skills/task-starter

Skill Files

Browse the full folder contents for task-starter.

Download Skill

Loading file tree…

ai-linux/.claude/skills/task-starter/SKILL.md

Skill Metadata

Name
task-starter
Description
|

Task Starter

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

スコープ

含むもの

  • プロジェクトフォルダ構造の新規生成
  • 仕様書・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）が一目で区別でき、計画の妥当性レビューや進捗把握がしやすくなる。

成功基準

  • 指定ディレクトリに YYYYMMDD-{name}/ フォルダ構造が生成されている
  • specs/ に要件・技術仕様を含む仕様書が作成され、非機能要件にセキュリティ・耐障害性・高可用性・スケーラビリティの方針が記載されている
  • todos/ に1-2時間粒度のタスクが**0xx 番台（001〜099）**で依存順に配置され、各 README.md の先頭フロントマターに depends_on / parallel_group が明記されている（1xx 番台は予約のため未使用）
  • 各 todos/{ID}/README.md に「開発原則チェック」（4原則の該当 or N/A理由）が記載されている
  • todos/README.md に Mermaid DAG・タスク表・クリティカルパス・並行可能タスク群・推奨ワークロードが記載されている
  • ユーザーが Phase 5 のレビューで承認している

ワークフロー

Phase 1: 情報収集

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

    AskUserQuestionツールで確認（$ARGUMENTSで既知の項目はスキップ）:
- プロジェクト/タスク名（$ARGUMENTSがあれば確認のみ）
- 出力先ディレクトリ
- 概要と目的
- 新規開発 or 既存コード改修

  2. 既存コード改修の場合、現状を分析

    • 関連ファイルをGlob/Grep/Readで調査
    • アーキテクチャと処理フローを把握
    • 課題・改善点を特定

Phase 2: 構造生成

  1. プロジェクトフォルダを作成

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

    生成される構造:

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

  2. 参考ファイルの有無を確認

    • ユーザーに参考データ・ファイルがあるか AskUserQuestionツールで確認
    • あれば files/ にコピーまたはリンク

Phase 3: ドキュメント生成

  1. references/ - 現状分析（既存コード改修時のみ）

    • references/templates/reference-template.md をベースに作成
    • 現状のアーキテクチャ、主要コンポーネント、処理フローを記載
    • 不明点はAskUserQuestionツールで随時確認

  2. 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」セクションを参照
    • ユーザーとの相談で曖昧な条件しか得られなかった場合は、検証可能な代替指標（コマンド出力等）を提案して合意を取る

  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（理由）」を記載する。セキュリティ対応は分量が大きければ独立タスクとして起票する
    • 不明点はAskUserQuestionツールで随時確認

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

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

  1. 依存関係の整理 各 todos/{ID}/README.md のフロントマター（depends_on, parallel_group）を集約し、以下を算出:

    • 依存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
└── 📁 logs/

  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: 並行可能性の判定で曖昧な場合はAskUserQuestionで確認
  • Phase 5: 必須（レビューと承認）
  • 途中キャンセル: 生成途中のファイルは削除またはユーザーに確認

エラーハンドリング

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

前提条件

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

リソース

scripts/

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

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で毎回参照）