@colin4k1024/tsp 2.4.0

package/commands/team-closeout.md

@@ -0,0 +1,49 @@
+# /team-closeout
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+用于在发布与观察窗口结束后做最终收口，确认最终验收状态、残余风险处置、遗留项回写和任务关闭结论。
+
+## 主责角色
+
+- `tech-lead`
+
+## 期望输入
+
+- 发布结果与观察窗口记录
+- 最终验收或业务确认结论
+- 残余风险与事故 / 回滚情况
+- 需要回写的 backlog / follow-up 项
+- 已落盘的 PRD、Delivery Plan、Review、Release 等主链 artifact
+
+## 标准输出
+
+- 最终收口结论
+- 最终验收状态
+- 观察窗口结论
+- 残余风险处置结果
+- backlog 回写清单
+- 任务关闭状态
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 确认 `/team-release` 已完成，并具备发布结果、观察窗口、监控与回滚证据；若仍在发布中或观察窗口未结束，不得进入 closeout。
+2. 复核最终验收是否满足上线目标、业务可用性与主要风险边界，必要时对发布结果、观察窗口充分性和遗留项处理方式提出质疑。
+3. 把残余风险分类为接受、转移、延后处理或重新打开主链，并为每项风险明确责任人与下一步动作。
+4. 若观察窗口内出现事故、回滚或严重偏差，明确任务状态为 `re-open` 或 `follow-up-required`，而不是直接关闭。
+5. 若任务启用了 private enterprise overlay、配套私有 runbook 或 overlay，确认 closeout 结论已经消费这些领域证据，不允许只引用口头结论。
+6. 形成最终收口结论，明确 `最终验收状态`、`观察窗口结论`、`backlog 回写` 和 `任务关闭结论`。
+7. 向相关角色回传 closeout 结果：若已关闭则同步后续跟踪项；若未关闭则明确重开入口和责任链。
+8. 【落盘 — 必须执行，不可跳过】
+① 复用既有任务 slug。
+② 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact closeout-summary --role tech-lead --status draft --state {final_state}` 创建 `closeout-summary.md`，其中 `{final_state}` 取 `closed`、`re-open` 或 `follow-up-required`。
+③ 立即在 `closeout-summary.md` 中补全：最终验收状态、观察窗口结论、残余风险处置、backlog 回写、任务关闭结论、lessons learned。
+④ 执行 `npm run artifact:persist -- write-project-context --project-name {project_name} --current-task {YYYY-MM-DD}-{slug} --phase {final_state} --tech-stack "{tech_stack_item}" --dependency "{dependency_item}" --risk "{risk_item}" --next-step "{next_step_item}"` 刷新 `docs/memory/project-context.md`。
+⑤ 若有 backlog 回写，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type backlog --title {backlog_title} --content "{backlog_markdown}"`。
+⑥ 若有跨任务经验沉淀，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type lessons --title {lesson_title} --content "{lesson_markdown}"`。
+⑦ 执行 `npm run artifact:persist -- write-session-summary --date {YYYY-MM-DD} --slug {slug} --role tech-lead --title "Closeout Summary - {slug}" --content "{session_summary_markdown}"` 写入 `docs/memory/sessions/{YYYY-MM-DD}-{NNN}-{slug}.md`。
+⑧ 完成后逐条输出确认：`已创建 closeout-summary.md`，`已刷新 project-context.md`，`已创建 sessions/{filename}`。

package/commands/team-execute.md

@@ -0,0 +1,83 @@
+# /team-execute
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+用于驱动前端、后端等实现角色在既定边界内完成交付，但只有在 readiness proof、需求挑战会、设计收口和 handoff 都齐备后才允许进入实现。
+
+## 主责角色
+
+- `backend-engineer`
+
+## 期望输入
+
+- 方案、契约、任务拆解
+- docs/memory/project-context.md（当前任务、关键依赖、活跃风险）
+- story slice / 当前执行单元
+- 实现范围与验收标准
+- 技能装配清单
+- 若涉及前端则附设计系统与体验约束
+- 需求挑战会结论
+- 上游 handoff
+- downstream challenge record
+
+## 标准输出
+
+- 实现结果
+- 自测结论
+- 交给 QA 的说明
+- story slice 完成状态
+- 领域扩展执行记录
+- 必要时补充 UI 检查清单
+- readiness proof
+- 阻断/回退说明
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 先确认本次实现范围与不做项，并核对是否已具备进入实现的 readiness proof。
+2. 实现阶段默认遵循 `karpathy-guidelines`：锁定 in-scope / out-of-scope、优先最小实现、保持改动外科化，并按明确成功标准落地而不是边做边猜。
+3. 执行前运行 `npm run workflow:readiness -- --phase execute --task-dir docs/artifacts/{YYYY-MM-DD}-{slug}`；若校验失败，停止实现并回补 challenge、design review、handoff 或 artifact 证据。
+4. 若缺少需求挑战会、上游 handoff 或 Design Review 结论，立即停止并回交 tech-lead。
+5. 开始实现前先消费 `docs/memory/project-context.md`，确认当前任务、关键依赖、活跃风险与团队约束未过期。
+6. 一次 `/team-execute` 默认只消费一个 story-sized execution unit；若当前 slice 无法独立验收或独立 handoff，先回到 `/team-plan` 重切。
+7. 若任务命中领域扩展层，先读取对应 `skills/` 技能；若命中配套 runbook / profile / toolkit，也先补看对应文档再开始实现。
+8. 若包含前端变更，优先复用设计 token、遵循响应式与可访问性基线，并记录关键交互和边界态。
+9. 若实现中遇到连续修错、跨模块链路或表象报错，切到 `systematic-debugging` 先定位根因，再继续修改。
+10. 以最小改动完成实现并记录影响面。
+11. 即便使用 private enterprise overlay，也要把最终实现说明、自测结果和风险统一归并到 `/handoff` 输出中。
+12. 若前端变更需要真实浏览器验证，补用 `browser-smoke-testing` 形成关键页面 / 核心路径 smoke 证据。
+13. 前端交付前使用 `templates/ui-review-checklist.md` 补齐自测证据，再通过 `/handoff` 交给 QA 或 DevOps。
+14. 完成自测后通过 `/handoff` 交给 QA 或 DevOps。
+15. 【落盘 — 必须执行，不可跳过】
+① 确认任务 slug。
+② 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact execute-log --role backend-engineer --status draft --state execute` 创建 `execute-log.md`。
+③ 立即在 `execute-log.md` 中补全：计划 vs 实际偏差、实施中的关键决定、阻塞与解决方式、影响面、未完成项。
+④ 若实施中有轻量决策需要跨任务沉淀，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type decisions --title {decision_title} --content "{decision_markdown}"` 追加到 `docs/memory/decisions.md`。
+⑤ 若实施中产生新 ADR，按既有规则在 `docs/adr/` 新建并同步 INDEX 的 ADR 列。
+⑥ 完成后输出确认：`已创建 execute-log.md`。
+
+## Claude 子 Agent 调用
+
+> 以下调用需要 `runSubagent` 工具。满足触发条件时，在当前对话中发起。
+
+### 并行调用（parallel）
+
+**触发条件**：任务同时涉及前端和后端实现，且用户选择并行时
+
+| 子 Agent | agentName | 职责范围 |
+|-----------|-----------|----------|
+| frontend-engineer | `frontend-engineer` | 页面与组件开发、样式与交互、自测证据 |
+| backend-engineer | `backend-engineer` | 接口实现、数据访问、业务逻辑、自测验证 |
+
+**Prompt 模板**（调用时将 `{task_context}` 替换为当前任务背景，`{role_name}` 替换为对应角色名，`{scope}` 替换为职责范围）：
+
+> 你是 Team Skills Platform 中的 {role_name}。基于以下实现规范，完成 {scope} 的具体实现：
+>
+> {task_context}
+>
+> 要求：说明实现范围、关键决策、自测结果和影响面。
+
+**汇总**：所有子 Agent 完成后，由 `tech-lead` 将结果合并落盘到 execute-log.md。

package/commands/team-help.md

@@ -0,0 +1,41 @@
+# /team-help
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+作为 `/team-*` 主链唯一公开入口，根据当前项目阶段、已有 artifacts 与用户目标，推荐下一条最合适的 `/team-*` 或 `/quick` 命令，并指出前置缺口、阻塞项与降级路径。
+
+## 主责角色
+
+- `tech-lead`
+
+## 期望输入
+
+- 当前目标或遇到的问题
+- 当前阶段（若已知）
+- 已存在的 artifacts / handoff / 测试证据
+- 是否为既有项目（brownfield）
+- 是否希望走快速模式或完整主链
+
+## 标准输出
+
+- 推荐的下一条命令
+- 推荐原因与适用前提
+- 进入下一步前必须补齐的证据与 `artifact:persist` 落盘动作
+- brownfield 补齐建议
+- 若不满足条件时的降级路径
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 先识别用户当前所处阶段：是新需求、挑战会 / 设计收口、准备实现、准备评审、准备发布、观察窗口收口，还是只想处理小范围快速任务。
+2. 默认以 `karpathy-guidelines` 的方式先暴露歧义、范围边界与更简单路径，不在入口阶段静默替用户补全高风险假设。
+3. 检查现有证据是否齐备：PRD、delivery-plan、arch-design、handoff、execute-log、test-plan、launch-acceptance、deployment-context、release-plan、closeout-summary，以及 `docs/memory/project-context.md`。
+4. 若任务边界清晰、影响面小、风险低，优先推荐 `/quick`；否则继续沿 `/team-*` 主链推进。
+5. 若是既有项目（brownfield）且现状上下文不足，优先建议执行 `/update-codemaps` 并启用 `doc-architecture`，把现有模块、集成点、关键数据流和历史包袱回落到 `delivery-plan.md` / `arch-design.md`。
+6. 若需求规模较大或涉及多角色并行，实现前先要求把计划切成可独立验收、可独立 handoff 的 story-sized execution units，并确认 `artifact:persist` 已创建对应任务目录与关键 artifact，再进入 `/team-execute`。
+7. 若缺少 PRD 或需求边界，推荐 `/team-intake`；若缺少 challenge、design review 或 implementation-readiness，推荐 `/team-plan`；若 readiness proof 与 handoff 齐备，推荐 `/team-execute`；若已完成实现与自测，推荐 `/team-review`；若已获得放行，推荐 `/team-release`；若发布观察窗口结束，推荐 `/team-closeout`。
+8. 若是既有项目且上下文不足，提示先补齐 brownfield / doc-architecture 类上下文，再进入计划或执行。
+9. 输出结构化建议：推荐命令、原因、阻塞项、降级路径，并说明是否需要先运行 `npm run workflow:readiness`。

package/commands/team-intake.md

@@ -0,0 +1,50 @@
+# /team-intake
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+用于接收需求、梳理目标、范围、约束和参与角色，并在涉及 UI 时提前锁定体验与质量门槛，同时输出需要进入需求挑战会的候选分组。
+
+## 主责角色
+
+- `tech-lead`
+
+## 期望输入
+
+- 需求背景
+- 目标与优先级
+- 关键约束与时间窗口
+- 是否涉及 UI、终端与设计约束
+- 是否企业内部应用、是否存在数据 / 合规风险
+- 是否涉及私有流程、权限系统、内部发布流程、私有观测或专属业务建模等 private enterprise overlay 线索
+
+## 标准输出
+
+- 需求简报
+- 参与角色清单
+- 待确认项列表
+- 企业治理待确认项
+- 领域技能包启用建议
+- UI 范围、终端假设与质量门禁
+- 需求挑战会候选分组
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 识别问题、目标、成功标准和上线时限。
+2. 默认使用 `karpathy-guidelines` 收敛 intake：显式写出关键假设、最小可行范围、非目标以及成功标准，避免把模糊愿望直接带进后续计划。
+3. 若任务包含架构文档补齐或演进，启用 `doc-architecture`，按 `docs/runbooks/doc-architecture-integration.md` 收集 Project Profile Card 并约束后续映射。
+4. 若为企业内部应用，先确认应用等级、技术架构等级、数据 / 合规风险是否需要后续补判。
+5. 识别是否需要私有 enterprise overlay 才能完成任务，并列出候选 overlay 能力、私有 runbook 或额外安装前提。
+6. 若需求包含前端变更，明确目标端、产品类型、关键页面、设计约束，以及可访问性和性能基线。
+7. 若任务复杂或存在方案分歧，提前建议需要参加需求挑战会的动态分组。
+8. 确认由哪些角色参与以及各自的输入缺口。
+9. 输出结构化 intake 结果并准备进入 `/team-plan`。
+10. 【落盘 — 必须执行，不可跳过】
+① 根据需求标题生成 slug（小写英文 + 短横线，≤30 字符，例 `user-login-flow`）。
+② 立即执行 `npm run artifact:persist -- ensure-task --date {YYYY-MM-DD} --slug {slug} --state intake`，确保 `docs/artifacts/{YYYY-MM-DD}-{slug}/` 和 INDEX 任务行存在。
+③ 再执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact prd --role tech-lead --status draft --state intake` 创建 `prd.md`。
+④ 立即在 `prd.md` 中补全本次 intake 的完整结构化内容（目标、范围、用户故事、风险、待确认项）。
+⑤ 完成后输出确认：`已创建 docs/artifacts/{YYYY-MM-DD}-{slug}/prd.md`。

package/commands/team-plan.md

@@ -0,0 +1,105 @@
+# /team-plan
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+用于先完成需求挑战会与设计收口，再锁定交付计划、角色分工、风险与依赖，并形成 implementation-readiness 结论，把前端治理要求前置到方案阶段。
+
+## 主责角色
+
+- `tech-lead`
+
+## 期望输入
+
+- 需求简报或 PRD
+- 现有技术上下文
+- 资源和时间约束
+- 设计与体验约束
+- intake 中识别的领域线索
+
+## 标准输出
+
+- 交付计划
+- 需求挑战会结论
+- implementation-readiness 结论与执行前提
+- brownfield 上下文快照
+- story slice 列表
+- 角色分工
+- 风险与依赖清单
+- 应用等级 / 技术架构等级 / 关键组件偏离
+- 是否需要 ADR
+- 技能装配清单
+- 前端交付物与检查点
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 先完成需求挑战会：明确至少 3 个核心假设、对应质疑人、结论与未决项，再进入方案收口。
+2. 默认把 `karpathy-guidelines` 作为计划收口护栏：要求显式写出假设、更简单备选路径、当前不做项，以及为什么本轮范围已经足够。
+3. 按任务特征装配动态讨论分组，先讨论再收敛，避免未经质疑直接进入计划冻结。
+4. 若启用 `doc-architecture`，补齐 Service Catalog、Communication Matrix、NFR Summary，并明确其 artifact 回落位置。
+5. 若是既有项目（brownfield），先梳理现有模块边界、外部依赖、历史约束和缺失文档；必要时运行 `/update-codemaps`，再把 brownfield snapshot 回落到 `delivery-plan.md` 与 `arch-design.md`。
+6. 若为企业内部应用，锁定应用等级、技术架构等级、关键组件偏离和资产入口要求，并判断是否必须输出 ADR。
+7. 为本次任务显式装配 shared 能力、ECC 增强与可选 enterprise overlay 组合，并说明哪些私有 overlay 能力、runbook 或 overlay 仅按场景启用。
+8. 若存在多参数、多角色、多配置或多终端组合，提前判断是否需要 `pairwise-test-design` 压缩测试矩阵。
+9. 若包含 UI，锁定产品类型、视觉方向、设计 token、响应式基线，以及 `/team-review` 需要的前端证据。
+10. 在需求挑战会与并行设计都完成之前，不得把交付计划标记为可执行。
+11. 把实现工作切成 story-sized execution units：每个 slice 必须有清晰目标、验收标准、依赖、owner 和 handoff 终点，避免把多个高风险改动揉成一次 `/team-execute`。
+12. 在计划冻结前运行 `npm run workflow:readiness -- --phase execute --task-dir docs/artifacts/{YYYY-MM-DD}-{slug}` 校验 implementation-readiness；若失败，先回补 challenge、design review、handoff 或 artifact 证据。
+13. 指定每个阶段的主责角色与交接顺序。
+14. 明确风险、阻塞、升级点和检查节点，并沉淀 ADR 所需输入。
+15. 【落盘 — 必须执行，不可跳过】
+① 复用 intake 阶段已有的 slug。
+② 立即执行 `npm run artifact:persist -- ensure-task --date {YYYY-MM-DD} --slug {slug} --state plan`，确保任务目录和 INDEX 行可复用。
+③ 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact delivery-plan --role tech-lead --status draft --state plan` 创建 `delivery-plan.md`。
+④ 若本阶段产出架构设计，执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact arch-design --role architect --status draft --state plan` 创建 `arch-design.md`。
+⑤ 如需 ADR，按既有规则在 `docs/adr/` 新建并同步 INDEX 的 ADR 列。
+⑥ 执行 `npm run artifact:persist -- write-project-context --project-name {project_name} --current-task {YYYY-MM-DD}-{slug} --phase handoff-ready --tech-stack "{tech_stack_item}" --dependency "{dependency_item}" --risk "{risk_item}" --next-step "{next_step_item}"` 刷新 `docs/memory/project-context.md`。
+⑦ 完成后逐条输出确认，例如：`已创建 delivery-plan.md / arch-design.md`，`已刷新 project-context.md`。
+
+## Claude 子 Agent 调用
+
+> 以下调用需要 `runSubagent` 工具。满足触发条件时，在当前对话中发起。
+
+### 需求挑战会（challenge）
+
+**触发条件**：需求刚进入方案阶段、核心假设尚未被挑战或任务存在明显分歧时
+
+| 子 Agent | agentName | 职责范围 |
+|-----------|-----------|----------|
+| product-manager | `product-manager` | 业务目标、范围边界、用户价值与可验证假设 |
+| project-manager | `project-manager` | 工期压力、依赖关系、串行假设与并行化机会 |
+| architect | `architect` | 技术可行性、架构边界、方案取舍与失败模式 |
+
+**Prompt 模板**（调用时将 `{task_context}` 替换为当前任务背景，`{role_name}` 替换为对应角色名，`{scope}` 替换为职责范围）：
+
+> 你是 Team Skills Platform 中的 {role_name}。基于以下任务背景，先挑战 {scope} 相关的核心假设，不要直接进入方案收口：
+>
+> {task_context}
+>
+> 要求：至少列出 1 条质疑、1 个替代路径、1 个阻断条件，并输出可回填到 Requirement Challenge Session Log 的内容。
+
+**汇总**：所有子 Agent 完成后，由 `tech-lead` 将结果合并落盘到 delivery-plan.md。
+
+### 并行调用（parallel）
+
+**触发条件**：任务涉及架构设计、接口设计或全栈改动时（由 tech-lead 在对话中判断）
+
+| 子 Agent | agentName | 职责范围 |
+|-----------|-----------|----------|
+| architect | `architect` | 系统边界、组件拆分、数据流、接口约定、技术选型、风险与约束 |
+| frontend-engineer | `frontend-engineer` | 关键页面结构、组件划分、设计 token、响应式基线、A11y 要求（任务涉及前端改动时） |
+| backend-engineer | `backend-engineer` | 接口契约、数据模型、核心业务逻辑、异常路径 |
+| ui-ux-designer | `ui-ux-designer` | 页面结构、交互流、设计 token、响应式策略、体验风险清单（任务涉及 UI 变更时） |
+
+**Prompt 模板**（调用时将 `{task_context}` 替换为当前任务背景，`{role_name}` 替换为对应角色名，`{scope}` 替换为职责范围）：
+
+> 你是 Team Skills Platform 中的 {role_name}。基于以下任务背景，产出 {scope} 方面的设计成果：
+>
+> {task_context}
+>
+> 要求：结论清晰，标注风险与约束，产出可落盘的格式。
+
+**汇总**：所有子 Agent 完成后，由 `tech-lead` 将结果合并落盘到 delivery-plan.md、arch-design.md。

package/commands/team-release.md

@@ -0,0 +1,71 @@
+# /team-release
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+用于组织发布准备、上线验证、监控与回滚保障，并在前端发布时覆盖 UI smoke、性能和回滚可见性。
+
+## 主责角色
+
+- `devops-engineer`
+
+## 期望输入
+
+- 测试放行结论
+- 发布窗口
+- 环境与回滚要求
+- 发布负责人 / 值守人与观察窗口
+- launch acceptance 结论
+- 企业治理上下文
+- 若涉及前端则附 smoke 范围和关键监控项
+
+## 标准输出
+
+- 发布方案
+- 部署上下文
+- 上线检查结果
+- 放行结论与后续观察项
+- 回滚与监控动作
+- 企业内控补充信息
+- 前端发布验证记录
+- 可选领域扩展执行记录
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 汇总发布范围、质量状态和环境前置条件。
+2. 默认沿用 `karpathy-guidelines` 复核发布输入：确认 release notes、rollout 范围、观察项与回滚前提仍然对应已约定的最小变更和成功标准，没有在发布阶段悄悄扩 scope。
+3. 记录发布责任链、执行步骤、暂停点 / Go-No-Go 判断点，以及观察窗口。
+4. 若包含前端变更，补充关键页面 smoke、静态资源发布风险、性能基线和回滚触发条件，必要时使用 `browser-smoke-testing` 留下真实浏览器验证证据。
+5. 若发布范围包含 GitHub Actions workflow、reusable workflow 或 release automation 变更，参考 `docs/runbooks/actionlint-workflow-gates.md` 与 `docs/runbooks/zizmor-workflow-audits.md` 汇总 workflow lint、安全审计与 triage 结论。
+6. 若发布范围包含 GitHub Actions workflow 的 `permissions`、默认 workflow 权限或 `GITHUB_TOKEN` scope 收敛，参考 `docs/runbooks/github-token-permissions-baseline.md` 汇总最小权限建议、例外和回退边界。
+7. 若发布范围包含 Terraform、CloudFormation、Bicep、ARM、OpenTofu、Helm、Kubernetes 或其他 IaC / 模板基线检查，参考 `docs/runbooks/checkov-iac-gates.md` 汇总 IaC 安全与合规预检结论。
+8. 若发布范围包含 Kubernetes manifests、Helm 渲染结果、kustomize 输出或 CRD schema 覆盖，参考 `docs/runbooks/kubeconform-schema-gates.md` 汇总 schema 校验、版本边界和覆盖缺口。
+9. 若发布范围包含 Helm chart 模板、values 组合、subchart 或 snapshot 回归，参考 `docs/runbooks/helm-unittest-playbook.md` 汇总 chart 层单测、snapshot 漂移和覆盖缺口。
+10. 若发布需要把 manifests 送到目标 API server 做不落盘预检，参考 `docs/runbooks/kubectl-server-dry-run-gates.md` 汇总 server-side validation、field conflict 和接收性结论。
+11. 若发布涉及容器镜像、Dockerfile、Helm、Kubernetes、Terraform 或仓库文件系统扫描，参考 `docs/runbooks/trivy-security-gates.md` 汇总镜像 / 文件系统 / IaC 扫描结果，并回写到放行结论或观察项。
+12. 若发布涉及 Helm、Kubernetes、Terraform、YAML、JSON 或其他结构化配置策略，参考 `docs/runbooks/conftest-policy-gates.md` 汇总 policy-as-code 预检、例外条件和阻塞结论。
+13. 若发布依赖 Kubernetes admission、background scan、policy reports 或 image verification 结果，参考 `docs/runbooks/kyverno-policy-gates.md` 汇总 `Audit/Enforce` 状态、policy 命中和例外边界。
+14. 若发布链主要运行在 GitHub Actions，且需要收敛 runner 的外部访问面或跟踪异常出站连接，参考 `docs/runbooks/runner-egress-hardening.md` 汇总 allowlist、异常访问和 triage 责任。
+15. 若发布包含二进制、容器镜像、压缩包或其他正式制品，参考 `docs/runbooks/sbom-generation-gates.md` 汇总 SBOM 生成范围、归档位置和版本追溯关系。
+16. 若发布需要为正式制品补 provenance 证明，参考 `docs/runbooks/artifact-attestation-gates.md` 汇总 attestation 的生成范围、归档位置和与产物的对应关系。
+17. 若发布链需要在 GitHub Actions 中整理更通用的 provenance 生成模式，参考 `docs/runbooks/slsa-generator-patterns.md` 汇总 workflow 约束、subject 绑定关系和归档方式。
+18. 若发布需要统一 attestation 的 predicate、schema 和 evidence model，参考 `docs/runbooks/in-toto-attestation-framework.md` 汇总证据结构、版本边界和与发布记录的映射方式。
+19. 若发布需要为正式制品或镜像补签名与验签链路，参考 `docs/runbooks/cosign-signing-gates.md` 汇总签名范围、验签入口和发布记录回链。
+20. 若发布需要独立验证 provenance / attestation，参考 `docs/runbooks/slsa-verification-gates.md` 汇总验证输入、验证结果和失败处置策略。
+21. 若集群侧需要在 admission 层强制执行签名、attestation 或验证策略，参考 `docs/runbooks/policy-controller-gates.md` 汇总策略范围、拒绝原因、例外流程和回退路径。
+22. 若发布链需要基于执行证据做更高阶的策略评估，参考 `docs/runbooks/witness-policy-gates.md` 汇总 evidence 来源、policy 规则、评估结果和例外处理。
+23. 若为企业内部应用，在发布方案中补齐应用等级、技术架构等级、资源隔离、关键组件偏离和资产入口。
+24. 若发布链命中 GitLab 手动流水线补充手册，可附加其执行记录，但不替代默认发布方案与验证步骤。
+25. 执行发布前后检查并记录结果，形成最终放行结论。
+26. 向 `tech-lead` 回报发布状态、放行结论和后续观察项。
+27. 【落盘 — 必须执行，不可跳过】
+① 确认任务 slug。
+② 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact deployment-context --role devops-engineer --status draft --state released` 创建 `deployment-context.md`。
+③ 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact release-plan --role devops-engineer --status draft --state released` 创建 `release-plan.md`。
+④ 立即在两个文件中补全环境、配置、密钥来源、部署入口、回滚入口、发布信息、执行步骤、验证与监控、放行结论。
+⑤ 执行 `npm run artifact:persist -- write-project-context --project-name {project_name} --current-task {YYYY-MM-DD}-{slug} --phase released --tech-stack "{tech_stack_item}" --dependency "{dependency_item}" --risk "{risk_item}" --next-step "{next_step_item}"` 刷新 `docs/memory/project-context.md`。
+⑥ 若发布中有值得跨任务沉淀的经验教训，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type lessons --title {lesson_title} --content "{lesson_markdown}"` 追加到 `docs/memory/lessons-learned.md`。
+⑦ 完成后逐条输出确认：`已创建 deployment-context.md / release-plan.md`，`已刷新 project-context.md`。

package/commands/team-review.md

@@ -0,0 +1,80 @@
+# /team-review
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+用于评审方案、实现、测试结果和交付质量，并在前端变更时强制检查视觉、交互、无障碍和性能。
+
+## 主责角色
+
+- `qa-engineer`
+
+## 期望输入
+
+- 实施说明
+- 测试结果
+- 风险和待确认项
+- 若涉及前端则附 UI 评审清单和自测证据
+
+## 标准输出
+
+- 评审结论
+- 阻塞项
+- 放行建议
+- 上线验收结论
+- 前端质量门禁检查结果
+- 领域扩展约束核对结果
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 检查交付物是否满足角色对应的质量门禁。
+2. 默认用 `karpathy-guidelines` 复核本轮交付是否保持最小范围、每处改动都能追溯到用户请求，并且成功标准与实际验证证据一致。
+3. 若启用 `doc-architecture`，按 `docs/runbooks/team-command-output-contracts.md` 的文档一致性审计字段核对服务名、API、事件、鉴权和索引完整性。
+4. 若任务启用了 private enterprise overlay 或配套私有 runbook / overlay，核对相关约束是否被正确执行，但不要把私有领域检查扩散成所有任务的默认门槛。
+5. 若存在明确的 consumer/provider 边界，参考 `docs/runbooks/contract-testing-playbook.md` 核对契约验证是否覆盖关键交互与失败路径。
+6. 若测试矩阵存在组合爆炸，优先用 `pairwise-test-design` 收敛覆盖策略，并说明哪些高风险场景需要额外定向补测。
+7. 若交付物涉及 GitHub Actions workflow、reusable workflow 或 composite action，参考 `docs/runbooks/actionlint-workflow-gates.md` 与 `docs/runbooks/zizmor-workflow-audits.md` 核对 workflow lint、安全审计与 triage 结论。
+8. 若交付物涉及 GitHub Actions workflow 的 `permissions`、默认 workflow 权限或 `GITHUB_TOKEN` scope 收敛，参考 `docs/runbooks/github-token-permissions-baseline.md` 核对最小权限建议、例外和回退边界。
+9. 若交付物涉及 Terraform、CloudFormation、Bicep、ARM、OpenTofu、Helm、Kubernetes 或其他 IaC / 模板基线检查，参考 `docs/runbooks/checkov-iac-gates.md` 核对 IaC 安全与合规预检结论。
+10. 若交付物涉及 Kubernetes manifests、Helm 渲染结果、kustomize 输出或 CRD schema 覆盖，参考 `docs/runbooks/kubeconform-schema-gates.md` 核对 schema 校验、版本边界和覆盖缺口。
+11. 若交付物涉及 Helm chart 模板、values 组合、subchart 或 snapshot 回归，参考 `docs/runbooks/helm-unittest-playbook.md` 核对 chart 层单测、snapshot 漂移和覆盖缺口。
+12. 若交付物需要把 manifests 送到目标 API server 做不落盘预检，参考 `docs/runbooks/kubectl-server-dry-run-gates.md` 核对 server-side validation、field conflict 和接收性结论。
+13. 若交付物涉及 Helm、Kubernetes、Terraform、YAML、JSON 或其他结构化配置策略，参考 `docs/runbooks/conftest-policy-gates.md` 核对 policy-as-code 预检、例外和阻塞条件。
+14. 若交付物涉及 Kubernetes admission、background scan、policy reports 或 image verification，参考 `docs/runbooks/kyverno-policy-gates.md` 核对 `Audit/Enforce` 状态、policy 命中和例外处理。
+15. 若变更涉及前端，必须验证视觉一致性、交互完整性、边界态、无障碍和前端性能。
+16. 若前端主路径或发布前验证需要真实浏览器证据，补用 `browser-smoke-testing`。
+17. 区分阻塞问题和非阻塞风险。
+18. 必要时把冲突升级给 `tech-lead`。
+19. 【落盘 — 必须执行，不可跳过】
+① 确认任务 slug。
+② 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact test-plan --role qa-engineer --status draft --state review` 创建 `test-plan.md`。
+③ 执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact launch-acceptance --role qa-engineer --status draft --state accepted` 创建 `launch-acceptance.md`。
+④ 立即在这两个文件中补全测试范围、风险、Go / No-Go 检查项、已接受风险和最终上线结论。
+⑤ 若评审中有值得跨任务沉淀的经验教训，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type lessons --title {lesson_title} --content "{lesson_markdown}"` 追加到 `docs/memory/lessons-learned.md`。
+⑥ 完成后输出确认：`已创建 test-plan.md / launch-acceptance.md`。
+
+## Claude 子 Agent 调用
+
+> 以下调用需要 `runSubagent` 工具。满足触发条件时，在当前对话中发起。
+
+### 并行调用（parallel）
+
+**触发条件**：有代码变更需要评审时
+
+| 子 Agent | agentName | 职责范围 |
+|-----------|-----------|----------|
+| code-reviewer | `code-reviewer` | 行为回归、设计问题、缺测路径、结构风险 |
+| security-reviewer | `security-reviewer` | 鉴权、注入、敏感数据、依赖漏洞 |
+
+**Prompt 模板**（调用时将 `{task_context}` 替换为当前任务背景，`{role_name}` 替换为对应角色名，`{scope}` 替换为职责范围）：
+
+> 你是 Team Skills Platform 中的 {role_name}。基于以下变更内容，产出 {scope} 方面的评审结论：
+>
+> {task_context}
+>
+> 要求：区分阻塞问题和非阻塞风险，给出明确建议。
+
+**汇总**：所有子 Agent 完成后，由 `qa-engineer` 将结果合并落盘到 test-plan.md。

package/commands/test-coverage.md

@@ -0,0 +1,69 @@
+# Test Coverage
+
+Analyze test coverage, identify gaps, and generate missing tests to reach 80%+ coverage.
+
+## Step 1: Detect Test Framework
+
+| Indicator | Coverage Command |
+|-----------|-----------------|
+| `jest.config.*` or `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
+| `vitest.config.*` | `npx vitest run --coverage` |
+| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
+| `Cargo.toml` | `cargo llvm-cov --json` |
+| `pom.xml` with JaCoCo | `mvn test jacoco:report` |
+| `go.mod` | `go test -coverprofile=coverage.out ./...` |
+
+## Step 2: Analyze Coverage Report
+
+1. Run the coverage command
+2. Parse the output (JSON summary or terminal output)
+3. List files **below 80% coverage**, sorted worst-first
+4. For each under-covered file, identify:
+   - Untested functions or methods
+   - Missing branch coverage (if/else, switch, error paths)
+   - Dead code that inflates the denominator
+
+## Step 3: Generate Missing Tests
+
+For each under-covered file, generate tests following this priority:
+
+1. **Happy path** — Core functionality with valid inputs
+2. **Error handling** — Invalid inputs, missing data, network failures
+3. **Edge cases** — Empty arrays, null/undefined, boundary values (0, -1, MAX_INT)
+4. **Branch coverage** — Each if/else, switch case, ternary
+
+### Test Generation Rules
+
+- Place tests adjacent to source: `foo.ts` → `foo.test.ts` (or project convention)
+- Use existing test patterns from the project (import style, assertion library, mocking approach)
+- Mock external dependencies (database, APIs, file system)
+- Each test should be independent — no shared mutable state between tests
+- Name tests descriptively: `test_create_user_with_duplicate_email_returns_409`
+
+## Step 4: Verify
+
+1. Run the full test suite — all tests must pass
+2. Re-run coverage — verify improvement
+3. If still below 80%, repeat Step 3 for remaining gaps
+
+## Step 5: Report
+
+Show before/after comparison:
+
+```
+Coverage Report
+──────────────────────────────
+File                   Before  After
+src/services/auth.ts   45%     88%
+src/utils/validation.ts 32%    82%
+──────────────────────────────
+Overall:               67%     84%  PASS:
+```
+
+## Focus Areas
+
+- Functions with complex branching (high cyclomatic complexity)
+- Error handlers and catch blocks
+- Utility functions used across the codebase
+- API endpoint handlers (request → response flow)
+- Edge cases: null, undefined, empty string, empty array, zero, negative numbers

package/commands/trigger-pipeline.md

@@ -0,0 +1,25 @@
+# /trigger-pipeline
+
+触发 GitLab 项目最新流水线中所有手动 Job。适用于发版、上线、CD 触发场景。
+
+## 触发词
+
+发版、上线、发布、开始部署、触发流水线、release、deploy
+
+## 输入
+
+用户提供 `PROJECT_ID, TOKEN`，例如 `12522, glpat-xxxxxx`
+
+## 执行
+
+```bash
+python ~/.claude/skills/trigger-gitlab-pipeline/scripts/trigger_pipeline.py <PROJECT_ID> <TOKEN>
+```
+
+## 输出
+
+- Latest Pipeline ID 及状态
+- 找到的手动 Job 数量
+- 每个 Job 的触发结果（OK / FAIL）
+
+**特殊情况**：若输出 `No manual jobs to trigger` 或 `No pipeline records found`，任务正常结束，无需重试。

package/commands/update-codemaps.md

@@ -0,0 +1,32 @@
+# /update-codemaps
+
+> 本文件由 `scripts/build-platform-artifacts.js` 生成，请勿手改。
+
+## 用途
+
+扫描代码结构并生成 token-lean codemaps，适合作为 brownfield 项目的现状快照与主链前置上下文。
+
+## 主责角色
+
+- `doc-updater`
+
+## 期望输入
+
+- 代码仓结构
+- 现有模块、入口、依赖与数据层信息
+- 是否允许覆盖已有 codemap
+
+## 标准输出
+
+- docs/CODEMAPS/ 下的结构化 codemap
+- .reports/codemap-diff.txt 差异摘要
+- 可供 `/team-help` / `/team-plan` 消费的 brownfield context
+
+输出字段定义与交付结构见 [team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)。
+
+## 默认流程
+
+1. 先识别仓库类型、源码目录、入口文件和主要依赖边界。
+2. 为 architecture/backend/frontend/data/dependencies 生成 token-lean 文档，不写实现细节噪音。
+3. 若已有 codemap，先比较变更比例；超过阈值时要求人工确认再覆盖。
+4. 把结果作为 brownfield context snapshot 的辅助输入，回落到 `delivery-plan.md` / `arch-design.md`，不要形成平行事实源。