@zmice/zc 0.2.6 → 0.2.8

package/vendor/packages/toolkit/src/content/skills/parallel-agent-dispatch/body.md

@@ -1,113 +1,113 @@
-# Parallel Agent Dispatch
-
-## 角色定位
-
-在用户明确允许多 agent / 并行 / team 模式时，把彼此独立的任务做上下文级 fan-out，并在结束时做 fan-in、冲突检测和集成验证。
-
-这个 skill 不是默认加速器。能并行不等于应该并行；并行会增加 token、延迟、集成和验证成本。
-
-## 快速路径
-
-1. 读取计划，列出所有任务、依赖和预计触达文件。
-2. 判断任务是否彼此独立，是否有清晰文件所有权。
-3. 给出并行推荐，但在用户明确确认前不启动子代理。
-4. 为每个 worker 分配唯一责任范围、允许修改文件和验证命令。
-5. fan-out 执行，期间不让多个 worker 修改同一文件。
-6. fan-in 汇总，检查 diff、冲突、接口一致性和测试结果。
-7. 记录验收 transcript：谁做了什么、证据是什么、还有什么风险。
-
-## 使用条件
-
-适用：
-
-- 多个任务互不依赖。
-- 每个任务能在独立上下文中完成。
-- 文件所有权可以提前划清。
-- fan-in 后有集成测试或人工审查门禁。
-
-不适用：
-
-- 任务依赖同一个未完成设计。
-- 多个任务必须改同一文件。
-- 缺少测试或集成验证方式。
-- 用户没有明确授权并行。
-
-## 模式选择
-
-| 模式 | 适用场景 | 代价 |
-|---|---|---|
-| Context Fan-Out | 只需要多个子代理分别分析或修改互不重叠文件 | 共享同一 worktree，fan-in 需谨慎检查 |
-| Worktree Parallel | 任务可能触及相邻区域，或需要独立构建环境 | 需要分支和 worktree 清理 |
-| Cascade | 任务有层级依赖，但每层内可并行 | 每层都要验证后再进下一层 |
-| Team Orchestration | 需要 tmux + git worktree + 多 CLI worker | 运行时成本最高，需 `zc team` 收尾 |
-
-如果需要文件系统级隔离，切到 `team-orchestration`；不要在本 skill 内展开完整 `zc team` 教程。
-
-## 授权提示
-
-启动前必须给用户看到这段信息的等价内容：
-
-```text
-Recommendation: 开启 <模式> because <并行收益> outweighs <集成代价>。
-- worker 数：
-- 文件所有权：
-- 不并行的替代方案：
-- fan-in 验证：
-
-确认后我再启动；不确认则按串行推进。
-```
-
-## Worker 合约
-
-每个子代理都必须收到：
-
-- 任务目标和验收标准
-- 允许读取的关键上下文
-- 允许修改的文件或模块边界
-- 不得触碰其他 worker 文件的说明
-- 任务内验证命令
-- 返回格式：`DONE / BLOCKED / NEEDS_CONTEXT`
-
-返回时必须列出：
-
-- 修改文件
-- 已运行验证
-- 未覆盖风险
-- 需要主线程 fan-in 的事项
-
-## Fan-In 门禁
-
-并行完成不等于任务完成。fan-in 必须检查：
-
-- 所有子代理结果是否到齐。
-- 是否出现同文件修改、命名冲突或接口冲突。
-- 局部验证是否可信。
-- 主线程是否运行集成测试或目标平台验证。
-- 是否需要清理分支、worktree、临时文件或保留待审查分支。
-
-推荐记录格式：
-
-```text
-Parallel acceptance transcript:
-- Plan:
-- Workers:
-- Files:
-- Results:
-- Verification:
-- Conflicts:
-- Follow-up:
-```
-
-## 失败处理
-
-- 单个 worker 失败时，不要自动丢弃其他成功结果。
-- 先收集成功结果，再判断是否可以部分合入。
-- 失败任务优先缩小范围、补上下文或改为串行处理。
-- 如果失败暴露计划不成立，回到 `planning-and-task-breakdown`。
-
-## 与相关技能的边界
-
-- `subagent-driven-development`：串行委派，不做并行 fan-out。
-- `team-orchestration`：进程级 + 文件系统级隔离。
-- `branch-finish-and-cleanup`：fan-in 后处理分支、worktree 和残留状态。
-- `verification-before-completion`：声明完成前读取验证输出。
+# Parallel Agent Dispatch
+
+## 角色定位
+
+在用户明确允许多 agent / 并行 / team 模式时，把彼此独立的任务做上下文级 fan-out，并在结束时做 fan-in、冲突检测和集成验证。
+
+这个 skill 不是默认加速器。能并行不等于应该并行；并行会增加 token、延迟、集成和验证成本。
+
+## 快速路径
+
+1. 读取计划，列出所有任务、依赖和预计触达文件。
+2. 判断任务是否彼此独立，是否有清晰文件所有权。
+3. 给出并行推荐，但在用户明确确认前不启动子代理。
+4. 为每个 worker 分配唯一责任范围、允许修改文件和验证命令。
+5. fan-out 执行，期间不让多个 worker 修改同一文件。
+6. fan-in 汇总，检查 diff、冲突、接口一致性和测试结果。
+7. 记录验收 transcript：谁做了什么、证据是什么、还有什么风险。
+
+## 使用条件
+
+适用：
+
+- 多个任务互不依赖。
+- 每个任务能在独立上下文中完成。
+- 文件所有权可以提前划清。
+- fan-in 后有集成测试或人工审查门禁。
+
+不适用：
+
+- 任务依赖同一个未完成设计。
+- 多个任务必须改同一文件。
+- 缺少测试或集成验证方式。
+- 用户没有明确授权并行。
+
+## 模式选择
+
+| 模式 | 适用场景 | 代价 |
+|---|---|---|
+| Context Fan-Out | 只需要多个子代理分别分析或修改互不重叠文件 | 共享同一 worktree，fan-in 需谨慎检查 |
+| Worktree Parallel | 任务可能触及相邻区域，或需要独立构建环境 | 需要分支和 worktree 清理 |
+| Cascade | 任务有层级依赖，但每层内可并行 | 每层都要验证后再进下一层 |
+| Team Orchestration | 需要 tmux + git worktree + 多 CLI worker | 运行时成本最高，需 `zc team` 收尾 |
+
+如果需要文件系统级隔离，切到 `team-orchestration`；不要在本 skill 内展开完整 `zc team` 教程。
+
+## 授权提示
+
+启动前必须给用户看到这段信息的等价内容：
+
+```text
+Recommendation: 开启 <模式> because <并行收益> outweighs <集成代价>。
+- worker 数：
+- 文件所有权：
+- 不并行的替代方案：
+- fan-in 验证：
+
+确认后我再启动；不确认则按串行推进。
+```
+
+## Worker 合约
+
+每个子代理都必须收到：
+
+- 任务目标和验收标准
+- 允许读取的关键上下文
+- 允许修改的文件或模块边界
+- 不得触碰其他 worker 文件的说明
+- 任务内验证命令
+- 返回格式：`DONE / BLOCKED / NEEDS_CONTEXT`
+
+返回时必须列出：
+
+- 修改文件
+- 已运行验证
+- 未覆盖风险
+- 需要主线程 fan-in 的事项
+
+## Fan-In 门禁
+
+并行完成不等于任务完成。fan-in 必须检查：
+
+- 所有子代理结果是否到齐。
+- 是否出现同文件修改、命名冲突或接口冲突。
+- 局部验证是否可信。
+- 主线程是否运行集成测试或目标平台验证。
+- 是否需要清理分支、worktree、临时文件或保留待审查分支。
+
+推荐记录格式：
+
+```text
+Parallel acceptance transcript:
+- Plan:
+- Workers:
+- Files:
+- Results:
+- Verification:
+- Conflicts:
+- Follow-up:
+```
+
+## 失败处理
+
+- 单个 worker 失败时，不要自动丢弃其他成功结果。
+- 先收集成功结果，再判断是否可以部分合入。
+- 失败任务优先缩小范围、补上下文或改为串行处理。
+- 如果失败暴露计划不成立，回到 `planning-and-task-breakdown`。
+
+## 与相关技能的边界
+
+- `subagent-driven-development`：串行委派，不做并行 fan-out。
+- `team-orchestration`：进程级 + 文件系统级隔离。
+- `branch-finish-and-cleanup`：fan-in 后处理分支、worktree 和残留状态。
+- `verification-before-completion`：声明完成前读取验证输出。

package/vendor/packages/toolkit/src/content/skills/performance-optimization/body.md

@@ -1,75 +1,75 @@
-# Performance Optimization
-
-## 角色定位
-
-性能优化必须从测量开始。这个 skill 用于定位真实瓶颈、做最小修复、再次测量，并补回归保护；不用于凭感觉提前复杂化实现。
-
-## 何时使用
-
-- 规格里有明确性能目标或预算。
-- 用户、监控或日志报告慢。
-- Core Web Vitals、接口延迟、吞吐、内存或 CPU 有异常。
-- 怀疑一次变更造成性能回归。
-- 功能会处理大数据量、高并发或关键首屏路径。
-
-不适用：没有性能证据，只是担心未来可能慢。
-
-## 快速路径
-
-1. 写清性能症状和目标指标。
-2. 建立 baseline：真实数据或可复现 synthetic 测量。
-3. 定位瓶颈：前端、后端、数据库、网络、渲染、内存或外部依赖。
-4. 只修当前证据指向的瓶颈。
-5. 再次测量，确认指标改善。
-6. 评估复杂度代价，避免为了小收益引入长期维护成本。
-7. 加 guard：监控、benchmark、预算或回归测试。
-
-## 指标选择
-
-| 场景 | 优先指标 |
-|---|---|
-| 首屏慢 | LCP、TTFB、bundle size、network waterfall |
-| 交互卡顿 | INP、long task、render count、main thread profile |
-| 布局跳动 | CLS、图片尺寸、字体加载、late content |
-| API 慢 | p95/p99 latency、query time、cache hit、payload size |
-| 资源异常 | CPU、memory、GC、connection pool、queue depth |
-
-默认使用能复现症状的最小指标。不要同时优化所有指标。
-
-## 常见定位方向
-
-- 前端首屏：大图片、render-blocking CSS/JS、bundle 过大、慢 TTFB。
-- 前端交互：长任务、重复渲染、过大 DOM、同步计算。
-- 数据加载：瀑布请求、N+1、过大 payload、缺少分页。
-- 后端接口：缺索引、锁等待、连接池耗尽、重复计算。
-- 内存/CPU：无界缓存、泄漏、正则回溯、同步重计算。
-
-## 修复纪律
-
-- 先证明瓶颈，再改代码。
-- 一次只优化一个瓶颈。
-- 保留 before / after 数字。
-- 小收益大复杂度的优化要默认拒绝。
-- 性能关键路径改动要补 benchmark、监控或预算门禁。
-
-## 输出契约
-
-```text
-Performance evidence:
-- Symptom:
-- Target:
-- Baseline:
-- Bottleneck:
-- Change:
-- After:
-- Regression guard:
-- Trade-off:
-```
-
-推荐结论：
-
-```text
-Recommendation: <optimize / monitor / defer / revert> because <baseline, measured impact, complexity cost, and rejected alternative>.
-```
-
-没有 baseline 和 after 数据，不要声明性能优化成立。
+# Performance Optimization
+
+## 角色定位
+
+性能优化必须从测量开始。这个 skill 用于定位真实瓶颈、做最小修复、再次测量，并补回归保护；不用于凭感觉提前复杂化实现。
+
+## 何时使用
+
+- 规格里有明确性能目标或预算。
+- 用户、监控或日志报告慢。
+- Core Web Vitals、接口延迟、吞吐、内存或 CPU 有异常。
+- 怀疑一次变更造成性能回归。
+- 功能会处理大数据量、高并发或关键首屏路径。
+
+不适用：没有性能证据，只是担心未来可能慢。
+
+## 快速路径
+
+1. 写清性能症状和目标指标。
+2. 建立 baseline：真实数据或可复现 synthetic 测量。
+3. 定位瓶颈：前端、后端、数据库、网络、渲染、内存或外部依赖。
+4. 只修当前证据指向的瓶颈。
+5. 再次测量，确认指标改善。
+6. 评估复杂度代价，避免为了小收益引入长期维护成本。
+7. 加 guard：监控、benchmark、预算或回归测试。
+
+## 指标选择
+
+| 场景 | 优先指标 |
+|---|---|
+| 首屏慢 | LCP、TTFB、bundle size、network waterfall |
+| 交互卡顿 | INP、long task、render count、main thread profile |
+| 布局跳动 | CLS、图片尺寸、字体加载、late content |
+| API 慢 | p95/p99 latency、query time、cache hit、payload size |
+| 资源异常 | CPU、memory、GC、connection pool、queue depth |
+
+默认使用能复现症状的最小指标。不要同时优化所有指标。
+
+## 常见定位方向
+
+- 前端首屏：大图片、render-blocking CSS/JS、bundle 过大、慢 TTFB。
+- 前端交互：长任务、重复渲染、过大 DOM、同步计算。
+- 数据加载：瀑布请求、N+1、过大 payload、缺少分页。
+- 后端接口：缺索引、锁等待、连接池耗尽、重复计算。
+- 内存/CPU：无界缓存、泄漏、正则回溯、同步重计算。
+
+## 修复纪律
+
+- 先证明瓶颈，再改代码。
+- 一次只优化一个瓶颈。
+- 保留 before / after 数字。
+- 小收益大复杂度的优化要默认拒绝。
+- 性能关键路径改动要补 benchmark、监控或预算门禁。
+
+## 输出契约
+
+```text
+Performance evidence:
+- Symptom:
+- Target:
+- Baseline:
+- Bottleneck:
+- Change:
+- After:
+- Regression guard:
+- Trade-off:
+```
+
+推荐结论：
+
+```text
+Recommendation: <optimize / monitor / defer / revert> because <baseline, measured impact, complexity cost, and rejected alternative>.
+```
+
+没有 baseline 和 after 数据，不要声明性能优化成立。

package/vendor/packages/toolkit/src/content/skills/planning-and-task-breakdown/body.md

@@ -1,83 +1,83 @@
-# 规划与任务拆解
-
-## 何时使用
-
-- 已有规格，需要拆成可执行单元
-- 任务太大、太模糊或依赖顺序不明显
-- 需要并行推进多个切片
-- 需要向人类清楚表达范围、风险和检查点
-
-不适用于单文件且边界显而易见的小改动。
-
-## 输入前提
-
-- 已有规格，或至少有清楚的问题定义
-- 已读相关代码并识别主要约束
-- 愿意在规划阶段保持只读，不边做边改
-
-## 执行步骤
-
-1. 进入只读分析模式，先看规格和现有代码
-2. 识别依赖图，确定哪些必须先做
-3. 优先做纵向切片，而不是按数据库、API、UI 横向分层
-4. 为每个任务写清：
-   - 描述
-   - Acceptance criteria
-   - Verification
-   - Dependencies
-   - Files likely touched
-5. 排出顺序，并设置阶段性检查点
-
-## 提问纪律
-
-- 能从规格、代码、配置、测试或用户原话判断的，不问。
-- 只有缺失信息会改变架构、数据模型、任务顺序、破坏性操作或并行边界时才问。
-- 一轮最多问 1-3 个关键问题，问题要说明选择会避免什么风险或解锁什么能力。
-- 用户已经给出偏好时，把它写进计划假设；不要把偏好扩展成长期配置或跨会话记忆授权。
-
-## 计划产物要求
-
-计划不是任务名列表，至少要包含：
-
-- `decision log`：关键取舍和采用原因
-- `evidence`：读取过的规格、代码、配置、测试或上游证据
-- `open risks`：尚未证明的风险和验证方式
-- `fan-out eligibility`：是否能并行、按哪些文件或模块拆、是否需要 `zc team plan`
-- `fan-in gate`：实现后如何合流、审查、验证和清理
-
-## 决策日志格式
-
-每个关键取舍都要写成可审查的推荐，而不是只写“建议这样做”：
-
-```text
-Recommendation: <chosen action> because <evidence and trade-off>.
-- Chosen:
-- Rejected alternative:
-- Evidence:
-- Cost / risk:
-- Verification gate:
-```
-
-理由必须说明被放弃的替代方案，以及当前选择为什么更适合本任务。不能只写“更稳”“更简单”“更符合最佳实践”。
-
-## 成功标准
-
-- 每个任务都能独立实现、测试和验证
-- 任务粒度足够小，不会一次触碰过多文件
-- 依赖顺序和可并行项是显式的
-- 人类看完计划后能明确判断“方案对不对”
-- 计划中的问题和风险都能落到后续验证命令或审查项
-- 并行任务必须有明确文件所有权或隔离理由
-
-## 相关原则
-
-- 计划服务实现，不是形式化文档
-- 先控制复杂度，再讨论并行度
-- 任务必须能验证，不能只写动作名
-- 计划阶段发现的问题要进入计划本身，不能只留在聊天里
-
-## 与其他技能的衔接
-
-- 接在 `spec-driven-development` 之后
-- 计划确认后交给 `incremental-implementation`
-- 涉及方案争议时，可搭配 `multi-perspective-review`
+# 规划与任务拆解
+
+## 何时使用
+
+- 已有规格，需要拆成可执行单元
+- 任务太大、太模糊或依赖顺序不明显
+- 需要并行推进多个切片
+- 需要向人类清楚表达范围、风险和检查点
+
+不适用于单文件且边界显而易见的小改动。
+
+## 输入前提
+
+- 已有规格，或至少有清楚的问题定义
+- 已读相关代码并识别主要约束
+- 愿意在规划阶段保持只读，不边做边改
+
+## 执行步骤
+
+1. 进入只读分析模式，先看规格和现有代码
+2. 识别依赖图，确定哪些必须先做
+3. 优先做纵向切片，而不是按数据库、API、UI 横向分层
+4. 为每个任务写清：
+   - 描述
+   - Acceptance criteria
+   - Verification
+   - Dependencies
+   - Files likely touched
+5. 排出顺序，并设置阶段性检查点
+
+## 提问纪律
+
+- 能从规格、代码、配置、测试或用户原话判断的，不问。
+- 只有缺失信息会改变架构、数据模型、任务顺序、破坏性操作或并行边界时才问。
+- 一轮最多问 1-3 个关键问题，问题要说明选择会避免什么风险或解锁什么能力。
+- 用户已经给出偏好时，把它写进计划假设；不要把偏好扩展成长期配置或跨会话记忆授权。
+
+## 计划产物要求
+
+计划不是任务名列表，至少要包含：
+
+- `decision log`：关键取舍和采用原因
+- `evidence`：读取过的规格、代码、配置、测试或上游证据
+- `open risks`：尚未证明的风险和验证方式
+- `fan-out eligibility`：是否能并行、按哪些文件或模块拆、是否需要 `zc team plan`
+- `fan-in gate`：实现后如何合流、审查、验证和清理
+
+## 决策日志格式
+
+每个关键取舍都要写成可审查的推荐，而不是只写“建议这样做”：
+
+```text
+Recommendation: <chosen action> because <evidence and trade-off>.
+- Chosen:
+- Rejected alternative:
+- Evidence:
+- Cost / risk:
+- Verification gate:
+```
+
+理由必须说明被放弃的替代方案，以及当前选择为什么更适合本任务。不能只写“更稳”“更简单”“更符合最佳实践”。
+
+## 成功标准
+
+- 每个任务都能独立实现、测试和验证
+- 任务粒度足够小，不会一次触碰过多文件
+- 依赖顺序和可并行项是显式的
+- 人类看完计划后能明确判断“方案对不对”
+- 计划中的问题和风险都能落到后续验证命令或审查项
+- 并行任务必须有明确文件所有权或隔离理由
+
+## 相关原则
+
+- 计划服务实现，不是形式化文档
+- 先控制复杂度，再讨论并行度
+- 任务必须能验证，不能只写动作名
+- 计划阶段发现的问题要进入计划本身，不能只留在聊天里
+
+## 与其他技能的衔接
+
+- 接在 `spec-driven-development` 之后
+- 计划确认后交给 `incremental-implementation`
+- 涉及方案争议时，可搭配 `multi-perspective-review`