@zmice/zc 0.2.6 → 0.2.8

package/vendor/packages/toolkit/src/content/skills/ci-cd-and-automation/body.md

@@ -1,86 +1,86 @@
-# CI/CD 与自动化
-
-## 角色定位
-
-把质量门禁自动化，让每次变更都能被一致地构建、测试和验证。CI/CD 的目标不是堆检查，而是用最小可维护管道拦住真实风险。
-
-## 何时使用
-
-- 新建或修改 CI pipeline。
-- 添加 lint、test、build、typecheck、安全扫描或发布门禁。
-- 调试 CI 失败。
-- 需要把本地验证提升成团队共享门禁。
-- 部署、preview、release 或 rollback 流程需要自动化。
-
-## 快速路径
-
-1. 明确要防的风险：格式、类型、测试、构建、发布、供应链、回滚。
-2. 先找现有 CI 文件和 package scripts，不重写整条流水线。
-3. 设计最小门禁：install/cache -> lint/format -> typecheck -> test -> build。
-4. 只在风险需要时增加 integration / E2E / security / bundle / deploy。
-5. 本地先跑等价命令，再改 CI。
-6. 对 CI 失败读取完整日志，定位失败阶段和根因。
-7. 记录门禁语义：smoke、full verify、release check 不要混名。
-
-## 最小可维护门禁
-
-默认顺序：
-
-```text
-install/cache -> lint/format -> typecheck -> unit test -> build
-```
-
-升级门禁前必须说明：
-
-- 它防什么风险。
-- 运行成本和维护成本。
-- 失败时谁能修、怎么修。
-- 是否需要 secrets、服务依赖或浏览器环境。
-
-## CI 失败处理
-
-```text
-CI failure loop:
-1. Preserve log.
-2. Identify failing job and command.
-3. Reproduce locally when practical.
-4. Fix root cause.
-5. Run local proof.
-6. Re-run CI / explain why CI is the remaining proof.
-```
-
-不要用跳过测试、禁用规则或放宽门禁来掩盖失败。确需降级门禁时，必须写明风险和恢复计划。
-
-## 部署与发布门禁
-
-发布管道至少要明确：
-
-- 触发条件：PR、main、tag、manual approval。
-- 环境：preview、staging、production。
-- secrets 来源和最小权限。
-- rollback 或 feature flag 策略。
-- release 前后验证命令。
-
-高风险发布优先使用小批次、preview、staging、feature flag 和可回滚路径，而不是一次性大改。
-
-## 输出契约
-
-```text
-CI/CD plan:
-- Risk addressed:
-- Existing pipeline:
-- Proposed gate:
-- Commands:
-- Secrets/services:
-- Failure handling:
-- Rollback:
-- Verification:
-```
-
-推荐结论：
-
-```text
-Recommendation: <add / change / defer / remove gate> because <风险、成本和被放弃替代方案>。
-```
-
-如果新增门禁的维护成本高于它防住的风险，默认先不加。
+# CI/CD 与自动化
+
+## 角色定位
+
+把质量门禁自动化，让每次变更都能被一致地构建、测试和验证。CI/CD 的目标不是堆检查，而是用最小可维护管道拦住真实风险。
+
+## 何时使用
+
+- 新建或修改 CI pipeline。
+- 添加 lint、test、build、typecheck、安全扫描或发布门禁。
+- 调试 CI 失败。
+- 需要把本地验证提升成团队共享门禁。
+- 部署、preview、release 或 rollback 流程需要自动化。
+
+## 快速路径
+
+1. 明确要防的风险：格式、类型、测试、构建、发布、供应链、回滚。
+2. 先找现有 CI 文件和 package scripts，不重写整条流水线。
+3. 设计最小门禁：install/cache -> lint/format -> typecheck -> test -> build。
+4. 只在风险需要时增加 integration / E2E / security / bundle / deploy。
+5. 本地先跑等价命令，再改 CI。
+6. 对 CI 失败读取完整日志，定位失败阶段和根因。
+7. 记录门禁语义：smoke、full verify、release check 不要混名。
+
+## 最小可维护门禁
+
+默认顺序：
+
+```text
+install/cache -> lint/format -> typecheck -> unit test -> build
+```
+
+升级门禁前必须说明：
+
+- 它防什么风险。
+- 运行成本和维护成本。
+- 失败时谁能修、怎么修。
+- 是否需要 secrets、服务依赖或浏览器环境。
+
+## CI 失败处理
+
+```text
+CI failure loop:
+1. Preserve log.
+2. Identify failing job and command.
+3. Reproduce locally when practical.
+4. Fix root cause.
+5. Run local proof.
+6. Re-run CI / explain why CI is the remaining proof.
+```
+
+不要用跳过测试、禁用规则或放宽门禁来掩盖失败。确需降级门禁时，必须写明风险和恢复计划。
+
+## 部署与发布门禁
+
+发布管道至少要明确：
+
+- 触发条件：PR、main、tag、manual approval。
+- 环境：preview、staging、production。
+- secrets 来源和最小权限。
+- rollback 或 feature flag 策略。
+- release 前后验证命令。
+
+高风险发布优先使用小批次、preview、staging、feature flag 和可回滚路径，而不是一次性大改。
+
+## 输出契约
+
+```text
+CI/CD plan:
+- Risk addressed:
+- Existing pipeline:
+- Proposed gate:
+- Commands:
+- Secrets/services:
+- Failure handling:
+- Rollback:
+- Verification:
+```
+
+推荐结论：
+
+```text
+Recommendation: <add / change / defer / remove gate> because <风险、成本和被放弃替代方案>。
+```
+
+如果新增门禁的维护成本高于它防住的风险，默认先不加。

package/vendor/packages/toolkit/src/content/skills/code-review-and-quality/body.md

@@ -1,140 +1,140 @@
-# 代码审查与质量
-
-## 何时使用
-
-- 合并任何变更之前
-- 完成一次功能实现之后
-- 评估自己、其他代理或人类写的代码时
-- bug 修复和重构之后
-
-## 输入前提
-
-- 已知道这次变更对应的规格或任务
-- 已有测试、构建或其他验证证据可供审查
-- 愿意按问题严重度给出明确结论，而不是泛泛评价
-
-## 执行步骤
-
-1. 先理解变更意图，再看测试和验证证据
-2. 按五个维度审查：
-   - 正确性
-   - 可读性
-   - 架构
-   - 安全性
-   - 性能
-3. 把发现按 `Critical / Important / Suggestion` 分级
-4. 对每条问题给出具体位置和修复方向
-5. 审查结论给出后，要求作者进入 review 响应闭环，逐条收敛问题
-6. 所有 Critical 清零并完成必要回归验证后，才算通过
-
-## 成功标准
-
-- 评审结论基于代码和证据，而不是个人偏好
-- 真正会阻塞合并的问题被明确指出
-- 报告能让作者快速定位问题和采取动作
-- 评审没有用“看起来还行”替代事实判断
-- 审查后的问题处理路径清楚，不把“提了意见”误当成“问题已关闭”
-
-## 推荐结论格式
-
-审查结论必须给出可执行推荐：
-
-```text
-Recommendation: <Approve / Request changes / Defer> because <evidence, risk, and trade-off>.
-```
-
-如果请求修改，说明哪些问题阻塞合并；如果批准，说明剩余风险和已验证证据；如果延后，说明为什么延后比本轮修复更合适。
-
-## 相关原则
-
-- 先报问题，再做总结
-- 只评论代码，不评论作者
-- 技术事实高于风格偏好
-
-## 与其他技能的衔接
-
-- 接在 `incremental-implementation` 或 bug 修复之后
-- 安全和性能深挖时可转给对应专项 skill
-- 对验证证据的审查依赖 `verification-before-completion`
-- 审查输出如果产生待修问题，应进入 `review-response-and-resolution`
-
-```markdown
-## Review: [PR/Change title]
-
-### Context
-- [ ] I understand what this change does and why
-
-### Correctness
-- [ ] Change matches spec/task requirements
-- [ ] Edge cases handled
-- [ ] Error paths handled
-- [ ] Tests cover the change adequately
-
-### Readability
-- [ ] Names are clear and consistent
-- [ ] Logic is straightforward
-- [ ] No unnecessary complexity
-
-### Architecture
-- [ ] Follows existing patterns
-- [ ] No unnecessary coupling or dependencies
-- [ ] Appropriate abstraction level
-
-### Security
-- [ ] No secrets in code
-- [ ] Input validated at boundaries
-- [ ] No injection vulnerabilities
-- [ ] Auth checks in place
-- [ ] External data sources treated as untrusted
-
-### Performance
-- [ ] No N+1 patterns
-- [ ] No unbounded operations
-- [ ] Pagination on list endpoints
-
-### Verification
-- [ ] Tests pass
-- [ ] Build succeeds
-- [ ] Manual verification done (if applicable)
-
-### Verdict
-- [ ] **Approve** — Ready to merge
-- [ ] **Request changes** — Issues must be addressed
-```
-
-## 另见
-
-- 更详细的安全审查指导，请见 `references/security-checklist.md`
-- 更详细的性能审查检查项，请见 `references/performance-checklist.md`
-
-## 常见合理化说辞
-
-| Rationalization | Reality |
-|---|---|
-| “能跑就行” | 能跑但不可读、不安全或架构错误的代码，只会制造持续累积的技术债。 |
-| “我写的，所以我知道它是对的” | 作者往往看不到自己的假设。每次变更都值得多一双眼睛。 |
-| “以后再清理” | 以后通常不会来。审查就是质量门槛，应该在提交前清理，而不是之后。 |
-| “AI 生成的代码大概没问题” | AI 代码更需要审查，而不是更少。它会用很流畅的语言包装错误。 |
-| “测试都过了，所以没问题” | 测试是必要条件，但不是充分条件。它们不能发现架构问题、安全问题或可读性问题。 |
-
-## 红旗
-
-- PR 在没有审查的情况下合并
-- 审查只看测试是否通过，而忽略其他维度
-- 没有真正审查就直接说 “LGTM”
-- 安全敏感改动没有安全向审查
-- 大 PR 大到“没法好好审查”
-- bug 修复没有回归测试
-- 审查意见没有严重程度标签，导致不清楚哪些必须修
-- 接受“我以后再修”——通常不会发生
-
-## 验证
-
-审查完成后：
-
-- [ ] 所有 Critical 问题已解决
-- [ ] 所有 Important 问题已解决，或已明确延后并给出理由
-- [ ] 审查意见已逐条进入响应闭环，没有“已读未处理”的项
-- [ ] 测试通过
-- [ ] 构建成功
-- [ ] 已记录验证故事（改了什么、如何验证）
+# 代码审查与质量
+
+## 何时使用
+
+- 合并任何变更之前
+- 完成一次功能实现之后
+- 评估自己、其他代理或人类写的代码时
+- bug 修复和重构之后
+
+## 输入前提
+
+- 已知道这次变更对应的规格或任务
+- 已有测试、构建或其他验证证据可供审查
+- 愿意按问题严重度给出明确结论，而不是泛泛评价
+
+## 执行步骤
+
+1. 先理解变更意图，再看测试和验证证据
+2. 按五个维度审查：
+   - 正确性
+   - 可读性
+   - 架构
+   - 安全性
+   - 性能
+3. 把发现按 `Critical / Important / Suggestion` 分级
+4. 对每条问题给出具体位置和修复方向
+5. 审查结论给出后，要求作者进入 review 响应闭环，逐条收敛问题
+6. 所有 Critical 清零并完成必要回归验证后，才算通过
+
+## 成功标准
+
+- 评审结论基于代码和证据，而不是个人偏好
+- 真正会阻塞合并的问题被明确指出
+- 报告能让作者快速定位问题和采取动作
+- 评审没有用“看起来还行”替代事实判断
+- 审查后的问题处理路径清楚，不把“提了意见”误当成“问题已关闭”
+
+## 推荐结论格式
+
+审查结论必须给出可执行推荐：
+
+```text
+Recommendation: <Approve / Request changes / Defer> because <evidence, risk, and trade-off>.
+```
+
+如果请求修改，说明哪些问题阻塞合并；如果批准，说明剩余风险和已验证证据；如果延后，说明为什么延后比本轮修复更合适。
+
+## 相关原则
+
+- 先报问题，再做总结
+- 只评论代码，不评论作者
+- 技术事实高于风格偏好
+
+## 与其他技能的衔接
+
+- 接在 `incremental-implementation` 或 bug 修复之后
+- 安全和性能深挖时可转给对应专项 skill
+- 对验证证据的审查依赖 `verification-before-completion`
+- 审查输出如果产生待修问题，应进入 `review-response-and-resolution`
+
+```markdown
+## Review: [PR/Change title]
+
+### Context
+- [ ] I understand what this change does and why
+
+### Correctness
+- [ ] Change matches spec/task requirements
+- [ ] Edge cases handled
+- [ ] Error paths handled
+- [ ] Tests cover the change adequately
+
+### Readability
+- [ ] Names are clear and consistent
+- [ ] Logic is straightforward
+- [ ] No unnecessary complexity
+
+### Architecture
+- [ ] Follows existing patterns
+- [ ] No unnecessary coupling or dependencies
+- [ ] Appropriate abstraction level
+
+### Security
+- [ ] No secrets in code
+- [ ] Input validated at boundaries
+- [ ] No injection vulnerabilities
+- [ ] Auth checks in place
+- [ ] External data sources treated as untrusted
+
+### Performance
+- [ ] No N+1 patterns
+- [ ] No unbounded operations
+- [ ] Pagination on list endpoints
+
+### Verification
+- [ ] Tests pass
+- [ ] Build succeeds
+- [ ] Manual verification done (if applicable)
+
+### Verdict
+- [ ] **Approve** — Ready to merge
+- [ ] **Request changes** — Issues must be addressed
+```
+
+## 另见
+
+- 更详细的安全审查指导，请见 `references/security-checklist.md`
+- 更详细的性能审查检查项，请见 `references/performance-checklist.md`
+
+## 常见合理化说辞
+
+| Rationalization | Reality |
+|---|---|
+| “能跑就行” | 能跑但不可读、不安全或架构错误的代码，只会制造持续累积的技术债。 |
+| “我写的，所以我知道它是对的” | 作者往往看不到自己的假设。每次变更都值得多一双眼睛。 |
+| “以后再清理” | 以后通常不会来。审查就是质量门槛，应该在提交前清理，而不是之后。 |
+| “AI 生成的代码大概没问题” | AI 代码更需要审查，而不是更少。它会用很流畅的语言包装错误。 |
+| “测试都过了，所以没问题” | 测试是必要条件，但不是充分条件。它们不能发现架构问题、安全问题或可读性问题。 |
+
+## 红旗
+
+- PR 在没有审查的情况下合并
+- 审查只看测试是否通过，而忽略其他维度
+- 没有真正审查就直接说 “LGTM”
+- 安全敏感改动没有安全向审查
+- 大 PR 大到“没法好好审查”
+- bug 修复没有回归测试
+- 审查意见没有严重程度标签，导致不清楚哪些必须修
+- 接受“我以后再修”——通常不会发生
+
+## 验证
+
+审查完成后：
+
+- [ ] 所有 Critical 问题已解决
+- [ ] 所有 Important 问题已解决，或已明确延后并给出理由
+- [ ] 审查意见已逐条进入响应闭环，没有“已读未处理”的项
+- [ ] 测试通过
+- [ ] 构建成功
+- [ ] 已记录验证故事（改了什么、如何验证）

package/vendor/packages/toolkit/src/content/skills/code-simplification/body.md

@@ -1,80 +1,80 @@
-# Code Simplification
-
-## 角色定位
-
-在不改变行为的前提下降低代码理解成本。目标不是减少行数，而是让下一位维护者更快理解、更安全修改、更容易验证。
-
-## 何时使用
-
-- 功能已经工作且测试通过，但实现明显偏重。
-- review 指出可读性、重复、嵌套或抽象层级问题。
-- 最近修改的代码引入了重复或不一致。
-- 需要在进入下一轮功能前降低维护成本。
-
-不适用：
-
-- 还没有理解代码为什么存在。
-- 缺少能保护行为的测试或验证方式。
-- 性能关键路径会因为“更简单”变慢。
-- 即将废弃或重写的代码。
-
-## 快速路径
-
-1. 明确要保持不变的行为、输入、输出、副作用和错误路径。
-2. 读取邻近代码和项目约定，确认本仓库的风格。
-3. 找一个具体简化目标：命名、重复、嵌套、函数职责、死代码、无效抽象。
-4. 一次只做一个简化切片。
-5. 每个切片后运行最小相关测试。
-6. 对比前后可读性和 diff 可审性。
-7. 如果新版本更难审或行为证据不足，回退该切片。
-
-## 简化信号
-
-优先处理具体信号，而不是泛泛“感觉复杂”：
-
-- 3 层以上嵌套，可以改为 guard clause 或提取谓词。
-- 长函数承担多个职责，可以拆成命名清楚的小函数。
-- 重复条件或重复逻辑，可以提取共享函数。
-- 命名不能表达业务含义，可以重命名。
-- 注释解释“做什么”，代码本身可表达时可以删除；解释“为什么”的注释保留。
-- 只有一个实现的过度抽象，可以考虑内联。
-- 不可达分支、未使用变量、过期注释，可以在确认后删除。
-
-## 行为保护
-
-简化前先回答：
-
-- 现有测试覆盖了什么？
-- 哪些边界没有测试但需要人工验证？
-- 这个代码是否有历史原因、平台限制或性能约束？
-- 是否有调用方依赖当前副作用或错误行为？
-
-无法回答时，先回到 `codebase-onboarding` 或 `test-driven-development` 补证据。
-
-## 反模式
-
-- 为了少几行牺牲可读性。
-- 把有意义的 helper 内联成重复逻辑。
-- 顺手重构无关文件，制造 review 噪声。
-- 同一个提交里混合功能变更和简化重构。
-- 没有测试保护就改公共接口或错误路径。
-
-## 输出契约
-
-```text
-Simplification evidence:
-- Target:
-- Behavior preserved:
-- Change made:
-- Tests / verification:
-- Before/after readability:
-- Remaining risk:
-```
-
-推荐结论：
-
-```text
-Recommendation: <apply / stop / add tests first / defer> because <行为证据、维护收益和被放弃替代方案>。
-```
-
-如果不能证明行为保持不变，默认不要简化。
+# Code Simplification
+
+## 角色定位
+
+在不改变行为的前提下降低代码理解成本。目标不是减少行数，而是让下一位维护者更快理解、更安全修改、更容易验证。
+
+## 何时使用
+
+- 功能已经工作且测试通过，但实现明显偏重。
+- review 指出可读性、重复、嵌套或抽象层级问题。
+- 最近修改的代码引入了重复或不一致。
+- 需要在进入下一轮功能前降低维护成本。
+
+不适用：
+
+- 还没有理解代码为什么存在。
+- 缺少能保护行为的测试或验证方式。
+- 性能关键路径会因为“更简单”变慢。
+- 即将废弃或重写的代码。
+
+## 快速路径
+
+1. 明确要保持不变的行为、输入、输出、副作用和错误路径。
+2. 读取邻近代码和项目约定，确认本仓库的风格。
+3. 找一个具体简化目标：命名、重复、嵌套、函数职责、死代码、无效抽象。
+4. 一次只做一个简化切片。
+5. 每个切片后运行最小相关测试。
+6. 对比前后可读性和 diff 可审性。
+7. 如果新版本更难审或行为证据不足，回退该切片。
+
+## 简化信号
+
+优先处理具体信号，而不是泛泛“感觉复杂”：
+
+- 3 层以上嵌套，可以改为 guard clause 或提取谓词。
+- 长函数承担多个职责，可以拆成命名清楚的小函数。
+- 重复条件或重复逻辑，可以提取共享函数。
+- 命名不能表达业务含义，可以重命名。
+- 注释解释“做什么”，代码本身可表达时可以删除；解释“为什么”的注释保留。
+- 只有一个实现的过度抽象，可以考虑内联。
+- 不可达分支、未使用变量、过期注释，可以在确认后删除。
+
+## 行为保护
+
+简化前先回答：
+
+- 现有测试覆盖了什么？
+- 哪些边界没有测试但需要人工验证？
+- 这个代码是否有历史原因、平台限制或性能约束？
+- 是否有调用方依赖当前副作用或错误行为？
+
+无法回答时，先回到 `codebase-onboarding` 或 `test-driven-development` 补证据。
+
+## 反模式
+
+- 为了少几行牺牲可读性。
+- 把有意义的 helper 内联成重复逻辑。
+- 顺手重构无关文件，制造 review 噪声。
+- 同一个提交里混合功能变更和简化重构。
+- 没有测试保护就改公共接口或错误路径。
+
+## 输出契约
+
+```text
+Simplification evidence:
+- Target:
+- Behavior preserved:
+- Change made:
+- Tests / verification:
+- Before/after readability:
+- Remaining risk:
+```
+
+推荐结论：
+
+```text
+Recommendation: <apply / stop / add tests first / defer> because <行为证据、维护收益和被放弃替代方案>。
+```
+
+如果不能证明行为保持不变，默认不要简化。