@llman-sdd/core 0.3.1 → 0.5.0

package/templates/zh-Hans/skills/llman-sdd-apply.md

@@ -1,125 +1,107 @@
 ---
 name: "llman-sdd-apply"
-description: "在一个闭环内实施 llman SDD 变更的 tasks：写代码 → 跑测试 → 失败自修复 → 直到门禁全绿。自动更新 tasks.md 勾选状态并运行校验。用于提案完成后的实现阶段。"
+description: "闭环实施已提案 change 的 tasks：写码→测试→失败自修复→门禁全绿。propose 完成、specs 落地后进入。"
 metadata:
   version: "{{ llman_version }}"
 ---
 
 # LLMAN SDD Apply
 
-使用此 skill 在**一个闭环内**按顺序完成 `llmanspec/changes/<id>/tasks.md` 的所有任务：
-实现代码 → 补测试/验收 → 跑门禁 → 失败自修复并重跑 → 全部通过后报告结果。
-除非遇到明确 blocker，否则**不要中途停下来问「要不要继续」**。
+在**一个闭环内**按顺序完成 `llmanspec/changes/<id>/tasks.md` 的所有任务：实现 → 补测试/验收 → 跑门禁 → 失败自修复重跑 → 全过后报告。除非明确 blocker，**不要中途问「要不要继续」**。
 
 ## Pipeline 位置
 
 {{ unit("skills/git-native-flow-brief") }}
 
-### Skill 导航（非生命周期；仅指示当前 skill）
-
 ```mermaid
 flowchart LR
-    propose["llman-sdd-propose<br/>提案"] --> apply
-    apply["★ llman-sdd-apply ★<br/>实施（须 readyToImplement）"]
-    apply --> verify["llman-sdd-verify<br/>验证"]
-    verify --> archive["llman-sdd-archive<br/>归档"]
+    propose["llman-sdd-propose"] --> apply["★ llman-sdd-apply"]
+    apply --> verify["llman-sdd-verify"]
+    verify --> archive["llman-sdd-archive"]
 
     style apply fill:#fff3cd,stroke:#ffc107,stroke-width:3px
 ```
 
-> 📍 你现在在完整 Git-native 生命周期图中的 **H（apply）**：进入前须 Specs-landed（或 `needs_specs_change: false`）且 `readyToImplement=true` → 下一步 `llman-sdd-verify`
+> 📍 进入前须 specs-landed 门通过（或 `needs_specs_change: false`）；`readyToImplement=true`（全门绿）是本闭环的完成信号 → 下一步 `llman-sdd-verify`。
 
 ## 硬约束
 
-- **SSOT 驱动**：以 `proposal.md` / `design.md` / `tasks.md` 及 feature 分支上的 live `llmanspec/specs/**` 为唯一事实来源；specs 中的 MUST/SHALL 必须逐条落实。
-- **范围锁定**：只实现当前 change 的范围；禁止顺手修「无关问题」。
-- **最小改动**：改动保持最小并严格围绕当前 tasks。
-- **禁止猜测**：需求不明确、specs 与实现矛盾时，先 STOP 并报告，不要自行假定行为。
-- **不保留旧兼容层**：若 change 要求改行为，直接全量升级到新写法，除非 tasks/proposal 明确写了要兼容。
-- **不要问「要不要继续」**：除非遇到无法自动解决的 blocker，否则一路执行到闭环结束。
-- **收尾**：本 skill 闭环以建议 `llman-sdd-verify` 结束；finalize/archive 由 `llman-sdd-archive` 负责（勿在自修复循环里 finalize）。
+- **唯一事实来源驱动**：`proposal.md` / `design.md` / `tasks.md` 与分支上的 `llmanspec/specs/**`；specs 的 MUST/SHALL 逐条落实。
+- **范围锁定**：只做当前 change 范围，禁止顺手修无关问题；改动保持最小。
+- **禁止猜测**：需求不明或 specs 与现实矛盾 → STOP 报告，不自行假定。
+- **不留旧兼容层**：change 要求改行为就全量升级到新写法，除非 tasks/proposal 明确要兼容。
+- **收尾**：闭环以建议 `llman-sdd-verify` 结束；finalize/archive 归 `llman-sdd-archive`（勿在自修复循环里 finalize）。
 
 ## Commit 策略
 
-- **change 分支上提交自由**（无存档点概念：`change finalize` 不要求干净树）：可按 task/里程碑分段提交（利于 review），也可保持工作区不提交、交给 finalize 一次收尾——两条路都是一等公民。`change checkpoint` 已不存在（调用它以非零退出报错并指向 finalize），因此没有「中途存档点」要维护；`change finalize` 对两种形态都原生支持（不要求干净树）。
-- **默认收尾**：全部 task 过门禁且 verify 全绿后，`llman-sdd change finalize <id>` 自动提交 `archive(sdd): <change-id>`（未提交的实现 diff + frontmatter + archive 改名一次提交）。不要在 apply 循环内 finalize。`--no-commit` 可跳过自动提交（手动/CI 历史、pre-commit hook 冲突场景）。
-- **blocker 中断**：必须因 blocker STOP 时，先做**一次** WIP commit（如 `wip(sdd): <change-id> <摘要>`）保全现场，再报告。
+- **change 分支上提交自由**（`change finalize` 不要求干净树）：按 task/里程碑分段提交，或留脏交给 finalize 一次收尾——均为一等公民。
+- **默认收尾**：全部 task 过门禁且 verify 全绿后，`llman-sdd change finalize <id>` 自动提交 `archive(sdd): <change-id>`（未提交 diff + frontmatter + 改名一笔）。不要在 apply 循环内 finalize。`--no-commit` 跳过自动提交（手动/CI 历史、pre-commit hook 冲突）。
+- **blocker 中断**：因 blocker STOP 前先做**一次** WIP commit（如 `wip(sdd): <change-id> <摘要>`）保全现场再报告。
 
 ## 步骤
 
-### 0) Preflight（必须做）
-- 读取并遵守：`llmanspec/config.yaml`、`AGENTS.md`（若存在）。
-- `git status --porcelain`：
-  - 若工作区不干净且改动不属于当前 change：先 `git stash push -u -m "llman-sdd-apply autopilot backup"` 做备份。
-- 运行 `llman-sdd validate --all --strict --no-interactive`：
-  - 若失败且与当前 change 无关，先停下报告（工件不一致会导致实现无法以 SSOT 驱动）。
-- **检查 spec valid_scope 完整性**：使用 `llman-sdd list --specs --json` 列出所有 spec，然后对每个 spec 验证其 `valid_scope` 中的每个路径是否存在于磁盘上。若存在缺失的文件/目录，停下并建议更新 spec（从 `valid_scope` 中移除已删除的路径）。
-
-### 1) 选择变更 id 并检查前置条件
-- 若已提供 change id，直接使用。
-- 否则从上下文推断；若不明确，运行 `llman-sdd list --json` 并让用户选择。
-- 始终说明："使用变更：<id>"，并告知如何覆盖。
-- 确认已在经 `llman-sdd change start <id>` 或 `change attach <id>` 绑定的非默认 feature 分支上（仅在需要重绑时用 `--force`）。分支上的 specs/features 即 SSOT——不要在 `changes/<id>/specs/` 下编写。
+### 0) Preflight（必须）
+- 读取并遵守 `llmanspec/config.yaml`、`AGENTS.md`（若存在）。
+- `git status --porcelain`：工作区不干净且改动不属于本 change → 先 `git stash push -u -m "llman-sdd-apply autopilot backup"`。
+- `llman-sdd validate --all --strict`：失败且与本 change 无关 → 停下报告（工件不一致则无法以事实来源驱动实现）。
+- **检查 spec valid_scope 完整性**：`llman-sdd list --specs --json` 列出所有 spec，逐个核对 `valid_scope` 路径存在于磁盘；有缺失 → 停下并建议更新 spec（移除已删路径）。
+
+### 1) 选定 change id 并查前置
+- 已提供则直接用；否则从上下文推断，不明确就跑 `llman-sdd list --json` 让用户选。始终说明「使用变更：<id>」并告知如何覆盖。
+- 确认在经 `llman-sdd change start <id>` 或 `change attach <id>` 绑定的非默认分支上（仅重绑用 `--force`）。分支上的 specs 即唯一事实来源——不要在 `changes/<id>/specs/` 下编写。
 {{ unit("skills/stage-guard") }}
-- 使用 `llman-sdd context --task "<proposal 中的目标>" --paths "<specs 中的 scope>"` 获取相关 specs。
-  - 若 context 不可用，运行 `llman-sdd index rebuild` 后重试。
+- 用 `llman-sdd context --task "<proposal 目标>" --paths "<specs scope>"` 获取相关 specs。
+  - context 不可用 → 先 `llman-sdd index check`：stale/缺失则 `llman-sdd index rebuild` 后重试；fresh 仍不可用（`LLMAN_SDD_INDEX_CHAT_MODEL` 未设）→ 改用 `llman-sdd list --specs` + 直读 `.feature`——勿循环 rebuild。
 
-### 2) 阅读 SSOT 工件
-必须通读以下文件：
-- `llmanspec/changes/<id>/proposal.md`
-- `llmanspec/changes/<id>/design.md`（如存在）
-- `llmanspec/changes/<id>/tasks.md`
-- feature 分支上的 live specs：`llmanspec/specs/**`（`<capability>.feature`）——这是 SSOT
+### 2) 通读事实来源工件
+- `llmanspec/changes/<id>/proposal.md`、`design.md`（如有）、`tasks.md`
+- 分支上的 `llmanspec/specs/**`（`<capability>.feature`）
 
-将 `proposal.md` 和 `design.md` 中的决策整理为不可违反的硬约束清单。把 `tasks.md` 转成可执行的最小步骤序列（保持原顺序）。
+把 proposal/design 的决策整理为不可违反的硬约束清单；把 tasks.md 转成最小可执行步骤序列（保持原顺序）。
 
 ### 3) 展示状态
-- 进度："N/M tasks complete"
-- 接下来 1–3 个未完成任务（简短概览）
+- 进度「N/M tasks complete」+ 接下来 1–3 个未完成任务的简短概览。
 
-### 4) 逐任务实施（闭环执行）
+### 4) 逐任务实施（闭环）
 对每个未完成 task：
-1. **实现**：严格按 task 描述 + specs 要求，改动保持最小。
-2. **完成后立刻更新 checkbox**：`- [ ]` → `- [x]`。
-3. 若 task 不明确、遇到 blocker、或发现 specs/design 与现实不一致 → STOP 并报告 blocker，不要自行假定。
-
-> 💡 上一阶段 `llman-sdd-propose`（已生成 tasks）；完成本阶段后 → `llman-sdd-verify`（验证）
-
-### 5) 验证与自修复循环（每个 task 或每批 task 完成后执行一次）
-运行项目门禁命令（根据项目实际选择）：
-- 相关测试集：`just test` 或 `cargo test --all`
-- 格式/lint：`just check` 或 `just lint` + `just fmt`
-- Git-native：留在绑定 feature 分支；按需编辑 live `llmanspec/specs/<capability>.feature`（扁平，或目录 `llmanspec/specs/<capability>/` 内主文件；规则 `@human`，验收 `@executable`）；spec 改动后跑 `llman-sdd validate --specs`；分支上可自由提交（分段，或留脏交给 finalize）。勿使用 `change delta` / solidify / feature_delta；`change checkpoint` 已移除。
-- SDD 校验：`llman-sdd validate <id> --strict --no-interactive`
-
-**若失败 → 进入自修复循环（不要问要不要继续）：**
-1. 解析失败原因（测试失败 / lint / 格式 / 校验错误）。
-2. **判定是否难定位的 bug**（测试失败原因不明 / 间歇性 flake / 回归且一眼看不穿）：
-   - **不是难定位的 bug**（明确的 lint/格式/编译错误/校验失败）：进行最小修复（不扩大范围），先重跑「最小失败复现命令」再重跑全部门禁。
-   - **难定位的 bug → 升级诊断子流程**：
-     1. **先建一个能复现失败的命令**（快、确定、agent 可运行，且能在这个 bug 上失败）——即一个能驱动真实 bug 路径并断言用户确切症状的命令。**MUST NOT 在没有这种命令前就开始猜原因**（盯着代码空想正是本流程要防止的失败）。
-     2. 运行并确认失败 → 最小化复现（逐个剔除输入/调用/配置/数据，只留关键部分）。
-     3. 生成 **3–5 个排序假设**，每个须可证伪（「若 X 是因，则改 Y 会让 bug 消失」）。
+1. **实现**：严格按 task 描述 + specs 要求，改动最小。
+2. **完成后立刻勾 checkbox**：`- [ ]` → `- [x]`。**收口不是 task**：`change finalize` / `change archive` 是流水线步骤，MUST NOT 出现在 tasks.md——若已列（如「收口——finalize」），删掉（收口的任务门要求全部任务已勾）。
+3. **编辑与验证串行**：验证 MUST 在编辑落盘后执行；MUST NOT 把编辑与测试/校验放进同一批并行工具调用（可能读到旧文件，产生假失败/假通过）。
+4. task 不明、遇 blocker、或 specs/design 与现实不一致 → STOP 报告，不自行假定。
+
+### 5) 验证与自修复循环（每个 task 或每批 task 后跑一次）
+按项目实际跑门禁：
+- 测试集：`just test` 或 `cargo test --all`；格式/lint：`just check` 或 `just lint` + `just fmt`
+- 分支上按需编辑 `llmanspec/specs/<capability>.feature`（扁平或目录主文件；统一原生分层：`@req:<id>` 挂 `规则:` 块头、嵌套 `场景:` 为可执行示例），spec 改动后跑 `llman-sdd validate --specs`；分支上可自由提交。
+- SDD 校验：`llman-sdd validate <id> --strict`
+
+**门禁证据**：
+- 收口会执行已配置的 `bdd.run_command`，收口前不必再跑一遍；`--no-check` 打出的跳过说明不是通过。
+- 门禁结论 MUST 来自真实 harness：MUST NOT 以 `--no-check` 取得「通过」；harness 失败 MUST 先查根因（环境变量泄漏、嵌套调用守卫、工作目录错误等），MUST NOT 以「固有/自指属性」定性后绕过。
+- 前后对比类判据（计数、基线）MUST 在 change 分支上测量（相对现算 merge-base）；默认分支测得的值通常恒为基线，不构成证据。
+- 重构或批量替换类 task：MUST 对比改动前后测试用例数；门禁全绿但用例数下降视为失败。
+
+**失败 → 自修复（不要问要不要继续）：**
+1. 解析失败原因（测试 / lint / 格式 / 校验）。
+2. 判定是否难定位 bug（原因不明 / 间歇 flake / 回归看不穿）：
+   - **不是**（明确的 lint/格式/编译/校验错误）：最小修复（不扩范围），先重跑最小失败复现命令，再重跑全部门禁。
+   - **是 → 升级诊断子流程**：
+     1. **先建一个能复现失败的命令**（快、确定、agent 可跑、能在此 bug 上变红）——驱动真实 bug 路径并断言用户症状。**MUST NOT 在没有它之前猜原因**（盯着代码空想正是要防止的失败）。
+     2. 运行确认变红 → 最小化复现（逐个剔除输入/调用/配置/数据，只留关键部分）。
+     3. 生成 **3–5 个排序假设**，每个可证伪（「若 X 是因，改 Y 会让 bug 消失」）。
      4. 单变量验证（一次只改一个），找到根因后修复。
-     5. 若没有合适的边界（seam）写回归测试，记录该架构缺口（交 `llman-sdd-arch-review`；该 skill 未在 `extra_skills` 启用时，把缺口写入该 change 的 `proposal.md` Further Notes 段或 `design.md`，MUST NOT 因此中断闭环）。
-3. 先重跑「最小失败复现命令」，再重跑全部门禁。
-4. 记录为一轮自修复：`Round N：失败点 → 修复 → 重跑 → 通过/失败`。
+     5. 没有合适 seam 写回归测试时，记录该架构缺口（交 `llman-sdd-arch-review`；未启用时写入本 change 的 `proposal.md` Further Notes 段或 `design.md`，MUST NOT 因此中断闭环）。
+3. 先重跑最小失败复现命令，再重跑全部门禁。
+4. 记为一轮自修复：`Round N：失败点 → 修复 → 重跑 → 通过/失败`。
 
-**自修复上限 8 轮**；超过仍不通过视为 blocker：停止并输出 blocker 报告（含最后一次失败命令与输出摘要、你已尝试的修复）。
+**自修复上限 8 轮**；超过仍不过视为 blocker：停止并输出 blocker 报告（最后一次失败命令与输出摘要、已尝试的修复）。
 
-**人审检查点（每个 task 批次门禁通过后）**：批次全绿后、进入下一批次或输出完成报告前，运行 `llman-sdd review`：
-
-- 退出码为零 → 继续。
-- 非零退出 = 存在 CRITICAL 发现：STOP，修复后重跑 review；MUST NOT 带着 CRITICAL 进入下一批次或输出完成报告。
+**人审关卡（每批 task 门禁通过后）**：进入下一批次或输出完成报告前跑 `llman-sdd review`：退出码零 → 继续；非零 = CRITICAL → STOP 修复后重跑；MUST NOT 带 CRITICAL 进入下一批次或输出完成报告。
 
 ### 6) 完成报告
-所有 task 完成 + 全部门禁通过后，输出结构化报告（见下方 Output Contract）。
-然后建议运行 `llman-sdd-verify` 进入验证阶段。
-
-> 💡 实施完成 → 下一步 `llman-sdd-verify`（验证）
+所有 task 完成 + 全部门禁通过后输出结构化报告（见 Output Contract），然后建议 `llman-sdd-verify`。
 
-> 命令细节用 `llman-sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
-> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman-sdd list --specs` / `llman-sdd show <capability>` 查全文。
+{{ unit("skills/cli-footer") }}
 
 {{ unit("skills/validation-hints") }}
 

package/templates/zh-Hans/skills/llman-sdd-arch-review.md

@@ -1,65 +1,58 @@
 ---
 name: "llman-sdd-arch-review"
-description: "扫描 codebase 的薄模块（接口几乎等于实现），找出可以加深（藏更多行为到更小接口后）的候选。当用户想做架构审查、寻找模块加深机会、或想改善代码可测性与 AI 可导航性时使用。"
+description: "架构审查：扫描薄模块（接口≈实现），给出加深候选，改善可测性与 AI 可导航性。"
 metadata:
   version: "{{ llman_version }}"
 ---
 
 # LLMAN SDD Architecture Review
 
-扫描 codebase 的架构摩擦，找出**可以加深的模块**——把薄模块（接口几乎等于实现）改造成厚模块（小接口后藏大量行为）。目标是可测性与 AI 可导航性。
-
-## Pipeline 位置
-
-辅助工具，不属于主实现 pipeline（explore→propose→apply→verify→archive）。任意阶段可用，常在 explore 阶段触发以发现改进候选。
-
-> 📍 这是独立可选 skill，不替代任何 pipeline 阶段。
+扫描代码库的架构摩擦，找出**可以加深的模块**——把薄模块（接口≈实现）改造成厚模块（小接口后藏大量行为）。目标是可测性与 AI 可导航性。辅助工具，不属于主 pipeline，任意阶段可用，常在 explore 阶段触发。
 
 ## 设计词汇
 
-下面是一组关于模块形状的词，用来说清楚「哪里值得改」。MUST NOT 替换为「component」「service」「API」「boundary」（它们含义更宽、不够精确）：
+描述模块形状的词；MUST NOT 替换为「component」「service」「API」「boundary」（含义更宽、不够精确）：
 
 - **Module（模块）** — 有接口和实现的东西（函数/类/包/跨层切片都算）。
-- **Interface（接口）** — 调用者为正确使用所须知道的一切：类型签名，外加不变量、顺序约束、错误模式、性能特征。
-- **Depth（厚度）** — 接口背后的行为量。**厚** = 小接口后藏大量行为；**薄** = 接口几乎和实现一样复杂（调用者要懂的 ≈ 写代码要写的）。本 skill 要把薄的变厚。
-- **Seam（接缝）** — 不改调用处就能换实现的位置（接口栖身的地方）。llman 里接缝 = `*.feature` 的 GWT 步骤所驱动的公共边界。
+- **Interface（接口）** — 调用者正确使用所须知道的一切：类型签名 + 不变量、顺序约束、错误模式、性能特征。
+- **Depth（厚度）** — 接口背后的行为量。**厚** = 小接口后藏大量行为；**薄** = 接口几乎和实现一样复杂（调用者要懂的 ≈ 写代码要写的）。本 skill 把薄的变厚。
+- **Seam（接缝）** — 不改调用处就能换实现的位置（接口栖身处）。llman 里接缝 = `*.feature` GWT 步骤驱动的公共边界。
 - **Leverage（杠杆）** — 调用者从厚度获得的好处：学一点接口就能驱动很多行为。
-- **Locality（局部性）** — 维护者从厚度获得的好处：变更/bug/知识/验证集中在一处，改一次到处生效。
+- **Locality（局部性）** — 维护者从厚度获得的好处：变更/bug/知识/验证集中一处，改一次到处生效。
 
 ## 步骤
 
 ### 1. 探索（先定范围，YAGNI）
-- 若用户指定了方向（模块/子系统/痛点），直接采信，跳过推断。
+- 用户指定方向（模块/子系统/痛点）则直接采信，跳过推断。
 - 否则回看 `git log --oneline` 找热点（反复出现的文件/区域）。
-- 优先读 live `<capability>.feature`（单轨 SSOT）与 `design.md`（已有 ADR），MUST NOT 另建 `CONTEXT.md`。
-- 用 Agent 工具（subagent_type=Explore）走查 codebase，记录摩擦点：
+- 优先读 `<capability>.feature`（唯一事实来源）与 `design.md`（已有 ADR）；MUST NOT 另建 `CONTEXT.md`。
+- 用 Agent 工具（subagent_type=Explore）走查代码库，记录摩擦点：
   - 理解一个概念是否要在多个小模块间跳来跳去？
-  - 哪里模块**薄**（接口几乎和实现一样复杂，调用者没省事）？
+  - 哪里模块**薄**（接口≈实现复杂度，调用者没省事）？
   - 哪里纯函数仅为可测性抽取，但真实 bug 藏在调用方式里（缺局部性）？
   - 哪些部分没测或难以通过当前接口测试？
 
 ### 2. 提出候选
-对每个候选，给出：
-- **Files** — 涉及哪些文件/模块。
-- **Problem** — 当前架构为何造成摩擦（用厚度/杠杆/局部性说清楚）。
+每个候选给出：
+- **Files** — 涉及的文件/模块。
+- **Problem** — 当前架构为何造成摩擦（用厚度/杠杆/局部性说清）。
 - **Solution** — 会改变什么的平实描述。
 - **Benefits** — 局部性与杠杆的改善，测试如何变好。
 - **Recommendation strength** — `Strong` / `Worth exploring` / `Speculative`。
 
-**删除验证**：对任何疑似薄的模块，想象删除它——复杂度是直接消失（它只是个透传，没价值）还是在 N 个调用点重新冒出来（它其实在扛事）？「重新冒出来」才是值得保留/加厚的信号。
+**删除验证**：对疑似薄的模块想象删除它——复杂度直接消失（只是透传，没价值）还是在 N 个调用点重新冒出来（其实在扛事）？「重新冒出来」才是值得保留/加厚的信号。
 
-**ADR 冲突**：若候选与既有 `design.md` 决策矛盾，仅在摩擦真实到值得重开时才浮现，并在候选中标注（「与 design.md 的 X 决策冲突——但因…值得重开」）。
+**ADR 冲突**：候选与既有 `design.md` 决策矛盾时，仅在摩擦真实到值得重开才浮现，并在候选中标注（「与 design.md 的 X 决策冲突——但因…值得重开」）。
 
 ### 3. 逐问深挖（用户选定候选后）
-用户从候选中选一个后，运行 `llman-sdd-explore` 的**逐问深挖分支**（触发词「深挖」）逐个走清决策——约束、依赖、加深后的模块形状、接缝后放什么、哪些测试存活。
+运行 `llman-sdd-explore` 的**逐问深挖分支**（触发词「深挖」）走清决策——约束、依赖、加深后的模块形状、接缝后放什么、哪些测试存活。
 
-- 加深后的模块用到了 capability `.feature` 里没有的概念？→ 仅在 change 已 Branch binding 且当前在绑定分支上时，更新 live `.feature`（Specs landing）；否则 STOP，先走 `llman-sdd-propose` / `change start`，**禁止**在默认分支改 live specs。
-- 用户以关键理由拒绝候选？→ 仅当「难逆转 + 无上下文会困惑 + 真实权衡」三者皆满足时，建议记入 `design.md`。
+- 加深后用到了 `.feature` 里没有的概念？→ 仅在 change 已绑定分支且当前在绑定分支上时更新 `.feature`；否则 STOP，先走 `llman-sdd-propose` / `change start`，**禁止**在默认分支改 specs。
+- 用户以关键理由拒绝候选？→ 仅当「难逆转 + 无上下文会困惑 + 真实权衡」皆满足时，建议记入 `design.md`。
 
 ## 输出
-候选清单（文本；可选 HTML 报告写 OS temp dir 不落 repo）+ 用户选定后的逐问深挖决策记录（回写 proposal；合约变更须经 Specs landing 才回写 live `<capability>.feature`）。
+候选清单（文本；可选 HTML 报告写 OS temp dir 不落 repo）+ 用户选定后的逐问深挖决策记录（回写 proposal；合约变更须在绑定分支落地后才回写 `.feature`）。
 
-> 命令细节用 `llman-sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
-> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman-sdd list --specs` / `llman-sdd show <capability>` 查全文。
+{{ unit("skills/cli-footer") }}
 
 {{ unit("skills/structured-protocol") }}

package/templates/zh-Hans/skills/llman-sdd-archive.md

@@ -1,84 +1,69 @@
 ---
 name: "llman-sdd-archive"
-description: "归档已完成的 llman SDD 变更。自动合并回基准分支（squash 缺省），再将 change 文档改名到 archive/。在 verify 报告全绿后运行。"
+description: "归档已完成 change：合并回基准分支（默认 squash）、文档改名入 archive/、自动收口提交。verify 全绿后运行。"
 metadata:
   version: "{{ llman_version }}"
 ---
 
 # LLMAN SDD 归档
 
-使用此 skill 归档已完成的变更。前置：verify 全绿，且变更已 Branch binding、Specs landing 完成（或 `needs_specs_change: false`；归档时 live specs 已在绑定分支上）。`change finalize` **自动合并**到基准分支（目标：`--into` > 绑定 `base_branch` > 默认分支；方式：`--method` > 配置 `sdd.merge_method`，squash 缺省——feature diff + 改名收敛为目标分支单个 commit）、**将** change 文档改名到 `changes/archive/`，然后**自动提交** `archive(sdd): <change-id>`（实现 diff + 改名一次提交；`--no-commit` 跳过）。`change checkpoint` 已移除（无存档点概念：中途不必存档，`change finalize` 不要求干净树）。`git push` / Hosting PR 仅为可选。
+归档已完成的变更。前置：verify 全绿，且 change 已绑定分支、specs 已落地（或 `needs_specs_change: false`）。`change finalize` **自动合并**到基准分支（目标：`--into` > 绑定 `base_branch` > 默认分支；方式：`--method` > 配置 `sdd.merge_method`，默认 squash——feature diff + 改名收敛为目标分支单个 commit）、**改名** change 文档到 `changes/archive/`、**自动提交** `archive(sdd): <change-id>`（`--no-commit` 跳过）。`git push` / PR 仅可选。
 
 ## Pipeline 位置
 
 ```mermaid
 flowchart LR
-    verify["llman-sdd-verify<br/>验证"] --> archive
-    archive["★ llman-sdd-archive ★<br/>归档（你现在在这里）"]
+    verify["llman-sdd-verify"] --> archive["★ llman-sdd-archive"]
 
     style archive fill:#fff3cd,stroke:#ffc107,stroke-width:3px
 ```
 
-> 📍 你现在在归档阶段：Git-native 生命周期的最后一站。
-> 📎 若 specs 逐渐膨胀，可运行 `llman-sdd-specs-compact` 压缩。
+> 📍 你在归档阶段：分支生命周期最后一站。specs 膨胀时可跑 `llman-sdd-specs-compact`。
 
 ## 硬约束
 
-- **必须先通过 verify 阶段全绿**：未通过验证的 change 禁止归档。
-- **须已 Branch binding**：`change start` / `attach` 已完成；无绑定则 STOP。
-- **SSOT 校验**：每个 change 归档前必须通过 `llman-sdd validate <id> --strict --no-interactive`。
-- **不要问「要不要继续」**：批量归档时间线上一路执行到底，除非遇到无法自动解决的错误。
-- **收尾不默认导向 PR/push**：archive/finalize 后由 CLI 处理本地合并（squash 缺省），再一次性 `git commit` 提交收口。`git push` / Hosting PR 仅为可选——仅当用户或项目明确要求远程审查时才做。**Agent MUST NOT** 因本 skill 默认执行 push 或创建 PR。
+- **必须先 verify 全绿**；**须已绑定分支**（`change start` / `attach`），无绑定 STOP。
+- 每个 change 归档前必须通过 `llman-sdd validate <id> --strict`。
+- **不要问「要不要继续」**：批量归档一路执行到底，除非遇到无法自动解决的错误。
+- **收尾不默认导向 PR/push**：CLI 本地合并（默认 squash）+ 一次性收口提交。push / PR 仅在用户或项目明确要求远程审查时做——**Agent MUST NOT** 默认 push 或建 PR。
 
 ## 步骤
 
 ### 0) Preflight
-- `git status --porcelain`：确认工作区改动属于已完成的 change。
-- 若有未预期改动，先处理（stash 或报告）。
+- `git status --porcelain`：确认工作区改动属于已完成的 change；有未预期改动先处理（stash 或报告）。
 
-### 1) 确认目标变更
-- 确定目标 ID：单个或批量（来自用户输入或 `llman-sdd list --json`）。
-- 始终说明："归档 IDs：<id1>, <id2>, ..."。
-- 确认每个 change 都已通过 verify 阶段的全绿验证。
+### 1) 确认目标
+- 确定 ID（单个或批量，来自用户输入或 `llman-sdd list --json`），始终说明「归档 IDs：<id1>, <id2>, ...」，并确认每个 change 都已 verify 全绿。
 
 ### 2) 逐个归档
-- **人审检查点（每个 id 归档执行前，含批量）**：运行 `llman-sdd review --capability <id>`。退出码为零 → 继续；非零 = CRITICAL 发现：STOP 修复后重跑；MUST NOT 带着 CRITICAL 归档。
-- 先逐个校验：`llman-sdd validate <id> --strict --no-interactive`。
-- 校验失败 → STOP 并报告；不要跳过校验强行归档。
+- **人审关卡（每个 id 归档前，含批量）**：跑 `llman-sdd review`（无旗标；`--capability` 只接受 spec id）。退出码零 → 继续；非零 = CRITICAL → STOP 修复后重跑；MUST NOT 带 CRITICAL 归档。
+- 先校验：`llman-sdd validate <id> --strict`；失败 → STOP 报告，禁止跳过强行归档。
 - 可选预览：`llman-sdd change archive <id> --dry-run`。
-- 执行归档：
-  - 默认：`llman-sdd change archive <id>`
-  - 仅工具类变更：`llman-sdd change archive <id> --skip-specs`
-  - **任一失败立即停止**，报告剩余未处理 ID。
-- **Git-native 收尾**：
-  - 前置：已 Branch binding（`change start` / `attach`）；仍在绑定分支上（或合并后已在目标分支）。
-  - `change archive` / `change finalize` **先自动合并**（目标 `--into` > 绑定 `base_branch` > 默认分支；方式 squash 缺省或 `ff`；目标被其他 worktree 持有时跳过并打印手动命令），**再**将 change 文档改名到 `changes/archive/`——合并失败也不会回滚改名，降级提示显式可见。
-  - specs 下遗留 `*.feature.delta.toon` 或 `spec.toon` 均为迁移阻断项——跑 `llman-sdd project migrate --kind toon2features`。
-  - **默认：`change finalize`（单命令收口）**——门禁 → 自动合并 → 文档改名 → **自动提交** `archive(sdd): <change-id>`（squash 缺省：实现 diff + 改名收敛为目标分支**单个**提交；无需手动 `git commit`；锁定规则改动为报告制 WARNING——只警告不阻断）：
+- 执行：`llman-sdd change archive <id>`；**任一失败立即停止**，报告剩余 ID。
+- **分支收尾**：
+  - 前置：已绑定分支；仍在绑定分支上（或合并后已在目标分支）。
+  - `change archive` / `change finalize` **先自动合并**（目标 `--into` > `base_branch` > 默认分支；方式默认 squash 或 `ff`；目标被其他 worktree 持有时在该 worktree 内原地执行，输出标注 `executed in target worktree <path>`；该 worktree 脏时中止报错并列出处置选项，零写入），**再**改名到 `changes/archive/`——合并失败不回滚改名，降级提示显式可见。
+  - **默认 `change finalize`（单命令收口）**——门禁 → 合并 → 改名 → **自动提交** `archive(sdd): <change-id>`（无需手动 `git commit`；锁定规则改动为报告制 WARNING，只警告不阻断）：
     ```text
-    1. 实现 live specs + 代码（工作区可保持脏；分支上提交自由——分段或完全不提交）
-    2. llman-sdd change finalize <id>    # 门禁 + 合并（squash 缺省）+ 改名 + 自动提交
-    3. 可选：git commit --amend          # 调整提交说明；git branch -D <feature>  # squash 后分支不再是祖先，-d 会被 git 拒绝
+    1. 实现 specs + 代码（工作区可保持脏；分支上提交自由）
+    2. llman-sdd change finalize <id>    # 门禁 + 合并（默认 squash）+ 改名 + 自动提交
+    3. 可选：git commit --amend 调整说明；git branch -D <feature>  # squash 后分支不再是祖先，-d 会被拒
     ```
-    `--no-commit` 跳过自动提交（CI / pre-commit hook 冲突）：finalize 此时留脏工作区并打印手动 `git commit` 命令。幂等重试：自动提交失败后重跑会识别已归档改名并补提交。
-  - **Fallback：普通 `change archive <id>`**——同样的合并 + 改名，无自动提交；要求干净树。`checkpointed`/`checkpoint_sha` 字段已随 checkpoint 一同移除（无存档点概念：`change finalize` 不要求干净树）——无需预写任何存档字段，快照审查用 `change diff`。
+    `--no-commit` 跳过自动提交（CI / pre-commit hook 冲突）：finalize 留脏工作区并打印手动提交命令。幂等重试：自动提交失败后重跑会识别已归档改名并补提交。
+  - **Fallback：`change archive <id>`**——与 finalize 同样的自动合并 + 改名 + 收口提交（此路无 `--no-commit`）；门禁：task 全勾 + 干净树 + 在绑定非默认分支（`--force` 跳过）。快照审查用 `change diff`。
 
 ### 3) 全量校验
-- 全部归档完成后执行：`llman-sdd validate --all --strict --no-interactive`。
-- 确认归档后的 specs 工件一致。
+- 全部归档后 `llman-sdd validate --all --strict`，确认 specs 工件一致。
 
 ### 4) Commit 引导
-- finalize 已自动提交（`archive(sdd): <id>`）；使用 `--no-commit` 时手动提交：`git add -A && git commit -m "archive(sdd): <id1>, <id2>"`（或本 skill 建议的格式）。
-- 可选：合并后 `git branch -D <feature>`（squash 后分支不再是 main 祖先，-d 会被拒绝）。push / Hosting PR 仅在用户或项目明确要求远程审查时才做。
-- **破坏性合约变更**（移除/重命名 frontmatter 字段、命令、tag 或 stage 值域）MUST 提供 `migrations/v<from>-v<to>/` 升级路径（README prompt + 一次性脚本，随仓库发布）——收口前确认它存在。
-- **archived `depends_on`**：archive 会把 change 目录改名为 `archive/YYYY-MM-DD-<id>`，但 validate 会把指向 archived/frozen id 的 `depends_on` 识别为 INFO（非 ERROR），所以**归档后无需**手动更新其它 change 的 `depends_on` frontmatter。
-
-> 💡 上一阶段 `llman-sdd-verify`（验证通过）→ 本阶段归档后闭环结束。若 specs 逐渐膨胀，可运行 `llman-sdd-specs-compact` 压缩。
+- finalize 已自动提交；`--no-commit` 时手动：`git add -A && git commit -m "archive(sdd): <id1>, <id2>"`。
+- 可选：合并后 `git branch -D <feature>`。push / PR 仅在明确要求时做。
+- **破坏性合约变更**（移除/重命名 frontmatter 字段、命令、tag 或 stage 值域）MUST 提供 `migrations/v<from>-v<to>/` 升级路径（README + 一次性脚本随仓库发布）——收口前确认存在。
+- **archived `depends_on`**：archive 把 change 目录改名为 `archive/YYYY-MM-DD-<id>`；validate 把指向 archived/frozen id 的 `depends_on` 识别为 INFO（非 ERROR），**无需**手动更新其它 change 的 frontmatter。
 
 {{ unit("workflow/archive-freeze-guidance") }}
 
-> 命令细节用 `llman-sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
-> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman-sdd list --specs` / `llman-sdd show <capability>` 查全文。
+{{ unit("skills/cli-footer") }}
 
 {{ unit("skills/validation-hints") }}
 

package/templates/zh-Hans/skills/llman-sdd-continue.md

@@ -1,41 +1,34 @@
 ---
 name: "llman-sdd-continue"
-description: "继续已有 llman SDD 变更，创建下一个缺失工件。"
+description: "继续已有 change：补建下一个缺失工件。"
 metadata:
   version: "{{ llman_version }}"
 ---
 
 # LLMAN SDD Continue
 
-使用此 skill 继续已有变更，创建下一个缺失的 artifact。
+继续已有 change，创建下一个缺失工件。
 
 ## 步骤
-1. 确定 change id：
-   - 若用户已提供，直接使用。
-   - 否则运行 `llman-sdd list --json` 并询问要继续哪个 change。
-   - 始终说明："使用变更：<id>"。
-2. 阅读变更目录：`llmanspec/changes/<id>/`。
-> 阶段判定：用 `llman-sdd show <id> --json --type change` 的 `stage` / `readyToImplement` 字段；完整判定表见 llman-sdd-apply。
-3. 确定下一个要创建的 artifact（按顺序）：
+1. 确定 change id：用户给了就用；否则跑 `llman-sdd list --json` 让用户选。始终说明「使用变更：<id>」。
+2. 读 `llmanspec/changes/<id>/`。
+> 阶段判定：用 `llman-sdd show <id> --output json --type change` 的 `stage` / `readyToImplement`；完整判定表见 llman-sdd-apply。
+3. 按顺序确定下一个缺失工件：
    1) `proposal.md`
-   2) `design.md`（仅当涉及设计权衡时）
+   2) `design.md`（仅有设计权衡时）
    3) `tasks.md`
-   4) `llman-sdd change start <id>`（或分支已存在时用 `change attach <id>`）——Branch binding
-   5) 在**绑定分支**上编辑 live `llmanspec/specs/<capability>.feature`（扁平，或目录主文件）并 commit——Specs landing（无合约变更可设 `needs_specs_change: false`）
-4. 只创建**一个**缺失 artifact（或在绑定分支上做一次 live spec/feature 编辑）。
-   - continue 模式**不要**实现应用代码。
-   - **不要**创建 `*.feature.delta.toon` 或 `changes/<id>/specs/` 下的文件。
-   - **不要**在未 start/attach 前改公共 `llmanspec/specs/**`。
-5. 若所有 artifact 已齐全，按 `llman-sdd show <id> --json` 建议下一步：
-   - `readyToImplement=false` → 先完成 Specs landing（或 `needs_specs_change: false`）；**不要**建议 apply
-   - `readyToImplement=true` → 实施：`llman-sdd-apply`
-   - verify 之后 → 归档：`llman-sdd-archive`
-   - 校验：`llman-sdd validate <id> --strict --no-interactive`
-   - 审查：`llman-sdd change diff <id>`（只读）
+   4) `llman-sdd change start <id>`（分支已存在用 `change attach <id>`）——绑定分支
+   5) 在**绑定分支**编辑 `llmanspec/specs/<capability>.feature`（扁平，或目录主文件）并 commit——落地 specs（无合约变更设 `needs_specs_change: false`）
+4. 只创建**一个**缺失工件（或一次绑定分支上的 spec 编辑）。
+   - 不写应用代码；**不要**建 `changes/<id>/specs/`；**不要**在 start/attach 前改 `llmanspec/specs/**`。
+5. 工件已齐全时，按 `llman-sdd show <id> --output json` 建议下一步：
+   - specs-landed 门未过 → 先落地 specs（或 `needs_specs_change: false`）；**不要**建议 apply
+   - specs-landed 门已绿（即使实施中期 `readyToImplement=false`、tasks 未完）→ `llman-sdd-apply`
+   - verify 之后 → `llman-sdd-archive`
+   - 校验：`llman-sdd validate <id> --strict`；审查：`llman-sdd change diff <id>`（只读）
 
 {{ unit("skills/git-native-flow") }}
-> 命令细节用 `llman-sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
-> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman-sdd list --specs` / `llman-sdd show <capability>` 查全文。
+{{ unit("skills/cli-footer") }}
 {{ unit("skills/validation-hints") }}
 
 {{ unit("skills/structured-protocol") }}

package/templates/zh-Hans/skills/llman-sdd-draft.md

@@ -1,64 +1,53 @@
 ---
 name: "llman-sdd-draft"
-description: "快速把一个 change 想法记成草案提案（仅 proposal.md，经 `change new --from`）。不强制 tasks/design/specs/attach。用于随手记 idea 或未来需求；准备好后用 propose 正式化。"
+description: "把 change 想法记成草案（仅 proposal.md，不问 id）。随手记 idea/未来需求；落实时走 propose。"
 metadata:
   version: "{{ llman_version }}"
 ---
 
 # LLMAN SDD 草案（Draft）
 
-把一个 change 想法记成**草案提案**（仅 `proposal.md` skeleton）。这是「先把 idea / 未来需求记下来」的轻量入口——不做 triage、不写 tasks、不编辑 live specs、不 attach。等想法准备好落实时，用 `llman-sdd-propose` 正式化。
+把 change 想法记成**草案**（仅 `proposal.md` skeleton）——「先记下来」的轻量入口：不判断规模、不写 tasks、不改 specs、不 attach。落实时用 `llman-sdd-propose` 正式化。
 
 ## Pipeline 位置
 
 ```mermaid
 flowchart LR
-    draft["★ llman-sdd-draft ★<br/>草案（你现在在这里）"] -.->|"正式化"| propose["llman-sdd-propose<br/>提案"]
-    propose --> apply["llman-sdd-apply<br/>实施"]
-    apply --> verify["llman-sdd-verify<br/>验证"]
-    verify --> archive["llman-sdd-archive<br/>归档"]
+    draft["★ llman-sdd-draft"] -.->|"正式化"| propose["llman-sdd-propose"]
+    propose --> apply["llman-sdd-apply"] --> verify["llman-sdd-verify"] --> archive["llman-sdd-archive"]
 
     style draft fill:#fff3cd,stroke:#ffc107,stroke-width:3px
 ```
 
-> 📍 你现在在草案阶段 → 下一步：完善 `proposal.md`，然后运行 `llman-sdd-propose` 正式化
-> 📎 本技能创建**草案** change（仅 proposal.md）。完整提案走 Git-native：tasks → Branch binding → Specs landing（见 propose 的生命周期图）
-> 🗺️ Skill 导航 ≠ Git-native 生命周期；Branch binding / Specs landing 不是独立 skill
+> 📍 草案阶段 → 下一步：完善 `proposal.md`，然后 `llman-sdd-propose` 正式化。
 
 ## 硬约束
 
-- **MUST NOT 询问用户 change id**：由 `change new --from` 从描述推导并告知用户。
-- **MUST NOT 创建 tasks/design/specs/attach**：本技能仅创建 `proposal.md` 草案壳。完整规划工件属于 `llman-sdd-propose`。
-- **MUST NOT 做 triage 或判断变更规模**：那是 propose 的职责。若用户想开始实现，建议 `llman-sdd-propose`。
-- **适用边界**：若描述明显涉及 MUST/SHALL 行为合约变更或多文件改动，建议用 `llman-sdd-propose` 而非停在草案——但仍先建草案壳以免想法丢失。
-- **frontmatter 有固定 schema**：充实 `proposal.md` 时只接受 `llmanspec/AGENTS.md`「Change Proposal Frontmatter SSOT」中的合法字段（含 `depends_on`、`blocks`、`branch`、`base_sha`、`needs_specs_change`）。`status`/`title`/`priority`/`author` 等会被 `llman-sdd validate` 报 ERROR 拒绝。生命周期阶段是推断量——用 `llman-sdd show`/`list` 查看，绝不写进 frontmatter。正文 MUST NOT 复读 frontmatter 字段（不要 `## Status` 段）；正文 H1 用人类可读标题，不要复读 change id。
+- **MUST NOT 询问 change id**：由 `change new --from` 从描述推导并告知用户。
+- **MUST NOT 创建 tasks/design/specs/attach**：只建 `proposal.md` 草案；完整规划归 `llman-sdd-propose`。
+- **MUST NOT 判断变更规模**：那是 propose 的职责。用户想开始实现 → 建议 `llman-sdd-propose`。
+- **适用边界**：描述明显涉及 MUST/SHALL 合约变更或多文件改动时，建议 `llman-sdd-propose`——但仍先建草案以免想法丢失。
+- **frontmatter 有固定 schema**：`proposal.md` 只接受 `llmanspec/AGENTS.md`「Change Proposal Frontmatter SSOT」的合法字段（`depends_on`、`blocks`、`branch`、`base_sha`、`needs_specs_change` 等）；`status`/`title`/`priority`/`author` 会被 `llman-sdd validate` 报 ERROR。生命周期阶段是推断量（用 `llman-sdd show`/`list` 查），绝不写进 frontmatter。正文 MUST NOT 复读 frontmatter 字段（不要 `## Status` 段）；H1 用人类可读标题，不复读 change id。
 
 ## 步骤
 
 ### 0) Preflight
-- 读取 `llmanspec/config.yaml` 了解项目上下文、规则、locale。
-- 必须存在 `llmanspec/`；若不存在，提示先运行 `llman-sdd init`，然后 STOP。
+- 读 `llmanspec/config.yaml`；`llmanspec/` 不存在则提示先跑 `llman-sdd init`，然后 STOP。
 
 ### 1) 捕获描述
-- 直接采用用户的描述（如「draft: 加一个导出 json 的命令」「记一下: sdd change 应该支持 worktree」）。
-- **MUST NOT 询问 change id。** 由描述推导。
+- 直接采用用户描述（如「draft: 加一个导出 json 的命令」「记一下: sdd change 应该支持 worktree」）。**MUST NOT 询问 change id。**
 
-### 2) 创建草案壳
+### 2) 创建草案
 ```bash
 llman-sdd change new --from "<用户描述>"
 ```
-- CLI 会生成合法的 kebab-case id（清洗 + 校验），在 `llmanspec/changes/<生成的 id>/` 下创建 `proposal.md`（含 `## Why` / `## What Changes` TODO 段的 skeleton），并打印最终 id 与路径。
-- 若生成的 id 与既有 change 冲突，CLI 以非零退出码失败；建议改写描述或用 `--force` 覆盖（对草案很罕见）。
+- CLI 生成合法 kebab-case id，在 `llmanspec/changes/<id>/` 建 `proposal.md`（含 `## Why` / `## What Changes` TODO 段），并打印 id 与路径。
+- id 冲突时 CLI 非零退出；建议改写描述或 `--force` 覆盖（草案罕见）。
 
 ### 3) 告知并交接
-- **MUST 告知用户已生成的 id**（例如「已创建草案 change `<id>`，路径 `llmanspec/changes/<id>/proposal.md`」）。
-- 建议下一步：
-  - 现在或稍后完善 `proposal.md`（Why / What Changes / Capabilities / Impact）。
-  - 准备好落实时，运行 `llman-sdd-propose` 正式化（triage + tasks → `change start`/`attach` → Specs landing）。
+- **MUST 告知生成的 id**（「已创建草案 change `<id>`，路径 `llmanspec/changes/<id>/proposal.md`」）。
+- 建议下一步：完善 `proposal.md`（Why / What Changes / Capabilities / Impact）；落实时跑 `llman-sdd-propose`。
 
-> 💡 草案已记 → 下一步：编辑 `proposal.md`，然后 `llman-sdd-propose` 正式化。
-
-> 命令细节用 `llman-sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
-> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman-sdd list --specs` / `llman-sdd show <capability>` 查全文。
+{{ unit("skills/cli-footer") }}
 
 {{ unit("skills/ethics-governance") }}