@zmice/zc 0.2.6 → 0.2.8

package/vendor/packages/toolkit/src/content/skills/sdd-tdd-workflow/body.md

@@ -1,95 +1,95 @@
-# SDD + TDD 开发工作流
-
-## 角色定位
-
-这是完整交付的编排 skill，不是每个阶段的详细教程。它负责把需求按阶段推进，并在进入具体阶段时再读取对应专项 skill。
-
-渐进式披露规则：
-
-- 当前只需要路由和门控时，只读取本文。
-- 进入某个阶段时，再加载该阶段 skill。
-- 不把所有阶段规则同时塞进上下文。
-- 发现任务变成 bug、文档、发布或上下文问题时，切换到对应入口，不继续硬走完整流程。
-
-## 快速路径
-
-1. 判断任务是否需要完整交付；简单修复、文档或调查任务不要套完整流程。
-2. 若需求模糊，先进入 `brainstorming-and-design` 或 `spec-driven-development`。
-3. 若规格清楚，进入 `planning-and-task-breakdown`。
-4. 计划确认后，进入 `incremental-implementation` + `test-driven-development`。
-5. 实现完成后，进入 `code-review-and-quality`。
-6. 准备声明完成前，进入 `verification-before-completion`。
-7. 需要提交时，进入 `git-workflow-and-versioning`，并等待用户确认。
-8. 周期结束或需要沉淀经验时，进入 `sprint-retrospective`。
-
-## 阶段门控
-
-| 阶段 | 默认入口 | 通过条件 |
-|---|---|---|
-| Brainstorm（可选） | `brainstorming-and-design` | 目标、约束、方案方向已收敛 |
-| Specify | `spec-driven-development` | 规格可测试，假设已显式列出 |
-| Plan | `planning-and-task-breakdown` | 任务有依赖、文件边界和验证方式 |
-| Plan Review（可选） | `multi-perspective-review` | `GO / REVISE / NO-GO` 结论明确 |
-| Build | `incremental-implementation` + `test-driven-development` | 每个切片实现、测试、回归通过 |
-| Review | `code-review-and-quality` | Critical/Important 已处理或有明确延后理由 |
-| Verify | `verification-before-completion` | 新鲜验证命令通过，输出已读 |
-| Commit（可选） | `git-workflow-and-versioning` | 用户确认提交范围和消息 |
-| Retro（可选） | `sprint-retrospective` | 偏差、复盘和行动项已记录 |
-
-## 构建模式选择
-
-- **Manual（默认）**：你自己按任务串行实现。适合大多数改动。
-- **Subagent-Driven**：任务彼此独立，但用户没有要求并行时，可作为串行委派建议。
-- **Parallel**：用户明确要求多 agent / 并行 / team 模式，且任务有清晰文件所有权时，使用 `parallel-agent-dispatch`。
-- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离或多 CLI worker 时，使用 `team-orchestration`。
-
-除非用户已经明确要求并行，否则只给并行建议，不直接启动子代理或 `zc team`。
-
-推荐提示格式：
-
-```text
-Recommendation: 按 Manual / Parallel / Team 模式推进 because <证据与 trade-off>。
-- 并行收益：
-- 并行代价：
-- 文件所有权：
-- fan-in 验证：
-```
-
-## 阶段切换纪律
-
-- 进入新阶段前，说明当前阶段已满足的证据。
-- 阶段中发现前提失真时，回退到上游阶段，不继续堆实现。
-- 长会话变慢或内容开始混乱时，切到 `context-budget-audit` / `context-engineering`。
-- 变更涉及浏览器体验时，在单元/API 测试之外补 `browser-qa-testing`。
-- 涉及高风险命令、生产数据或敏感文件时，先切到 `safety-guardrails`。
-
-## 停线条件
-
-立即停止当前阶段并重新定位：
-
-- 测试、构建或 lint 失败但原因未读清。
-- 用户纠正了需求、范围或安全边界。
-- 计划要求修改的文件和实际代码结构明显不一致。
-- 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
-- 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
-
-## 输出契约
-
-完整交付过程中的关键结论都要使用可审查的推荐格式：
-
-```text
-Recommendation: <下一步动作> because <具体证据、取舍和被放弃的替代方案>。
-```
-
-不要只说“更稳”“更好”“建议继续”。必须说明为什么这个动作优于至少一个替代方案，以及如何验证它成立。
-
-## 验证
-
-声明完成前至少给出：
-
-- 实际运行的验证命令
-- 退出结果
-- 与本次任务相关的关键输出
-- 未运行的验证及原因
-
-不能用历史结果、主观判断或“应该没问题”替代验证证据。
+# SDD + TDD 开发工作流
+
+## 角色定位
+
+这是完整交付的编排 skill，不是每个阶段的详细教程。它负责把需求按阶段推进，并在进入具体阶段时再读取对应专项 skill。
+
+渐进式披露规则：
+
+- 当前只需要路由和门控时，只读取本文。
+- 进入某个阶段时，再加载该阶段 skill。
+- 不把所有阶段规则同时塞进上下文。
+- 发现任务变成 bug、文档、发布或上下文问题时，切换到对应入口，不继续硬走完整流程。
+
+## 快速路径
+
+1. 判断任务是否需要完整交付；简单修复、文档或调查任务不要套完整流程。
+2. 若需求模糊，先进入 `brainstorming-and-design` 或 `spec-driven-development`。
+3. 若规格清楚，进入 `planning-and-task-breakdown`。
+4. 计划确认后，进入 `incremental-implementation` + `test-driven-development`。
+5. 实现完成后，进入 `code-review-and-quality`。
+6. 准备声明完成前，进入 `verification-before-completion`。
+7. 需要提交时，进入 `git-workflow-and-versioning`，并等待用户确认。
+8. 周期结束或需要沉淀经验时，进入 `sprint-retrospective`。
+
+## 阶段门控
+
+| 阶段 | 默认入口 | 通过条件 |
+|---|---|---|
+| Brainstorm（可选） | `brainstorming-and-design` | 目标、约束、方案方向已收敛 |
+| Specify | `spec-driven-development` | 规格可测试，假设已显式列出 |
+| Plan | `planning-and-task-breakdown` | 任务有依赖、文件边界和验证方式 |
+| Plan Review（可选） | `multi-perspective-review` | `GO / REVISE / NO-GO` 结论明确 |
+| Build | `incremental-implementation` + `test-driven-development` | 每个切片实现、测试、回归通过 |
+| Review | `code-review-and-quality` | Critical/Important 已处理或有明确延后理由 |
+| Verify | `verification-before-completion` | 新鲜验证命令通过，输出已读 |
+| Commit（可选） | `git-workflow-and-versioning` | 用户确认提交范围和消息 |
+| Retro（可选） | `sprint-retrospective` | 偏差、复盘和行动项已记录 |
+
+## 构建模式选择
+
+- **Manual（默认）**：你自己按任务串行实现。适合大多数改动。
+- **Subagent-Driven**：任务彼此独立，但用户没有要求并行时，可作为串行委派建议。
+- **Parallel**：用户明确要求多 agent / 并行 / team 模式，且任务有清晰文件所有权时，使用 `parallel-agent-dispatch`。
+- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离或多 CLI worker 时，使用 `team-orchestration`。
+
+除非用户已经明确要求并行，否则只给并行建议，不直接启动子代理或 `zc team`。
+
+推荐提示格式：
+
+```text
+Recommendation: 按 Manual / Parallel / Team 模式推进 because <证据与 trade-off>。
+- 并行收益：
+- 并行代价：
+- 文件所有权：
+- fan-in 验证：
+```
+
+## 阶段切换纪律
+
+- 进入新阶段前，说明当前阶段已满足的证据。
+- 阶段中发现前提失真时，回退到上游阶段，不继续堆实现。
+- 长会话变慢或内容开始混乱时，切到 `context-budget-audit` / `context-engineering`。
+- 变更涉及浏览器体验时，在单元/API 测试之外补 `browser-qa-testing`。
+- 涉及高风险命令、生产数据或敏感文件时，先切到 `safety-guardrails`。
+
+## 停线条件
+
+立即停止当前阶段并重新定位：
+
+- 测试、构建或 lint 失败但原因未读清。
+- 用户纠正了需求、范围或安全边界。
+- 计划要求修改的文件和实际代码结构明显不一致。
+- 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
+- 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
+
+## 输出契约
+
+完整交付过程中的关键结论都要使用可审查的推荐格式：
+
+```text
+Recommendation: <下一步动作> because <具体证据、取舍和被放弃的替代方案>。
+```
+
+不要只说“更稳”“更好”“建议继续”。必须说明为什么这个动作优于至少一个替代方案，以及如何验证它成立。
+
+## 验证
+
+声明完成前至少给出：
+
+- 实际运行的验证命令
+- 退出结果
+- 与本次任务相关的关键输出
+- 未运行的验证及原因
+
+不能用历史结果、主观判断或“应该没问题”替代验证证据。

package/vendor/packages/toolkit/src/content/skills/sprint-retrospective/body.md

@@ -1,99 +1,99 @@
-# Sprint Retrospective
-
-## 角色定位
-
-在一个交付周期结束后，用证据复盘计划、实现、审查和验证的质量，并把下一轮要改变的行为写成少量可执行行动项。
-
-Retro 不是情绪总结，也不是长篇过程记录。没有行动项的 retro 通常只是仪式。
-
-## 何时使用
-
-- 完成一次 SDD+TDD 周期后。
-- 一周或一个里程碑结束后。
-- 生产事故、重大返工或计划偏差后。
-- 发现重复摩擦，但还没有明确改进项时。
-- 开始新大任务前，需要先复盘上一轮。
-
-## 快速路径
-
-1. 收集事实：提交、diff、测试、验证、PR/issue、事故记录。
-2. 对照原始 spec / plan，检查 scope drift。
-3. 识别有效做法、失败模式和根因。
-4. 评估流程健康：TDD、review、verify、build、handoff。
-5. 选出最多 3-5 个行动项。
-6. 给每个行动项写 owner、deadline、success metric。
-7. 判断哪些经验应该进入 ADR、docs、skill、memory 或保持为聊天结论。
-
-## 推荐数据
-
-按当前任务范围收集即可，不要为了复盘跑无关统计：
-
-- commit count / changed files / insertions / deletions
-- tests added or changed
-- verification commands and failures
-- review findings and resolution time
-- spec items delivered / modified / deferred / dropped
-- CI/build stability
-
-monorepo 中必须限定路径范围，避免 unrelated diff 污染结论。
-
-## Drift 判断
-
-```text
-Spec drift:
-- Delivered as planned:
-- Modified:
-- Deferred:
-- Added:
-- Dropped:
-- Reason:
-```
-
-drift 不一定是坏事。没有记录的 drift 才危险，因为下一轮会基于错误文档继续推进。
-
-## 行动项格式
-
-```text
-Action item:
-- What:
-- Why:
-- Owner:
-- Deadline:
-- Success metric:
-- Verification:
-```
-
-行动项最多 3-5 个。超过这个数量，优先级通常还没有收敛。
-
-## 知识沉淀边界
-
-- 架构或公共接口决策：进入 ADR / docs。
-- 项目长期约定：进入项目文档或入口规则。
-- 用户偏好或跨会话经验：只有明确授权后才进入 memory。
-- 一次性上下文和临时事故细节：只保留在本次记录中。
-
-## 输出契约
-
-```markdown
-# Retrospective: <period / milestone>
-
-## Evidence
-- ...
-
-## What Worked
-- ...
-
-## What Failed
-- ...
-
-## Drift
-- ...
-
-## Action Items
-- ...
-
-## Recommendation
-Recommendation: <keep / change / document / escalate> because <evidence, trade-off, and rejected alternative>.
-```
-
-推荐必须说明下一轮具体改变什么，而不是只说“继续保持”。
+# Sprint Retrospective
+
+## 角色定位
+
+在一个交付周期结束后，用证据复盘计划、实现、审查和验证的质量，并把下一轮要改变的行为写成少量可执行行动项。
+
+Retro 不是情绪总结，也不是长篇过程记录。没有行动项的 retro 通常只是仪式。
+
+## 何时使用
+
+- 完成一次 SDD+TDD 周期后。
+- 一周或一个里程碑结束后。
+- 生产事故、重大返工或计划偏差后。
+- 发现重复摩擦，但还没有明确改进项时。
+- 开始新大任务前，需要先复盘上一轮。
+
+## 快速路径
+
+1. 收集事实：提交、diff、测试、验证、PR/issue、事故记录。
+2. 对照原始 spec / plan，检查 scope drift。
+3. 识别有效做法、失败模式和根因。
+4. 评估流程健康：TDD、review、verify、build、handoff。
+5. 选出最多 3-5 个行动项。
+6. 给每个行动项写 owner、deadline、success metric。
+7. 判断哪些经验应该进入 ADR、docs、skill、memory 或保持为聊天结论。
+
+## 推荐数据
+
+按当前任务范围收集即可，不要为了复盘跑无关统计：
+
+- commit count / changed files / insertions / deletions
+- tests added or changed
+- verification commands and failures
+- review findings and resolution time
+- spec items delivered / modified / deferred / dropped
+- CI/build stability
+
+monorepo 中必须限定路径范围，避免 unrelated diff 污染结论。
+
+## Drift 判断
+
+```text
+Spec drift:
+- Delivered as planned:
+- Modified:
+- Deferred:
+- Added:
+- Dropped:
+- Reason:
+```
+
+drift 不一定是坏事。没有记录的 drift 才危险，因为下一轮会基于错误文档继续推进。
+
+## 行动项格式
+
+```text
+Action item:
+- What:
+- Why:
+- Owner:
+- Deadline:
+- Success metric:
+- Verification:
+```
+
+行动项最多 3-5 个。超过这个数量，优先级通常还没有收敛。
+
+## 知识沉淀边界
+
+- 架构或公共接口决策：进入 ADR / docs。
+- 项目长期约定：进入项目文档或入口规则。
+- 用户偏好或跨会话经验：只有明确授权后才进入 memory。
+- 一次性上下文和临时事故细节：只保留在本次记录中。
+
+## 输出契约
+
+```markdown
+# Retrospective: <period / milestone>
+
+## Evidence
+- ...
+
+## What Worked
+- ...
+
+## What Failed
+- ...
+
+## Drift
+- ...
+
+## Action Items
+- ...
+
+## Recommendation
+Recommendation: <keep / change / document / escalate> because <evidence, trade-off, and rejected alternative>.
+```
+
+推荐必须说明下一轮具体改变什么，而不是只说“继续保持”。

package/vendor/packages/toolkit/src/content/skills/team-orchestration/body.md

@@ -1,126 +1,126 @@
-# Team Orchestration
-
-## 角色定位
-
-使用 `zc team` 把多个 AI CLI worker 运行在 tmux pane 和 git worktree 中，适合需要文件系统级隔离、长时间并行或多 CLI 协作的任务。
-
-这是重型能力。默认先考虑串行执行或 `parallel-agent-dispatch`；只有用户明确要求多 worker / team 模式，且文件边界清楚时才启动。
-
-## 何时使用
-
-使用：
-
-- 多个任务可以分配给不同 worker。
-- 需要独立 worktree 避免写入冲突。
-- 需要不同 CLI 处理不同类型任务。
-- 任务较长，值得承担 fan-in 和清理成本。
-
-不使用：
-
-- 单个简单任务。
-- 任务高度耦合、共享大量上下文。
-- 没有测试或集成验证方式。
-- 只是想“快一点”，但文件所有权不清。
-
-## 快速路径
-
-1. 先用 `zc doctor` 检查环境。
-2. 用 `zc team plan` 做 dry-run，任务必须带 `files=` 边界。
-3. 只有 `canStart=true` 且用户确认后，才运行 `zc team start`。
-4. 用 `zc team status` 和 `zc team log` 监控 worker。
-5. fan-in 前运行 `zc team shutdown <team> --plan` 查看 clean/dirty/ahead/merged 状态。
-6. 明确每个分支去向后再 `zc team shutdown`。
-
-```bash
-zc doctor
-
-zc team plan \
-  -w 2 \
-  -t "API | files=src/api.ts,src/api.test.ts" \
-  -t "UI | files=src/ui.ts,src/ui.test.ts"
-
-zc team start \
-  -w "w1:codex,w2:qwen-code" \
-  -t "API | files=src/api.ts,src/api.test.ts" \
-  -t "UI | files=src/ui.ts,src/ui.test.ts"
-
-zc team status <team-name>
-zc team log <team-name>
-zc team shutdown <team-name> --plan
-zc team shutdown <team-name>
-```
-
-## 任务描述规则
-
-每个 `-t` 至少包含：
-
-- 任务名
-- `files=` 文件或目录所有权
-- 验收标准
-- 验证命令
-
-示例：
-
-```text
-实现用户认证 API | files=src/auth.ts,src/auth.test.ts | verify=pnpm test auth
-```
-
-没有 `files=` 时，默认不能证明任务可安全并行。
-
-## 启动前推荐格式
-
-```text
-Recommendation: 使用 zc team because <文件系统隔离收益> outweighs <tmux/worktree/fan-in 成本>。
-- worker：
-- worktree 边界：
-- 不使用 team 的替代方案：
-- fan-in 验证：
-- 清理策略：
-
-确认后我再启动；不确认则按串行或 Context Fan-Out 推进。
-```
-
-## Worker 协作纪律
-
-- 每个 worker 只修改自己的 `files=` 范围。
-- 共享接口变更必须通过 mailbox 或主线程广播。
-- worker 完成时报告修改文件、验证结果和待集成事项。
-- 主线程负责最终集成，不把 fan-in 交给任意单个 worker 自行处理。
-
-## Fan-In 与收尾
-
-结束前必须记录：
-
-```text
-Team acceptance transcript:
-- Team:
-- Workers:
-- Task ownership:
-- Branch/worktree status:
-- Worker results:
-- Integrated diff:
-- Verification:
-- Cleanup:
-```
-
-收尾判断：
-
-- clean 且已合入：可删除 worktree/branch。
-- dirty：先读 diff，决定合入、保留或放弃。
-- ahead 但未合入：明确是否提交、PR 或丢弃。
-- unknown：不要直接删除，先人工确认状态。
-
-## 边界与安全
-
-- 不把 `zc team` 当成默认实现方式。
-- 不为了形式统一创建多个 worker。
-- 不在未验证 `canStart=true` 时启动。
-- 不直接清理 dirty worktree。
-- 不混入破坏性 git 操作；需要删除或重置时必须先确认。
-
-## 相关技能
-
-- `parallel-agent-dispatch`：上下文级并行，成本更低。
-- `subagent-driven-development`：串行子代理委派。
-- `branch-finish-and-cleanup`：分支和 worktree 收尾。
-- `verification-before-completion`：声明完成前的最终证据门禁。
+# Team Orchestration
+
+## 角色定位
+
+使用 `zc team` 把多个 AI CLI worker 运行在 tmux pane 和 git worktree 中，适合需要文件系统级隔离、长时间并行或多 CLI 协作的任务。
+
+这是重型能力。默认先考虑串行执行或 `parallel-agent-dispatch`；只有用户明确要求多 worker / team 模式，且文件边界清楚时才启动。
+
+## 何时使用
+
+使用：
+
+- 多个任务可以分配给不同 worker。
+- 需要独立 worktree 避免写入冲突。
+- 需要不同 CLI 处理不同类型任务。
+- 任务较长，值得承担 fan-in 和清理成本。
+
+不使用：
+
+- 单个简单任务。
+- 任务高度耦合、共享大量上下文。
+- 没有测试或集成验证方式。
+- 只是想“快一点”，但文件所有权不清。
+
+## 快速路径
+
+1. 先用 `zc doctor` 检查环境。
+2. 用 `zc team plan` 做 dry-run，任务必须带 `files=` 边界。
+3. 只有 `canStart=true` 且用户确认后，才运行 `zc team start`。
+4. 用 `zc team status` 和 `zc team log` 监控 worker。
+5. fan-in 前运行 `zc team shutdown <team> --plan` 查看 clean/dirty/ahead/merged 状态。
+6. 明确每个分支去向后再 `zc team shutdown`。
+
+```bash
+zc doctor
+
+zc team plan \
+  -w 2 \
+  -t "API | files=src/api.ts,src/api.test.ts" \
+  -t "UI | files=src/ui.ts,src/ui.test.ts"
+
+zc team start \
+  -w "w1:codex,w2:qwen-code" \
+  -t "API | files=src/api.ts,src/api.test.ts" \
+  -t "UI | files=src/ui.ts,src/ui.test.ts"
+
+zc team status <team-name>
+zc team log <team-name>
+zc team shutdown <team-name> --plan
+zc team shutdown <team-name>
+```
+
+## 任务描述规则
+
+每个 `-t` 至少包含：
+
+- 任务名
+- `files=` 文件或目录所有权
+- 验收标准
+- 验证命令
+
+示例：
+
+```text
+实现用户认证 API | files=src/auth.ts,src/auth.test.ts | verify=pnpm test auth
+```
+
+没有 `files=` 时，默认不能证明任务可安全并行。
+
+## 启动前推荐格式
+
+```text
+Recommendation: 使用 zc team because <文件系统隔离收益> outweighs <tmux/worktree/fan-in 成本>。
+- worker：
+- worktree 边界：
+- 不使用 team 的替代方案：
+- fan-in 验证：
+- 清理策略：
+
+确认后我再启动；不确认则按串行或 Context Fan-Out 推进。
+```
+
+## Worker 协作纪律
+
+- 每个 worker 只修改自己的 `files=` 范围。
+- 共享接口变更必须通过 mailbox 或主线程广播。
+- worker 完成时报告修改文件、验证结果和待集成事项。
+- 主线程负责最终集成，不把 fan-in 交给任意单个 worker 自行处理。
+
+## Fan-In 与收尾
+
+结束前必须记录：
+
+```text
+Team acceptance transcript:
+- Team:
+- Workers:
+- Task ownership:
+- Branch/worktree status:
+- Worker results:
+- Integrated diff:
+- Verification:
+- Cleanup:
+```
+
+收尾判断：
+
+- clean 且已合入：可删除 worktree/branch。
+- dirty：先读 diff，决定合入、保留或放弃。
+- ahead 但未合入：明确是否提交、PR 或丢弃。
+- unknown：不要直接删除，先人工确认状态。
+
+## 边界与安全
+
+- 不把 `zc team` 当成默认实现方式。
+- 不为了形式统一创建多个 worker。
+- 不在未验证 `canStart=true` 时启动。
+- 不直接清理 dirty worktree。
+- 不混入破坏性 git 操作；需要删除或重置时必须先确认。
+
+## 相关技能
+
+- `parallel-agent-dispatch`：上下文级并行，成本更低。
+- `subagent-driven-development`：串行子代理委派。
+- `branch-finish-and-cleanup`：分支和 worktree 收尾。
+- `verification-before-completion`：声明完成前的最终证据门禁。