parallel-feature-development

parallel-feature-development 技能概览

parallel-feature-development 技能是做什么的

parallel-feature-development 技能用于把一个功能拆分成多个可并行推进的实现流，让多个 agent 或开发者能够同时工作，又尽量避免改到同一批文件而互相冲突。它的核心价值并不是抽象意义上的“更快生成代码”，而是减少合并阶段的痛苦、明确归属边界，并且尽早定义接口契约，让彼此独立的工作可以更安全地并行展开。

谁适合使用这个技能

这个技能尤其适合以下场景：

• 一个功能需要多个 AI agent 或多位实现者协作
• 技术负责人要规划一项中大型改动，涉及 UI、API、types、tests 或数据层
• 仓库里真正拖慢交付的不是写代码，而是 merge conflict 和职责不清
• Git workflow 需要更明确的分支、归属和集成规则

如果你只有一个实现者，或者只是一个很小、很独立的改动，parallel-feature-development 往往会比实际需要更“重”。

这个技能真正解决的问题

用户选择 parallel-feature-development for Git Workflows，通常是因为他们需要回答这些非常实际的问题：

• 这个功能应该怎么拆？
• 哪些文件该归哪个实现者负责？
• 哪些内容必须共享，或者应由 lead 统一持有？
• 应该按目录、按模块，还是按层来拆分？
• 这个功能最安全的 merge 模式是什么？

真正让它有区分度的，就是这类决策支持。普通 prompt 可能只会建议“把工作拆开”，而这个技能提供的是可执行的规划框架，能直接落到文件归属和集成方式上。

它和普通规划类提示有什么不同

这个仓库之所以有用，关键在于它把下面几类内容组合在了一起：

• 按目录和按模块的归属策略
• references/file-ownership.md 里的具体项目类型示例
• references/merge-strategies.md 里的 merge 模式建议
• 对接口点、共享 types 和依赖感知式集成的明确强调

因此，parallel-feature-development skill 比那种模糊的“协调多个 agents”指令更可落地，也更容易真正用于团队协作。

安装前你应该先确认什么

如果你要的是并行执行的规划支持，而不是自动帮你编排分支或在 Git 里强制执行所有权规则，那就适合安装这个技能。它偏重方法与决策指导，而不是工具自动化。采纳与否，其实就看一个问题：你是否需要一套人和 agent 都能重复执行的拆分方法。

如何使用 parallel-feature-development 技能

parallel-feature-development 的安装上下文

按你平时的 skills 安装流程，从 wshobson/agents 仓库加载 agent-teams 插件集里的 parallel-feature-development skill 即可。常见安装方式是：

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 则说明如何把并行产出重新集成回来，并尽量减少冲突。

想让技能发挥效果，需要提供哪些输入

如果你能提供下面这些信息，技能输出通常会明显更好：

• 用一句话说明 feature 目标
• 可能会改动的文件或目录
• 你的技术栈，例如 React、Next.js、Express 或 Fastify
• 实现者或 agents 的数量
• 是否允许使用 branches、feature flags 或 direct commits
• 哪些共享文件是高风险冲突区
• 必须通过的检查项，例如 build、typecheck、lint 和 tests

缺少这些上下文时，输出很容易停留在泛泛而谈的层面，甚至会选错归属模型。

把模糊目标变成高质量 prompt

弱输入：

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.

之所以更强，是因为它补齐了关键上下文：可能涉及的文件边界、团队规模、技术栈，以及集成约束。

让 parallel-feature-development 直接产出可执行结果

一个好的 parallel-feature-development usage prompt，不该只要“建议”，而应该明确要求可直接执行的产出。可以让模型给出：

• 按实现者划分的 ownership map
• 共享文件及其 owner
• 哪些 contract 必须先稳定下来
• 推荐的 branch strategy
• merge 顺序
• 集成后的 verification checklist

这样一来，这个技能就不只是“提建议”，而会变成你可以直接发给 agents 或 reviewer 的规划工具。

选择合适的归属模型

这个仓库重点强调两种主要的 ownership 方式：

• By directory：适合仓库本身已经有清晰的结构边界
• By module：适合一个功能横跨多个位置，但仍然属于同一个完整模块

实际选择时，可以这样判断：

• 仓库结构成熟、组织清晰时，优先选 directory ownership
• 功能内聚性比文件夹布局更重要时，优先选 module ownership
• 尽量避免同一个文件被多人混合持有；如果必须这样做，至少要由一位 lead 明确负责共享 contract

尽早处理共享契约

这个技能里价值最高的实践之一，就是在并行开发开始前先定义好接口点。很多仓库里真正的瓶颈并不是写代码速度，而是 contract 不稳定。

在 agents 开始实现前，先把这些内容定下来：

• 共享 type definitions
• API request 和 response 的 shape
• event names 和 payloads
• 组件或 service 边界上的 function signatures

如果跳过这一步，并行工作通常很容易退化成事后对账式的返工。

选择与团队规模匹配的集成模式

参考文件里给出了三种实用的 merge 模式：

• Direct integration：适合小团队、归属严格、预计重叠很少
• Sub-branch integration：更适合更大的团队，或者依赖关系更重的工作
• Trunk-based with feature flags：适合持续部署环境

快速判断可以这样用：

• 2 到 3 位实现者，且文件边界很干净：可以考虑 direct integration
• 4 位以上实现者，或者边界是否重叠还不确定：更建议用 sub-branches
• 生产系统持续发布：trunk-based 加 feature flags 往往干扰最小

使用基于依赖关系的 merge 顺序

仓库里一个很实用的细节，是按照 dependency graph 来安排 merge sequencing。先合并基础层，再合并依赖它的工作。典型顺序是：

1. 共享 types 或 contracts
2. services 或 API layer
3. UI 或 consumer layer
4. tests 和 integration polish

这点很重要，因为很多所谓“冲突”，本质上并不是 Git 问题，而是 contract 定义时机不对。

每次都用同一套方式验证集成结果

并行实现完成后，固定跑一轮验证：

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

这个来自 references/merge-strategies.md 的 checklist，是这个技能最值得用的原因之一：它把流程从前期规划闭环到了集成质量。

真实仓库里最适合的 parallel-feature-development 工作流

一套比较实用的 parallel-feature-development install 与落地流程，大致是这样：

1. 先找出所有可能改动的文件
2. 把它们按内聚性聚成若干 ownership group
3. 把共享 contract 文件单独隔离出来，并指定 lead owner
4. 根据重叠程度和团队规模选择 branch strategy
5. 给