Task: {Stream Name}

Task: {Stream Name}

Objective

{1-2 sentence description of what to build}

Owned Files

• {file1} — {purpose}
• {file2} — {purpose}

Requirements

1. {Specific deliverable 1}
2. {Specific deliverable 2}
3. {Specific deliverable 3}

Interface Contract

• Exports: {types/functions this stream provides}
• Imports: {types/functions this stream consumes from other streams}

Acceptance Criteria

• [ ] {Verifiable criterion 1}
• [ ] {Verifiable criterion 2}
• [ ] {Verifiable criterion 3}

Out of Scope

• {Explicitly excluded work}

模板中每个字段都有明确的协作含义：

- **Objective**：一两句说清要构建什么，供接收任务的 implementer 快速对齐目标；
- **Owned Files**：显式列出该成员**可修改**的文件/目录——[team-implementer.md](https://gitcode.com/GitHub_Trending/agents24/agents/blob/a30778f8c4e6b0a87567941b7cca4f534bf642b6/plugins/agent-teams/agents/team-implementer.md?utm_source=gitcode_repo_files) 的文件归属协议第 1 条就是"只修改分配给你的文件——查看任务描述中显式的归属文件清单"，第 5 条"拿不准就问"也以这份清单为判定依据；
- **Requirements**：具体可交付物或预期行为，而非笼统目标；
- **Interface Contract**：Exports/Imports 双向声明本流提供什么、消费别的流什么，让并行方可以在对端未完成时先对着契约开发（team-implementer 的"集成点"章节明确要求：开发期对依赖组件打桩/mock，实现完成后再替换）；
- **Acceptance Criteria**：可勾选、可验证的完成判据，对应 implementer 工作流中 Phase 4（Verify）"确认验收标准满足"；
- **Out of Scope**：显式排除项，防止范围蔓延——team-implementer 的行为特质中"No scope creep"与之一一对应。

## 五、支撑分解的两块基石：文件归属与依赖图

### 文件归属决策框架

分解示例中"owned files 零重叠"不是巧合，而是一套决策流程。[file-ownership.md](https://gitcode.com/GitHub_Trending/agents24/agents/blob/a30778f8c4e6b0a87567941b7cca4f534bf642b6/plugins/agent-teams/skills/parallel-feature-development/references/file-ownership.md?utm_source=gitcode_repo_files) 给出了四步归属决策法：

1. **Step 1 列出全部文件**——枚举该功能需要新建或修改的每个文件；
2. **Step 2 识别自然聚类**——按目录邻近、功能关联（互相 import 的文件）、层归属（全部 UI 文件、全部 API 文件）分组；
3. **Step 3 将聚类分配给 owner**——每个聚类成为一个 implementer 的归属边界，要求：没有文件出现在多个聚类中、每个聚类内部内聚、跨聚类依赖最小化；
4. **Step 4 定义接口点**——在聚类交互处定义共享类型（由 lead 或指定 implementer 拥有）、API 契约（函数签名、请求/响应结构）、事件契约（事件名与 payload 结构）。

该文档还按项目类型给出了常见归属划分，例如 React/Next.js 前端中 `src/components/{feature}/`、`src/hooks/{feature}/`、`src/api/{feature}/` 分别归三位 implementer，`src/types/{feature}.ts` 归 lead 共享；Django 项目中 views/urls/forms 与 models/serializers/managers 分属两个 owner，`{app}/tests/` 归第三方。当两个 implementer 需要改同一个文件时，冲突解决顺序是：**优先拆分文件 → 指定单一 owner（另一方发变更请求）→ 最后手段是顺序访问，绝不允许多人同时改同一文件**。

[parallel-feature-development/SKILL.md](https://gitcode.com/GitHub_Trending/agents24/agents/blob/a30778f8c4e6b0a87567941b7cca4f534bf642b6/plugins/agent-teams/skills/parallel-feature-development/SKILL.md?utm_source=gitcode_repo_files) 的 Troubleshooting 章节进一步给出了实战故障定位，与分解质量直接相关："即使有清晰归属规则仍出现合并冲突"通常源于某个文件被分配给两个 Agent，或 `index.ts`/`__init__.py` 这类自动导入的 barrel 文件被双方修改——解法是指定 barrel/index 文件由单一 owner 持有，或由 lead 最后统一合并。

### 依赖图模式与反模式

分解确定后，依赖关系需要显式建模。[SKILL.md](https://gitcode.com/GitHub_Trending/agents24/agents/blob/a30778f8c4e6b0a87567941b7cca4f534bf642b6/plugins/agent-teams/skills/task-coordination-strategies/SKILL.md?utm_source=gitcode_repo_files) 给出三种基础形态（独立扇出、顺序链、菱形混合），并展示了如何用任务工具落依赖：

TaskCreate: { subject: "Build API endpoints" } → Task #1 TaskCreate: { subject: "Build frontend components" } → Task #2 TaskCreate: { subject: "Integration testing" } → Task #3 TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] } → #3 waits for #1 and #2