@zmice/zc 0.2.7 → 0.2.8

package/vendor/packages/toolkit/src/content/skills/context-engineering/body.md

@@ -1,67 +1,67 @@
-# 上下文工程
-
-这是 `command:start` 判型后进入的专项 skill：当任务核心不是“做什么”，而是“如何把正确上下文装载给接下来的阶段”，进入这里。
-
-## 何时使用
-
-- 开始新的编码会话或新子任务时
-- 输出质量下降，开始出现幻觉、忽略约定或跑偏
-- 任务切换导致上下文混杂时
-- 需要为代理准备最小但足够的输入材料时
-
-## 方法原则
-
-- 复杂任务先校准目标、边界和验证方式，再装载上下文
-- 最小充分上下文优先于“大而全”材料堆叠
-- 上下文装载要服务当前任务，不为可能发生的旁支需求提前铺料
-- 一旦任务阶段变化，就主动压缩和重建上下文，避免 drift
-- skill 按需加载优先于常驻加载；常驻文件只放稳定项目约定和路由规则
-- 用户级配置、跨项目路由、跨会话记忆或跨机器同步都属于持久化行为，必须先说明影响并取得明确授权
-
-## 输入前提
-
-- 已知道当前任务真正需要哪些信息
-- 愿意主动裁剪无关上下文
-- 接受规则文件、规格、源码、错误输出有不同优先级
-
-## 执行步骤
-
-1. 先校准：明确目标、非目标、风险点和需要的验证证据
-2. 先装载稳定规则：规则文件、长期约定、关键边界
-3. 再装载任务级上下文：规格片段、相关源码、测试、错误输出
-4. 控制上下文体积，只保留当前任务需要的信息
-5. 任务切换或阶段推进时主动压缩总结，清理旧上下文
-6. 发现上下文冲突、缺口或陈旧信息时，显式暴露而不是猜测
-7. 区分上下文载体：
-   - `AGENTS.md` / `CLAUDE.md` / `GEMINI.md`：长期规则、项目边界、稳定路由
-   - skill 文件：阶段性工作流，按需加载
-   - references / checklists：需要深入验证时再加载
-   - 用户级配置或记忆：只在明确授权后写入
-
-## 成功标准
-
-- 开始执行前，代理已经知道目标、边界和验证方式
-- 代理看到的是当前任务需要的最小充分上下文
-- 规则、规格、源码和错误信息的层级清晰
-- 上下文切换不会把旧问题带入新任务
-- 遇到冲突时能清楚指出需要人类决策的点
-- 不会因为上下文膨胀而偏离当前任务
-- 没有为了“方便”把所有 skill、所有上游文档或所有历史记忆一次性塞入当前会话
-- 任何持久化写入都有明确授权、可解释影响和回滚路径
-
-## 相关原则
-
-- 复杂任务谨慎优先于求快
-- 少而准，比多而杂更有效
-- 目标导向决定装载顺序
-- 外科式修改也适用于上下文，只带入要改的那一小块
-- 规格和规则优先于猜测
-- 压缩上下文是持续动作，不是最后补救
-- 上游能力先变成治理记录，再决定是否成为常驻规则或平台能力
-
-## 回到主流程
-
-- 上下文已校准完成：回到后续真正要执行的阶段或专项入口
-- 需求仍模糊：回到 `spec-driven-development`
-- 任务已经明确、准备实现：回到 `incremental-implementation`
-- 会话健康恶化明显：结合 `context-budget-audit`
+# 上下文工程
+
+这是 `command:start` 判型后进入的专项 skill：当任务核心不是“做什么”，而是“如何把正确上下文装载给接下来的阶段”，进入这里。
+
+## 何时使用
+
+- 开始新的编码会话或新子任务时
+- 输出质量下降，开始出现幻觉、忽略约定或跑偏
+- 任务切换导致上下文混杂时
+- 需要为代理准备最小但足够的输入材料时
+
+## 方法原则
+
+- 复杂任务先校准目标、边界和验证方式，再装载上下文
+- 最小充分上下文优先于“大而全”材料堆叠
+- 上下文装载要服务当前任务，不为可能发生的旁支需求提前铺料
+- 一旦任务阶段变化，就主动压缩和重建上下文，避免 drift
+- skill 按需加载优先于常驻加载；常驻文件只放稳定项目约定和路由规则
+- 用户级配置、跨项目路由、跨会话记忆或跨机器同步都属于持久化行为，必须先说明影响并取得明确授权
+
+## 输入前提
+
+- 已知道当前任务真正需要哪些信息
+- 愿意主动裁剪无关上下文
+- 接受规则文件、规格、源码、错误输出有不同优先级
+
+## 执行步骤
+
+1. 先校准：明确目标、非目标、风险点和需要的验证证据
+2. 先装载稳定规则：规则文件、长期约定、关键边界
+3. 再装载任务级上下文：规格片段、相关源码、测试、错误输出
+4. 控制上下文体积，只保留当前任务需要的信息
+5. 任务切换或阶段推进时主动压缩总结，清理旧上下文
+6. 发现上下文冲突、缺口或陈旧信息时，显式暴露而不是猜测
+7. 区分上下文载体：
+   - `AGENTS.md` / `CLAUDE.md` / `GEMINI.md`：长期规则、项目边界、稳定路由
+   - skill 文件：阶段性工作流，按需加载
+   - references / checklists：需要深入验证时再加载
+   - 用户级配置或记忆：只在明确授权后写入
+
+## 成功标准
+
+- 开始执行前，代理已经知道目标、边界和验证方式
+- 代理看到的是当前任务需要的最小充分上下文
+- 规则、规格、源码和错误信息的层级清晰
+- 上下文切换不会把旧问题带入新任务
+- 遇到冲突时能清楚指出需要人类决策的点
+- 不会因为上下文膨胀而偏离当前任务
+- 没有为了“方便”把所有 skill、所有上游文档或所有历史记忆一次性塞入当前会话
+- 任何持久化写入都有明确授权、可解释影响和回滚路径
+
+## 相关原则
+
+- 复杂任务谨慎优先于求快
+- 少而准，比多而杂更有效
+- 目标导向决定装载顺序
+- 外科式修改也适用于上下文，只带入要改的那一小块
+- 规格和规则优先于猜测
+- 压缩上下文是持续动作，不是最后补救
+- 上游能力先变成治理记录，再决定是否成为常驻规则或平台能力
+
+## 回到主流程
+
+- 上下文已校准完成：回到后续真正要执行的阶段或专项入口
+- 需求仍模糊：回到 `spec-driven-development`
+- 任务已经明确、准备实现：回到 `incremental-implementation`
+- 会话健康恶化明显：结合 `context-budget-audit`

package/vendor/packages/toolkit/src/content/skills/continuous-learning/body.md

@@ -1,102 +1,102 @@
-# Continuous Learning
-
-## 角色定位
-
-把一次会话中的可复用经验提炼成可审查、可回滚的学习项。它服务于长期协作质量，不是默认打开的遥测系统，也不是跨会话记忆的自动授权入口。
-
-核心模式：观察 → 提炼 → 验证 → 持久化 → 演化。
-
-## 何时使用
-
-- 用户明确要求 `/learn` 或复盘当前会话。
-- 多次出现同一纠正、错误修复路径或项目约定。
-- Sprint retrospective 需要沉淀可复用经验。
-- 需要把高频经验升级成 skill、command 或项目规则。
-
-不适用：
-
-- 单次偶然偏好。
-- 未经验证的猜测。
-- 敏感信息、凭据、生产数据或私人内容。
-- 用户没有同意的自动跨会话记忆。
-
-## 快速路径
-
-1. 收集本轮会话中可复用的观察，不存大段原始输入输出。
-2. 区分事实、用户偏好、项目约定和一次性上下文。
-3. 只提炼“触发条件 → 行动”的原子 instinct。
-4. 给每条 instinct 标置信心、证据、作用域和失效条件。
-5. 低置信度只留本地候选；高置信度也要说明为什么可复用。
-6. 需要写入长期文件或跨会话记忆时，先说明范围并等待用户同意。
-7. 多次重复后，再考虑演化为正式 skill / command / AGENTS 规则。
-
-## Instinct 格式
-
-```yaml
-id: prefer-targeted-verification
-trigger: "when finishing a scoped toolkit content change"
-action: "run toolkit lint and package tests before claiming completion"
-confidence: 0.8
-scope: project
-evidence:
-  - "User repeatedly asked for evidence before completion"
-expires_when: "project verification policy changes"
-```
-
-写得下这一段，才说明它足够明确；写不下就不要持久化。
-
-## 作用域判断
-
-| 类型 | 默认作用域 |
-|---|---|
-| 当前仓库验证命令、目录边界、提交习惯 | project |
-| 用户长期偏好，但不含敏感信息 | personal，需确认 |
-| 通用安全实践、证据先于断言 | global candidate，需多次证明 |
-| 一次性任务背景、临时路径、失败日志 | 不持久化 |
-
-## 证据质量
-
-可用证据：
-
-- 用户明确纠正。
-- 同一模式在多个任务中重复出现。
-- 修复失败后验证证明某个流程更可靠。
-- 仓库文档、测试或代码约束支持该规则。
-
-不可用证据：
-
-- 模型自己的感觉。
-- 单次偶然成功。
-- 未读完整输出的命令结果。
-- 涉及秘密、个人数据或生产数据的原文。
-
-## 演化门槛
-
-从 instinct 升级为正式内容前，检查：
-
-- 是否至少出现多次，或由用户明确要求沉淀。
-- 是否能写成清晰触发条件，而不是宽泛建议。
-- 是否与现有 skill / command 重叠。
-- 是否有验证方式或反例边界。
-- 是否会增加常驻上下文负担。
-
-优先把稳定规则写进已有 skill 或项目文档；只有边界清楚、复用频繁时才新增 skill。
-
-## Hook 边界
-
-Hook / automation 只能作为显式 opt-in 能力：
-
-- 安装前说明会记录什么、不记录什么、写到哪里。
-- 默认只记录摘要，不记录完整工具输入输出。
-- 支持关闭和清理。
-- 平台事件名和配置方式必须以当前官方能力为准。
-
-不要在内容层假设所有平台都支持同样的 hook 事件，也不要把 hook 当成默认运行前提。
-
-## 推荐输出
-
-```text
-Recommendation: <不记录 / 记录为候选 / 写入项目规则 / 演化为 skill> because <证据、作用域和长期上下文代价>。
-```
-
-推荐必须说明被放弃的替代方案，例如“只留聊天结论”“写入 AGENTS”“新增 skill”，以及为什么当前选择更合适。
+# Continuous Learning
+
+## 角色定位
+
+把一次会话中的可复用经验提炼成可审查、可回滚的学习项。它服务于长期协作质量，不是默认打开的遥测系统，也不是跨会话记忆的自动授权入口。
+
+核心模式：观察 → 提炼 → 验证 → 持久化 → 演化。
+
+## 何时使用
+
+- 用户明确要求 `/learn` 或复盘当前会话。
+- 多次出现同一纠正、错误修复路径或项目约定。
+- Sprint retrospective 需要沉淀可复用经验。
+- 需要把高频经验升级成 skill、command 或项目规则。
+
+不适用：
+
+- 单次偶然偏好。
+- 未经验证的猜测。
+- 敏感信息、凭据、生产数据或私人内容。
+- 用户没有同意的自动跨会话记忆。
+
+## 快速路径
+
+1. 收集本轮会话中可复用的观察，不存大段原始输入输出。
+2. 区分事实、用户偏好、项目约定和一次性上下文。
+3. 只提炼“触发条件 → 行动”的原子 instinct。
+4. 给每条 instinct 标置信心、证据、作用域和失效条件。
+5. 低置信度只留本地候选；高置信度也要说明为什么可复用。
+6. 需要写入长期文件或跨会话记忆时，先说明范围并等待用户同意。
+7. 多次重复后，再考虑演化为正式 skill / command / AGENTS 规则。
+
+## Instinct 格式
+
+```yaml
+id: prefer-targeted-verification
+trigger: "when finishing a scoped toolkit content change"
+action: "run toolkit lint and package tests before claiming completion"
+confidence: 0.8
+scope: project
+evidence:
+  - "User repeatedly asked for evidence before completion"
+expires_when: "project verification policy changes"
+```
+
+写得下这一段，才说明它足够明确；写不下就不要持久化。
+
+## 作用域判断
+
+| 类型 | 默认作用域 |
+|---|---|
+| 当前仓库验证命令、目录边界、提交习惯 | project |
+| 用户长期偏好，但不含敏感信息 | personal，需确认 |
+| 通用安全实践、证据先于断言 | global candidate，需多次证明 |
+| 一次性任务背景、临时路径、失败日志 | 不持久化 |
+
+## 证据质量
+
+可用证据：
+
+- 用户明确纠正。
+- 同一模式在多个任务中重复出现。
+- 修复失败后验证证明某个流程更可靠。
+- 仓库文档、测试或代码约束支持该规则。
+
+不可用证据：
+
+- 模型自己的感觉。
+- 单次偶然成功。
+- 未读完整输出的命令结果。
+- 涉及秘密、个人数据或生产数据的原文。
+
+## 演化门槛
+
+从 instinct 升级为正式内容前，检查：
+
+- 是否至少出现多次，或由用户明确要求沉淀。
+- 是否能写成清晰触发条件，而不是宽泛建议。
+- 是否与现有 skill / command 重叠。
+- 是否有验证方式或反例边界。
+- 是否会增加常驻上下文负担。
+
+优先把稳定规则写进已有 skill 或项目文档；只有边界清楚、复用频繁时才新增 skill。
+
+## Hook 边界
+
+Hook / automation 只能作为显式 opt-in 能力：
+
+- 安装前说明会记录什么、不记录什么、写到哪里。
+- 默认只记录摘要，不记录完整工具输入输出。
+- 支持关闭和清理。
+- 平台事件名和配置方式必须以当前官方能力为准。
+
+不要在内容层假设所有平台都支持同样的 hook 事件，也不要把 hook 当成默认运行前提。
+
+## 推荐输出
+
+```text
+Recommendation: <不记录 / 记录为候选 / 写入项目规则 / 演化为 skill> because <证据、作用域和长期上下文代价>。
+```
+
+推荐必须说明被放弃的替代方案，例如“只留聊天结论”“写入 AGENTS”“新增 skill”，以及为什么当前选择更合适。

package/vendor/packages/toolkit/src/content/skills/multi-perspective-review/body.md

@@ -1,81 +1,81 @@
-# 多视角评审
-
-## 何时使用
-
-- Spec 或 Plan 写完、实现还没开始时
-- 架构决策牵涉产品、工程、设计和开发体验多个面向时
-- 团队觉得方案“好像没问题”，但还没经过压力测试时
-- 需要尽早发现范围、体验或维护性盲区时
-
-## 输入前提
-
-- 已有可评审的规格、计划或方案草案
-- 愿意在实现前先暴露问题
-- 接受同一个方案需要经过多种视角拷问
-- 明确这里评审的是“计划态假设”，不是实现后的真实走查
-
-## 执行步骤
-
-1. 用 **产品视角** 检查是否在解决正确问题
-2. 用 **工程视角** 检查架构、数据流、状态、失败模式、边界条件、性能和测试策略
-3. 用 **设计视角** 检查交互、可用性、响应式和无障碍
-4. 用 **DevEx 视角** 检查计划中的集成成本、配置复杂度、文档前提、学习曲线和维护负担
-5. 把四个视角发现的问题改写成可执行的修订项、约束或验收标准
-6. 汇总结论，明确需要修订的点，再决定是否进入实现
-
-## 评审产物
-
-评审结果必须能回写到 plan / spec，而不是只形成聊天意见：
-
-- `GO / REVISE / NO-GO` 结论
-- 分级发现：`Critical / Warning / Suggestion`
-- 每条发现对应的证据、影响和修订动作
-- 对应的验收标准或验证命令
-- 如果需要提问，最多 1-3 个会改变方案的关键问题
-
-## 推荐结论格式
-
-最终结论必须包含明确推荐和取舍：
-
-```text
-Recommendation: <GO / REVISE / NO-GO + next action> because <specific cross-perspective trade-off>.
-```
-
-推荐理由至少说明：
-
-- 哪个视角的证据最关键
-- 放弃了什么替代方案
-- 接受了什么代价或风险
-- 下一步用什么验证或修订来收敛
-
-如果需要提问，每个问题都要说明它会解锁哪个决策，避免只收集背景信息。
-
-## 边界说明
-
-- 这里的 DevEx 只评估“实现前是否想清楚”，不替代实现后的真实安装和上手走查
-- 如果代码已经落地，需要确认 getting started、安装链和首次成功路径是否真的成立，转到 `developer-experience-audit`
-- 不要把这里当成发布前体验签收清单；它的价值是提前暴露盲点，而不是事后补测
-- 不引入重型运行时、遥测、自动升级或跨会话记忆作为评审前提；这些只能作为显式 opt-in 的后续能力讨论
-
-## 成功标准
-
-- 方案不再只从工程角度自证合理
-- 关键风险能在写代码前暴露
-- 每个视角都有具体 concern，而不是泛泛评价
-- DevEx 问题被表达为计划假设、约束或验收条件，而不是模糊感受
-- 最终结论可以明确是 `GO / REVISE / NO-GO`
-- 评审输出能直接变成 plan 修订、任务依赖或验证门禁
-
-## 相关原则
-
-- 越早发现问题，修复成本越低
-- 单一视角的“没问题”不算通过
-- 评审输出必须能转化为具体修订动作
-- 计划态评审与实现后实测必须分相位处理
-
-## 与其他技能的衔接
-
-- 常接在 `spec-driven-development` 或 `planning-and-task-breakdown` 之后
-- 评审通过后再进入 `incremental-implementation`
-- 实现完成后，如需验证 DevEx 假设是否成立，继续进入 `developer-experience-audit`
-- 产品或架构争议较大时，可结合 `product-owner` 和 `architect`
+# 多视角评审
+
+## 何时使用
+
+- Spec 或 Plan 写完、实现还没开始时
+- 架构决策牵涉产品、工程、设计和开发体验多个面向时
+- 团队觉得方案“好像没问题”，但还没经过压力测试时
+- 需要尽早发现范围、体验或维护性盲区时
+
+## 输入前提
+
+- 已有可评审的规格、计划或方案草案
+- 愿意在实现前先暴露问题
+- 接受同一个方案需要经过多种视角拷问
+- 明确这里评审的是“计划态假设”，不是实现后的真实走查
+
+## 执行步骤
+
+1. 用 **产品视角** 检查是否在解决正确问题
+2. 用 **工程视角** 检查架构、数据流、状态、失败模式、边界条件、性能和测试策略
+3. 用 **设计视角** 检查交互、可用性、响应式和无障碍
+4. 用 **DevEx 视角** 检查计划中的集成成本、配置复杂度、文档前提、学习曲线和维护负担
+5. 把四个视角发现的问题改写成可执行的修订项、约束或验收标准
+6. 汇总结论，明确需要修订的点，再决定是否进入实现
+
+## 评审产物
+
+评审结果必须能回写到 plan / spec，而不是只形成聊天意见：
+
+- `GO / REVISE / NO-GO` 结论
+- 分级发现：`Critical / Warning / Suggestion`
+- 每条发现对应的证据、影响和修订动作
+- 对应的验收标准或验证命令
+- 如果需要提问，最多 1-3 个会改变方案的关键问题
+
+## 推荐结论格式
+
+最终结论必须包含明确推荐和取舍：
+
+```text
+Recommendation: <GO / REVISE / NO-GO + next action> because <specific cross-perspective trade-off>.
+```
+
+推荐理由至少说明：
+
+- 哪个视角的证据最关键
+- 放弃了什么替代方案
+- 接受了什么代价或风险
+- 下一步用什么验证或修订来收敛
+
+如果需要提问，每个问题都要说明它会解锁哪个决策，避免只收集背景信息。
+
+## 边界说明
+
+- 这里的 DevEx 只评估“实现前是否想清楚”，不替代实现后的真实安装和上手走查
+- 如果代码已经落地，需要确认 getting started、安装链和首次成功路径是否真的成立，转到 `developer-experience-audit`
+- 不要把这里当成发布前体验签收清单；它的价值是提前暴露盲点，而不是事后补测
+- 不引入重型运行时、遥测、自动升级或跨会话记忆作为评审前提；这些只能作为显式 opt-in 的后续能力讨论
+
+## 成功标准
+
+- 方案不再只从工程角度自证合理
+- 关键风险能在写代码前暴露
+- 每个视角都有具体 concern，而不是泛泛评价
+- DevEx 问题被表达为计划假设、约束或验收条件，而不是模糊感受
+- 最终结论可以明确是 `GO / REVISE / NO-GO`
+- 评审输出能直接变成 plan 修订、任务依赖或验证门禁
+
+## 相关原则
+
+- 越早发现问题，修复成本越低
+- 单一视角的“没问题”不算通过
+- 评审输出必须能转化为具体修订动作
+- 计划态评审与实现后实测必须分相位处理
+
+## 与其他技能的衔接
+
+- 常接在 `spec-driven-development` 或 `planning-and-task-breakdown` 之后
+- 评审通过后再进入 `incremental-implementation`
+- 实现完成后，如需验证 DevEx 假设是否成立，继续进入 `developer-experience-audit`
+- 产品或架构争议较大时，可结合 `product-owner` 和 `architect`