parallel-feature-development

parallel-feature-development スキルの概要

parallel-feature-development スキルでできること

parallel-feature-development スキルは、1つの機能を複数の実装ストリームに分割し、複数のエージェントが同じファイルで衝突せずに並行して作業できるよう支援します。価値の中心は、抽象的に「コード生成を速くする」ことではありません。マージ時の痛みを減らし、責任範囲を明確にし、独立した作業を安全に進められるだけのインターフェース契約を早い段階で固めることにあります。

このスキルが向いている人

このスキルが特に合うのは、次のようなケースです。

• 1つの機能を複数の AI エージェントや実装担当者で進めるチーム
• UI、API、types、tests、data layer までまたぐ中規模〜大規模な変更を設計するリード
• コーディングそのものより、マージ衝突や責任分担の曖昧さが開発速度を落としているリポジトリ
• branch、ownership、integration のルールを意図的に設計したい Git ワークフロー

実装担当が1人だけ、あるいは変更がごく小さく独立しているなら、parallel-feature-development は必要以上に構造化しすぎになることが多いです。

本当に解決したい仕事

ユーザーが parallel-feature-development for Git Workflows を導入するのは、次のような実務的な問いに答えが欲しいからです。

• 機能をどう分解すべきか
• どのファイルを誰の担当にすべきか
• 共有すべきもの、あるいは lead が持つべきものは何か
• directory 単位、module 単位、layer 単位のどれで分けるべきか
• この機能に最も安全な merge パターンはどれか

差別化ポイントは、こうした判断支援にあります。汎用的なプロンプトでも「作業を分けましょう」とは言えますが、このスキルは file ownership と integration まで踏み込んだ、実際に使える計画フレームを提供します。

普通の planning プロンプトと何が違うのか

このリポジトリが実用的なのは、次の要素が揃っているからです。

• directory 単位・module 単位の ownership 戦略
• references/file-ownership.md にある具体的な project type 別の例
• references/merge-strategies.md にある merge パターンのガイダンス
• interface point、shared types、dependency を踏まえた integration への明確な注力

そのため、parallel-feature-development skill は、曖昧な「複数エージェントを調整して」という指示よりも、はるかに実行に移しやすい内容になっています。

インストール前に確認したいこと

このスキルは、並列実行の計画を助けてほしい場合に導入してください。branch を自動でオーケストレーションしたり、Git 上で ownership を強制したりするものではありません。自動化ツール寄りではなく、ガイダンス重視のスキルです。導入判断はシンプルで、人でもエージェントでも再現できる分解方法が必要かどうかです。

parallel-feature-development スキルの使い方

parallel-feature-development のインストール方法

wshobson/agents リポジトリに対する通常の skills 導入フローを使い、agent-teams プラグインセットから parallel-feature-development スキルを読み込みます。よくあるインストール例は次のとおりです。

npx skills add https://github.com/wshobson/agents --skill parallel-feature-development

利用環境で別の skill loader を使っている場合でも、重要なのはソースパスです。
plugins/agent-teams/skills/parallel-feature-development

最初に読むべきファイル

短時間で要点をつかみたい parallel-feature-development guide としては、次の順で読むのがおすすめです。

1. SKILL.md
2. references/file-ownership.md
3. references/merge-strategies.md

この順番がよい理由は次のとおりです。

• SKILL.md で、このスキルを使うべき場面と主な分解パターンを把握できる
• references/file-ownership.md で、衝突しにくい担当境界を設計できる
• references/merge-strategies.md で、競合を減らしながら作業を再統合する方法がわかる

スキルの精度を上げるために必要な入力

このスキルは、次の情報を与えると結果がかなり良くなります。

• 機能の目的を1文で
• 変更が入りそうな files または directories
• React、Next.js、Express、Fastify などの stack
• 実装担当者またはエージェントの人数
• branches、feature flags、direct commits のどれが許されるか
• 競合リスクの高い shared files
• build、typecheck、lint、tests など必須の checks

この文脈がないと、出力はどうしても汎用的になり、ownership model の選択も外しやすくなります。

曖昧な依頼を強いプロンプトに変える

弱い入力:

Split this feature across 3 agents.

より良い入力:

Use the parallel-feature-development skill to decompose an auth feature for 3 implementers in a Next.js app. Expected changes likely touch src/components/auth/, src/hooks/auth/, src/api/auth/, src/types/auth.ts, and tests. We want low merge risk, one lead-owned shared types file, and a merge plan that respects dependencies. Recommend file ownership, interface contracts, and the safest branch strategy.

このプロンプトが強いのは、想定ファイル境界、チームサイズ、stack、integration 上の制約まで含めているためです。

すぐ実行できる成果物を出してもらう

良い parallel-feature-development usage プロンプトでは、単なる助言ではなく、明示的な成果物を要求するべきです。モデルには次の出力を求めてください。

• implementer ごとの ownership map
• shared files とその owner
• 最初に安定化すべき contract definitions
• 推奨 branch strategy
• merge order
• integration 後の verification checklist

こうすることで、このスキルはそのままエージェントや reviewer に渡せる planning tool になります。

適切な ownership model を選ぶ

このリポジトリでは、主に次の2つの ownership アプローチを重視しています。

• By directory: 既にリポジトリの構造境界が明確な場合に最適
• By module: 1つの機能が複数箇所にまたがっていても、まとまりのある unit として扱える場合に有効

実務では次のように判断します。

• 構造が成熟して整理された repos では directory ownership を選ぶ
• folder 配置より機能的なまとまりが重要なら module ownership を選ぶ
• 同一ファイルを複数人で混在 ownership するのは避ける。やるなら shared contracts を1人の lead が明示的に持つ

shared contracts は最初に固める

このスキルで特に価値が高いのは、並列コーディングを始める前に interface point を定義するパターンです。多くの repos では、本当のボトルネックはコーディング速度ではなく、不安定な contracts です。

エージェントが実装に入る前に、次を固定してください。

• shared type definitions
• API の request / response shapes
• event names と payloads
• component や service の境界にある function signatures

ここを飛ばすと、並列作業は後から辻褄を合わせるだけの調整戦になりがちです。

チーム規模に合った integration パターンを選ぶ

references では、実用的な merge パターンとして次の3つが説明されています。

• Direct integration: 小規模チーム向け。ownership が厳密で、重なりが少ない場合
• Sub-branch integration: 大きめのチームや dependency の重い作業でより安全
• Trunk-based with feature flags: 継続的に本番投入する環境に向く

判断の近道は次のとおりです。

• 2〜3人の implementers で file 境界が明確なら、direct integration でも回る
• 4人以上、または重なりが読めないなら、sub-branches を使う
• 継続的に production へ出しているシステムなら、trunk-based + feature flags が最も混乱を起こしにくいことが多い

dependency を意識した merge 順序を使う

この repo の有用な点の1つが、dependency graph に基づく merge sequencing です。依存される基盤側の作業を、依存する側より先に merge します。典型的な順序は次のとおりです。

1. shared types または contracts
2. services または API layer
3. UI または consumer layer
4. tests と integration の仕上げ

重要なのは、多くの「conflicts」は Git の問題というより、contract を固めるタイミングの問題だということです。

毎回同じ方法で integration を検証する

並列実装の後は、固定の validation pass を走らせます。

• build check
• type check
• lint
• unit tests
• integration tests
• interface verification

この references/merge-strategies.md の checklist は、このスキルを使う強い理由の1つです。planning から integration quality まで、きちんとループを閉じられます。

実際のリポジトリでハマりにくい導入フロー

parallel-feature-development install と定着の実務フローは、次の形が現実的です。

1. 変更が入りそうな全ファイルを洗い出す
2. それらをまとまりのある ownership group にクラスタリングする
3. shared contract files を分離し、lead owner を決める
4. 重なり具合とチーム規模を見て branch strategy を選ぶ
5. 各 implementer に、担当 files と dependencies を明示して brief する
6. dependency 順で統合する
7. verification checklist を実行する

この使い方が、手戻りを最も減らしやすいパターンです。

このスキルが特に効くケース

parallel-feature-development は、機能が複数 layer をまたぐときに特に効果を発揮します。たとえば次のようなケースです。

• frontend + backend + tests
• routes + services + models
• hooks + API client + shared types
• event producer + event consumer + schema validation

逆に、1ファイルだけの孤立した変更、単独担当の bugfix、あるいは repo 構造が混沌としていてきれいな境界を定義できないタスクでは、価値は下がります。

parallel-feature-development スキル FAQ

小さな変更にも parallel-feature-development は使う価値がありますか？

たいていはありません。1人の implementer が無理なく完了できるなら、planning のオーバーヘッドのほうが大きくなりやすいからです。このスキルが真価を発揮するのは、コーディング難易度より coordination risk のほうが高い場面です。

parallel-feature-development スキルは初心者でも使えますか？

はい。ただし、自分のリポジトリの形をある程度理解している初心者に向いています。ownership や merge pattern の説明自体は明快ですが、どの files・layers・dependencies が関係するかを見極める前提は必要です。新しい開発者なら、まず codebase をマッピングする支援が必要なこともあります。

普通の「作業を分担して」プロンプトと何が違いますか？

通常のプロンプトは、役割分担で止まりがちです。parallel-feature-development skill はさらに踏み込んで、file ownership、shared contract の扱い、merge strategy の選定まで支援します。この追加の構造こそが、Git workflow の結果を改善するポイントです。

parallel-feature-development は Git の branch や merge を自動化しますか？

いいえ。提供するのは strategy と planning guidance です。実際の branch 作成、作業割り当て、code review、変更の merge は、自分たちの tooling で行う必要があります。

parallel-feature-development は Web 以外のプロジェクトでも使えますか？

はい。codebase を明確な interface を持つ ownership zone に分割できるなら使えます。付属 references は一般的な Web stack に特に強いですが、根本の方法論自体は、他の modular system にも応用できます。

どんな場合は parallel-feature-development for Git Workflows を使うべきではありませんか？

次のような場合は避けたほうがよいです。

• 機能が小さすぎて分解コストに見合わない
• 共有ファイルが多すぎて、きれいに ownership を切れない
• contracts が本質的にまだ不安定で、設計途中である
• 並列化する前に、1人の lead がまず prototype を作るべき

このようなケースでは、順番に実装したほうが速く、安全なことがあります。

parallel-feature-development スキルを改善するには

file 単位のたたき台を最初に渡す

出力品質を最も大きく押し上げるのは、変更候補の file list を渡すことです。完璧でなくても、ラフな一覧があるだけで、モデルは現実的な ownership boundary を提案しやすくなります。ゼロから作らせるより、自分の map を改善させる形で使うのが効果的です。

shared files と conflict hotspot を明示する

次のような、分割すると危険な files をスキルに伝えてください。

• shared type files
• route registries
• root configuration files
• central index exports
• layer をまたいで使われる schema definitions

これにより、parallel-feature-development は lead ownership や contract-first の順序づけを提案しやすくなります。

曖昧な選択肢を5つ求めるより、推奨案を1つ出させる

広く brainstorm させると、腰の引けた出力になりがちです。より良いプロンプトは次のようなものです。

Recommend the single best ownership model and merge strategy for this repo, with a short rationale and fallback only if the primary plan fails.

これなら、単なるメニューではなく、意思決定として使える回答が得られます。

実装計画の前に contract 定義を必須にする

よくある失敗は、interface の合意前に implementer を割り振ってしまうことです。結果を改善するには、次の内容を先に求めてください。

• 最初に安定化すべき contract files
• producer / consumer の正確な boundary
• 下流の作業を先に始める必要がある場合の temporary stubs や mocks

これは full-stack feature では特に重要です。

理由付きの merge order を要求する

「順番に merge してください」だけでは不十分です。dependency の順序を明示し、その理由まで説明するようスキルに求めてください。そうすることで integration の当て推量が減り、その分解案が本当に成立するかも見えやすくなります。

例を自分の stack に合わせて置き換える

references には、React/Next.js frontend、Express/Fastify backend、full-stack layout など、project type ごとのパターンが含まれています。これらをテンプレートとして使いつつ、path 名は自分の repo に合わせて置き換えてください。抽象的な layers だけでなく、実際の directories をプロンプトに含めたほうが、このスキルは格段に役立ちます。

過剰な並列化に注意する

見落とされがちな失敗パターンが、作業を細かく分けすぎることです。どの implementer も頻繁な contract 変更に依存する状態なら、それは速度ではなく coordination overhead を増やしているだけです。どの部分は順次進行に残すべきか、あるいは lead-owned にすべきかを、スキルに判定させてください。

最初の計画の後にもう一度回す

最初の parallel-feature-development guide を出した後は、新しい情報を踏まえて2回目を回してください。

• まだ重なっている boundary はどこか
• どの contracts がまだ曖昧か
• 見落としていた files は何か
• 選んだ branch strategy がまだ適切か

良い追加入力の例:

Revise the ownership map after discovering overlap in src/types/auth.ts and src/api/auth/index.ts. Minimize rebasing and keep one implementer responsible for final interface reconciliation.

references は読むだけでなく、意思決定に使う

references/file-ownership.md は、誰が何を持つかを決めるときに最も役立ちます。
references/merge-strategies.md は、どう着地させれば安全かを決めるときに最も役立ちます。

実行前に両方を見ておくほうが、いきなり implementation prompt に入るより結果が良くなります。

成功は integration friction で測る

実務で parallel-feature-development skill を改善する最善の方法は、計画そのものではなく結果で評価することです。

• merge conflicts が減ったか
• interface mismatches が減ったか
• integration 後の手戻りが減ったか
• implementer 間の handoff が速くなったか

ここが改善しないなら、必要なのは分解を増やすことではなく、ownership boundary をより良く切ること、あるいは contract 定義をもっと早めることです。