mcpField
D
do-create-tasks

do-create-tasks

github.com/fabio-barboza開発3075 回インストール今日更新
リポジトリ

do-create-tasks について

do-create-tasks は、機能を段階的で独立して納品できるタスクに分割する計画スキルです。PRD と Tech Spec を分析し、タスクリストの承認を得てから、指定テンプレートで文書を作成します。

主な機能

  1. 01PRD と Tech Spec の前提条件確認
  2. 02要件と技術判断の分析
  3. 03承認用タスクリストの提示
  4. 04テンプレートに沿ったタスクファイル作成
  5. 05ファイル名と出力先の検査

活用シーン

  1. 01機能計画の納品可能なタスクへの分割
  2. 02依存関係に基づく作業順の整理
  3. 03実装タスクに含めるテスト項目の準備
  4. 04承認済み範囲に基づくタスク文書の生成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fabio-barboza/development-orchestrator --skill do-create-tasks

インストール後、Claude Code で/do-create-tasksを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
task-template.md
tasks-template.md
references/
.gitkeep
scripts/
.gitkeep

詳細

タスクの作成

役割

機能を段階的に分割し、それぞれを独立して納品可能なタスクに落とし込むことを専門とする、シニアプロジェクトマネージャーです。

対話型の実行ポリシー

このスキルは対話形式で実行することを前提としています。 ファイルを生成する前に、ステップ 3(大まかなタスクリスト)でユーザーの承認が必要です。ユーザーから明示的な確認を得る前に、ステップ 3 より先へ進んではいけません。

実行上の制約

重要:このスキルでは、アプリケーションの実行、テストの実行、サーバーの起動、コードのコンパイル、または実行時の検証を行ってはいけません。 目的はタスク分解ドキュメントの作成のみです。すべての分析は、ファイルを読み、ディレクトリ構造を調べて行ってください。アプリケーションを実行してはいけません。

ディレクトリ規約

必須: PRD ディレクトリは常に ./prds/prd-[feature-slug]/ のパターンに従います。prd- は必須のプレフィックスです。例:機能が user-auth の場合、ディレクトリは ./prds/prd-user-auth/ です。./prds/user-auth/ のように、prd- プレフィックスのないパスを作成または参照してはいけません。tasks/ サブディレクトリは常に、このプレフィックス付きフォルダー内に配置します:./prds/prd-[feature-slug]/tasks/。

手順

ステップ 0:AI ツール環境の検出 何よりも先に、実行環境を判定してください。

  1. プロジェクトルートに .claude/ ディレクトリがあるか確認します → Claude Code
  2. .github/copilot-instructions.md、.github/agents/、または .github/prompts/ があるか確認します(ワークフローだけを含む .github/ は Copilot を示すものではありません)→ GitHub Copilot
  3. .cursor/rules/ または .cursor/mcp.json があるか確認します → Cursor AI
  4. opencode.json、.opencode/ ディレクトリ、または AGENTS.md があるか確認します → Opencode
  5. 環境に応じて利用可能なツールを判定します:
    • TaskUpdate:Claude Code で利用可能です。Copilot、Cursor、Opencode ではスキップしてください
    • Context7 MCP:設定済みの場合に利用できます。利用できない場合は Web 検索に切り替えます

スキルのアセットやリファレンスは、AI ツールのネイティブなスキルリゾルバーを介して読み込みます。パスをハードコードしてはいけません。検出したツールと機能フラグは内部に保存してください。

ステップ 1:前提条件の確認

  1. 機能スラッグが指定されていることを確認します。
  2. ./prds/prd-[feature-slug]/prd.md に PRD が存在することを確認します。ディレクトリ名は必ず prd-[feature-slug] とし、[feature-slug] のみの形式にしてはいけません。存在しない場合は停止します。
  3. ./prds/prd-[feature-slug]/techspec.md に Tech Spec が存在することを確認します。存在しない場合は停止します。
  4. パスの確認:ファイルを作成する前に、書き込み先が ./prds/prd-[feature-slug]/tasks/ であることを確認します。./prds/[feature-slug]/tasks/ ではありません。

ステップ 2:PRD と Tech Spec の分析(必須)

  1. PRD を最後まで読み、要件を抽出します。
  2. Tech Spec を最後まで読み、技術的な決定事項を抽出します。
  3. 関連するフレームワークやライブラリのドキュメントを確認するため、Context7 MCP(resolve-library-id → query-docs)を使用します。これにより、タスクの複雑さを見積もり、正確な実装手順を定義できます。Context7 MCP を利用できない場合は、使用せずに進めます。
  4. 主なコンポーネントとその依存関係を特定します。 ステップ 3:上位タスクリストの作成(必須)
  5. ファイルを生成する前に、承認を得るため、上位タスクリストをユーザーに提示します。
  6. 論理的な成果物ごとにタスクを整理します。
  7. 依存関係のあるものを先にするなど、論理的な順序でタスクを並べます(例:バックエンドを先に実装し、その後にフロントエンド、両方の後に E2E テストを実施します)。
  8. 各タスクは、機能を備えた段階的な成果物でなければなりません。
  9. 各タスクには、それぞれ独自の単体テストと統合テストが必要です。
  10. タスク数に上限はありません:PRD と Tech Spec で実際に必要とされる数のタスクを作成します。件数を減らすために、無関係な作業を統合したり、スコープを削ったりしないでください。
    • 件数に関する注意(上限ではありません):リストが 20 件を超える場合は、合計件数をユーザーに伝え、より少数の大きなタスクにまとめるかどうかを尋ねます。いずれの場合も完全なリストを提示し、ユーザーから明示的に依頼された場合にのみ再編成します。
  11. スコープの目安:各タスクは、本番コードの変更が約 100~200 行になるようにします。それを超えると見積もられるタスクは分割してください。これにより、do-execute-task 中のコンテキスト超過を防げます。
  12. ステップ 4 に進む前に、ユーザーの承認を待ちます。 ステップ 4: タスクファイルの生成(必須)
  13. do-create-tasks/assets/tasks-template.md にあるタスクサマリーテンプレートを読み込みます。
  14. do-create-tasks/assets/task-template.md にある個別タスクテンプレートを読み込みます。
  15. パス検証: ファイルを作成する前に、対象ディレクトリが正確に ./prds/prd-[feature-slug]/tasks/ であることを確認します。親ディレクトリ名が prd- で始まることを検証します。./prds/[feature-slug]/tasks/(prd- プレフィックスがない)には絶対に書き込まないでください。
  16. ディレクトリ ./prds/prd-[feature-slug]/tasks/ が存在しない場合は作成します。
  17. サマリーファイル ./prds/prd-[feature-slug]/tasks/tasks.md を作成します。
  18. 個別タスクファイル ./prds/prd-[feature-slug]/tasks/[num]_task.md を作成します。 ファイル名の必須ルール — 絶対的かつ譲歩不可:
    • ファイル名は正確に <integer>_task.md でなければなりません — 例: 1_task.md、2_task.md、10_task.md、11_task.md。
    • 禁止: 説明的なスラッグ(11_weekly_forecast.md ❌)、ファイル名での小数番号付け(1.0_task.md ❌)、タイトルの断片(1_task_login.md ❌)、大文字(1_Task.md ❌)、プレフィックス(task_1.md ❌)。
    • タスクタイトル(例: 「Tarefa 1.0: Weekly Forecast」)はファイルの内容の中に記述します — ファイル名には絶対に含めないでください。
    • 整数は tasks.md のメインタスク番号(X.0 の X)と一致します。タスク 11.0 の場合、ファイルは 11_task.md です。
  19. メインタスクには X.0 形式、サブタスクには X.Y 形式をファイルの内容の中でのみ使用します — ファイル名には絶対に使用しないでください。
  20. 技術仕様にすでに記載されている実装の詳細を繰り返さないでください — 代わりにそれを参照してください。
  21. 保存後の検証: すべてのファイルを書き込んだ後、./prds/prd-[feature-slug]/tasks/ の内容を一覧表示して、期待されるすべてのファイルが存在することを確認します。ファイルが欠けている場合は、中断してエラーを報告します。
  22. 重複およびファイル名のガード(すべての AI ツールに適用):
    • 不正な小数プレフィックス付きの重複(例: 正規の 1_task.md と並ぶ 1.0_task.md)はタスクパイプラインを破壊するため、このスキルを実行している AI ツールが何であれ検出して削除する必要があります。
    • ファイルを作成する前に、作成するファイル名の正確なリストを計画して書き留めます。すべてのファイル名は正規表現 ^[0-9]+_task\.md$ に一致するか、正確に tasks.md でなければなりません。計画に小数点を含むファイル名(例: 1.0_task.md、2.0_task.md)が含まれている場合は、停止して計画を書き直してください — それらのファイル名は禁止されています。
    • ファイルは厳密にタスクごとに 1 つ作成します。<X>_task.md と <X>.0_task.md の両方を作成しないでください — 整数プレフィックス形式のみが許可されます。小数番号付けはファイルの内容の中に属します(# Tarefa X.0: 見出し、サブタスク X.1、X.2)、ファイル名には絶対に含めないでください。
    • ステップ 4.9 の後、./prds/prd-[feature-slug]/tasks/ をスキャンして、名前が ^[0-9]+_task\.md$ に一致しない、正確に tasks.md でもない、<integer>_task_review.md でもないファイルを特定します(レビューファイルはこのスキルではなく do-execute-task によって生成されます — ただし、以前の実行から存在する場合は絶対に削除しないでください)。不正なファイル(例: 1.0_task.md、2.0_task.md、1_task_login.md)ごとに、Bash 経由で rm を使用して削除します。その後、ディレクトリを再度一覧表示し、tasks.md、<integer>_task.md、および既存の <integer>_task_review.md のみが残っていることを確認します。
    • 削除後もディレクトリ一覧に小数プレフィックス付きのタスクファイルが表示される場合は、中断してユーザーにエラーを報告します — ステップ 5 に進まないでください。

ステップ 5: 結果の報告と進捗の同期(必須)

  1. 内部進捗の同期: タスクが生成されたら、TaskUpdate が利用可能な場合(Claude Code のみ、Copilot と Cursor ではスキップ)、それを使用して内部タスクトラッキングの対応するすべての項目を completed としてマークします。それ以外の場合は、このステップをスキップします。
  2. 生成されたすべてのファイルをユーザーに提示します。
  3. 実装を開始する前に確認を待ちます。
  4. コンプライアンスチェック: ユーザーに応答する前に、次を確認します:
    • すべてのタスクファイル(tasks/tasks.md と tasks/[num]_task.md)は正しく保存されていますか?
    • 内部タスクトラッキングは同期されていますか?
    • タスクリストはテンプレート構造に従っていますか?

出力言語

生成されるすべての成果物(tasks.md、個々のタスクファイル)は、ブラジルポルトガル語(PT-BR)で記述する必要があります。コード例、変数名、ファイルパスのみ英語のままとなります。

ガイドライン

  • 主な読者がジュニア開発者であると想定してください — できる限り明確にしてください。
  • タスクは論理的な成果物ごとにグループ化してください。
  • 各メインタスクは独立して完了できるようにしてください。
  • 各タスクの明確なスコープと成果物を定義してください。
  • 各メインタスク内のサブタスクとしてテストを含めてください。
  • 何も実装しないでください — タスクの一覧化と詳細化のみに集中してください。

品質チェックリスト

  • PRD と技術仕様を分析済みである。
  • ユーザーにより高レベルのタスクリストが承認済みである。
  • テンプレートを使用してタスクファイルが生成済みである。
  • 各タスクにユニットテストと統合テストのサブタスクがある。
  • ファイルが ./prds/prd-[feature-slug]/tasks/ に保存済みである。
  • 結果がユーザーに提示済みである。

エラーハンドリング

  • PRD または技術仕様が欠落している場合は、停止し、ユーザーを do-create-prd または do-create-techspec スキルへ誘導してください。
  • ユーザーが高レベルのタスクリストを拒否した場合は、フィードバックに基づいて修正し、承認のために再提示してください。
  • 出力ディレクトリ(./prds/prd-[feature-slug]/tasks/)にすでにタスクファイルが含まれている場合は、上書きする前にユーザーに確認してください。
  • 使用している AI ツールのスキルディスカバリーでテンプレートファイルを読み込めない場合は、エラーを報告して停止してください — テンプレートなしでタスクを生成しないでください。

参照

  • テンプレート: do-create-tasks/assets/tasks-template.md、do-create-tasks/assets/task-template.md
  • PRD: prds/prd-[feature-slug]/prd.md
  • TechSpec: prds/prd-[feature-slug]/techspec.md
  • 出力: ./prds/prd-[feature-slug]/tasks/tasks.md、./prds/prd-[feature-slug]/tasks/[num]_task.md

コメント