@fxri/toolkit 1.12.2 → 1.12.4

package/skills/fxri-plan-to-task/references/conventions-spec.md

@@ -1,6 +1,6 @@
 # 规范载体规范（conventions）
 
-> 面向多人 + AI 协作，任何语言项目可直接使用，仅依赖文件读写能力。本文件为 SKILL.md 的配套规范，定义 `.tasks/conventions/` 的目录结构、归属分类、读写判定、内容修订与存量迁移；任务文件本身的规范见 `task-spec.md`。
+> 面向多人 + AI 协作，任何语言项目可直接使用，仅依赖文件读写能力。本文件为 SKILL.md 的配套规范，定义 `.tasks/conventions/` 的目录结构、归属分类、读写判定与内容修订；存量迁移见 `conventions-migration.md`，文风与模板见 `conventions-templates.md`；任务文件本身的规范见 `task-spec.md`。
 
 ## 1. 载体结构
 
@@ -91,14 +91,14 @@
 
 - **列集合固定为五列**：`ID | 规则 | 当前语义 | 归属 | 单一事实源`，列名与次序均不得增减或调换——列集合即读接口，漂移会破坏机械读写；`toolkit tasks check` / `toolkit conventions status` 检出列集合偏离（列名 / 次序 / 列数不符）并软告警（只报不改，须人工确认后按本规范归一）
 - **ID**：`C-<n>`（`C` 表 conventions），**去补零、不带端前缀、只追加不重排不回收**；插入或重排不漂移，废弃条目不回收其 ID（容量不是问题，去补零取的是可读性）
-- **引用**：载体内部引用一律行内代码包裹（如 `` `C-17` ``），便于机械匹配；v1 遗留的裸「第 N 条」在升级时改写（见 §10.2）
+- **引用**：载体内部引用一律行内代码包裹（如 `` `C-17` ``），便于机械匹配；v1 遗留的裸「第 N 条」在升级时改写（见 `conventions-migration.md` §10.2）
 - **归属**：取值必须对应一个实际承接处——`common`、端清单中的端名、或载体目录下存在的分类标签分册名，否则为悬空指针（需修正）
 - **单一事实源**：条文正文去哪看。已指向项目现有规则层（AGENTS / 全局规则 / skills）时填指向；条文就在本载体分册内时填分册名（如 `common.md`）
 - **不含「状态」「确立来源任务」两列**（区别于 v2）：Z1 只收录活跃条目，故「状态」恒为活跃、不必占列；「确立来源任务」属留痕信息、交 git 历史承载，退休条目则记于 `retired.md`
 
 ### 2.3 用法说明
 
-写明本项目采用哪种形态、读写判定要点、以及规则层源头变更时的同步纪律。骨架与写法见 §13（T2）；通用部分收敛为一句并指向本规范，不逐条复述规则正文。
+写明本项目采用哪种形态、读写判定要点、以及规则层源头变更时的同步纪律。骨架与写法见 `conventions-templates.md`（T2）；通用部分收敛为一句并指向本规范，不逐条复述规则正文。
 
 ## 3. 分册与留痕文件
 
@@ -114,7 +114,7 @@
 （条文全文）
 ```
 
-端分册同构，首部 `# {端名} 规范`、`> 归属：{端名}`；分类标签分册同构，首部 `# {标签} 规范`。小节标题用稳定 ID（`## C-<n>. {规则名}`），与 `index.md` 索引一致，便于互引。条文正文的子项与次序见 §13（T4）；分册内不写「确立来源」行——来源已由 `index.md` 索引列与 `history.md` 承载（见 §13）。
+端分册同构，首部 `# {端名} 规范`、`> 归属：{端名}`；分类标签分册同构，首部 `# {标签} 规范`。小节标题用稳定 ID（`## C-<n>. {规则名}`），与 `index.md` 索引一致，便于互引。条文正文的子项与次序见 `conventions-templates.md`（T4）；分册内不写「确立来源」行——来源已由 `index.md` 索引列与 `history.md` 承载（见 `conventions-templates.md`）。
 
 ### 3.2 history.md 结构
 
@@ -131,7 +131,7 @@
 ```
 
 - **首列记为行内代码包裹的裸 ID `C-<n>`，不写规则名**（规范名以 `index.md` 索引表为准；规则改名等沿革信息作前置括注记入「修订内容」列，如「（原名「X」）」）。此为硬性要求：`toolkit tasks check` 与 `toolkit conventions status` 检出非 ID 首列并软告警（只报不改——历史行只追加不改旧行的元规则下，补齐须人工确认）
-- **「修订内容」列只记该条自身语义**：新立条目直接写其语义；语义变更写「旧语义」→「新语义」（箭头两侧文本加全角引号）。两条禁令——不得写自指套话（如「（本次起入表）」「新立条目：」，表内每行本就是入表记录、自指零信息量）；不得复述 `index.md` 索引列信息（如「；条文全文落 `common.md`」与索引「单一事实源」列重复，违反 §1.1 不变量 I4）。规范名沿革作前置括注（如「（原名「增量判别」）」）。**措辞归一例外**：属 §9 同类的措辞层归一、非语义变更，可原地改写旧行、不入 `history.md` 留痕行。`toolkit tasks check` / `toolkit conventions status` 检出禁用语料并软告警（只报不改，改写须人工确认）
+- **「修订内容」列只记该条自身语义**：新立条目直接写其语义；语义变更写「旧语义」→「新语义」（箭头两侧文本加全角引号）。两条禁令——不得写自指套话（如「（本次起入表）」「新立条目：」，表内每行本就是入表记录、自指零信息量）；不得复述 `index.md` 索引列信息（如「；条文全文落 `common.md`」与索引「单一事实源」列重复，违反 §1.1 不变量 I4）。规范名沿革作前置括注（如「（原名「增量判别」）」）。**措辞归一例外**：措辞层归一（表格形态归一见 §9，规范词归一见 `conventions-templates.md` T5）属非语义变更，可原地改写旧行、不入 `history.md` 留痕行。`toolkit tasks check` / `toolkit conventions status` 检出禁用语料并软告警（只报不改，改写须人工确认）
 - **表头固定**：须恰为 `ID | 修订内容 | 修订来源任务` 三列，逐格一致（含列名与次序）；`toolkit tasks check` / `toolkit conventions status` 检出表头偏离并软告警
 - **表语义边界写死**：载体结构升级（如 v1 / v2 → v3）、入口壳生成 / 删除、条目退休都不入表——表只记**规范语义**变更
 
@@ -216,65 +216,11 @@
 
 ## 10. 存量迁移
 
-### 10.1 旧单文件 → 目录形态（v0 → v1）
-
-触发：`toolkit tasks check` 报旧 `conventions.md` 存在；或用户直接要求迁移。
-
-**三段式**（可中断，中途停下不丢内容）：
-
-1. **机器搬骨架**：建 `conventions/`，旧文件**整体**搬为 `index.md`（原文一字不丢），删除旧文件——此刻 `index.md` 是原文快照，功能上与旧文件等价
-2. **AI 提归属建议**：读原有条目，逐条给出「`common` / 某端」建议与理由（旧文件无端信息，语义分流无法机械完成），形成待确认清单
-3. **用户逐条确认**：确认后写索引行 + 把条文全文拆入对应分册；**未确认的条目保持原样留在 `index.md`**，不强推
-
-补充要求：
-
-- 迁移与内容重排分开做：先完成形态迁移（结构到位），再谈条目归属调整，避免一次变更混合两种风险
-- 端清单在迁移时同步建立：从项目已有 `scope` 取值与实际子项目构成归纳，经用户确认写入端清单节
-- 旧文件已不存在时不重复迁移
-
-### 10.2 v1 → v2 结构升级
-
-触发：`toolkit conventions status` 报「需升级」；`toolkit tasks check` 报形态告警（标为 v2 缺 `history.md` 或索引表首列非 `ID`；有 `history.md` 但首列仍是 `#`）；或用户直接要求升级。
-
-优先用 `toolkit conventions upgrade`（纯机械，可 `--dry-run` 预演），动作序：
-
-1. **发 ID**：按现有条序 `1..n` 发 `C-1..C-n`，索引表首列由 `#` 改 `ID`
-2. **切 `history.md`**：原 `index.md`「演进记录」节整表平移为独立 `history.md`（表头首格归一为 `ID`），`index.md` 撤该节；标题归一 `# 项目协作规范索引`，首行补形态标记（版本段写 `v2`）
-3. **改内部引用**：裸「第 N 条」（仅 N ≤ 索引表最大序号者）改写为 `` `C-<n>` ``；带外部文档限定词前缀的引用（如 `AGENTS.md` 质量门第 5 条、`SPEC.md` 协作模型第 3 条、`task-spec.md` 第 6 节）一律不动；改写清单进报告
-4. **分册小节归一**：分册小节标题改 `## C-<n>. {规则名}`
-
-补充要求：
-
-- **ID 映射不落盘**：映射由 `upgrade` 输出（实跑与 `--dry-run` 均打印）；真值可由 git 历史复现（迁移提交的父提交即 v1 原件），故不落盘代价近零
-- **先判后写**：遇形态异常（标记与结构不一致）拒绝执行并给非 0 退出码，**不写任何文件**，提示人工确认
-- `upgrade` 幂等：已是 v2（或更高）时原样返回，不做二次改写
-- **手工迁 v2 与工具升级的落点不同**：手工迁移按本节在首行写版本段为 `v2` 的形态标记、停在 v2；用 `toolkit conventions upgrade` 升级则不落 v2——工具从 v1 输入链式直达 v3（`v1 → v2 → v3`，见 §10.3），仅手工路径停在 v2
-- 手动迁移时按同一动作序执行
-
-### 10.3 v2 → v3 结构升级
-
-触发：`toolkit conventions status` 报「需升级」；`toolkit tasks check` 报形态告警（标为 v3 缺 `history.md` 或索引表首列非 `ID`；有 `history.md` 但首列仍是 `#`）；或用户直接要求升级。
-
-优先用 `toolkit conventions upgrade`（纯机械，可 `--dry-run` 预演；v1 输入将链式升级 v1 → v2 → v3），动作序：
-
-1. **索引表删两列**：删「状态」「确立来源任务」两列
-2. **`history.md` 表头归一**：v2 存量 `history.md` 沿用「规则 ID / 名称」旧表头，首格归一为稳定 ID `ID`（与索引表首列同归一）
-3. **退休条目迁出**：把原状态为 `已废弃` 的行迁入 `retired.md`（首部补 `# 规范退休记录`、元规则与 7 列表头），并从 Z1 索引表删除；同步删除 Z2 分册内对应小节（三层清理的索引 + 分册两层）
-4. **`retired.md` 按需建**：无退休条目则不创建该文件
-5. **来源 / ID 补录报告**：`history.md` 中 ID 列仍用规则名者、来源列含多任务者，输出人工复核报告——**不做全自动改写**（历史行只追加不改旧的元规则下，改写须人工确认）
-6. **用法说明 / 写入纪律复核**：`index.md` 表外的自由文本（用法说明、写入纪律）若仍残留 v2 措辞（如「填『确立来源任务』」「把『状态』改为『已废弃』」），输出人工复核报告——升级只机械归一索引表列结构，不改写描述该表的自由文本
-7. **标记升 v3**：`index.md` 首行改为 `<!-- toolkit-conventions: v3 -->`
-
-补充要求：
-
-- **先判后写**：遇形态异常（标记与结构不一致）拒绝执行并给非 0 退出码，**不写任何文件**，提示人工确认
-- **dry-run 迁移报告**：`--dry-run` 打印将删的列、将迁出的条目与将删的分册小节、待人工复核项，供人工确认后再实跑
-- `upgrade` 幂等：已是 v3 时原样返回，不做二次改写
-- 手动迁移时按同一动作序执行
+见 `conventions-migration.md`（10.1 旧单文件 → 目录形态、10.2 v1 → v2、10.3 v2 → v3）。仅在迁移存量载体或处置形态告警时加载。
 
 ## 11. 兼容读（迁移期）
 
-读取时先找 `conventions/index.md`；不存在再看旧单文件 `conventions.md`，存在则按旧单文件内容读取并**在对话中提示可迁移**。两者并存时以目录形态为准，并提示旧文件待清理。v1 / v2 / v3 都按目录形态正常读取，形态判据见 §10.3（`index.md` 首行标记：无标记为 v1，`v2` 且含 `history.md` 与首列 `ID` 为 v2，`v3` 且含 `history.md` 与首列 `ID` 为 v3）。
+读取时先找 `conventions/index.md`；不存在再看旧单文件 `conventions.md`，存在则按旧单文件内容读取并**在对话中提示可迁移**。两者并存时以目录形态为准，并提示旧文件待清理。v1 / v2 / v3 都按目录形态正常读取，形态判据见 `conventions-migration.md` §10.3（`index.md` 首行标记：无标记为 v1，`v2` 且含 `history.md` 与首列 `ID` 为 v2，`v3` 且含 `history.md` 与首列 `ID` 为 v3）。
 
 ## 12. 自查清单
 
@@ -296,84 +242,8 @@
 - [ ] 有入口壳时其标记与当前 toolkit 一致（落后或无标记可重跑 `toolkit init` 就地更新）、且未被 `.gitignore` 覆盖（否则 `check` / `conventions status` 告警）
 - [ ] 载体与任务区表格为紧凑形态（无列对齐填充、无按列宽补长的分隔行横线；`toolkit conventions format` 可归一，`check` / `conventions status` 会检出）
 - [ ] 规范写入均经用户确认，来源可溯：活跃条目记于写入任务文件正文，退休条目记入 `retired.md` 的「退休来源任务」列
-- [ ] 分册内无「确立来源」行（来源由 `index.md` 索引列与 `history.md` / `retired.md` 承载；`toolkit tasks check` / `toolkit conventions status` 检出并软告警，见 §13）
+- [ ] 分册内无「确立来源」行（来源由 `index.md` 索引列与 `history.md` / `retired.md` 承载；`toolkit tasks check` / `toolkit conventions status` 检出并软告警，见 `conventions-templates.md`）
 
 ## 13. 载体文风与模板
 
-§1–§3 规定结构层，本节规定**文风与模板层**。多个仓库的载体在结构上早已一致，分歧集中在头注、用法说明骨架、引用写法、条文格式、规范词与标点这些原先未规定的层面；以下 T1–T6 为**唯一形态**，新载体照此起步、存量载体照此归一，偏离由 `toolkit conventions status` / `toolkit tasks check` 按可机械判定者软告警（只报不改，交人工确认）。
-
-### T1 index 头注固定两行
-
-`index.md` 首行形态标记之后、端清单之前，头注**恰为两行**，各一句 blockquote：
-
-```markdown
-<!-- toolkit-conventions: v3 -->
-# 项目协作规范索引
-
-> 本文件为规范载体唯一入口与唯一权威；规范全貌见下方索引，条文见各分册。
-> 读面纪律：`history.md` / `retired.md` 属归档面，仅在审计 / 恢复时读，不在常规读面。
-```
-
-- 第 1 行说明载体定位（唯一入口 + 条文去向），第 2 行说明归档面读面纪律
-- 头注只承载「读什么、去哪读」；检测面细则、维护步骤、指向 spec 等**不进头注**——它们是写作者须知、非每次建档必读，进了常驻面即违反 §1.1 元原则
-
-### T2 用法说明固定骨架
-
-`index.md`「用法说明」节固定三段，段名与次序为 载体形态 → 本项目约定（可选）→ 读写与维护；通用部分收敛为一句 + 指向本规范，不逐条复述规则正文：
-
-```markdown
-- **载体形态**：本项目采用「溯源索引式」（条文在外部规则层，本载体只索引）/「条文式」（条文在本载体分册）。
-- **本项目约定**：（可选，如 `scope` 分类标签、分册命名等本仓特例；无则整段省略）
-- **读写与维护**：读面与读写判定、写入归属、语义修订与退休流程一律见 `skills/<技能名>/references/conventions-spec.md`，本载体不另述。
-```
-
-- 「载体形态」取值即 §7 两种形态（可混用，需逐条说明时在括号内补述）
-- 「读写与维护」指向 spec，不在此复述 §5 / §6 / §8 的规则正文
-
-### T3 「单一事实源」列写法二分
-
-索引表「单一事实源」列的写法按指向目标二分：
-
-- **载体内分册**（条文就在本载体）→ 相对链接：`[common.md](./common.md)`、`[web.md](./web.md)`
-- **载体外文件**（条文在项目规则层）→ 行内代码：`docs/ai-rules.md`、`AGENTS.md`、`skills/<技能名>/references/task-spec.md`
-- 同格需补充说明时，链接 / 代码之后接短述（如 `skills/<技能名>/references/task-spec.md（口径随版本走）`）
-
-理由：两类指向的可点击性不同——载体内相对链接点击即达；载体外路径跨仓后不可靠，故不作链接、只作行内代码指路。
-
-### T4 分册条文模板
-
-分册内每条条文固定为 小节标题 + 一句当前语义 + 四类子项，**子项次序固定为 要求 → 反例 → 理由 → 配套**：
-
-```markdown
-## C-<n>. {规则名}
-
-{一句当前语义}。
-
-- **要求**：{须做什么 / 不得做什么}。
-- **反例**：{常见的错误做法}。
-- **理由**：{为什么这样规定}。
-- **配套**：{与索引 `C-<n>`、外部载体等的联动关系；无则省略本子项}。
-```
-
-- 子项名与次序固定；`配套` 无内容时整条省略
-- 子项以 `- **{名}**：` 起头（全角冒号），内容用规范词（见 T5）
-- **分册内不得写「确立来源」子项**：来源已由 `index.md` 索引行（活跃条目）与 `history.md` / `retired.md`（留痕与退休）承载，分册内重复即违反 §1.1 不变量 I4；`toolkit conventions status` / `toolkit tasks check` 对残留行软告警（跳过 fenced code block）
-
-### T5 规范词分级
-
-条文正文用统一强弱词，对标 RFC 2119 的 MUST / SHOULD / MAY：
-
-| 词 | 强度 | 含义 |
-| --- | --- | --- |
-| `须` | 强制 | 必须遵守，违反即偏离 |
-| `应` | 推荐 | 通常遵守，例外须有理由 |
-| `可` | 可选 | 允许但不强制 |
-| `不得` | 禁止 | 必须避免 |
-
-同一强度不混用多种措辞——不用「必须」「应该」「不可以」「禁止」等近义词替代上表四词。
-
-### T6 标点与代码
-
-- 标识符、文件路径、文件名、命令、配置项、规则 ID 一律用**行内代码**包裹（如 `C-17`、`index.md`、`toolkit conventions status`、`scope`）
-- 中文引述、术语、举例名用全角直角引号「」，不用英文引号或书名号
-- 中英文混排的空格处理随仓库既有排版习惯，不作硬性要求
+见 `conventions-templates.md`（T1 索引头注、T2 用法说明骨架、T3 单一事实源列、T4 分册条文、T5 规范词、T6 标点与代码）。新建载体、归一存量文风或处置文风偏离告警时加载。

package/skills/fxri-plan-to-task/references/conventions-templates.md

@@ -0,0 +1,83 @@
+# 规范载体文风与模板
+
+> 本文件为 `conventions-spec.md` 的配套规范，承载载体的文风与模板层（T1–T6）。新建载体、归一存量载体文风，或按机械判定处置文风偏离时加载；结构层见 `conventions-spec.md` §1–§3。
+
+多个仓库的载体在结构上早已一致，分歧集中在头注、用法说明骨架、引用写法、条文格式、规范词与标点这些原先未规定的层面；以下 T1–T6 为**唯一形态**，新载体照此起步、存量载体照此归一，偏离由 `toolkit conventions status` / `toolkit tasks check` 按可机械判定者软告警（只报不改，交人工确认）。
+
+## T1 index 头注固定两行
+
+`index.md` 首行形态标记之后、端清单之前，头注**恰为两行**，各一句 blockquote：
+
+```markdown
+<!-- toolkit-conventions: v3 -->
+# 项目协作规范索引
+
+> 本文件为规范载体唯一入口与唯一权威；规范全貌见下方索引，条文见各分册。
+> 读面纪律：`history.md` / `retired.md` 属归档面，仅在审计 / 恢复时读，不在常规读面。
+```
+
+- 第 1 行说明载体定位（唯一入口 + 条文去向），第 2 行说明归档面读面纪律
+- 头注只承载「读什么、去哪读」；检测面细则、维护步骤、指向 spec 等**不进头注**——它们是写作者须知、非每次建档必读，进了常驻面即违反 `conventions-spec.md` §1.1 元原则
+
+## T2 用法说明固定骨架
+
+`index.md`「用法说明」节固定三段，段名与次序为 载体形态 → 本项目约定（可选）→ 读写与维护；通用部分收敛为一句 + 指向本规范，不逐条复述规则正文：
+
+```markdown
+- **载体形态**：本项目采用「溯源索引式」（条文在外部规则层，本载体只索引）/「条文式」（条文在本载体分册）。
+- **本项目约定**：（可选，如 `scope` 分类标签、分册命名等本仓特例；无则整段省略）
+- **读写与维护**：读面与读写判定、写入归属、语义修订与退休流程一律见 `skills/<技能名>/references/conventions-spec.md`，本载体不另述。
+```
+
+- 「载体形态」取值即 `conventions-spec.md` §7 两种形态（可混用，需逐条说明时在括号内补述）
+- 「读写与维护」指向 spec，不在此复述 §5 / §6 / §8 的规则正文
+
+## T3 「单一事实源」列写法二分
+
+索引表「单一事实源」列的写法按指向目标二分：
+
+- **载体内分册**（条文就在本载体）→ 相对链接：`[common.md](./common.md)`、`[web.md](./web.md)`
+- **载体外文件**（条文在项目规则层）→ 行内代码：`docs/ai-rules.md`、`AGENTS.md`、`skills/<技能名>/references/task-spec.md`
+- 同格需补充说明时，链接 / 代码之后接短述（如 `skills/<技能名>/references/task-spec.md（口径随版本走）`）
+
+理由：两类指向的可点击性不同——载体内相对链接点击即达；载体外路径跨仓后不可靠，故不作链接、只作行内代码指路。
+
+## T4 分册条文模板
+
+分册内每条条文固定为 小节标题 + 一句当前语义 + 四类子项，**子项次序固定为 要求 → 反例 → 理由 → 配套**：
+
+```markdown
+## C-<n>. {规则名}
+
+{一句当前语义}。
+
+- **要求**：{须做什么 / 不得做什么}。
+- **反例**：{常见的错误做法}。
+- **理由**：{为什么这样规定}。
+- **配套**：{与索引 `C-<n>`、外部载体等的联动关系；无则省略本子项}。
+```
+
+- 子项名与次序固定；`配套` 无内容时整条省略
+- 子项以 `- **{名}**：` 起头（全角冒号），内容用规范词（见 T5）
+- **分册内不得写「确立来源」子项**：来源已由 `index.md` 索引行（活跃条目）与 `history.md` / `retired.md`（留痕与退休）承载，分册内重复即违反 `conventions-spec.md` §1.1 不变量 I4；`toolkit conventions status` / `toolkit tasks check` 对残留行软告警（跳过 fenced code block）
+
+## T5 规范词分级
+
+条文正文用统一强弱词，对标 RFC 2119 的 MUST / SHOULD / MAY：
+
+| 词 | 强度 | 含义 |
+| --- | --- | --- |
+| `须` | 强制 | 必须遵守，违反即偏离 |
+| `应` | 推荐 | 通常遵守，例外须有理由 |
+| `可` | 可选 | 允许但不强制 |
+| `不得` | 禁止 | 必须避免 |
+
+同一强度不混用多种措辞——不用「必须」「应该」「不可以」「禁止」等近义词替代上表四词。
+
+适用范围：条文正文、`index.md` 索引行与 `history.md`「修订内容」列。`history.md` 的规范词归一属措辞层（非语义变更），按 `conventions-spec.md` §3.2 措辞归一例外原地改写、不新增留痕行；引号内引述的外部文档原文不改。
+
+## T6 标点与代码
+
+- 标识符、文件路径、文件名、命令、配置项、规则 ID 一律用**行内代码**包裹（如 `C-17`、`index.md`、`toolkit conventions status`、`scope`）
+- 中文引述、术语、举例名用全角直角引号「」，不用英文引号或书名号
+- 中英文混排的空格处理随仓库既有排版习惯，不作硬性要求

package/skills/fxri-plan-to-task/references/task-spec.md

@@ -21,7 +21,7 @@
 
 目录名 `.tasks` 为默认约定，项目可自定（如集中式任务库按项目分子目录），内部子结构不变。
 
-`index.md` 首行为形态标记（`<!-- toolkit-conventions: v3 -->`），索引表首列是稳定 ID（`C-<n>`）；无标记的 v1、标记为 `v2` 的旧形态仍合法、`check` 不告警，可用 `toolkit conventions upgrade` 升级。载体结构、端名规则、分层读写判定与存量迁移见 `conventions-spec.md`。
+`index.md` 首行为形态标记（`<!-- toolkit-conventions: v3 -->`），索引表首列是稳定 ID（`C-<n>`）；无标记的 v1、标记为 `v2` 的旧形态仍合法、`check` 不告警，可用 `toolkit conventions upgrade` 升级。载体结构、端名规则与分层读写判定见 `conventions-spec.md`；存量迁移、文风与模板见同目录 `conventions-migration.md` / `conventions-templates.md`。
 
 `conventions/` 不是任务文件：tasks 各子命令不读其内容，check 不会因内容告警（仅在载体形态异常与入口层现场异常时软告警，口径见 `conventions-spec.md`）；它只作为 AI 协作时的规范源，由 fxri-plan-to-task 归档时与 fxri-session-recap 收尾时维护（写入前需用户确认）。
 
@@ -103,11 +103,16 @@ scope: app            # 影响范围；只标本仓内的端 / 面（跨仓库
 ## 6. 协作约定
 
 - 任务区是多写者共享区：先查后写，同一需求共用一个任务文件；建档与执行时遵守 conventions 载体（`.tasks/conventions/index.md`，存在时）中的项目规范，旧单文件 `conventions.md` 亦兼容读取
-- **多人同天归档冲突**：归档文件按完成日期聚合、整文件重写，两个写者落在同一日必冲突；`pull` 后残留 git 冲突标记时跑 `toolkit tasks normalize --fix` 按并集去重 + 完成时间降序**确定性**解决（保留两侧任务块、丢弃 diff3 的 `\|\|\|\|\|\|\|` base 段与全部标记行），无需人工逐块合并
+- **多人同天归档冲突**：归档文件按完成日期聚合、整文件重写，两个写者落在同一日必冲突；`pull` 后残留冲突标记的处置见 §4（可跑 `toolkit tasks normalize --fix` 确定性解决，无需人工逐块合并）
 - **动手前置建档评估**：涉及仓库文件改动的任务，动手前先查 active/archive 判同主题（完整判别表见 SKILL.md 工作流第 1 步）；active 有同主题则更新原文件；archive 有同主题且本次不产生仓库文件改动（重复提议 / 重复执行）则不重复建档，本次产生仓库文件改动（延续 / 扩展 / 重新实现）则重新建档并标注来源链
 - **仓库文件改动口径**：需写入版本控制的工作区文件的增 / 改 / 删（源码、配置、文档、技能、任务区自身均计入）；纯读取、纯执行、纯汇报不计入；拿不准时列出差异问用户，不猜
 - **动作不算，改动才算**：收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不构成任务、不单独建档；这些动作过程中若出现需改仓库文件才能解决的缺陷（如打包配置错误、发布渠道错误），该修复按普通任务建档
-- **跨仓库改动各自归档（本仓自述）**：任务档是仓库自述，只记本仓的改动与动机；跨仓库是会话属性而非仓库属性，同一会话涉及多仓时各仓各自建档归档，不在一仓记录里承载另一仓的工作痕迹。判据取**视角**（描述的是不是本仓的改动与动机），非词表——依赖包名 / 被调接口名等属本仓事实者照写
+- **跨仓库改动各自归档（本仓自述）**：任务档是仓库自述，只记本仓的改动与动机；跨仓库是会话属性而非仓库属性，同一会话涉及多仓时各仓各自建档归档，不在一仓记录里承载另一仓的工作痕迹。判据取**视角**（描述的是不是本仓的改动与动机），非词表——依赖包名 / 被调接口名等本仓事实者照写
+- **任务粒度（按序判定）**：一个任务 = 可独立验收、可独立回滚、单独提交后仓库自洽的最小交付单元，且不跨仓库。判定顺序：① 跨仓库必拆——一个任务只属于一个仓库；② 拆出的中间态仓库验收不过则合并回去；③ 写不出一句独立的验收结论则合并；④ 单独回滚会破坏其他交付则合并。常见反例：按文件拆、按步骤拆（编码 / 测试 / 文档各建一档）、把文档 + 技能 + 变更集从代码任务里拆出、按人拆、把重构与依赖它的功能随意拆开。任务数通常不超过 7，超过多半是把步骤当成了任务
+- **触发建档的改动不含任务区自身**：建档评估与「本次是否产生仓库文件改动」的判别中，`.tasks/` 下的读写不单独构成建档理由（否则建档本身即为改动，形成自证循环）；archive 同主题判别仍按上一条「任务区自身均计入」的完整口径
+- **纯展示开发计划表**：方案确认后、建档前，若涉及两个及以上任务，先在对话中给出唯一一张顺序表，列为「序号 | 仓库 | 任务 | 前置」——跨端、跨仓同表，按执行先后排列；表只作展示与排序，不落档、不写入任务正文、不设状态列（状态以任务 frontmatter 为唯一真源）。单任务方案不出表；计划调整时先更新该表再继续
+- **逐任务交付**：按计划表顺序推进，前置未完成或阻塞未解除时下游不开工；每个任务完成即走完该仓库的「归档 → 验收 → 提交」，不跨任务攒批。一个任务至少一次提交、允许多次；不得把多个任务攒成一个提交，也不得为凑一次提交塞入无关改动
+- **任务正文保留顺序线索**：批次 / 计划位置 / 前置任务写在正文，用于回顾与中断恢复；串行先后只进展示表与正文，不写 `depends_on`（`depends_on` 只用于仍 active 的并行依赖，指向已归档任务会被 check 告警）
 - **归档块不可变**：已归档块是终结记录（唯一键 + 完成时间已固定），不追加新的工作内容；延续 / 扩展需求走新任务并标注来源链。唯一例外是**事实更正**——后续核实推翻原块结论、或协作口径变更导致历史事实字段需更正时，在其正文末尾追加「修订记录」（保留原结论、附更正时刻与依据）；口径变更类更正可改受影响的**事实字段**（如 `scope`），但唯一键 / 完成时间 / 状态 / 负责人仍冻结。与 conventions 载体「废弃不删行」同属留痕优于抹除
 - **验收与 CI 同源，不手写清单**：项目的验收步骤清单只允许一份真源——一条聚合命令（如 `pnpm verify`）背后由脚本定义步骤，本地与全部 CI 流水线共用它；禁止在规则文件、CI 配置里另抄一份步骤枚举。多份手写清单必然漂移，征兆就是「本地自检通过、CI 才报错」，出现该征兆先查清单是否已经漂移
 - 强制约束到**沉淀**为止：归档 + 规范沉淀即流程终点；提交、发版、推送不是必经步骤，是否执行取决于用户的全局 / 个人 / 项目规则；若提交代码，按「归档与沉淀 → 跑项目验收命令 → git commit」的顺序执行，任务记录（归档文件 + conventions 载体）与代码变更落在同一提交

package/skills/fxri-release-changelog/SKILL.md

@@ -1,74 +1,74 @@
----
-name: fxri-release-changelog
-description: 基于 changesets 的发版与多语言 CHANGELOG 维护流程：创建变更集、消费发版、把分组标题与条目转为项目语言风格、清理变更集、打标签发布；无 changesets 的项目提供同格式手工模式。当用户表达发版或记录变更意图——含创建变更集、changeset、发版、version、CHANGELOG 格式化等说法及其口语近义表达（如发一版、出个版本、记一下这次改动、生成更新日志）时使用。⚠️ 注意区分：用户说「提交个版本 / 先提交一版 / commit」通常指 git 提交当前改动（走任务收尾后提交），**不是发版**。不用于日常 commit message 撰写、git 提交操作或与发版无关的文档修改。
-license: MIT
-metadata:
-  version: "1.1.9"
-  author: fxri
-  source: https://github.com/fxri-net/toolkit
----
-
-# 发版与 CHANGELOG
-
-> 本技能版本 1.1.9（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
-
-## 何时使用
-
-- 记录变更（创建变更集）、消费变更集发版、格式化 CHANGELOG（语义触发，不要求字面一致）：changeset / 变更集 / 发版 / version / CHANGELOG 格式化 / 发一版 / 出个版本 / 记一下这次改动 / 生成更新日志
-- 触发前置条件：**用户明确表达发版或记录变更意图**。⚠️ **git 提交 ≠ 发版**：用户说「提交个版本 / 先提交一版 / 提交一下 / commit 这版」通常指把当前改动 git 提交（涉及任务时先走 fxri-plan-to-task / fxri-session-recap 收尾再提交），**不触发本技能**；纯日常对话出现「版本」字样也不触发
-- 拿不准用户意图时向用户确认，不猜
-
-**何时不使用**：日常 commit message 撰写、git 提交操作、与发版无关的文档修改。
-
-## 前置检查
-
-- ⚠️ 发版不是必经步骤：仅在用户明确要求，或用户全局 / 个人 / 项目规则约定时才进入本技能，不主动发版
-- ⚠️ **发版是收尾动作，不是任务**：本技能不为发版本身建档——发版的输入是「已归档的任务改动」，发版过程及其固有产物（版本号、更新日志、标签）不构成任务、不作为建档对象。例外：过程中暴露的、需改仓库文件才能修复的缺陷（打包配置错误、发布渠道错误、版本号冲突）→ 走 fxri-plan-to-task 先建档再改
-- `.tasks/active/` 存在未归档任务 → 先完成归档再发版（任务归档是发版的前置顺序）
-- **覆盖核对**：本次待发布的改动逐项确认已有归档记录；出现「有改动却无归档记录」→ 先补归档（fxri-session-recap 模式一）再发版
-- 项目根存在 `.changeset/` 目录 → 走「changesets 流程」
-- 不存在 → 走「手工模式」（规范见 `references/changelog-format.md`）
-
-## changesets 流程
-
-1. 记录变更：`npx changeset`（或项目包管理器等价脚本）——**变更描述一律逐条以 `- 类型：描述` 书写**：既要 `类型：` 前缀（如 `新增：` / `修复：` / `优化：`）作归类信号，也要 `- ` 列表标记把每条独立成项（缺标记的裸行会被 changesets 并入相邻条目作缩进续行，整段塌成单一条目、只有首行归组剥前缀）；并按改动的**能力量级**选影响级别（破坏性→major、全新大功能/独立新能力→minor、存量能力上的修补与增量→patch，完整对照见 `references/changelog-format.md`）。写完可跑 `toolkit tasks check` 早期自查：它扫 `.changeset/` 下待发布变更集，逐文件报出缺前缀条目与未加 `- ` 标记的裸行及条数（免得到发版、变更集源被消费删除后才由 changelog 侧兜底告警——那时已无从补写）
-2. 消费发版：`npx changeset version`——自动写版本号与 CHANGELOG
-3. 格式化：按 `references/changelog-format.md` 的语义分组规则归类条目、转换分组标题、润色为项目语言风格（中文示例：`### Patch Changes` 下的 `- 修复：xxx` → `### 🐛 问题修复` 下的 `- xxx`——归类后类型前缀被剥离，类型由分组标题承接）；分组维度与 bump 维度正交，条目归组只看类型前缀
-4. 归一：润色后跑一次 `toolkit changelog --history format`——人工润色（含补写历史块明细）容易在条目之间留空行，该命令按「同组顶层条目逐行相邻」重排历史块；项目另有更新日志镜像页（如 `docs/changelog.md`）时再跑一次同步脚本，否则镜像一致性校验会失败
-5. 清理：删除已消费的 `.changeset/*.md`
-6. 门禁：发布前跑一次项目的验收命令（如 `pnpm verify`）——**关卡设在发布前而非推送前**：发布到包仓库 / 制品库不可逆，推送失败重推即可，故必须拦在不可逆动作之前；任一步失败即中止发版，不进入提交、打标签、发布
-7. 发布：提交版本与 CHANGELOG 改动 → 打 `vX.Y.Z` 标签 → 按项目渠道发布（如 `npm publish`）
-
-⚠️ 自动生成的条目必须人工核对润色，与仓库既有 CHANGELOG 风格保持一致。
-
-## 手工模式（无 changesets 项目）
-
-版本号与 CHANGELOG 全部手工维护：版本标题、发布日期行、分组标题与条目格式见 `references/changelog-format.md`；多语言四段结构（语义分组 / 标题替换映射 / 依赖更新文案 / 发布日期后缀）同文件。
-
-## 失败模式
-
-| 症状 | 处置 |
-| --- | --- |
-| version 后 CHANGELOG 分组标题仍是英文 | 按 references 的映射表补一次格式化 |
-| CHANGELOG 出现「- - 条目」双前缀伪影（变更集条目以 `- ` 开头） | `toolkit changelog version/format` 已自动还原为顶层条目；手工模式按 references 规则手动清理 |
-| 条目与仓库既有风格不一致 | 人工润色为项目语言与句式，勿保留机器直译 |
-| 变更集遗漏（发版后才发现功能未记录） | 补建变更集随下次发版；本次在发布说明中人工补充 |
-| `toolkit tasks check` 报「变更集条目缺类型前缀」 | 打开所列文件，给缺前缀的**顶层条目**按「类型：描述」补前缀（缩进续行随父条目迁属、无需加）；补前缀只改分类信号，不改变 bump 级别 |
-| `toolkit tasks check` 报「变更集条目未加「- 」列表标记」 | 打开所列文件，把裸行逐条改为 `- 类型：描述`（列 0 起首、无 `- ` 标记的行会被 changesets 并入相邻条目作续行，整段塌成单一条目、只有首行归组剥前缀）；若已发版才发现，说明该版本块条目可能已挤在单组且前缀未剥离，按 references 的「人工事实更正」修 `CHANGELOG.md` 并重跑镜像页同步 |
-| 改动已发布却无归档记录（有提交、无任务档） | 先补归档（fxri-session-recap 模式一）再继续发布后续步骤；发版本身不补建档 |
-| 发版后历史块内出现多余空行（`自举一致性` 类零改动用例失败） | 跑 `toolkit changelog --history format` 归一（**必须带 `--history`**，默认模式不动历史块），再补跑一次镜像页同步脚本 |
-| 格式化时 stderr 报「归类后条目数由 N 降为 M，疑似丢失内容」 | 归类只应搬移条目，减少即疑似丢内容：核对该版本块是否含非纯条目分组（标题下先出现正文）或被保留分组；确认属正常去重可忽略，否则按 references 的归类规则修回 |
-| 一批改动含新增能力 / 参数，却整批按 `修复：` 前缀登记（整块落 `问题修复` 组）——常见于 bump 判定为 patch 时，误以为级别与条目前缀绑定 | 前缀按**变更本身性质**逐条定：新增命令 / 参数 / 产物用 `新增：`、缺陷纠正用 `修复：`。分组只看前缀、与 bump 正交，**patch 也可挂 `新增：`**——bump 按改动的能力量级判（存量能力上的小新增即 patch），口径见 references |
-
-## 可选加速（不构成依赖）
-
-⚠️ 工具探测顺序（先项目内、后全局）：先 `pnpm exec toolkit --help`（项目 devDependency，npm 项目等价 `npx toolkit`），失败再 `toolkit --help`（全局安装）；两者都不可用即工具未安装，按各步手工继续，**不安装、不阻塞**。探测成功后用对应前缀执行下列命令：
-
-- `toolkit changelog`：创建变更集（等价 changeset）
-- `toolkit changelog version`：发版并自动做中文分组标题格式化
-- `toolkit changelog format`：仅格式化既有 CHANGELOG
-- `toolkit changelog --history format`：连带追溯改写历史版本块（用户主动要求修正历史块时才加，默认不动）
-- `toolkit changelog --lang <语言> …`：切换输出语言（内置 zh / en，其余可配置扩展）
-- `toolkit tasks check`：扫 `.changeset/` 下待发布变更集并逐文件报出缺前缀条目与未加 `- ` 标记的裸行（流程第 1 步的早期自查入口，归档前的 `tasks check` 即含此项）
-- ⚠️ `changelog` 域开了选项透传，自有选项（`--lang` / `--history` / `--redact` / `--warn`）必须写在子命令**之前**：`toolkit changelog --history format` 生效，写成 `toolkit changelog format --history` 会被 changesets 静默忽略（表现为「无 CHANGELOG 需要更新」）
-- `toolkit skills install` / `toolkit skills status`：把本包 fxri-* 技能分发到目标技能目录（`--scope` 缺省按 CLI 安装位置自动判定全局面 / 项目面；项目面真源落 `<仓库根>/.agents/skills/`、其余候选目录落入口薄壳，随仓库入库后队友 clone 即用）/ 查看链接、副本与项目面现场（技能随包同源分发，与 CLI 同一发布批次；技能内容版本独立编号，`skills status` 会打印各技能真源版本）
+---
+name: fxri-release-changelog
+description: 基于 changesets 的发版与多语言 CHANGELOG 维护流程：创建变更集、消费发版、把分组标题与条目转为项目语言风格、清理变更集、打标签发布；无 changesets 的项目提供同格式手工模式。用户表达发版或记录变更意图时使用——含创建变更集、changeset、发版、version、CHANGELOG 格式化等说法及口语近义表达（发一版、出个版本、记一下这次改动、生成更新日志）。⚠️ 注意区分：用户说「提交个版本 / 先提交一版 / commit」通常指 git 提交当前改动（走任务收尾后提交），**不是发版**。不用于日常 commit message 撰写、git 提交操作或与发版无关的文档修改。
+license: MIT
+metadata:
+  version: "1.2.1"
+  author: fxri
+  source: https://github.com/fxri-net/toolkit
+---
+
+# 发版与 CHANGELOG
+
+> 本技能版本 1.2.1（随 @fxri/toolkit 同批分发）。被问版本时即报此值（不读磁盘、不跑 CLI）；与 `toolkit skills status` 的磁盘值不一致即说明会话上下文已过期，开新会话即可。
+
+## 何时使用
+
+- 记录变更（创建变更集）、消费变更集发版、格式化 CHANGELOG（语义触发，不要求字面一致；触发词见 frontmatter `description`）
+- 触发前置条件：**用户明确表达发版或记录变更意图**。⚠️ **git 提交 ≠ 发版**：用户说「提交个版本 / 先提交一版 / 提交一下 / commit 这版」通常指把当前改动 git 提交（涉及任务时先走 fxri-plan-to-task / fxri-session-recap 收尾再提交），**不触发本技能**；纯日常对话出现「版本」字样也不触发
+- 拿不准用户意图时向用户确认，不猜
+
+**何时不使用**：日常 commit message 撰写、git 提交操作、与发版无关的文档修改。
+
+## 前置检查
+
+- ⚠️ 发版不是必经步骤：仅在用户明确要求，或用户全局 / 个人 / 项目规则约定时才进入本技能，不主动发版
+- ⚠️ **发版是收尾动作，不是任务**：本技能不为发版本身建档——发版的输入是「已归档的任务改动」，发版过程及其固有产物（版本号、更新日志、标签）不构成任务、不作为建档对象。例外：过程中暴露的、需改仓库文件才能修复的缺陷（打包配置错误、发布渠道错误、版本号冲突）→ 走 fxri-plan-to-task 先建档再改
+- `.tasks/active/` 存在未归档任务 → 先完成归档再发版（任务归档是发版的前置顺序）
+- **覆盖核对**：本次待发布的改动逐项确认已有归档记录；出现「有改动却无归档记录」→ 先补归档（fxri-session-recap 模式一）再发版
+- 项目根存在 `.changeset/` 目录 → 走「changesets 流程」
+- 不存在 → 走「手工模式」（规范见 `references/changelog-format.md`）
+
+## changesets 流程
+
+1. 记录变更：`npx changeset`（或项目包管理器等价脚本）——**变更描述一律逐条以 `- 类型：描述` 书写**：既要 `类型：` 前缀（如 `新增：` / `修复：` / `优化：`）作归类信号，也要 `- ` 列表标记把每条独立成项（缺标记的裸行会被 changesets 并入相邻条目作缩进续行，整段塌成单一条目、只有首行归组剥前缀）；并按改动的**能力量级**选影响级别（破坏性→major、全新大功能/独立新能力→minor、存量能力上的修补与增量→patch，完整对照见 `references/changelog-format.md`）。写完可跑 `toolkit tasks check` 早期自查：它扫 `.changeset/` 下待发布变更集，逐文件报出缺前缀条目与未加 `- ` 标记的裸行及条数（免得到发版、变更集源被消费删除后才由 changelog 侧兜底告警——那时已无从补写）
+2. 消费发版：`npx changeset version`——自动写版本号与 CHANGELOG
+3. 格式化：按 `references/changelog-format.md` 的语义分组规则归类条目、转换分组标题、润色为项目语言风格（中文示例：`### Patch Changes` 下的 `- 修复：xxx` → `### 🐛 问题修复` 下的 `- xxx`——归类后类型前缀被剥离，类型由分组标题承接）；分组维度与 bump 维度正交，条目归组只看类型前缀
+4. 归一：润色后跑一次 `toolkit changelog --history format`——人工润色（含补写历史块明细）容易在条目之间留空行，该命令按「同组顶层条目逐行相邻」重排历史块；项目另有更新日志镜像页（如 `docs/changelog.md`）时再跑一次同步脚本，否则镜像一致性校验会失败
+5. 清理：删除已消费的 `.changeset/*.md`
+6. 门禁：发布前跑一次项目的验收命令（如 `pnpm verify`）——**关卡设在发布前而非推送前**：发布到包仓库 / 制品库不可逆，推送失败重推即可，故必须拦在不可逆动作之前；任一步失败即中止发版，不进入提交、打标签、发布
+7. 发布：提交版本与 CHANGELOG 改动 → 打 `vX.Y.Z` 标签 → 按项目渠道发布（如 `npm publish`）
+
+⚠️ 自动生成的条目必须人工核对润色，与仓库既有 CHANGELOG 风格保持一致。
+
+## 手工模式（无 changesets 项目）
+
+版本号与 CHANGELOG 全部手工维护：版本标题、发布日期行、分组标题与条目格式见 `references/changelog-format.md`；多语言四段结构（语义分组 / 标题替换映射 / 依赖更新文案 / 发布日期后缀）同文件。
+
+## 失败模式
+
+| 症状 | 处置 |
+| --- | --- |
+| version 后 CHANGELOG 分组标题仍是英文 | 按 references 的映射表补一次格式化 |
+| CHANGELOG 出现「- - 条目」双前缀伪影（变更集条目以 `- ` 开头） | `toolkit changelog version/format` 已自动还原为顶层条目；手工模式按 references 规则手动清理 |
+| 条目与仓库既有风格不一致 | 人工润色为项目语言与句式，勿保留机器直译 |
+| 变更集遗漏（发版后才发现功能未记录） | 补建变更集随下次发版；本次在发布说明中人工补充 |
+| `toolkit tasks check` 报「变更集条目缺类型前缀」 | 打开所列文件，给缺前缀的**顶层条目**按「类型：描述」补前缀（缩进续行随父条目迁属、无需加）；补前缀只改分类信号，不改变 bump 级别 |
+| `toolkit tasks check` 报「变更集条目未加「- 」列表标记」 | 打开所列文件，把裸行逐条改为 `- 类型：描述`（成因见 changesets 流程第 1 步）；若已发版才发现，说明该版本块条目可能已挤在单组且前缀未剥离，按 references 的「人工事实更正」修 `CHANGELOG.md` 并重跑镜像页同步 |
+| 改动已发布却无归档记录（有提交、无任务档） | 先补归档（fxri-session-recap 模式一）再继续发布后续步骤；发版本身不补建档 |
+| 发版后历史块内出现多余空行（`自举一致性` 类零改动用例失败） | 跑 `toolkit changelog --history format` 归一（**必须带 `--history`**，默认模式不动历史块），再补跑一次镜像页同步脚本 |
+| 格式化时 stderr 报「归类后条目数由 N 降为 M，疑似丢失内容」 | 归类只应搬移条目，减少即疑似丢内容：核对该版本块是否含非纯条目分组（标题下先出现正文）或被保留分组；确认属正常去重可忽略，否则按 references 的归类规则修回 |
+| 一批改动含新增能力 / 参数，却整批按 `修复：` 前缀登记（整块落 `问题修复` 组）——常见于 bump 判定为 patch 时，误以为级别与条目前缀绑定 | 前缀按**变更本身性质**逐条定：新增命令 / 参数 / 产物用 `新增：`、缺陷纠正用 `修复：`。分组只看前缀、与 bump 正交，**patch 也可挂 `新增：`**——bump 按改动的能力量级判（存量能力上的小新增即 patch），口径见 references |
+
+## 可选加速（不构成依赖）
+
+⚠️ 工具探测顺序（先项目内、后全局）：先 `pnpm exec toolkit --help`（项目 devDependency，npm 项目等价 `npx toolkit`），失败再 `toolkit --help`（全局安装）；两者都不可用即工具未安装，按各步手工继续，**不安装、不阻塞**。探测成功后用对应前缀执行下列命令：
+
+- `toolkit changelog`：创建变更集（等价 changeset）
+- `toolkit changelog version`：发版并自动做中文分组标题格式化
+- `toolkit changelog format`：仅格式化既有 CHANGELOG
+- `toolkit changelog --history format`：连带追溯改写历史版本块（用户主动要求修正历史块时才加，默认不动）
+- `toolkit changelog --lang <语言> …`：切换输出语言（内置 zh / en，其余可配置扩展）
+- `toolkit tasks check`：扫 `.changeset/` 下待发布变更集并逐文件报出缺前缀条目与未加 `- ` 标记的裸行（流程第 1 步的早期自查入口，归档前的 `tasks check` 即含此项）
+- ⚠️ `changelog` 域开了选项透传，自有选项（`--lang` / `--history` / `--redact` / `--warn`）必须写在子命令**之前**：`toolkit changelog --history format` 生效，写成 `toolkit changelog format --history` 会被 changesets 静默忽略（表现为「无 CHANGELOG 需要更新」）
+- `toolkit skills install` / `toolkit skills status`：把本包 fxri-* 技能分发到目标技能目录（`--scope` 缺省按 CLI 安装位置自动判定全局面 / 项目面；项目面真源落 `<仓库根>/.agents/skills/`、其余候选目录落入口薄壳，随仓库入库后队友 clone 即用）/ 查看链接、副本与项目面现场（技能随包同源分发，与 CLI 同一发布批次；技能内容版本独立编号，`skills status` 会打印各技能真源版本）