用途：把 design/ 目录作为系统架构的唯一事实来源，让代理（或开发者）在编码前先读设计、在边界内工作。人塑造骨架，代理构建肌肉；design/ 也是超出单个代理会话的机构记忆。
主要能力：
- 命令：/design-driven init 读取并执行 commands/init.md，做一次性项目配置（代理配置、空目录、可选钩子），不生成 DESIGN.md；/design-driven bootstrap 读取并执行 commands/bootstrap.md，从已有代码库生成初始 design/DESIGN.md，并幂等处理 init 未做的配置；/design-driven audit 读取并执行 commands/audit.md，对照当前代码核对 design/，发现漂移、分类并提出更新或追溯提案；无参数则进入正常开发循环。
- 目录结构：design/ 为永久骨架（DESIGN.md、可选的 DESIGN-<aspect>.md、decisions/ 中的 001-... 提案，含 adopted/rejected）；blueprints/ 为实现记录（进行中含 TODO，完成后清理并保留 Follow-ups）。
- 30/70 原则：design/ 捕获 30% 的关键骨架（模块边界、数据流、关键机制、取舍），代理自由决定其余 70%（API、函数签名、错误处理、数据结构、算法、文件组织、命名、模式）。判据：改动会改变系统形态的是 30%，只在同形态内改变行为的是 70%。
- 开发循环：读 DESIGN.md → 判断任务是否改变系统形态 → 是则写提案、人工审核通过后更新 DESIGN.md；然后 Plan（写 blueprint，含方法、范围、验证标准，约 10 个 TODO 内，含 Serves: C<n> 可追溯）→ Build（自由编码、勾选 TODO 并即时更新 State）→ Verify（可证伪检查，默认自动化测试，TDD 最强）→ Close out（核对文档漂移、Follow-ups、可复用模式，剥离 TODO/State，标记完成并随代码提交）。
- 提案流程：在 design/decisions/NNN-title.md 起草，编号取最大值加一、补零三位；先派对抗性冷评审（Agent 工具，提示见 references/cold-review-prompt.md，只读 DESIGN.md 与提案），再等人工审核；adopted 则更新 DESIGN.md 并一起提交，rejected 则记录原因。
适用场景：系统具有值得承诺的可识别形态（模块、机制、边界不会下周重写）的大多数持续工程工作。
限制与不适用：方向不明（无可证伪成功标准、无期限、无目标）应先用 /goal-driven set；范式全新（如 AI-native 系统、agent-first 接口）应先用 /reframe 重画骨架再固化进 DESIGN.md；形态在已知范式内仍不稳定时用 goal-driven；一次性工作（修 bug、脚本、一次性原型）不需要本框架。Design-driven 与 evidence-driven 可叠加：安装了后者时，每项验证勾选必须引用可证伪观察（如“[x] tests pass — 14/14 in store.test.ts”），证据驱动会加深可证伪性规则。测试揭示 DESIGN.md 未覆盖内容时，应修文档、提提案或加入 Constraints/Non-goals，而不是绕过测试。bug 修复、小改动或比规划更省时的任务可跳过 blueprint，但仍须遵守 DESIGN.md 边界。已完成的 blueprint 作为历史记录保留，过多时可移入 blueprints/archive/，不要删除。其他功能、收费、价格、平台与效果资料暂未提供。