cross-project-coordinator

name	cross-project-coordinator
description	跨项目并行开发协调框架创建 Skill。当启动涉及2个或以上子项目并行开发时激活：收集项目清单，生成标准协调框架文档（项目地图/API契约/并行轨道/Day 1清单）。触发词：「多项目并行」「建协调框架」「几个项目同时做」「分工要明确」「并行开发」「各自独立启动」「RULE-37」。与元项目导航的区别：元项目导航是轻量指针文档，本Skill生成可操作的协调框架（含API契约和并行轨道）。

跨项目并行开发协调框架创建（cross-project-coordinator）

RULE-37 的执行层落地：把「必须建协调框架」的规则转化为「如何一步步建」的操作流程。

---

触发判断

触发条件（满足任一即触发）：

• 用户提到同时要推进 2 个或以上子项目
• 不同子项目存在 API 调用关系（A 调用 B 的接口）
• 多名开发者分别负责不同子项目

触发判断示例：

• ✅「我们要同时做 twin-engine 后端和 tashan-world 前端」→ 触发
• ✅「后端开发者和前端开发者今天各自开工」→ 触发
• ❌「我要做 A 功能，做完再做 B 功能」（顺序不并行）→ 不触发
• ❌「帮我更新某个 Skill」→ 不触发

---

激活后立即执行

Step 0  确认触发
        问用户（或从上下文推断）：
        「本次并行开发涉及哪些子项目？每个项目大致做什么？」
        收集：项目名称列表 + 每个项目的一句话职责描述

Step 1  检查元项目导航
        Read: _内部总控/元项目导航.md
        → 确认各子项目是否已在导航中（未登记的需同步更新）
        → 获取各子项目的产品定义.md 和技术架构.md 路径

Step 2  检查是否已有协调框架文档
        检查 _内部总控/ 目录下是否已有 [生态名]_跨项目协调框架.md
        
        已有 → 读取现有文档，判断是否需要追加更新（新增项目/新接口）
        未有 → 执行 Step 3-6 全量创建

Step 3  生成「项目地图」（第一章）
        对每个子项目输出：
        - 职责：做什么（一句话）+ 不做什么（边界声明）
        - 部署位置：服务器 + 端口
        - 格式：ASCII 表格或 mermaid 图

Step 4  生成「跨项目 API 契约」（第二章）
        对每一对存在调用关系的项目对（A→B）：
        
        接口已定义时：
          列出端点 + HTTP方法 + 路径 + 关键请求/响应字段 + 鉴权方式
        
        接口未定义时（❗关卡A发现的问题，修复：先输出占位符）：
          「⚠️ [端点名] — 接口待定义，建议由 [项目A] 技术架构师填写」
          留占位符行，不留空白
        
        必须包含错误码规范（见模板格式）

Step 5  生成「并行开发轨道」（第三章）
        并行判断规则：
        - 两个工作包之间没有共享的「输出 → 输入」依赖 → 可并行
        - 例：后端 API 定义完成后，前端才能开始联调 → 串行约束
        
        用时间轴格式输出：
        - 轨道A：[项目A的工作]（可立刻开始/依赖X完成后开始）
        - 轨道B：[项目B的工作]（同上）
        - 阻塞关系：明确列出「A的X完成前，B的Y无法开始」

Step 6  生成「各项目启动前提清单」（第四章）
        对每个子项目开发者的 Day 1 清单：
        ✅ 已就绪的文档（列路径）
        🔲 缺失的文档（标注谁负责/何时完成）
        ✅ 可以先 mock 开始的工作（说明 mock 约定）

Step 7  保存文档
        路径：_内部总控/[生态名称]_跨项目协调框架.md
        
        关系声明（写在文档头部）：
        「关系类型：implements → _内部总控/AGENT_RULES.md RULE-37」
        
        同步更新 元项目导航.md：
        - 在「跨项目并行协调文档」行补充本文档路径

Step 8  触发 F-022 挑战者反思（高依赖度文档必做）
        以「消费方开发者」和「接口破坏者」双视角检查：
        1. API 契约是否完整（每个接口都有错误码规范？）
        2. 并行轨道依赖关系是否漏写？
        3. 有没有"循环依赖"（A等B，B等A）？
        
        发现问题 → 立即修复再输出

---

文档模板（保存时使用）

# [生态名] · 跨项目并行开发协调框架

> 关系类型：implements → _内部总控/AGENT_RULES.md RULE-37
> 创建日期：YYYY-MM-DD
> 维护规则：任何跨项目 API 变更，必须先更新本文档，再通知消费方

## 一、项目地图
[项目地图内容]

## 二、跨项目 API 契约
[API 契约内容]

**错误码规范**：
| 状态码 | 含义 | 前端行为 |
| 400 | 请求格式错误 | 显示具体字段错误 |
| 401 | 未认证 | 跳转登录页 |
| 403 | 无权限 | 提示无权操作 |
| 404 | 资源不存在 | 显示友好提示 |
| 429 | Rate Limit | 禁用按钮N秒 |
| 5xx | 服务器错误 | 通用错误提示 |

**Mock 数据约定**：
- Mock 文件位置：[前端项目]/src/mocks/[被调用服务]/
- 格式：与 API 契约返回字段完全一致的 JSON fixture

## 三、并行开发轨道
[轨道内容]

## 四、各项目启动前提清单
[清单内容]

## 五、接口变更通知规则
任何一方变更跨项目接口时：
1. 先更新本文档
2. 在对方项目追踪台创建 P1 问题
3. 任务日志标注「跨项目接口变更」

## 六、变更记录
| 日期 | 变更 | 触发原因 |

---

与其他 Skill 的关系

关系	Skill/Rule
基于此规则触发	_内部总控/AGENT_RULES.md RULE-37
更新后通知	元项目导航.md 跨项目协调文档引用
接口变更时更新	deploy-arch-maintenance.mdc RULE-22

---

变更记录

v1.0 — 2026-03-21 — 初始创建

根因：RULE-37 填补了「必须建协调框架」的规范空白，但缺少「如何建」的操作步骤。 今日手动创建了认知协作生态_跨项目协调框架.md，没有可重复使用的步骤规范。

经验核心：

• 关卡A 发现：触发条件需要明确判断标准（并行 vs 顺序）
• 关卡A 发现：接口未定义时输出占位符而非空白
• Step 8 F-022 是强制步骤（高依赖度文档必做）

验证状态：🔵 待验证（下次多项目并行启动时验证）