严格规范驱动 kw12121212/strict-spec-driven

strict-spec-driven

文档： 快速入门 · 架构文档 · 架构文档快速入门 · UI 设计系统快速入门 · 路线图快速入门 · 路线图指南 · AGENTS

strict-spec-driven 是一个 YAML 优先的规范驱动开发工作流。它提供规范驱动生命周期（提议 → 执行 → 验证 → Skill 驱动代码审查 → 归档）和 Agent Skills 集成，将工作流制品——规范、变更、路线图、任务、问题——转换为严格 YAML 模式，由确定性脚本强制执行。

SKILL.md 文件保留为 Markdown，因为这是 Agent Skills 打包格式的要求。变化的是这些 Skills 生成和消费的制品格式。

目录结构

| 目录 | 用途 |
| .strict-spec-driven/ | 活跃的严格工作流状态 |
| .strict-spec-driven/changes/ | 活跃的变更目录 |
| .strict-spec-driven/changes/archive/ | 已归档的变更 |
| .strict-spec-driven/roadmap/ | 严格 YAML 路线图制品 |
| .strict-spec-driven/roadmap/planned-changes/ | 首选的独立路线图工作项文件 |
| .strict-spec-driven/specs/ | 严格 YAML 主规范文件 |
| templates/strict-spec-driven/schemas/ | 捆绑的严格 YAML 模式文件 |
| examples/strict-spec-driven/ | 仓库参考用的最小有效 YAML 示例 |
| templates/strict-spec-driven/scaffold/ | init 和 propose 使用的脚手架模板 |
| skills/ | 严格 Skill 包（strict-spec- 和 strict-roadmap-） |
| src/ | TypeScript CLI 源码 |
| dist/ | 编译输出（由构建生成） |

本仓库只保留一个活跃工作流目录 .strict-spec-driven/。.spec-driven/ 仅作为仍使用旧版 Markdown 工作流的其他项目的迁移输入相关，详见迁移边界。本仓库已完成该迁移，不再保留根级 .spec-driven/ 目录。

升级说明

九个单命令 roadmap 技能已合并为一个带参数的技能，随后 /strict-roadmap-reorder 又被拆回独立技能，因为它的调用频率足以支撑一个专属入口。
/strict-roadmap-pause、/strict-roadmap-resume、/strict-roadmap-defer、 /strict-roadmap-refine、/strict-roadmap-move、/strict-roadmap-reopen、 /strict-roadmap-archive 和 /strict-roadmap-sync 已不再是技能包，也没有任何别名包做转发，因此调用这些斜杠命令现在会直接失败，而不是悄悄执行原来的行为。

/strict-spec-sop、/strict-spec-harness-init、/strict-spec-harness-session、 /strict-spec-migrate 和 /strict-spec-propose-from-roadmap 这五个技能以同样的方式被移除。
sop- 和 migrate 命令没有变化——都保留原有名称、参数和行为——因此这些能力仍可通过 strict-spec-cli 使用；而路线图支持的提案，在需要跨整个路线图挑选下一件工作时由 /strict-roadmap-recommend 脚手架化，在请求指名某一个里程碑时则由 /strict-spec-propose 脚手架化。

除 reorder 重新拥有独立技能外，其余已退役的 roadmap 名称都变成了同一个技能的一个显式操作：

| 已退役的斜杠命令 | 替代写法 |
| /strict-roadmap-pause | /strict-roadmap-transition pause |
| /strict-roadmap-resume | /strict-roadmap-transition resume |
| /strict-roadmap-defer | /strict-roadmap-transition defer |
| /strict-roadmap-refine | /strict-roadmap-transition refine |
| /strict-roadmap-reorder | /strict-roadmap-reorder（重新成为独立技能） |
| /strict-roadmap-move | /strict-roadmap-transition move |
| /strict-roadmap-reopen | /strict-roadmap-transition reopen |
| /strict-roadmap-archive | /strict-roadmap-transition archive |
| /strict-roadmap-sync | /strict-roadmap-transition sync |

底层 CLI 命令没有变化：roadmap-pause、roadmap-sync 等仍然保持原有名称和参数，改变的只是技能打包方式。

harness 能力已被整体移除，因为声明、启动、停止项目服务并查看其日志不属于规格驱动工作流工具的职责。
harness-edit、harness-infer、harness-doctor、harness-plan、harness-start、 harness-stop、harness-status、harness-logs、harness-scripts 和 harness-session 命令不再注册，调用时按未知命令失败；init 不再生成 harness.yaml；MCP 服务器也不再提供 harness 工具、strict://harness/declaration 资源和 strict_harness_investigation 提示。
没有任何命令会读取旧版本遗留的文件，因此 .strict-spec-driven/harness.yaml、 .strict-spec-driven/harness-sessions/ 和生成的 scripts/harness- 包装脚本可以手动删除。

如果你在此变更之前安装过这些技能，请重新安装，让已退役的技能包从技能目录中移除，并装上合并后的技能：

bun run install-strict-skills

严格命令接口

CLI：strict-spec-driven

在 bun run build 之后（或通过已安装的 node dist/strict-spec-cli.js）可用的子命令：

| 子命令 | 用途 |
| init | 在项目中创建 .strict-spec-driven/ 脚手架 |
| propose <name> | 创建新的严格变更脚手架 |
| apply <name> | 完成变更中的下一个待处理任务 |
| verify <name> | 验证变更的制品和任务完成情况 |
| archive <name> | 合并增量规范并将变更移入归档 |
| ship <name> | 读取已归档变更摘要以进行 git 提交交接 |
| migrate | 将 .spec-driven/ 引导状态转换为 .strict-spec-driven/ |
| list | 报告活跃和已归档的变更 |
| modify [<name>] | 列出变更的可编辑制品路径 |
| cancel <name> | 删除活跃变更（已归档变更受保护） |
| maintenance | 运行已配置的仓库维护检查 |
| roadmap-status | 验证并报告严格路线图状态 |
| roadmap-overview | 输出面向人的路线图总览表 |
| roadmap-sync [--fix-names] | 协调并重新生成严格路线图索引；--fix-names 将命名不规范的 planned-change 文件重命名为规范文件名 |
| roadmap-generate milestone | 通过结构化命名参数创建或更新严格路线图里程碑 |
| roadmap-generate planned-change | 在 CLI 计算的规范文件名处创建或更新独立 planned-change 工件 |
| validate-skills | 验证严格 Skill 打包元数据和命令脚本符号链接 |
| schema-list | 列出捆绑的严格 schema 资源键 |
| schema-show <name> | 输出一个捆绑的严格 schema 资源 |
| sample-list | 列出捆绑的严格 YAML sample 资源键 |
| sample-show <name> | 输出一个捆绑的严格 YAML sample 资源 |
| template-list | 列出捆绑的模板和 schema 资源键 |
| template-show <key> | 输出一个捆绑的模板或 schema 资源 |

安装

类 Unix 主机运行 install.sh，Windows 运行 install.ps1。安装器会安装 strict skills 包和 strict-spec-cli 命令，并自动引导自身依赖：缺失时自动安装 bun，node_modules 缺失时用 bun install 安装项目依赖，并通过 bunx 运行全局 skills CLI。

在类 Unix 主机上，当 npm/Node 可用且 npm 全局前缀可写时，install.sh 通过 npm install -g . 安装 strict-spec-cli——命令进入 npm 全局 bin 目录（已在 PATH 上），装完即可直接使用，无需改 PATH，也不产生大型原生可执行文件。当 npm 不可用，或 npm install -g . 因权限失败（系统管理的全局前缀需要 sudo）时，回落到构建原生 strict-spec-cli 可执行文件并放入用户级 bin 目录（默认 ~/.local/bin，或 $STRICT_SPEC_BIN_DIR / $XDG_BIN_HOME）。npm 安装成功时还会删除先前回落安装遗留的原生可执行文件，确保 PATH 上只解析到一个 strict-spec-cli。

在 Windows 上，当 npm/Node 可用时，install.ps1 通过 npm install -g . 安装 strict-spec-cli——命令进入 npm 全局 bin 目录（已在 PATH 上），因此装完即可在任意终端直接使用，无需改 PATH。当 npm 不可用时，回落到构建原生 strict-spec-cli 可执行文件并放入用户级 bin 目录；此情况下默认把该目录加入当前用户的 PATH，在安装器会话之外用 strict-spec-cli 命令名前请重新打开一个终端。使用 -NoPathUpdate 可跳过 PATH 变更，使用 -KeepPathOnUninstall 可在卸载时保留 PATH 条目。

两个安装器还会删除本仓库已退役的技能。安装过程只做添加，因此在旧检出之上升级曾会把所有已删除的技能永久留在机器上，继续提供一个已经无法解析的斜杠命令。退役名单记录在 retired-skills.json 中——它无法从名字前缀推导，因为部分退役包早于当前的命名家族——每次安装都会把该名单交给 skills CLI，由它从其管理的所有 agent 目录中移除。卸载同样会显式列出打包的和已退役的技能，原因相同：不给名字时 skills CLI 会打开交互式选择菜单，而非交互式会话对它不会作出任何选择。

Skills：strict-spec-、strict-roadmap- 和 strict-scene-

Skills 是通过 install.sh 安装的 Agent Skills 包。在 Claude Code 中使用斜杠命令名称调用它们：

严格规范工作流 Skills（strict-spec-）：

| 斜杠命令 | 用途 |
| /strict-spec-init | 在项目中初始化严格工作流 |
| /strict-spec-propose | 提议新变更，可独立提出，也可限定到指名的路线图里程碑 |
| /strict-spec-apply | 实现变更中的任务 |
| /strict-spec-verify | 验证变更是否完成 |
| /strict-spec-review | 基于证据对变更进行代码质量审查 |
| /strict-spec-archive | 归档已完成的变更 |
| /strict-spec-auto | 端到端自动化变更生命周期 |
| /strict-spec-ship | 通过 git 提交发布已归档的变更 |
| /strict-spec-brainstorm | 在提议前对变更想法进行头脑风暴 |
| /strict-spec-modify | 修改现有变更的制品 |
| /strict-spec-spec-edit | 直接编辑主规范文件 |
| /strict-spec-sync-specs | 与代码漂移同步规范 |
| /strict-spec-design | 编写或刷新设计系统制品并渲染 DESIGN.md |
| /strict-spec-design-sync | 将设计系统制品与 UI 代码漂移对账同步 |
| /strict-spec-maintenance | 运行仓库维护工作流 |

严格路线图 Skills（strict-roadmap-）：

| 斜杠命令 | 用途 |
| /strict-roadmap-recommend | 从路线图推荐下一个计划变更 |
| /strict-roadmap-review | 审查未完成的路线图里程碑并直接修复 |
| /strict-roadmap-plan | 创建或重构路线图 |
| /strict-roadmap-transition | 执行一次路线图状态迁移：pause、resume、defer、refine、move、reopen、archive 或 sync |
| /strict-roadmap-reorder | 修改某个活动里程碑在路线图中的顺序位置 |

严格场景 Skills（strict-scene-）：

| 斜杠命令 | 用途 |
| /strict-scene-edit | 编写或修正一个场景：参与者、前置条件、主流程、异常流程，以及每个步骤的覆盖情况 |

路线图文档描述了首选的拆分文件协作模型：保持里程碑文件和 INDEX.yaml 低变动率，将日常路线图工作存储在 .strict-spec-driven/roadmap/planned-changes/ 中，在合并或归档交接后重新运行 roadmap-sync，并将外部跟踪器引用视为可选上下文而非必需的真实来源。

独立 planned-change 文件使用由 CLI 负责的规范文件名：<milestone-id>-<planned-change-id>.yaml（当 planned-change id 已以 milestone id 开头时不重复前缀）。文件名顺序具有语义意义——roadmap-recommend 按文件名顺序选择第一个符合条件的 planned change——因此活动 planned-change 文件的非规范文件名是 roadmap-status 与 roadmap-sync 的阻塞性验证诊断（已归档的 planned-change 文件豁免）。请通过 roadmap-generate planned-change 创建和更新 planned-change 工件（文件名由 CLI 自行计算），并用 roadmap-sync --fix-names 修复历史遗留的错误命名；切勿手工挑选 planned-change 文件名。

需求拷问

每一条从人类请求开始的路径——/strict-spec-brainstorm、/strict-spec-propose、 /strict-spec-bugfix、/strict-spec-auto——都会先拷问需求，再由变更接收问题门去拷问 方案。它排在前面，是因为一个范围划得很干净、却建立在误读需求之上的变更，依然是错的变更。

需求类答案永远不从仓库证据中获取。代码能说明系统做了什么，说明不了一个人想要什么。
只有请求者自己的话（包括他在当前请求里已经说过的内容），或者回放的路线图 planned-change 与里程碑详情，才能回答这些问题。

第一次运行 generate <change-name> questions ... 时会把五条固定问题作为 open 条目写入 questions.yaml，因此刚开始编写的变更会被阻断：

| 问题 id | 问什么 | 怎样才算答完整 |
| requirement-problem | 今天具体出了什么问题，谁在承受？ | 谁受影响、他现在改用什么办法、多久发生一次——且不点名任何功能 |
| requirement-outcome | 什么样的可观测差异证明它被解决了？ | 一个人将会看到什么、或不必再做什么，且能从系统外部核对 |
| requirement-trigger | 为什么是现在，什么逼出了它？ | 具体的事件、期限、事故或代价；如果确实没有，就如实说明 |
| requirement-non-goals | 什么明确不能改？ | 必须原样保留的邻近行为，以及谁依赖它 |
| requirement-interpretation | 打算取哪一种读法？ | 把想要的那一种说清楚到足以排除其他读法 |

每条预置条目都自带说明——为什么问、怎样才算答完整、一个具体范例、以及这个答案会改变什么，因此回答它不需要事先了解这套工作流。

答案带归属记录。--answered-by human 和 --answered-by roadmap 满足门禁； --answered-by assumption 表示答案由 agent 在没有人类确认的情况下给出，会阻断 ready 直到有人明确决定：

strict-spec-cli generate <change-name> questions --resolve requirement-problem \
--answer "..." --answered-by human

只要任一固定问题缺失、仍处于 open、由 assumption 回答，或者已解决却完全没有归属标注， ready 就会输出 requirement_intake 诊断并非零退出。没有任何 questions 生成器标志可以删除 requirement 类条目。

强制力分三层，值得说清楚哪层管什么：

| 层 | 机制 | 保证什么 |
| CLI | 第一次编写 questions、ready 诊断 | 问题存在、已被回答、带有归属 |
| Skills | 四个 skill 提示词中的提问技术，由 validate-skills 强制 | 一次问一条、每条带具体猜测、提问前先解释、推回时说明理由 |
| 都不管 | — | agent 是否真的认真拷问过。这是判断，无法检查；记录 answered_by: assumption 让糊弄留下痕迹，而不是阻止它 |

场景优先的需求路由

需求拷问确立的是需要，场景优先路由确立的是这个需要发生在什么情境中，它运行在上下两道门禁之间——因为缺少它写出的需求集合会有空洞，而这些空洞在需求本身里是看不见的。

/strict-spec-propose、/strict-spec-brainstorm 和 /strict-spec-auto 会在每一次提议中询问四个问题，无论变更最终是什么：谁在行动、每个参与者做什么；主流程开始前必须已经成立的是什么；一切顺利时逐步发生什么；可能出什么问题、每条异常流程由什么触发、之后会发生什么。被直接索要需求的作者会跳过这四问而毫无察觉，因为需求里没有任何东西会记录那个从未被问出的问题。

场景是提问强制、工件可选的。当变更触及用户可观察行为时，场景要被写下来——作为变更下的 delta scene，写在 delta spec 之前，这样每条需求都是从流程步骤推导出来的，而不是凭记忆回想的。当变更是纯技术性的——重构、构建或测试工具链、仓库维护、架构约束、脚本或技能指引——没有参与者流程可描述，技能会记录「为何不适用场景」，而不是编造一个。

每个流程步骤都要声明覆盖它的需求，或者一条明确的「刻意不被覆盖」的理由；一个步骤可以跨多个规范领域指名覆盖需求。一旦变更携带了 delta scene，ready 和 verify 会在两者皆无的步骤上以非零退出，诊断信息会给出记录覆盖的可运行命令：

strict-spec-cli scene-status --scene <scene-id>
strict-spec-cli generate <change-name> delta-scene --target-scene <scene-id> \
--operation MODIFIED --step <step-id> --action "..." \
--covered-by <spec-id>:<requirement-id>

检查由场景的存在触发，绝不由规范的存在触发。没有记录任何场景的项目不会看到新的诊断，也不会多出必填字段，因此采纳场景是增量的，升级 CLI 不是破坏性变更。场景存放在 .strict-spec-driven/scenes//，在变更之外用 /strict-scene-edit 编辑；当变更携带 delta scene 时，archive 会把它们合并进该存储。

变更接收问题门

面向提案的 Skills 会在上述需求拷问之后、实现之前运行一个简短的变更接收问题门。它们会先用可用证据回答检查清单：当前请求、路线图 planned-change 详情、严格规范、技术标准、已有变更制品、仓库搜索结果以及确定性 CLI 输出。如果这些证据已经回答了清单项，工作流不会再向人重复提问。

检查清单覆盖：要改什么、为什么值得做、包含什么、不包含什么、哪些既有行为必须保持不变、工作可能位于哪里、如何证明它有效、相关风险或依赖是什么，以及适用哪些技术规则。

如果发现后仍缺少必需答案，Skill 会在 questions.yaml.open 中记录条目，包含具体上下文、影响和推荐答案或选项。当 questions.yaml.open 还有必需条目时，实现交接会刻意停止；必须先把答案解析到 questions.yaml.resolved，/strict-spec-auto 或 /strict-spec-apply 才能继续。

面向人的问题文本、上下文、建议、选项和摘要会使用 .strict-spec-driven/config.yaml 中的 preferred_human_language，除非当前用户消息明确要求另一种语言。问题 id、制品字段、schema 名称、命令名和文件路径等稳定技术值保持为不随语言变化的标识符。

MCP Server：strict-spec-driven-mcp

构建的包还包含一个用于兼容 MCP 客户端的本地 MCP 服务器。它是仅 stdio 的集成，始终需要显式的项目根目录：

{
"mcpServers": {
"strict-spec-driven": {
"command": "node",
"args": [
"/path/to/strict-spec-driven/dist/scripts/strict-spec-driven-mcp.js",
"--project",
"/path/to/your/project"
]
}
}
}

MCP 服务器将 CLI 和 Agent Skills 保留为权威的工作流实现。它将严格工作流制品公开为资源，将工具委托给配置项目根目录下的严格 CLI，并提供指导现有严格 Skills 的提示。

代表性资源：
- strict://workflow/state
- strict://changes/{change}/proposal
- strict://specs/{specId}
- strict://roadmap/planned-changes/{plannedChangeId}

代表性只读请求：要求 MCP 客户端检查严格工作流状态。预期的工具调用是 check_workflow_state，它委托给 strict-spec-cli check-workflow-state，不会修改项目文件。

代表性提示请求：使用 { "change": "my-change" } 请求 strict_review_change，以获取将验证、直接代码审查和完整回归证据保留在工作流中的审查指导。

变更工具需要宿主可见的确认边界。propose_change、generate_change_artifact、mark_next_task_complete、roadmap_sync 和 archive_change 等工具会写入严格工作流状态。archive_change 属于发布级别，因为它会合并规范并协调路线图状态。

CLI 独占的 YAML 编写

仓库拥有的所有严格制品，其 YAML 结构与文件系统写入均由 CLI 代码负责。受支持的 AI 工作流通过各制品的所属严格 CLI 命令和命名语义参数表达每一次创建、更新、命名条目删除和整个制品的删除；绝不提供原始 YAML 载荷、heredoc、临时载荷文件、任意输出路径或直接文件编辑。只读的 YAML 查看始终允许；人类保留完全的手工自主权——该策略约束的是 AI 变更工作流，不是人。

协议的权威表述由 CLI 自身输出：

strict-spec-cli yaml-authoring-protocol
strict-spec-cli yaml-authoring-protocol <artifact-kind>

其七个有序步骤：

1. 读取所属命令的机器可读帮助 —— <owning-command> --help --json。帮助即契约；凭记忆的标志不是。
2. 解析目标制品的 schema —— schema-list，然后 schema-show <schema-key>。
3. 查看注册的最小示例 —— sample-list，然后 sample-show <example-key>。示例是只读参考，绝不复制到目标位置当作起始文件。
4. 将确认的事实转换为文档化的命名参数 —— 每个值都必须能追溯到请求、schema 或仓库证据。
5. 用这些参数执行所属命令。
6. 检查结构化结果与变更路径 —— 报告不完整的结果是一次成功但仍有后续工作的写入，不是需要重试的失败。
7. 运行该制品的验证命令 —— 捕获单次写入自身结果无法报告的跨文件影响。

协议以一条边界收尾：当所需的命令、参数或制品类型不可用时，停止并报告缺失的能力——无法完成的操作、目标制品类型与对象、缺失的命令或参数、已查阅过的发现命令。没有任何回退路径；命令不可用是停止的理由，不是即兴变通的理由。

用 yaml-surface-list 和 yaml-surface-show <kind> 可按制品族发现完整的变更接口：每个族支持的操作、所属命令、被拒绝的操作和跨文件影响。制品写入是惰性且原子的：第一次成功的 generate 调用同时创建变更容器和制品，绝不写占位文件，被拒绝的写入不会触碰任何既有状态。

模式和示例资源

捆绑的严格 YAML 模式文件位于 templates/strict-spec-driven/schemas/。最小有效示例作为仓库参考资源位于 examples/strict-spec-driven/。这些与 .strict-spec-driven/ 工作流状态分离。

templates/strict-spec-driven/schemas/schema-registry.yaml 中的模式注册表索引了所有支持的严格制品族。

CLI 也会内置捆绑的 schema 和脚手架资源，因此已安装的 Skills 不需要每个目录都带一个 templates 符号链接。Agent 可以通过以下命令查看内置契约：

strict-spec-cli schema-list
strict-spec-cli schema-show change-proposal
strict-spec-cli sample-show change-proposal
strict-spec-cli template-show scaffold/config.yaml

共享模式缓存

每个 strict-spec-driven CLI 命令（--help/-h 除外）和 MCP 服务器在启动时会将捆绑的 schema 文件和严格 YAML sample 文件导出到共享的磁盘缓存 ~/.strict-spec-schemas/，使 Agent 无需每个项目都带 templates 或 examples 目录即可将制品的 schema_file 路径和 schema 的 example_ref 路径解析到一个固定的根目录。缓存包含 templates/strict-spec-driven/schemas/ 下的 schema 文件、examples/strict-spec-driven/ 下的 sample 文件，以及记录导出版本的 manifest.yaml；当捆绑 schema 或 sample 变化，或缓存文件缺失、被修改时会自动刷新，随时可以安全删除——下次运行会重建。设置 STRICT_SPEC_SCHEMA_CACHE_DIR 环境变量可重定向缓存根目录。若缓存不可写，命令会继续使用捆绑资源并打印包含解析后缓存路径的警告。制品声明的 schema_file 路径在该缓存根目录下解析，schema 的 example_ref 路径在缓存的 examples 树下解析；已安装的 Skills 绝不假设存在源码仓库的 templates 或 examples 目录。

标准作业程序（SOP）

经 schema 验证的标准作业程序位于 .strict-spec-driven/sops/ 下，是由 CLI 负责的 YAML。通过命名参数编写和维护：新建程序用 sop-create（--title、--category、--purpose、--trigger、步骤、角色、升级、异常），字段与命名条目的更新和删除用 sop-edit，用 sop-validate 按 SOP schema 验证单个或全部程序。只读查看用 sop-list、sop-show、sop-category-list、sop-category-show；用 schema-show sop 和 schema-show sop-category 查看制品契约。

strict-spec-cli sop-create --title "发布回滚" --category release \
--purpose "..." --trigger "..." --scope-in "..." --success "..." \
--prerequisite "..." --exception-condition "..." --exception-handling "..." \
--step-id assess --step-actor operator --step-action "..." --step-expected "..."
strict-spec-cli sop-edit <sop-id> --step-id verify --step-actor operator \
--step-action "..." --step-expected "..."
strict-spec-cli sop-validate

每个类别都强制要求自己的必需章节——编写前用 sop-category-show <id> 查看。

迁移边界

strict-spec-cli migrate 子命令将支持的旧版 .spec-driven/ Markdown 制品转换为 .strict-spec-driven/ YAML 制品。源 .spec-driven/ 目录不会被修改。不支持或模糊的旧版格式会在迁移报告中作为手动跟进事项报告。

迁移后，.strict-spec-driven/ 是活跃的工作流状态。.spec-driven/ 保留为引导或旧版历史，不作为有效的严格工作流目标处理。

dsh 文档查看器插件

plugins/dsh-strict-spec/ 中的 dsh-plugin-strict-spec 是一个只读的 DeepSeek Harness 插件，可在 Web 客户端和 Desktop 应用中浏览 workspace 的 .strict-spec-driven/ 文档。关于从本仓库 checkout 构建、通过 link: 或本地打包的 tarball 安装以及支持的 dsh 版本，请参阅其 README。该插件不会发布到 npm。

自托管状态

本仓库自托管于严格工作流之上。.strict-spec-driven/ 是唯一活跃的工作流状态，包含活跃的严格规范、路线图和变更历史。从旧版 .spec-driven/ 工作流的迁移已完成，不再保留根级 .spec-driven/ 目录。

开发

前置条件： Bun 是运行时和包管理器（安装器会在缺失时自动安装）。Node.js 仅用于 node 相关命令（bun run validate-skills、MCP 服务器），安装过程不需要。

构建：
bun run build
通过 TypeScript 将 src/ 编译到 dist/，并将 templates/ 和 scripts/ 复制到 dist/。

测试：
bun test/run.ts
针对已编译的 dist/ 输出运行测试套件。

验证 Skills：
bun run validate-skills
验证所有严格 Skill 包的元数据、命令引用和必需的命令脚本访问。

约定：
- 使用结构化 YAML 解析器——核心制品数据绝不使用临时字符串处理。
- 规范变更应在实现之前反映在 .strict-spec-driven/specs/ 中。
- 任何源码变更后运行 bun run build && bun test/run.ts。
- 修改前先阅读现有代码；只实现当前任务所需的内容。