{
  "schemaVersion": "team.workflow-help-catalog.v1",
  "generatedFrom": "scripts/lib/team-skills-data.json",
  "entryCommand": "/team-help",
  "routeOrder": [
    "/team-intake",
    "/team-plan",
    "/handoff",
    "/team-execute",
    "/team-review",
    "/team-release",
    "/team-closeout"
  ],
  "commands": {
    "/team-intake": {
      "command": "/team-intake",
      "summary": "用于接收需求、梳理目标、范围、约束和参与角色，并在涉及 UI 时提前锁定体验与质量门槛，同时输出需要进入需求挑战会的候选分组。",
      "primaryRole": "tech-lead",
      "requiredInputs": [
        "需求背景",
        "目标与优先级",
        "关键约束与时间窗口",
        "是否涉及 UI、终端与设计约束",
        "是否企业内部应用、是否存在数据 / 合规风险",
        "是否涉及私有流程、权限系统、内部发布流程、私有观测或专属业务建模等 private enterprise overlay 线索"
      ],
      "expectedOutputs": [
        "需求简报",
        "参与角色清单",
        "待确认项列表",
        "企业治理待确认项",
        "领域技能包启用建议",
        "UI 范围、终端假设与质量门禁",
        "需求挑战会候选分组"
      ],
      "gateHints": [
        "识别问题、目标、成功标准和上线时限。",
        "默认使用 `karpathy-guidelines` 收敛 intake：显式写出关键假设、最小可行范围、非目标以及成功标准，避免把模糊愿望直接带进后续计划。",
        "若任务包含架构文档补齐或演进，启用 `doc-architecture`，按 `docs/runbooks/doc-architecture-integration.md` 收集 Project Profile Card 并约束后续映射。"
      ]
    },
    "/team-plan": {
      "command": "/team-plan",
      "summary": "用于先完成需求挑战会与设计收口，再锁定交付计划、角色分工、风险与依赖，并形成 implementation-readiness 结论，把前端治理要求前置到方案阶段。",
      "primaryRole": "tech-lead",
      "requiredInputs": [
        "需求简报或 PRD",
        "现有技术上下文",
        "资源和时间约束",
        "设计与体验约束",
        "intake 中识别的领域线索"
      ],
      "expectedOutputs": [
        "交付计划",
        "需求挑战会结论",
        "implementation-readiness 结论与执行前提",
        "brownfield 上下文快照",
        "story slice 列表",
        "角色分工",
        "风险与依赖清单",
        "应用等级 / 技术架构等级 / 关键组件偏离",
        "是否需要 ADR",
        "技能装配清单",
        "前端交付物与检查点"
      ],
      "gateHints": [
        "先完成需求挑战会：明确至少 3 个核心假设、对应质疑人、结论与未决项，再进入方案收口。",
        "默认把 `karpathy-guidelines` 作为计划收口护栏：要求显式写出假设、更简单备选路径、当前不做项，以及为什么本轮范围已经足够。",
        "按任务特征装配动态讨论分组，先讨论再收敛，避免未经质疑直接进入计划冻结。"
      ]
    },
    "/handoff": {
      "command": "/handoff",
      "summary": "用于在角色之间执行标准化交接，保证上下游共享同一事实，并把阶段切换、下游质疑和 readiness proof 一起交接。",
      "primaryRole": "tech-lead",
      "requiredInputs": [
        "当前角色结论",
        "输入依据",
        "风险与待确认项",
        "必要时附上 UI 方案、截图或检查清单",
        "当前阶段与目标阶段",
        "readiness proof"
      ],
      "expectedOutputs": [
        "结构化交接摘要",
        "下一跳角色动作清单",
        "可追溯的设计和质量证据",
        "阶段切换凭证",
        "readiness proof",
        "下游质疑记录"
      ],
      "gateHints": [
        "按 `rules/handoff-contract.md` 固定交接字段。",
        "先确认当前阶段、目标阶段与 readiness 状态，再决定是否允许下一跳开始。",
        "在 handoff 文件的 frontmatter 中显式写入 `current_phase`、`target_phase`、`readiness_status`、`accepted_by`；在正文中保留 `readiness proof` 与 `downstream challenge record`。"
      ]
    },
    "/team-execute": {
      "command": "/team-execute",
      "summary": "用于驱动前端、后端等实现角色在既定边界内完成交付，但只有在 readiness proof、需求挑战会、设计收口和 handoff 都齐备后才允许进入实现。",
      "primaryRole": "backend-engineer",
      "requiredInputs": [
        "方案、契约、任务拆解",
        "docs/memory/project-context.md（当前任务、关键依赖、活跃风险）",
        "story slice / 当前执行单元",
        "实现范围与验收标准",
        "技能装配清单",
        "若涉及前端则附设计系统与体验约束",
        "需求挑战会结论",
        "上游 handoff",
        "downstream challenge record"
      ],
      "expectedOutputs": [
        "实现结果",
        "自测结论",
        "交给 QA 的说明",
        "story slice 完成状态",
        "领域扩展执行记录",
        "必要时补充 UI 检查清单",
        "readiness proof",
        "阻断/回退说明"
      ],
      "gateHints": [
        "先确认本次实现范围与不做项，并核对是否已具备进入实现的 readiness proof。",
        "实现阶段默认遵循 `karpathy-guidelines`：锁定 in-scope / out-of-scope、优先最小实现、保持改动外科化，并按明确成功标准落地而不是边做边猜。",
        "执行前运行 `npm run workflow:readiness -- --phase execute --task-dir docs/artifacts/{YYYY-MM-DD}-{slug}`；若校验失败，停止实现并回补 challenge、design review、handoff 或 artifact 证据。"
      ]
    },
    "/team-review": {
      "command": "/team-review",
      "summary": "用于评审方案、实现、测试结果和交付质量，并在前端变更时强制检查视觉、交互、无障碍和性能。",
      "primaryRole": "qa-engineer",
      "requiredInputs": [
        "实施说明",
        "测试结果",
        "风险和待确认项",
        "若涉及前端则附 UI 评审清单和自测证据"
      ],
      "expectedOutputs": [
        "评审结论",
        "阻塞项",
        "放行建议",
        "上线验收结论",
        "前端质量门禁检查结果",
        "领域扩展约束核对结果"
      ],
      "gateHints": [
        "检查交付物是否满足角色对应的质量门禁。",
        "默认用 `karpathy-guidelines` 复核本轮交付是否保持最小范围、每处改动都能追溯到用户请求，并且成功标准与实际验证证据一致。",
        "若启用 `doc-architecture`，按 `docs/runbooks/team-command-output-contracts.md` 的文档一致性审计字段核对服务名、API、事件、鉴权和索引完整性。"
      ]
    },
    "/team-release": {
      "command": "/team-release",
      "summary": "用于组织发布准备、上线验证、监控与回滚保障，并在前端发布时覆盖 UI smoke、性能和回滚可见性。",
      "primaryRole": "devops-engineer",
      "requiredInputs": [
        "测试放行结论",
        "发布窗口",
        "环境与回滚要求",
        "发布负责人 / 值守人与观察窗口",
        "launch acceptance 结论",
        "企业治理上下文",
        "若涉及前端则附 smoke 范围和关键监控项"
      ],
      "expectedOutputs": [
        "发布方案",
        "部署上下文",
        "上线检查结果",
        "放行结论与后续观察项",
        "回滚与监控动作",
        "企业内控补充信息",
        "前端发布验证记录",
        "可选领域扩展执行记录"
      ],
      "gateHints": [
        "汇总发布范围、质量状态和环境前置条件。",
        "默认沿用 `karpathy-guidelines` 复核发布输入：确认 release notes、rollout 范围、观察项与回滚前提仍然对应已约定的最小变更和成功标准，没有在发布阶段悄悄扩 scope。",
        "记录发布责任链、执行步骤、暂停点 / Go-No-Go 判断点，以及观察窗口。"
      ]
    },
    "/team-closeout": {
      "command": "/team-closeout",
      "summary": "用于在发布与观察窗口结束后做最终收口，确认最终验收状态、残余风险处置、遗留项回写和任务关闭结论。",
      "primaryRole": "tech-lead",
      "requiredInputs": [
        "发布结果与观察窗口记录",
        "最终验收或业务确认结论",
        "残余风险与事故 / 回滚情况",
        "需要回写的 backlog / follow-up 项",
        "已落盘的 PRD、Delivery Plan、Review、Release 等主链 artifact"
      ],
      "expectedOutputs": [
        "最终收口结论",
        "最终验收状态",
        "观察窗口结论",
        "残余风险处置结果",
        "backlog 回写清单",
        "任务关闭状态"
      ],
      "gateHints": [
        "确认 `/team-release` 已完成，并具备发布结果、观察窗口、监控与回滚证据；若仍在发布中或观察窗口未结束，不得进入 closeout。",
        "复核最终验收是否满足上线目标、业务可用性与主要风险边界，必要时对发布结果、观察窗口充分性和遗留项处理方式提出质疑。",
        "把残余风险分类为接受、转移、延后处理或重新打开主链，并为每项风险明确责任人与下一步动作。"
      ]
    }
  }
}