プロジェクト管理スキル

チームを管理 — 役割を作成し、タスクを割り当て、ワーカーを起動し、進捗を監視します

モデルが多様なサブエージェントカウンシルを実行し、同じ問題を複数の視点から調査し、結果を比較して最終的な推奨事項を生成します。ユーザーがカウンシル、セカンドオピニオン、一つの質問を評価するための複数のエージェント/モデル、並行調査、レッドチーム/ブルーチームの比較、または競合する技術的アプローチの選択の支援を求めた場合に、このスキルを使用してください。

2つ以上の独立したタスクに直面し、それらが共有状態や逐次的な依存関係なしに作業できる場合に使用します。

別のセッションでレビューチェックポイントを設けて実行するための、書面による実装計画がある場合に使用します。

実装が完了し、すべてのテストが合格した際に使用し、作業の統合方法を決定する必要がある場合に利用します。マージ、PR、クリーンアップの構造化されたオプションを提示することで、開発作業の完了を導きます。

ユーザーの計画や設計について、決定木の各分岐を解決しながら、相互理解に達するまで執拗に質問を続けます。ユーザーが計画をストレステストしたい、設計について詰められたい、または「grill me」と言った場合に使用します。

ユーザーの計画や設計について執拗に質問を重ねます。ユーザーが構築前に計画をストレステストしたい場合、または「grill」に関連するトリガーフレーズを使用した場合に使用します。

現在の会話を、別のエージェントが引き継ぐためのハンドオフ文書に圧縮します。

PRDまたは一連の課題に基づいて作業を実装する。

飞書審批 API：審批實例、審批任務管理。

飞书 OKR：目標と主要な結果を管理します。OKRサイクル、目標、主要な結果、アライメント関係、定量指標、進捗記録を表示・編集します。ユーザーがOKRの表示や作成、目標と主要な結果の管理、アライメント関係の確認を行う際に使用します。担当外：タスク管理（lark-task）、スケジュール/会議調整（lark-calendar）、パフォーマンス評価

飞书任务：管理任务、清单和任务智能体。创建待办任务、查看和更新任务状态、拆分子任务、组织任务清单、分配协作成员、上传任务附件、注册或注销任务智能体、更新任务智能体的主页数据、写入智能体任务记录。当用户需要创建待办事项、查看任务列表、跟踪任务进度、管理项目清单或给他人分配任务、为任务上传附件文件、注册注销任务智能体、更新智能体主页数据、写入任务记录时使用。

日程待办摘要：编排calendar +agenda和task +get-my-tasks，生成指定日期的日程与未完成任务摘要。适用于了解今天/明天/本周的安排。

ユーザーが製品のローンチ、機能発表、リリース戦略を計画したい場合に使用します。また、ユーザーが「ローンチ」「Product Hunt」「機能リリース」「発表」「Go-to-Market」「ベータローンチ」「アーリーアクセス」「ウェイトリスト」「製品アップデート」「どうやってローンチすればいいか」「ローンチチェックリスト」「GTM計画」「もうすぐリリースする」と言及した場合にも使用します。誰かが何かを公開リリースする準備をしているときに使用してください。ローンチ後の継続的なマーケティングについては、marketing-ideasを参照してください。

このワークスペース内で構築したいワークフローの仕様について、私に質問してください。

Nxワークスペースを探索・理解します。ワークスペース、プロジェクト、タスクに関する質問に答える際に使用します。また、nxコマンドが失敗した場合や、タスクを実行する前に利用可能なターゲットや設定を確認する必要がある場合にも使用します。例：「このワークスペースにはどのプロジェクトがありますか？」「プロジェクトXはどのように設定されていますか？」「ライブラリYに依存しているものは何ですか？」「実行可能なターゲットは何ですか？」「タスクの設定が見つかりません」「nxタスクの失敗をデバッグする」。

We need to translate the given English text into Japanese, preserving the name "orchestration" and technical terms like "Orca", "orca-cli", "task DAGs", etc. The instruction says to translate only the text inside <text>, and not include the name unless it appears in the source text. The name "orchestration" appears in the source text as part of "Orca orchestration", so we should keep it as is. Also preserve URLs, numbers, technical terms. No extra commentary. The text describes using Orca orchestration for various multi-agent coordination patterns, and then mentions using orca-cli for full ownership handoffs with specific phrases. We need to produce a natural Japanese translation that maintains the technical terms. Let's break it down: "Use Orca orchestration for structured multi-agent coordination: threaded messages, blocking ask/reply flows, task dispatch, worker_done/escalation waits, task DAGs, decision gates, coordinator loops, or decomposing work across agents." Translation: "Orca orchestrationを使用して、構造

Manusスタイルのファイルベース計画を実装し、複雑なタスクの整理と進捗追跡を行います。task_plan.md、findings.md、progress.mdを作成します。マルチステップのプロジェクト、調査タスク、または5回以上のツール呼び出しが必要な作業の計画立案、分解、整理を求められた際に使用します。/clear後の自動セッション復元をサポートします。

ユーザーとのインタビューを通じて小さなコミット単位の詳細なリファクタリング計画を作成し、それをGitHub Issueとして登録します。ユーザーがリファクタリングの計画を立てたい場合、リファクタリングRFCを作成したい場合、またはリファクタリングを安全な段階的ステップに分割したい場合に使用します。

自律的で仕様駆動型の開発「サガ」を実行し、中規模から大規模な機能をオーケストレーターエージェントとワーカーサブエージェント群で実現します。ユーザーが/sagaを呼び出したとき、人間の介入を最小限に抑えて大規模な機能をエンドツーエンドで自律的に構築したいとき、並列実装前にマイルストーンとタスクに分割され、厳格な検証基準を持つ包括的な仕様を求めるとき、またはオーケストレーターがワーカーエージェントに実装を委任し、その…を維持したいときにこのスキルを使用します。

Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.

実装前にPRODUCT.mdを作成し、必要に応じてTECH.mdを作成し、実装の進行に合わせて両方の仕様を更新することで、大規模な機能に対して仕様駆動のワークフローを推進します。重要な機能の開始時、エージェント駆動の実装計画時、またはユーザーが製品仕様と技術仕様をソース管理にチェックインしたい場合に使用します。

現在のセッション内で独立したタスクを持つ実装計画を実行する際に使用する

大まかなアイデアを、コード作成前に承認され意思決定が完了した検証済み構造の計画に変換します。ユーザーが機能、アーキテクチャ、価値判断について「出方案/给方案/深入分析/怎么设计/有没有必要/值不值得/plan this/how should I/should we keep this」と尋ねた場合に使用します。バグ修正や小さな編集には使用しません。

計画、仕様、PRDを、トレーサー・ブレットの垂直スライスを用いて、プロジェクトの課題トラッカー上で個別に取得可能な課題に分割します。ユーザーが計画を課題に変換したい、実装チケットを作成したい、または作業を課題に分解したい場合に使用します。

現在の会話コンテキストをPRDに変換し、プロジェクトの課題トラッカーに公開します。ユーザーが現在のコンテキストからPRDを作成したい場合に使用します。

トリアージロールによって駆動されるステートマシンを通じて課題をトリアージします。ユーザーが課題を作成したい、課題をトリアージしたい、新着のバグや機能リクエストをレビューしたい、AFKエージェント向けに課題を準備したい、または課題ワークフローを管理したい場合に使用します。

Warpの重要なユーザー向け機能について、詳細な動作と検証に焦点を当てたPRODUCT.md仕様書を作成します。ユーザーがプロダクト仕様、期待動作ドキュメント、PRDを求めている場合、実装前に機能の動作を定義したい場合、または仕様書を作成することで実装やレビューが改善されるほど機能が大規模または動作的に曖昧な場合に使用します。

コードに触れる前に、複数ステップのタスクの仕様や要件がある場合に使用します。