跨团队统一规格包

多团队读同一份「真相」却各写各的规格

产品要「为什么」、开发要「怎么做」、设计要「谁与流程」——若各自维护 PRD、技术说明与验收清单，评审时口径不一致，返工往往发生在集成与验收阶段。Accord（@org-02qudk26/accord-zh）的定位是：在不写代码的前提下，产出一份可被多角色从不同切面阅读的统一规格包，并把它当作下游智能体（Builder、Radar、Voyager 等）可消费的可执行规格，而不是堆在仓库里没人更新的文档。

分阶段怎么写、写到哪里

技能按 L0 → L1 → L2 → L3 顺序构建，并强制「先 L0 再 L2」：

• L0：愿景一页纸——问题、目标用户、KPI、范围进/出、时间线。
• L1：用户故事、REQ-*、跨职能需求（CFR）与优先级；避免把 NFR 拖到故事之后才补。
• L2：按受众拆分细节（业务 / 开发 / 设计），不替架构师拍板，也不产出线框或模型。
• L3：AC-* 与 BDD（Given / When / Then），强调声明式业务语言、单场景单行为，并与需求保持双向可追溯（沿用 REQ-*、AC-{FEATURE}-{NNN} 等共享 ID，Full/Standard 可生成 .traceability.yaml）。

范围上按复杂度选 Lite / Standard / Full（例如未拆解需求到 10+ 条时往往应先交 Sherpa 拆解）。工作流上常见阶段包括 INTAKE → L0 → L1 → L2 → L3 与 BRIDGE / VERIFY / DELIVER；子命令如 vision、requirements、detail、ac 以及 story-map、stakeholder、raci 用于聚焦某一类产出。上游可接入 Field（研究）、Cast（画像）、Voice（反馈）；下游可路由到 Sherpa（拆解）、Builder（L2-Dev 就绪）、Radar（测试用例）、Voyager（E2E）、Canvas（可视化）、Scribe（正式 PRD/SRS）、Lore（可复用模式）。若工具链支持 GitHub Spec Kit，可将 L0–L3 映射到 Constitution → Specify → Plan → Tasks，减少二次翻译。

适用边界

• 交给别的技能：纯实施/架构/测试执行（Builder、Atlas、Radar）；不需要跨职能打包的独立正式文档（Scribe）；视觉与线框（Vision、Palette）；写代码（Builder / Forge）。
• Accord 不做：编写实现代码、做架构裁决、在 BDD 里写 DOM/SQL/API 端点、命令式逐步点击场景、跳过 L0 直接堆技术细节、未经 Three Amigos（产品 + 开发 + QA）就定稿 L3。
• 起草前应先对齐：受众是谁、选 Lite/Standard/Full 的理由、团队组成与是否涉及合规/安全等额外利益相关者——资料里列出的「先询问」场景应认真对待，否则包容易在范围或 L2-Dev 决策上卡住。