需要创建、更新或校验架构脊柱以固定独立构建单元的一致性不变量…

当用户要创建技术架构、架构脊柱或方案设计，或需要从规格、原始想法、现有代码库中提炼、更新、校验架构一致性契约时使用。

适用场景

解决思路

1. 产出“架构脊柱”：只固定让独立构建单元不漂移的**不变量**——设计范式、边界与依赖规则、状态如何变更、共享数据归谁；把未来构建者无法从合规代码中读出的持久性决策写下来。
2. 把技术栈、目录树、完整数据形状等结构性内容视为 **seed**：冷启动时成立，代码出现后归代码所有；用命名范式打头，保持 seed 最小。
3. 用唯一测试决定一条决策是否进脊柱：如果下一层的两个单元独立构建，是否可能选择不兼容？仅当答案为是、且该决策非显而易见、且是真实权衡时，才在这里固定；否则放入 `Deferred` 并继续。
4. 默认输出面向构建的 **build substrate**：简短、收敛，避免小智能体或人类在小型意图上漂移。
5. 当目标是对齐人时，优先产出 **discussion** 文档，把开放问题放在前面。
6. 按眼前对象匹配脊柱规模：小东西写少量决策，平台写全面；覆盖整个系统或某功能触及的切片。
7. 只记录决策，不记录理由；理由放在 memlog。
8. 用图承载形状，不用散文描述。
9. 绑定任何命名技术前，上网核验其当前版本与适配度。
10. 默认走 Coaching path：把引导作为价值，抵抗直接产出架构的冲动，坚持这条线。
11. 在 Activation 阶段、起草前，用用户语言提供选择：**Coaching path**（一起工作——开放式问题，我拉出决策并在单薄处 push back）或 **Fast path**（我快速起草完整脊柱，用 `[ASSUMPTION]` 标记，你在评审时纠正）。
12. 除非用户明显想要速度，否则进行 coaching；不要静默起草。
13. 对承重决策——范式、技术栈或 starter、主要边界——要**展示而非静默做出**：列出你权衡过的现实替代方案与倾向原因，然后让用户选择。
14. 承重决策的理由留在对话和 memlog，绝不写进简短的脊柱。
15. 引导而不是测验：开放式“你如何考虑 X？”优于多选题；只对真正二选一的分叉保留清晰 either/or。
16. 在 Fast path 上，推断并打标签就是工作本身。
17. 当技术栈开放时（greenfield，或可能落在 paved path 上的小型/初学者项目），推荐知名且当前主流的 starter（先上网核验当前选择）：好的 starter 免费预先决定一整块连贯架构，对经验较少的用户优于手写。
18. 对 brownfield，先调查再决定：读取足够真实代码（以及 `{workflow.persistent_facts}`），确认代码已有约定，而不是发明新约定；不要复述扫描已展示的内容。
19. 从输入本身判断任务类型，不要盘问用户。`SPEC.md` 及其 memlog 组成 spec package，是最丰富起点，也是脊柱的归宿，因此把脊柱折叠回其中。
20. 也支持从原始想法、需要蒸馏的冗长架构文档、现有代码库（从代码推导脊柱，确认代码已展示的约定而不重复记录）、新功能触及的切片、或现有脊柱（扩展或压力测试）开始。
21. 优先读 `.memlog.md`，而不是重读其来源。
22. 蒸馏所给内容；真实缺口标为开放问题，不要发明答案。
23. 脊柱的 **altitude** 镜像它所增补的内容，并保持下一层连贯：initiative→features，feature→epics，epic→stories。
24. 静默继承已定内容——无论来自输入（spec、prd）还是常设 `{workflow.persistent_facts}`；不要重新决策或重新询问。
25. 如果输入太薄无法构建，先建议 `bmad-spec`；否则通过同一个 `memlog.py` 把缺失答案捕获到共享 spec workspace，以便 `bmad-spec` 后续派生 `SPEC.md` 时不会漂移。
26. 继承父脊柱时（例如指向已有 feature/initiative spine 的 spec 中某个 epic）：先加载父 `ARCHITECTURE-SPINE.md`，把其 `AD`s、约定和范式视为**绑定、只读**约束。
27. 将每条继承约束记录为 `constraint` 条目，列在脊柱的 *Inherited Invariants* 下（父 `AD` ID 永不重编号），不要重新推导。
28. 继承父脊柱时，你的任务只处理父级**留下开放**的内容：其 `Deferred` 项，以及该 epic 的故事可能遇到的偏差。
29. 新增 `AD` 若与继承项矛盾或削弱继承项，是要**暴露的冲突**，不是本地覆盖。
30. epic 脊柱固定该 epic 故事必须共享的不变量；**不**展开逐故事细节。
31. 把 `memlog`（`.memlog.md`）作为本次运行的 working memory：每个决策、约束、版本、假设和开放问题都作为一行 append-only 记录；对决策，记录它绑定什么、防止什么偏差。
32. memlog 不携带生命周期状态；终态时刻记录为 `event` 条目，而不是 frontmatter 标志。
33. 脊柱文件本身在最后从 memlog 蒸馏，而不是边做边写。
34. 每个存活决策变成 `AD-n`（稳定 ID，含 `Binds`/`Prevents`/`Rule`；当用户或既有现实已定则标 `[ADOPTED]`）；只存在于图里的决策也要记录。
35. 通过重新加载其 memlog 恢复先前运行。
36. 写入走共享脚本；除恢复外不要回读文件：
37. 初始化：`uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field scope="…" --field purpose="…" --field altitude="…"`
38. 追加：`uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type <decision|constraint|version|assumption|question|direction|event> --text "…"`
39. 解析裸路径和 `{skill-root}` 时，从本技能安装目录开始。
40. `{project-root}` 解析为项目工作目录；`{skill-name}` 解析为技能目录 basename。
41. `{workflow.<name>}` 解析为合并后的 `customize.toml` 字段；`{doc_workspace}` 解析为绑定的 run folder。
42. 只用正斜杠。配置变量已解析值中已含 `{project-root}`——绝不重复加前缀。
43. 若为转发激活：调用方带明确意图和预解析 customization 字段时，原样遵守——跳过自己的意图推断，对指定字段使用提供值，只从自己的 `customize.toml` 解析剩余字段。
44. 解析 customization：`uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow`。
45. 若脚本未找到：说明 BMad 未设置；提议运行 `bmad` 技能的 setup，必要时先安装 `bmad`（`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`），然后重跑该命令。
46. 若其他失败：读取 `{skill-root}/customize.toml` 并使用默认值。
47. 运行 `{workflow.activation_steps_prepend}`，再运行 `{workflow.activation_steps_append}`。把 `{workflow.persistent_facts}` 作为常设上下文——除非用户选择加入，否则为空——并按需查阅 `{workflow.external_sources}`。
48. 解析 config：`uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}`（合并 `_bmad/config.toml` 与 `_bmad/custom/` 覆盖）。
49. 从合并 JSON 解析 `{project_name}`（`core` 下）、`{planning_artifacts}`（`modules.bmm` 下）和 `{date}`；缺失键取中性默认值，绝不阻塞。
50. 无交互用户时走 headless：按 `references/headless.md` 执行整个运行。
51. 有交互用户时问候用户。从对话和输入检测意图——**create**（默认）、**update** 现有脊柱、或 **validate** 一个脊柱。
52. 如果真实请求是需求 / UX / 能力契约 / epic 拆分 / agent，改为调用 `bmad-prd`、`bmad-ux`、`bmad-spec`、`bmad-create-epics-and-stories` 或 `bmad-workflow-builder`（若安装了 BMad Builder）。
53. 如果目标 run folder 已存在于 `{workflow.spine_output_path}` 下，提议从其 memlog 恢复，而不是重启。
54. 交互式 create：在任何起草前提供工作模式——**Coaching path**（默认）或 **Fast path**；除非用户要求速度，默认 Coaching。
55. 两种路径都强制：起草前询问脊柱是否是唯一交付物；如果不是，引出**目的和受众**，而不是文档类型。说“一份架构文档”会膨胀；实际可能需要给单个团队的一细节解释，或给董事会的非技术愿景稿。目的决定制品大小，可能需要额外的前期引导，而不是只在结尾加东西。
56. 对新脊柱，将 `{doc_workspace}` 绑定到 `{workflow.spine_output_path}/{workflow.run_folder_pattern}/`。
57. 用 `{workflow.spine_template}` 初始化 `ARCHITECTURE-SPINE.md`。
58. 运行 `memlog.py init`，并告诉用户路径。
59. 在 epic altitude，将文件夹按 epic 划定范围（按 `customize.toml` 设置 `run_folder_pattern`），避免 per-epic 运行冲突。
60. Reviewer Gate：脊柱交付前评审，完整机制在 `references/reviewer-gate.md`。在 finalizing 或 validating 时加载：先跑确定性的 `lint_spine.py`，然后 rubric walker（good-spine checklist）+ 每个 `{workflow.finalize_reviewers}` lens 作为并行 subagents 针对 `ARCHITECTURE-SPINE.md` 调度，按风险缩放。
61. 在 Finalize，应用明确修复；在 Validate 意图下，交付定制 HTML 报告，然后获取用户输入。
62. Finalize 步骤 1 Distill：从 memlog（brownfield：+ code sweep）写脊柱——不变量优先，seed 最小，每个 `AD` 带 `Binds`/`Prevents`/`Rule`，`Deferred` 指出不决定什么。无占位符；绝不发明内容填空。
63. 模板的 `<!-- -->` 注释是指导——执行后删除；完成脊柱不携带模板注释，只保留传达结构的图（按 altitude 需要多少就多少，合法 mermaid）。
64. 扫过 altitude 拥有的广度——每个结构维度都已决定、延后或成为开放问题；整个维度沉默（例如运维/环境包络：部署与环境、基础设施/供应商策略、运营）是失败，不是干净脊柱。
65. 长时间 coaching 运行在 subagent 中蒸馏更干净；父级内联回退。
66. Finalize 步骤 2 Reconcile inputs：每个承重输入一个 subagent，对照脊柱检查并返回未落地内容——尤其被 `AD` 结构丢掉的安静需求（语气、约束）。在 gate 前完成。
67. Finalize 步骤 3 Reviewer pass：运行 Reviewer Gate（`references/reviewer-gate.md`）。在润色前解决。
68. Finalize 步骤 4 Triage：开放问题和 `[ASSUMPTION]` 标签：阻塞项（对下一步不安全）逐项解决；其余延后并在 memlog 中写复查条件。
69. Finalize 步骤 5 Renderings & polish：脊柱是构建交付物；脊柱和 memlog 就位后，按前期引出的目的和受众，产出用户需要的任何*额外*面向人的制品。
70. 前期问题已标记是否需要额外制品；若没有，仍在此提供，并给出具体选项：可交互 HTML+SVG deck 带团队走查架构并推动讨论、更完整的 HTML/md solution design、C4 集、或工作如何跨团队/epic 拆分的视图。
71. 只构建用户选择的，且按目的调整大小；仅对该 prose 应用 `{workflow.doc_standards}` 润色，绝不应用到脊柱。
72. Finalize 步骤 6 External handoffs：运行 `{workflow.external_handoffs}`；展示返回的 URLs/IDs。
73. 提议调用 `bmad-spec` 技能，将脊柱作为 companion 采纳，保持 `AD` ID 稳定，以便下游引用。
74. Finalize 步骤 7 Close：设置脊柱自己的 frontmatter `status: final`、`updated: {date}`；记录 `memlog.py append --type event --text "spine finalized"`（memlog 无 status 字段）。
75. 分享路径。下一步：**以 `bmad-spec` 打头**——推荐采纳/刷新脊柱作为 spec companion（当 spec 是输入时始终是首要推荐；不是时也有用），然后是 `bmad-create-epics-and-stories`，或——epic altitude——`bmad-build`；或调用 `bmad` 技能路由。
76. 运行 `{workflow.on_complete}`。
77. Update：修订现有脊柱或提供的制品。从其 `.memlog.md` 恢复（已决定内容的权威），而不是渲染后的脊柱。
78. 将变更捕获为新的 memlog 条目；**保持 `AD` ID 稳定**——原地修订 Rule，为新决策追加下一个 `AD-n`，绝不重编号或复用已废弃 ID。
79. 然后重新蒸馏（Finalize 步骤 1），运行 Reviewer Gate（`references/reviewer-gate.md`），并按 Finalize 关闭。
80. 若 Update 覆盖来自 source input 的内容：提议也更新该来源，避免上游与脊柱静默分叉。
81. Validate：独立意图——批评现有脊柱而不修改它。
82. 对它运行 Reviewer Gate（`references/reviewer-gate.md`），交付定制 HTML 报告，然后提议将发现滚入 Update。
83. 在 Finalize，同一 gate 作为你自己的交付前检查运行，此时你应用修复而不是报告。

适用边界 · 注意事项

• 当请求实质是需求、UX、能力契约、epic 拆分或构建 agent 时，不要用本技能，改用 `bmad-prd`、`bmad-ux`、`bmad-spec`、`bmad-create-epics-and-stories` 或 `bmad-workflow-builder`。
• 当输入太薄、无法支撑架构决策时，先建议 `bmad-spec`，而不是硬造答案。
• 当未安装/无法运行 BMad 及其 uv 脚本环境时，先完成 BMad setup；否则本技能不可用。