subagent-driven-development

subagent-driven-development スキルの概要

subagent-driven-development スキルは、実装作業を独立したタスクに分解し、各タスクを新しいサブエージェントに割り当て、結果を確認してから次へ進めるためのものです。品質管理を落とさずにスピードを上げたい、エージェントのオーケストレーション用途に最適です。

subagent-driven-development skill を使うのは、計画やバックログがあるとき、あるいは状態を共有しない複数の issue を扱うときです。バグ修正、機能の切り出し、リポジトリ整理、調査作業のように、ひとつの長いコンテキストで進めると遅くなり、ノイズも増えやすい作業に向いています。

このスキルが特に向いているケース

ファイル単位、サブシステム単位、あるいは意思決定単位で切り分けられるタスクに強みがあります。価値の中心は単なる並列化ではなく、各タスクをクリーンなサブエージェントから始めることでコンテキスト汚染を減らし、その出力を次に進む前に確認できる点にあります。

どんなときにフィットするか

3件以上の独立した issue に対して作業フローが必要なとき、または明確なステップをレビューゲート付きで順番に実行したいロードマップがあるときに選びます。即興のプロンプトではなく、再現性のある subagent-driven-development の手順を求める場合に特に有効です。

期待できること

期待すべきなのは、自動で全部やってくれる魔法ではなく、タスク分割とレビューのプロセスです。作業の境界をすでに把握しているほど、このスキルは速度と品質を高めます。問題が曖昧、強く結合している、あるいは全ステップでひとつの共通した推論の流れが必要な場合は、効果が下がります。

subagent-driven-development スキルの使い方

スキルをインストールして接続する

まず、エージェント環境で subagent-driven-development install の流れを使い、計画を始める前にスキルを読み込みます。利用しているプラットフォームがリポジトリからのスキルインストールに対応しているなら、NeoLabHQ/context-engineering-kit の plugins/sadd/skills/subagent-driven-development パスを指定してください。

曖昧な目的を使えるプロンプトに落とし込む

このスキルは、次の情報を与えると最もよく機能します。

• 対象の repo または workspace
• 望む最終成果を正確に説明したもの
• 独立したタスクや issue の一覧
• スコープ、テスト、触れてはいけない file に関する制約

たとえば「認証まわりを直して」ではなく、「ログインフロー、token refresh、error handling を別タスクとして監査し、各項目に 1 つずつサブエージェントを割り当て、結果を確認してから次へ進む」と指定します。

先に読むべきファイル

まず SKILL.md を読んで実行パターンを把握してください。その後、近くにあるドキュメントや repo の規約があれば確認します。この repository には support folder がないため、主な正本はスキル本体です。だからこそ、最初の読み込みは subagent-driven-development usage の判断にとって特に重要です。

実務フローでの使い方

基本の流れは、タスクを定義し、独立作業をグループ化し、タスクごとに新しいサブエージェントを送出し、コードと出力をレビューしてから、続行・修正・停止を判断することです。subagent-driven-development for Agent Orchestration では、各サブエージェントの担当範囲を狭く保ち、最後まで待たずに各タスクまたはバッチごとにレビューするのが重要です。

subagent-driven-development スキル FAQ

通常のプロンプトより優れていますか？

はい、作業が分割可能で、品質ゲートを設けたい場合はそうです。単発の変更なら通常のプロンプトでも十分ですが、subagent-driven-development skill は複数ステップの実装作業に対して、より規律のある実行ループを提供します。

これは人間のレビューを置き換えますか？

いいえ。タスク間でミスを引きずる可能性は下げられますが、判断が必要なポイントでのレビューは依然として必要です。このスキルは、レビューを不要にするのではなく、レビューコストを下げるためのものです。

初心者でも使いやすいですか？

タスクと境界を明確に説明できるなら、初心者にも使いやすいです。2つの issue が独立しているのか、それとも強く結合しているのかをまだ見分けにくい段階では、うまく使うのが難しくなります。

使わないほうがいいのはいつですか？

小さな修正、強く絡み合ったリファクタリング、またはひとつの共有された調査経路が必要な問題では使わないほうがいいです。そのような場合、サブエージェントのオーケストレーションにかかるオーバーヘッドが、得られる利点を上回ることがあります。

subagent-driven-development スキルを改善するには

サブエージェントごとのタスク境界をもっと明確にする

入力が良ければ、出力も良くなります。「コードベースを改善して」ではなく、「lint 修正と test failure を分け、その後で file group ごとに独立してレビューする」のように具体化してください。境界が明確だと、作業の重複なくタスクを割り当てやすくなります。

受け入れ条件と停止条件を追加する

完了条件を明記します。変更した file、通過すべき tests、許容する risk の上限、API 変更禁止といった条件です。これにより subagent-driven-development guide が実行しやすくなり、サブエージェントが必要以上に踏み込むのを防げます。

よくある失敗パターンに注意する

最大の失敗要因は、タスクの重なり、曖昧なスコープ、サブタスク同士の依存が強すぎることです。あるタスクが別タスクの shared state を必要とするなら、サブエージェントを送る前にまとめてください。

1回目の実行後に改善する

最初の出力は、結果をただ採用するか却下するためではなく、タスクの粒度を見直す材料として使います。サブエージェントの返答が広すぎたなら、作業をさらに分割します。逆に細かすぎたなら、関連する確認を 1 回のレビューサイクルにまとめます。