Accord 是一个用于编写统一规格包的技能，目标是让业务（Biz）、开发（Dev）和设计（Design）团队共享同一份规格文档，并从各自角度阅读。它明确不编写代码。
用途 当任务需要一份多团队可共享的规格产物、从愿景到验收标准的分阶段细化、可追溯需求、BDD 场景或跨职能评审包时使用 Accord。它也可将研究、人物画像或干系人反馈转化为可交付的规格，并为实现、拆解、测试、图表或正式文档提供结构化下游输入。Accord 被描述为 Nexus/AUTORUN 流程中规格驱动开发（SDD）的入口点，可产出供下游 AI 智能体（Builder/Radar/Voyager）驱动的可执行规格。
主要能力
- 分阶段细化：按 L0 → L1 → L2 → L3 顺序构建规格包。L0 为愿景（一页、两分钟可读），L1 为需求（用户故事、REQ-*、非功能需求、优先级），L2 为面向不同受众的细节（Biz=为什么、Dev=怎么做、Design=谁/流程），L3 为 Given/When/Then 形式的验收标准、边界情况与追溯矩阵。
- 范围模式：Full（12+ 需求或高复杂度，2-4 小时）、Standard（4-11 需求或中等复杂度，1-2 小时）、Lite（1-3 需求、缺陷修复或窄范围双团队工作，≤30 分钟）。
- 工作流：ALIGN → STRUCTURE → ELABORATE → BRIDGE → VERIFY → DELIVER。
- 子命令/配方：vision（默认）、requirements、detail、ac、story-map、stakeholder、raci。
- 追溯性：使用 _common/TRACEABILITY.md 中的规范 ID 方案（REQ-* / CFR-* / AC-{FEATURE}-{NNN} / SC-*），Full/Standard 包输出 .traceability.yaml 台账。
- BDD 验收标准：L3 包含 BDD 场景，要求使用业务领域语言、声明式风格、单一 When 子句，并需产品+开发+QA 三方（Three Amigos）评审。
- 与 GitHub Spec-Kit 阶段契约映射：L0 Vision → Constitution；L1 Requirements → Specify；L2 Team Detail → Plan；L3 Acceptance Criteria → Tasks。
- 交付后通过 UNIFY 记录校准数据（RECORD → EVALUATE → CALIBRATE → PROPAGATE）。
使用方式 通过子命令分发：解析用户输入的第一个 token，若匹配配方子命令则激活该配方并加载对应“Read First”文件；否则回退到默认配方 vision。输出语言遵循 CLI 全局配置（settings.json 的 language 字段、CLAUDE.md、AGENTS.md 或 GEMINI.md），但 ID、YAML、BDD 关键词与技术术语保持英文。
适用场景 SaaS、电商、仪表盘（高亲和度），API、库（中等亲和度）。适合需要跨团队共享规格、可追溯需求、BDD 场景、跨职能评审包，或为下游实现/拆解/测试/图表/正式文档提供结构化输入的任务。
限制 不编写实现代码；不创建视觉产物或原型；不代替架构专家做架构决策；不跳过 L0 直接进入技术或设计细节；不隐藏范围外项或让验收标准缺失。BDD 场景不得包含技术实现细节（DOM 选择器、SQL、API 端点），不得使用命令式（逐步交互）风格，不得包含多个 When 子句，不得混淆 Given 与 When。单个用户故事的验收标准不应超过 7 条（3-5 条为佳）。L1 中每个 NFR 必须在 L3 有至少一个可测试 AC。追溯性最低完整度：Full ≥95%、Standard ≥85%、Lite ≥70%。LLM 生成的需求不得未经干系人验证即作为最终版本。
其他说明 资料中提及 L4（v4 扩展，Phase 1 可选、Phase 2 强制）包含可逆性证明、学习证明与取消资格模式，但原文在此处截断，具体字段内容暂未提供。