{ "plugin": { "name": "team-skills-platform", "version": "2.3.0", "category": "Engineering", "authorName": "Engineering Team", "authorUrl": "https://github.com/affaan-m/everything-claude-code", "homepage": "https://github.com/affaan-m/everything-claude-code", "repository": "https://github.com/affaan-m/everything-claude-code", "license": "MIT", "keywords": [ "team-skills", "agents", "skills", "commands", "hooks", "workflow", "frontend", "code-review", "verification" ], "roleAgentDir": "agents/roles", "specialistAgentDir": "agents/specialists" }, "roleRequiredFields": [ "id", "display_name", "mission", "inputs", "outputs", "handoff_to", "quality_gates", "workflow_gates", "upstream_challenge", "default_commands", "platform_bindings" ], "roleOptionalListFields": [ "recommended_shared_skills", "recommended_ecc_skills", "recommended_domain_skills", "governance_rules", "sub_agent_invocations" ], "teamCommandDefinitions": [ { "name": "team-help", "summary": "作为 `/team-*` 主链唯一公开入口，根据当前项目阶段、已有 artifacts 与用户目标，推荐下一条最合适的 `/team-*` 或 `/quick` 命令，并指出前置缺口、阻塞项与降级路径。", "primary_role": "tech-lead", "inputs": [ "当前目标或遇到的问题", "当前阶段（若已知）", "已存在的 artifacts / handoff / 测试证据", "是否为既有项目（brownfield）", "是否希望走快速模式或完整主链" ], "outputs": [ "推荐的下一条命令", "推荐原因与适用前提", "进入下一步前必须补齐的证据与 `artifact:persist` 落盘动作", "brownfield 补齐建议", "若不满足条件时的降级路径" ], "steps": [ "先识别用户当前所处阶段：是新需求、挑战会 / 设计收口、准备实现、准备评审、准备发布、观察窗口收口，还是只想处理小范围快速任务。", "默认以 `karpathy-guidelines` 的方式先暴露歧义、范围边界与更简单路径，不在入口阶段静默替用户补全高风险假设。", "检查现有证据是否齐备：PRD、delivery-plan、arch-design、handoff、execute-log、test-plan、launch-acceptance、deployment-context、release-plan、closeout-summary，以及 `docs/memory/project-context.md`。", "若任务边界清晰、影响面小、风险低，优先推荐 `/quick`；否则继续沿 `/team-*` 主链推进。", "若是既有项目（brownfield）且现状上下文不足，优先建议执行 `/update-codemaps` 并启用 `doc-architecture`；默认用 CodeGraph 做 MCP-backed 符号、调用链和影响面证据，需要轻量结构证据时选择 Graphify，需要跨模块或多仓影响面时选择 GitNexus，再把现有模块、集成点、关键数据流和历史包袱回落到 `delivery-plan.md` / `arch-design.md`。", "若需求规模较大或涉及多角色并行，实现前先要求把计划切成可独立验收、可独立 handoff 的 story-sized execution units，并确认 `artifact:persist` 已创建对应任务目录与关键 artifact，再进入 `/team-execute`。", "若缺少 PRD 或需求边界，推荐 `/team-intake`；若缺少 challenge、design review 或 implementation-readiness，推荐 `/team-plan`；若 readiness proof 与 handoff 齐备，推荐 `/team-execute`；若已完成实现与自测，推荐 `/team-review`；若已获得放行，推荐 `/team-release`；若发布观察窗口结束，推荐 `/team-closeout`。", "若是既有项目且上下文不足，提示先补齐 brownfield / doc-architecture 类上下文；必要时用 CodeGraph、Graphify 或 GitNexus 补图谱证据，再进入计划或执行。", "输出结构化建议：推荐命令、原因、阻塞项、降级路径，并说明是否需要先运行 `npm run workflow:readiness`。" ] }, { "name": "team-intake", "summary": "用于接收需求、梳理目标、范围、约束和参与角色，并在涉及 UI 时提前锁定体验与质量门槛，同时输出需要进入需求挑战会的候选分组。", "primary_role": "tech-lead", "inputs": [ "需求背景", "目标与优先级", "关键约束与时间窗口", "是否涉及 UI、终端与设计约束", "是否企业内部应用、是否存在数据 / 合规风险", "是否涉及私有流程、权限系统、内部发布流程、私有观测或专属业务建模等 private enterprise overlay 线索" ], "outputs": [ "需求简报", "参与角色清单", "待确认项列表", "企业治理待确认项", "领域技能包启用建议", "UI 范围、终端假设与质量门禁", "需求挑战会候选分组" ], "steps": [ "识别问题、目标、成功标准和上线时限。", "默认使用 `karpathy-guidelines` 收敛 intake：显式写出关键假设、最小可行范围、非目标以及成功标准，避免把模糊愿望直接带进后续计划。", "若任务包含架构文档补齐或演进，启用 `doc-architecture`，按 `docs/runbooks/doc-architecture-integration.md` 收集 Project Profile Card 并约束后续映射。", "若为企业内部应用，先确认应用等级、技术架构等级、数据 / 合规风险是否需要后续补判。", "识别是否需要私有 enterprise overlay 才能完成任务，并列出候选 overlay 能力、私有 runbook 或额外安装前提。", "若需求包含前端变更，明确目标端、产品类型、关键页面、设计约束，以及可访问性和性能基线。", "若任务复杂或存在方案分歧，提前建议需要参加需求挑战会的动态分组。", "确认由哪些角色参与以及各自的输入缺口。", "输出结构化 intake 结果并准备进入 `/team-plan`。", "【落盘 — 必须执行，不可跳过】\n① 根据需求标题生成 slug（小写英文 + 短横线，≤30 字符，例 `user-login-flow`）。\n② 立即执行 `npm run artifact:persist -- ensure-task --date {YYYY-MM-DD} --slug {slug} --state intake`，确保 `docs/artifacts/{YYYY-MM-DD}-{slug}/` 和 INDEX 任务行存在。\n③ 再执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact prd --role tech-lead --status draft --state intake` 创建 `prd.md`。\n④ 立即在 `prd.md` 中补全本次 intake 的完整结构化内容（目标、范围、用户故事、风险、待确认项）。\n⑤ 完成后输出确认：`已创建 docs/artifacts/{YYYY-MM-DD}-{slug}/prd.md`。" ] }, { "name": "team-plan", "summary": "用于先完成需求挑战会与设计收口，再锁定交付计划、角色分工、风险与依赖，并形成 implementation-readiness 结论，把前端治理要求前置到方案阶段。", "primary_role": "tech-lead", "inputs": [ "需求简报或 PRD", "现有技术上下文", "资源和时间约束", "设计与体验约束", "intake 中识别的领域线索" ], "outputs": [ "交付计划", "需求挑战会结论", "implementation-readiness 结论与执行前提", "brownfield 上下文快照", "story slice 列表", "角色分工", "风险与依赖清单", "应用等级 / 技术架构等级 / 关键组件偏离", "是否需要 ADR", "技能装配清单", "前端交付物与检查点" ], "steps": [ "先完成需求挑战会：明确至少 3 个核心假设、对应质疑人、结论与未决项，再进入方案收口。", "默认把 `karpathy-guidelines` 作为计划收口护栏：要求显式写出假设、更简单备选路径、当前不做项，以及为什么本轮范围已经足够。", "按任务特征装配动态讨论分组，先讨论再收敛，避免未经质疑直接进入计划冻结。", "若启用 `doc-architecture`，补齐 Service Catalog、Communication Matrix、NFR Summary，并明确其 artifact 回落位置。", "若是既有项目（brownfield），先梳理现有模块边界、外部依赖、历史约束和缺失文档；必要时运行 `/update-codemaps`，默认用 CodeGraph 补 MCP-backed 符号、调用链和影响面证据，需要轻量结构证据时选择 Graphify，需要跨模块或多仓影响面时选择 GitNexus，再把 brownfield snapshot 回落到 `delivery-plan.md` 与 `arch-design.md`。", "若为企业内部应用，锁定应用等级、技术架构等级、关键组件偏离和资产入口要求，并判断是否必须输出 ADR。", "为本次任务显式装配 shared 能力、ECC 增强与可选 enterprise overlay 组合，并说明哪些私有 overlay 能力、runbook 或 overlay 仅按场景启用。", "若存在多参数、多角色、多配置或多终端组合，提前判断是否需要 `pairwise-test-design` 压缩测试矩阵。", "若包含 UI，锁定产品类型、视觉方向、设计 token、响应式基线，以及 `/team-review` 需要的前端证据。", "在需求挑战会与并行设计都完成之前，不得把交付计划标记为可执行。", "把实现工作切成 story-sized execution units：每个 slice 必须有清晰目标、验收标准、依赖、owner 和 handoff 终点，避免把多个高风险改动揉成一次 `/team-execute`。", "在计划冻结前运行 `npm run workflow:readiness -- --phase execute --task-dir docs/artifacts/{YYYY-MM-DD}-{slug}` 校验 implementation-readiness；若失败，先回补 challenge、design review、handoff 或 artifact 证据。", "指定每个阶段的主责角色与交接顺序。", "明确风险、阻塞、升级点和检查节点，并沉淀 ADR 所需输入。", "【落盘 — 必须执行，不可跳过】\n① 复用 intake 阶段已有的 slug。\n② 立即执行 `npm run artifact:persist -- ensure-task --date {YYYY-MM-DD} --slug {slug} --state plan`，确保任务目录和 INDEX 行可复用。\n③ 执行 `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`。\n④ 若本阶段产出架构设计，执行 `npm run artifact:persist -- ensure-artifact --date {YYYY-MM-DD} --slug {slug} --artifact arch-design --role architect --status draft --state plan` 创建 `arch-design.md`。\n⑤ 如需 ADR，按既有规则在 `docs/adr/` 新建并同步 INDEX 的 ADR 列。\n⑥ 执行 `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`。\n⑦ 完成后逐条输出确认，例如：`已创建 delivery-plan.md / arch-design.md`，`已刷新 project-context.md`。" ] }, { "name": "handoff", "summary": "用于在角色之间执行标准化交接，保证上下游共享同一事实，并把阶段切换、下游质疑和 readiness proof 一起交接。", "primary_role": "tech-lead", "inputs": [ "当前角色结论", "输入依据", "风险与待确认项", "必要时附上 UI 方案、截图或检查清单", "当前阶段与目标阶段", "readiness proof" ], "outputs": [ "结构化交接摘要", "下一跳角色动作清单", "可追溯的设计和质量证据", "阶段切换凭证", "readiness proof", "下游质疑记录" ], "steps": [ "按 `rules/handoff-contract.md` 固定交接字段。", "先确认当前阶段、目标阶段与 readiness 状态，再决定是否允许下一跳开始。", "在 handoff 文件的 frontmatter 中显式写入 `current_phase`、`target_phase`、`readiness_status`、`accepted_by`；在正文中保留 `readiness proof` 与 `downstream challenge record`。", "若变更涉及前端，附上设计 token、异常态说明、响应式约束和自测/评审证据。", "显式说明已完成内容、未完成内容和风险。", "接收方必须先留下至少 1 条下游质疑记录，再开始消费交接内容。", "指定下一跳角色与期望产出。", "【落盘 — 必须执行，不可跳过】\n① 确认当前任务 slug（目录格式 `{YYYY-MM-DD}-{slug}`）。\n② 立即执行 `npm run artifact:persist -- ensure-handoff --date {YYYY-MM-DD} --slug {slug} --from {from-role} --to {to-role} --status draft`，自动创建 `handoffs/{NNN}-{from-role}-to-{to-role}.md`。\n③ 立即在生成的 handoff 文件中补全本次交接的完整结构化内容（背景、输入依据、结论、风险、待确认项、下一跳角色、下游质疑记录）。\n④ 完成后输出确认：`已创建 handoffs/{NNN}-{from-role}-to-{to-role}.md`。" ] }, { "name": "team-execute", "summary": "用于驱动前端、后端等实现角色在既定边界内完成交付，但只有在 readiness proof、需求挑战会、设计收口和 handoff 都齐备后才允许进入实现。", "primary_role": "backend-engineer", "inputs": [ "方案、契约、任务拆解", "docs/memory/project-context.md（当前任务、关键依赖、活跃风险）", "story slice / 当前执行单元", "实现范围与验收标准", "技能装配清单", "若涉及前端则附设计系统与体验约束", "需求挑战会结论", "上游 handoff", "downstream challenge record" ], "outputs": [ "实现结果", "自测结论", "交给 QA 的说明", "story slice 完成状态", "领域扩展执行记录", "必要时补充 UI 检查清单", "readiness proof", "阻断/回退说明" ], "steps": [ "先确认本次实现范围与不做项，并核对是否已具备进入实现的 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 证据。", "若缺少需求挑战会、上游 handoff 或 Design Review 结论，立即停止并回交 tech-lead。", "开始实现前先消费 `docs/memory/project-context.md`，确认当前任务、关键依赖、活跃风险与团队约束未过期。", "一次 `/team-execute` 默认只消费一个 story-sized execution unit；若当前 slice 无法独立验收或独立 handoff，先回到 `/team-plan` 重切。", "若任务命中领域扩展层，先读取对应 `skills/` 技能；若命中配套 runbook / profile / toolkit，也先补看对应文档再开始实现。", "若包含前端变更，优先复用设计 token、遵循响应式与可访问性基线，并记录关键交互和边界态。", "若实现中遇到连续修错、跨模块链路或表象报错，切到 `systematic-debugging` 先定位根因，再继续修改。", "以最小改动完成实现并记录影响面。", "即便使用 private enterprise overlay，也要把最终实现说明、自测结果和风险统一归并到 `/handoff` 输出中。", "若前端变更需要真实浏览器验证，补用 `browser-smoke-testing` 形成关键页面 / 核心路径 smoke 证据。", "前端交付前使用 `templates/ui-review-checklist.md` 补齐自测证据，再通过 `/handoff` 交给 QA 或 DevOps。", "完成自测后通过 `/handoff` 交给 QA 或 DevOps。", "【落盘 — 必须执行，不可跳过】\n① 确认任务 slug。\n② 执行 `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`。\n③ 立即在 `execute-log.md` 中补全：计划 vs 实际偏差、实施中的关键决定、阻塞与解决方式、影响面、未完成项。\n④ 若实施中有轻量决策需要跨任务沉淀，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type decisions --title {decision_title} --content \"{decision_markdown}\"` 追加到 `docs/memory/decisions.md`。\n⑤ 若实施中产生新 ADR，按既有规则在 `docs/adr/` 新建并同步 INDEX 的 ADR 列。\n⑥ 完成后输出确认：`已创建 execute-log.md`。" ] }, { "name": "team-review", "summary": "用于评审方案、实现、测试结果和交付质量，并在前端变更时强制检查视觉、交互、无障碍和性能。", "primary_role": "qa-engineer", "inputs": [ "实施说明", "测试结果", "风险和待确认项", "若涉及前端则附 UI 评审清单和自测证据" ], "outputs": [ "评审结论", "阻塞项", "放行建议", "上线验收结论", "前端质量门禁检查结果", "领域扩展约束核对结果" ], "steps": [ "检查交付物是否满足角色对应的质量门禁。", "默认用 `karpathy-guidelines` 复核本轮交付是否保持最小范围、每处改动都能追溯到用户请求，并且成功标准与实际验证证据一致。", "若启用 `doc-architecture`，按 `docs/runbooks/team-command-output-contracts.md` 的文档一致性审计字段核对服务名、API、事件、鉴权和索引完整性。", "若任务启用了 private enterprise overlay 或配套私有 runbook / overlay，核对相关约束是否被正确执行，但不要把私有领域检查扩散成所有任务的默认门槛。", "若存在明确的 consumer/provider 边界，参考 `docs/runbooks/contract-testing-playbook.md` 核对契约验证是否覆盖关键交互与失败路径。", "若测试矩阵存在组合爆炸，优先用 `pairwise-test-design` 收敛覆盖策略，并说明哪些高风险场景需要额外定向补测。", "若交付物涉及 GitHub Actions workflow、reusable workflow 或 composite action，参考 `docs/runbooks/actionlint-workflow-gates.md` 与 `docs/runbooks/zizmor-workflow-audits.md` 核对 workflow lint、安全审计与 triage 结论。", "若交付物涉及 GitHub Actions workflow 的 `permissions`、默认 workflow 权限或 `GITHUB_TOKEN` scope 收敛，参考 `docs/runbooks/github-token-permissions-baseline.md` 核对最小权限建议、例外和回退边界。", "若交付物涉及 Terraform、CloudFormation、Bicep、ARM、OpenTofu、Helm、Kubernetes 或其他 IaC / 模板基线检查，参考 `docs/runbooks/checkov-iac-gates.md` 核对 IaC 安全与合规预检结论。", "若交付物涉及 Kubernetes manifests、Helm 渲染结果、kustomize 输出或 CRD schema 覆盖，参考 `docs/runbooks/kubeconform-schema-gates.md` 核对 schema 校验、版本边界和覆盖缺口。", "若交付物涉及 Helm chart 模板、values 组合、subchart 或 snapshot 回归，参考 `docs/runbooks/helm-unittest-playbook.md` 核对 chart 层单测、snapshot 漂移和覆盖缺口。", "若交付物需要把 manifests 送到目标 API server 做不落盘预检，参考 `docs/runbooks/kubectl-server-dry-run-gates.md` 核对 server-side validation、field conflict 和接收性结论。", "若交付物涉及 Helm、Kubernetes、Terraform、YAML、JSON 或其他结构化配置策略，参考 `docs/runbooks/conftest-policy-gates.md` 核对 policy-as-code 预检、例外和阻塞条件。", "若交付物涉及 Kubernetes admission、background scan、policy reports 或 image verification，参考 `docs/runbooks/kyverno-policy-gates.md` 核对 `Audit/Enforce` 状态、policy 命中和例外处理。", "若变更涉及前端，必须验证视觉一致性、交互完整性、边界态、无障碍和前端性能。", "若前端主路径或发布前验证需要真实浏览器证据，补用 `browser-smoke-testing`。", "区分阻塞问题和非阻塞风险。", "必要时把冲突升级给 `tech-lead`。", "【落盘 — 必须执行，不可跳过】\n① 确认任务 slug。\n② 执行 `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`。\n③ 执行 `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`。\n④ 立即在这两个文件中补全测试范围、风险、Go / No-Go 检查项、已接受风险和最终上线结论。\n⑤ 若评审中有值得跨任务沉淀的经验教训，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type lessons --title {lesson_title} --content \"{lesson_markdown}\"` 追加到 `docs/memory/lessons-learned.md`。\n⑥ 完成后输出确认：`已创建 test-plan.md / launch-acceptance.md`。" ] }, { "name": "team-release", "summary": "用于组织发布准备、上线验证、监控与回滚保障，并在前端发布时覆盖 UI smoke、性能和回滚可见性。", "primary_role": "devops-engineer", "inputs": [ "测试放行结论", "发布窗口", "环境与回滚要求", "发布负责人 / 值守人与观察窗口", "launch acceptance 结论", "企业治理上下文", "若涉及前端则附 smoke 范围和关键监控项" ], "outputs": [ "发布方案", "部署上下文", "上线检查结果", "放行结论与后续观察项", "回滚与监控动作", "企业内控补充信息", "前端发布验证记录", "可选领域扩展执行记录" ], "steps": [ "汇总发布范围、质量状态和环境前置条件。", "默认沿用 `karpathy-guidelines` 复核发布输入：确认 release notes、rollout 范围、观察项与回滚前提仍然对应已约定的最小变更和成功标准，没有在发布阶段悄悄扩 scope。", "记录发布责任链、执行步骤、暂停点 / Go-No-Go 判断点，以及观察窗口。", "若包含前端变更，补充关键页面 smoke、静态资源发布风险、性能基线和回滚触发条件，必要时使用 `browser-smoke-testing` 留下真实浏览器验证证据。", "若发布范围包含 GitHub Actions workflow、reusable workflow 或 release automation 变更，参考 `docs/runbooks/actionlint-workflow-gates.md` 与 `docs/runbooks/zizmor-workflow-audits.md` 汇总 workflow lint、安全审计与 triage 结论。", "若发布范围包含 GitHub Actions workflow 的 `permissions`、默认 workflow 权限或 `GITHUB_TOKEN` scope 收敛，参考 `docs/runbooks/github-token-permissions-baseline.md` 汇总最小权限建议、例外和回退边界。", "若发布范围包含 Terraform、CloudFormation、Bicep、ARM、OpenTofu、Helm、Kubernetes 或其他 IaC / 模板基线检查，参考 `docs/runbooks/checkov-iac-gates.md` 汇总 IaC 安全与合规预检结论。", "若发布范围包含 Kubernetes manifests、Helm 渲染结果、kustomize 输出或 CRD schema 覆盖，参考 `docs/runbooks/kubeconform-schema-gates.md` 汇总 schema 校验、版本边界和覆盖缺口。", "若发布范围包含 Helm chart 模板、values 组合、subchart 或 snapshot 回归，参考 `docs/runbooks/helm-unittest-playbook.md` 汇总 chart 层单测、snapshot 漂移和覆盖缺口。", "若发布需要把 manifests 送到目标 API server 做不落盘预检，参考 `docs/runbooks/kubectl-server-dry-run-gates.md` 汇总 server-side validation、field conflict 和接收性结论。", "若发布涉及容器镜像、Dockerfile、Helm、Kubernetes、Terraform 或仓库文件系统扫描，参考 `docs/runbooks/trivy-security-gates.md` 汇总镜像 / 文件系统 / IaC 扫描结果，并回写到放行结论或观察项。", "若发布涉及 Helm、Kubernetes、Terraform、YAML、JSON 或其他结构化配置策略，参考 `docs/runbooks/conftest-policy-gates.md` 汇总 policy-as-code 预检、例外条件和阻塞结论。", "若发布依赖 Kubernetes admission、background scan、policy reports 或 image verification 结果，参考 `docs/runbooks/kyverno-policy-gates.md` 汇总 `Audit/Enforce` 状态、policy 命中和例外边界。", "若发布链主要运行在 GitHub Actions，且需要收敛 runner 的外部访问面或跟踪异常出站连接，参考 `docs/runbooks/runner-egress-hardening.md` 汇总 allowlist、异常访问和 triage 责任。", "若发布包含二进制、容器镜像、压缩包或其他正式制品，参考 `docs/runbooks/sbom-generation-gates.md` 汇总 SBOM 生成范围、归档位置和版本追溯关系。", "若发布需要为正式制品补 provenance 证明，参考 `docs/runbooks/artifact-attestation-gates.md` 汇总 attestation 的生成范围、归档位置和与产物的对应关系。", "若发布链需要在 GitHub Actions 中整理更通用的 provenance 生成模式，参考 `docs/runbooks/slsa-generator-patterns.md` 汇总 workflow 约束、subject 绑定关系和归档方式。", "若发布需要统一 attestation 的 predicate、schema 和 evidence model，参考 `docs/runbooks/in-toto-attestation-framework.md` 汇总证据结构、版本边界和与发布记录的映射方式。", "若发布需要为正式制品或镜像补签名与验签链路，参考 `docs/runbooks/cosign-signing-gates.md` 汇总签名范围、验签入口和发布记录回链。", "若发布需要独立验证 provenance / attestation，参考 `docs/runbooks/slsa-verification-gates.md` 汇总验证输入、验证结果和失败处置策略。", "若集群侧需要在 admission 层强制执行签名、attestation 或验证策略，参考 `docs/runbooks/policy-controller-gates.md` 汇总策略范围、拒绝原因、例外流程和回退路径。", "若发布链需要基于执行证据做更高阶的策略评估，参考 `docs/runbooks/witness-policy-gates.md` 汇总 evidence 来源、policy 规则、评估结果和例外处理。", "若为企业内部应用，在发布方案中补齐应用等级、技术架构等级、资源隔离、关键组件偏离和资产入口。", "若发布链命中 GitLab 手动流水线补充手册，可附加其执行记录，但不替代默认发布方案与验证步骤。", "执行发布前后检查并记录结果，形成最终放行结论。", "向 `tech-lead` 回报发布状态、放行结论和后续观察项。", "【落盘 — 必须执行，不可跳过】\n① 确认任务 slug。\n② 执行 `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`。\n③ 执行 `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`。\n④ 立即在两个文件中补全环境、配置、密钥来源、部署入口、回滚入口、发布信息、执行步骤、验证与监控、放行结论。\n⑤ 执行 `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`。\n⑥ 若发布中有值得跨任务沉淀的经验教训，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type lessons --title {lesson_title} --content \"{lesson_markdown}\"` 追加到 `docs/memory/lessons-learned.md`。\n⑦ 完成后逐条输出确认：`已创建 deployment-context.md / release-plan.md`，`已刷新 project-context.md`。" ] }, { "name": "team-closeout", "summary": "用于在发布与观察窗口结束后做最终收口，确认最终验收状态、残余风险处置、遗留项回写和任务关闭结论。", "primary_role": "tech-lead", "inputs": [ "发布结果与观察窗口记录", "最终验收或业务确认结论", "残余风险与事故 / 回滚情况", "需要回写的 backlog / follow-up 项", "已落盘的 PRD、Delivery Plan、Review、Release 等主链 artifact" ], "outputs": [ "最终收口结论", "最终验收状态", "观察窗口结论", "残余风险处置结果", "backlog 回写清单", "任务关闭状态" ], "steps": [ "确认 `/team-release` 已完成，并具备发布结果、观察窗口、监控与回滚证据；若仍在发布中或观察窗口未结束，不得进入 closeout。", "复核最终验收是否满足上线目标、业务可用性与主要风险边界，必要时对发布结果、观察窗口充分性和遗留项处理方式提出质疑。", "把残余风险分类为接受、转移、延后处理或重新打开主链，并为每项风险明确责任人与下一步动作。", "若观察窗口内出现事故、回滚或严重偏差，明确任务状态为 `re-open` 或 `follow-up-required`，而不是直接关闭。", "若任务启用了 private enterprise overlay、配套私有 runbook 或 overlay，确认 closeout 结论已经消费这些领域证据，不允许只引用口头结论。", "形成最终收口结论，明确 `最终验收状态`、`观察窗口结论`、`backlog 回写` 和 `任务关闭结论`。", "向相关角色回传 closeout 结果：若已关闭则同步后续跟踪项；若未关闭则明确重开入口和责任链。", "【落盘 — 必须执行，不可跳过】\n① 复用既有任务 slug。\n② 执行 `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`。\n③ 立即在 `closeout-summary.md` 中补全：最终验收状态、观察窗口结论、残余风险处置、backlog 回写、任务关闭结论、lessons learned。\n④ 执行 `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`。\n⑤ 若有 backlog 回写，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type backlog --title {backlog_title} --content \"{backlog_markdown}\"`。\n⑥ 若有跨任务经验沉淀，执行 `npm run artifact:persist -- append-memory --date {YYYY-MM-DD} --memory-type lessons --title {lesson_title} --content \"{lesson_markdown}\"`。\n⑦ 执行 `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`。\n⑧ 完成后逐条输出确认：`已创建 closeout-summary.md`，`已刷新 project-context.md`，`已创建 sessions/{filename}`。" ] } ], "eccCommandDefinitions": [ { "name": "plan", "summary": "调用 specialist planners 产出更细粒度的实施方案，并把结果回落到团队角色交接模型。", "primary_role": "planner", "inputs": [ "目标、约束、现有上下文", "风险与边界条件" ], "outputs": [ "实施计划", "阶段拆解", "需要回交给 `tech-lead` 的决策点" ], "steps": [ "聚焦实现策略、拆解阶段和依赖顺序。", "明确哪些结论属于 specialist 建议，哪些需要角色或 `tech-lead` 决策。", "通过 `/handoff` 或 `/team-plan` 把结果回落到团队主链。" ] }, { "name": "tdd", "summary": "使用 TDD specialist 帮助建立测试先行的实现节奏。", "primary_role": "tdd-guide", "inputs": [ "功能目标", "现有测试缺口", "相关接口或行为说明" ], "outputs": [ "测试优先计划", "建议的 red-green-refactor 步骤", "回归验证重点" ], "steps": [ "识别可先测试的外部行为与边界态。", "先产出测试切入点，再规划最小实现路径。", "把测试计划回交给研发角色或 QA 消费。" ] }, { "name": "code-review", "summary": "触发通用或语言专项 reviewer，对代码质量、设计风险和回归风险做结构化评审。", "primary_role": "code-reviewer", "inputs": [ "变更说明", "diff 或实现摘要", "测试与风险信息" ], "outputs": [ "评审结论", "阻塞问题", "语言或安全专项建议" ], "steps": [ "优先检查行为回归、设计问题、缺测和安全风险。", "若仓库启用了 AI PR review 试点，可参考 `docs/runbooks/ai-pr-review-automation.md` 把 AI 摘要和风险提示作为辅助输入，但不能替代人工结论。", "若 diff 涉及依赖清单、lockfile 或构建插件版本，参考 `docs/runbooks/dependency-review-gates.md` 检查新增依赖、漏洞和许可证变化。", "若当前 PR 主要是依赖升级批次或自动化更新结果，参考 `docs/runbooks/dependency-update-automation.md` 判断分组是否合理、验证范围是否足够以及是否适合自动合并。", "若仓库启用了 GitHub CodeQL / code scanning，参考 `docs/runbooks/codeql-pr-security-gates.md` 读取语义安全扫描结果与 triage 结论。", "若 diff 涉及配置文件、示例、脚本、测试数据、文档或疑似凭据暴露，参考 `docs/runbooks/secret-scanning-gates.md` 检查新增命中、baseline 变化和泄漏处置要求。", "若 diff 涉及 `.github/workflows/`、reusable workflow、composite action 或 workflow 表达式 / shell 片段，参考 `docs/runbooks/actionlint-workflow-gates.md` 检查 workflow 语法、结构、上下文引用和 shell 误用。", "若 diff 涉及 GitHub Actions workflow 的 `permissions`、默认 workflow 权限或 `GITHUB_TOKEN` scope 收敛，参考 `docs/runbooks/github-token-permissions-baseline.md` 检查最小权限建议、例外和最终 YAML 配置是否一致。", "若 diff 涉及 GitHub Actions workflow 的权限、第三方 action、secret 暴露、危险表达式或 release automation 安全面，参考 `docs/runbooks/zizmor-workflow-audits.md` 读取 workflow 安全审计结果与 triage 结论。", "若 diff 涉及 Terraform、CloudFormation、Bicep、ARM、OpenTofu、Helm、Kubernetes 或其他 IaC / 模板基线检查，且仓库启用了 Checkov，参考 `docs/runbooks/checkov-iac-gates.md` 读取 IaC 安全与合规预检结果、例外和 triage 结论。", "若 diff 涉及 Kubernetes manifests、Helm 渲染结果、kustomize 输出或 CRD schema 覆盖，且仓库启用了 schema 校验，参考 `docs/runbooks/kubeconform-schema-gates.md` 读取 schema 校验结果、覆盖缺口和版本边界。", "若 diff 涉及 Helm chart 模板、values 组合、subchart 或 snapshot 断言，参考 `docs/runbooks/helm-unittest-playbook.md` 检查 chart 层单测、snapshot 更新和覆盖范围是否合理。", "若 diff 涉及 `kubectl apply --server-side`、`--dry-run=server`、field manager 或 manifests 的 API server 接受性预检，参考 `docs/runbooks/kubectl-server-dry-run-gates.md` 读取 server-side validation、field conflict 和 RBAC 结论。", "若 diff 涉及 Dockerfile、容器镜像、Helm、Kubernetes、Terraform 或仓库文件系统扫描，且仓库启用了 Trivy，参考 `docs/runbooks/trivy-security-gates.md` 读取镜像 / 文件系统 / IaC 扫描结果与 triage 结论。", "若 diff 涉及 Helm、Kubernetes、Terraform、YAML、JSON 或其他结构化配置策略，且仓库启用了 policy-as-code 预检，参考 `docs/runbooks/conftest-policy-gates.md` 读取 policy 命中、例外和阻塞边界。", "若 diff 涉及 Kyverno policy、background scan、policy reports、image verification 或 Kubernetes 原生策略治理，参考 `docs/runbooks/kyverno-policy-gates.md` 读取策略范围、`Audit/Enforce` 状态和例外处理结论。", "若 diff 涉及 GitHub Actions workflow、token 权限、第三方 action pinning、分支保护或 release automation，且仓库启用了 OSSF Scorecard，参考 `docs/runbooks/scorecard-supply-chain-gates.md` 读取仓库级供应链基线结果与 triage 结论。", "若 diff 涉及 GitHub Actions runner 的外部访问面、网络放行列表或 workflow 运行时收敛策略，参考 `docs/runbooks/runner-egress-hardening.md` 核对 egress allowlist、异常连接和例外处理边界。", "若 diff 涉及 attestation predicate、schema、evidence model 或供应链 policy 规则，参考 `docs/runbooks/in-toto-attestation-framework.md` 与 `docs/runbooks/witness-policy-gates.md` 核对证据结构与策略边界。", "必要时联动 language reviewer 或 security reviewer。", "将结论回交给 `/team-review` 或对应实现角色。" ] }, { "name": "build-fix", "summary": "使用 build-error specialists 分析并修复构建、编译或测试失败。", "primary_role": "build-error-resolver", "inputs": [ "错误日志", "构建命令", "相关模块上下文" ], "outputs": [ "失败归因", "修复建议", "建议的验证命令" ], "steps": [ "先归因失败类型，再决定是否切到语言专项 resolver。", "优先给出最小修复路径和验证命令。", "完成后把结果回交给实现角色或 `tech-lead`。" ] }, { "name": "verify", "summary": "运行 verification specialists，对结论、实现和交付证据做持续验证。", "primary_role": "loop-operator", "inputs": [ "目标结论", "验证标准", "现有证据与命令" ], "outputs": [ "验证记录", "未覆盖风险", "是否建议继续迭代" ], "steps": [ "明确验证标准、停机条件，以及本轮需要补齐的证据。", "逐轮区分哪些结论已经验证、哪些仍是未验证推测，不把计划当成证据。", "若出现证据缺口、结果冲突或复现不稳定，先停在事实收集和验证，不要继续边猜边改。", "把每一轮的验证结论回交给 `/handoff`、`/team-review` 或 `/team-release`，让主链能消费这些证据。" ] }, { "name": "update-codemaps", "summary": "扫描代码结构并生成 token-lean codemaps，适合作为 brownfield 项目的现状快照与 CodeGraph / Graphify / GitNexus 图谱分析前置上下文。", "primary_role": "doc-updater", "inputs": [ "代码仓结构", "现有模块、入口、依赖与数据层信息", "是否允许覆盖已有 codemap" ], "outputs": [ "docs/CODEMAPS/ 下的结构化 codemap", ".reports/codemap-diff.txt 差异摘要", "可供 `/team-help` / `/team-plan` 消费的 brownfield context", "可供 CodeGraph / Graphify / GitNexus 继续深挖的结构化问题清单" ], "steps": [ "先识别仓库类型、源码目录、入口文件和主要依赖边界。", "为 architecture/backend/frontend/data/dependencies 生成 token-lean 文档，不写实现细节噪音。", "若已有 codemap，先比较变更比例；超过阈值时要求人工确认再覆盖。", "把结果作为 brownfield context snapshot 的辅助输入；若需要图谱证据，再选择 CodeGraph、Graphify 或 GitNexus，并把结论回落到 `delivery-plan.md` / `arch-design.md`，不要形成平行事实源。" ] }, { "name": "pua", "summary": "启用 PUA 高能动性与高压闭环模式，统一处理连续失败、原地打转、空口完成、没搜就猜和被动等待。", "primary_role": "planner", "inputs": [ "当前任务描述或卡点", "是否需要切换模式：p7 / p9 / p10 / pro / yes / mama / loop / on / off / flavor", "当前失败次数、已尝试方案和验证状态" ], "outputs": [ "已选中的 PUA 模式", "当前 flavor 与方法论路由", "下一轮必须执行的动作清单", "若为 on / off / flavor，则给出本地状态更新动作" ], "steps": [ "先根据参数路由决定模式：无参数默认加载 `pua` 核心；`p7`、`p9`、`p10`、`pro`、`yes`、`mama`、`loop` 分别切到对应 skill。", "若参数是 `on`，创建或更新 `~/.claude/pua/config.json`，写入 `{ \"always_on\": true }`，并保留当前 flavor。", "若参数是 `off`，创建或更新 `~/.claude/pua/config.json`，写入 `{ \"always_on\": false }`。", "若参数是 `flavor`，先读取 `skills/pua/references/flavors.md`，再让用户明确选择 flavor，并把结果写入 `~/.claude/pua/config.json`。", "若参数是任务描述或卡点，先读取 `skills/pua/references/methodology-router.md`，按任务类型自动选择默认 flavor 与方法论。", "激活后严格遵循三条红线：没证据不算完成、没验证不允许归因、没穷尽不允许放弃。", "若当前已连续失败 2 次以上，明确当前等级 L1-L4，并按 `skills/pua/SKILL.md` 的 7 项检查清单或失败切换链继续推进。", "当前本平台仅对 SessionStart、PostToolUse、PostToolUseFailure、PreCompact、Stop 做了 hooks 映射；不支持 UserPromptSubmit 级别的即时拦截，需要显式说明这是降级兼容项。" ] }, { "name": "multi-frontend", "summary": "针对前端复杂改版、跨页面交互或多前端子域任务做专门编排。", "primary_role": "planner", "inputs": [ "前端范围", "设计与接口约束", "交付窗口" ], "outputs": [ "前端子任务拆解", "页面/组件责任边界", "前端验证链路" ], "steps": [ "优先识别页面、组件、状态、接口和设计系统五个维度。", "联动 `frontend-engineer`、`qa-engineer` 和前端 specialists。", "结果必须回落到 `/team-plan`、`/team-execute`、`/team-review`。" ] }, { "name": "multi-backend", "summary": "针对多服务、多模块或多数据边界的后端任务做编排。", "primary_role": "planner", "inputs": [ "服务边界", "接口与数据影响", "依赖与发布约束" ], "outputs": [ "后端子任务拆解", "依赖顺序", "验证与发布注意项" ], "steps": [ "先拆服务和模块边界，再拆验证与发布链。", "必要时联动 architecture、database 和 language specialists。", "结果回落到主团队交付链。" ] }, { "name": "harness-audit", "summary": "检查 Harness 配置的完整性和有效性，输出 7 维度评分和改进建议。", "primary_role": "harness-optimizer", "inputs": [], "outputs": [ "Overall Score", "Dimension Scores", "Top Actions", "Recommendations" ], "steps": [ "评估 Agent Coverage（代理覆盖）。", "评估 Skill Completeness（技能完整性）。", "评估 Hook Effectiveness（Hook 有效性）。", "评估 Rule Enforcement（规则执行）。", "评估 Command Coverage（命令覆盖）。", "评估 Documentation Quality（文档质量）。", "评估 Integration Depth（集成深度）。", "输出改进建议和优先级。" ] } ], "specialistAgentDefinitions": [ { "name": "planner", "display_name": "Planner", "mission": "负责把复杂需求转成可执行实施计划、阶段边界和并行拆解。", "triggers": [ "需要更细实施计划", "需求涉及多角色或多模块", "要做并行拆解或阶段编排" ], "outputs": [ "实施计划", "任务图", "关键依赖与风险点" ], "default_commands": [ "/plan" ], "focus_rules": [ "rules/common/patterns.md", "rules/common/agents.md" ], "focus_skills": [] }, { "name": "architect", "display_name": "Specialist Architect", "mission": "负责从 harness 视角补充系统边界、方案取舍和结构化技术建议。", "triggers": [ "需要架构取舍建议", "要补充边界或失败模式", "需要 specialist 视角的系统设计评估" ], "outputs": [ "方案建议", "失败模式与风险", "需要回交给 role architect 的问题" ], "default_commands": [ "/plan", "/code-review", "/multi-backend" ], "focus_rules": [ "rules/common/patterns.md", "rules/common/security.md" ], "focus_skills": [] }, { "name": "tdd-guide", "display_name": "TDD Guide", "mission": "负责建立测试先行节奏，帮助实现 red-green-refactor 工作流。", "triggers": [ "需要先补测试", "要明确回归保护", "改动容易引发行为回归" ], "outputs": [ "TDD 路径", "优先级最高的测试建议", "回归矩阵" ], "default_commands": [ "/tdd", "/verify" ], "focus_rules": [ "rules/common/testing.md" ], "focus_skills": [ "pairwise-test-design" ] }, { "name": "code-reviewer", "display_name": "Code Reviewer", "mission": "负责做行为、设计、质量和回归风险评审。", "triggers": [ "需要代码评审", "要找潜在缺陷或设计问题", "要给出结构化 review 结论" ], "outputs": [ "评审结论", "问题列表", "剩余风险" ], "default_commands": [ "/code-review" ], "focus_rules": [ "rules/common/coding-style.md", "rules/common/testing.md" ], "focus_skills": [] }, { "name": "security-reviewer", "display_name": "Security Reviewer", "mission": "负责识别认证、授权、输入处理、依赖和数据暴露等安全问题。", "triggers": [ "改动涉及安全边界", "需要安全 review", "怀疑存在漏洞或敏感数据暴露" ], "outputs": [ "安全问题清单", "缓解建议", "是否建议阻塞放行" ], "default_commands": [ "/code-review", "/verify" ], "focus_rules": [ "rules/common/security.md" ], "focus_skills": [] }, { "name": "build-error-resolver", "display_name": "Build Error Resolver", "mission": "负责归因构建、编译和测试失败，并给出最小修复路径。", "triggers": [ "构建失败", "测试跑不通", "编译日志难以快速定位" ], "outputs": [ "失败归因", "修复建议", "验证命令" ], "default_commands": [ "/build-fix", "/verify" ], "focus_rules": [ "rules/common/testing.md" ], "focus_skills": [ "systematic-debugging" ] }, { "name": "e2e-runner", "display_name": "E2E Runner", "mission": "负责用端到端视角梳理关键用户路径和回归风险。", "triggers": [ "需要 E2E 覆盖", "要定义关键用户旅程", "前端变更影响交互主路径" ], "outputs": [ "E2E 方案", "关键用户路径", "端到端风险" ], "default_commands": [ "/verify", "/multi-frontend" ], "focus_rules": [ "rules/common/testing.md", "rules/typescript/frontend.md" ], "focus_skills": [ "browser-smoke-testing" ] }, { "name": "refactor-cleaner", "display_name": "Refactor Cleaner", "mission": "负责识别死代码、重复实现和可安全收敛的复杂度。", "triggers": [ "需要重构清理", "发现死代码", "要降低复杂度或重复实现" ], "outputs": [ "清理建议", "潜在风险", "建议的分步重构路径" ], "default_commands": [ "/code-review", "/plan" ], "focus_rules": [ "rules/common/coding-style.md" ], "focus_skills": [] }, { "name": "doc-updater", "display_name": "Doc Updater", "mission": "负责判断改动引发的文档影响，并给出同步建议。", "triggers": [ "改动需要同步文档", "不确定该改哪些文档", "需要保持 runbook/spec/example 一致" ], "outputs": [ "文档影响面", "建议更新项", "缺失文档清单" ], "default_commands": [], "focus_rules": [ "rules/common/git-workflow.md" ], "focus_skills": [] }, { "name": "docs-lookup", "display_name": "Docs Lookup", "mission": "负责快速定位规范、API 文档和内部知识入口。", "triggers": [ "需要查文档", "需要快速搜规则/示例/规范", "多文档上下文需要收敛" ], "outputs": [ "文档入口", "关键信息摘录", "推荐下一跳" ], "default_commands": [ "/plan" ], "focus_rules": [ "rules/common/patterns.md" ], "focus_skills": [] }, { "name": "chief-of-staff", "display_name": "Chief of Staff", "mission": "负责复杂任务的沟通编排、汇报摘要和协作节奏设计。", "triggers": [ "任务跨角色很多", "需要高层摘要或阶段汇报", "需要梳理同步节奏和升级路径" ], "outputs": [ "摘要", "同步计划", "升级建议" ], "default_commands": [], "focus_rules": [ "rules/common/agents.md", "rules/common/git-workflow.md" ], "focus_skills": [] }, { "name": "loop-operator", "display_name": "Loop Operator", "mission": "负责组织验证循环、多阶段执行和中间结果收敛。", "triggers": [ "需要多轮验证", "需要自动化式迭代节奏", "任务需要明确停机条件和循环检查" ], "outputs": [ "循环计划", "阶段结果", "停机或继续建议" ], "default_commands": [ "/verify" ], "focus_rules": [ "rules/common/performance.md", "rules/common/agents.md" ], "focus_skills": [ "systematic-debugging" ] }, { "name": "harness-optimizer", "display_name": "Harness Optimizer", "mission": "负责优化插件、规则、hooks、commands 和安装链的可用性。", "triggers": [ "要改进 harness 本身", "要提升插件可用性", "需要优化规则和命令编排" ], "outputs": [ "harness 改进建议", "目录或配置调整方案", "回归风险提示" ], "default_commands": [ "/plan" ], "focus_rules": [ "rules/common/hooks.md", "rules/common/agents.md" ], "focus_skills": [] }, { "name": "cpp-reviewer", "display_name": "C++ Reviewer", "mission": "负责 C++ 代码质量和设计评审。", "triggers": [ "需要 C++ review", "怀疑 C++ 改动有资源或边界问题" ], "outputs": [ "C++ 评审结论", "潜在问题", "建议修复项" ], "default_commands": [ "/code-review" ], "focus_rules": [ "rules/common/coding-style.md" ], "focus_skills": [] }, { "name": "cpp-build-resolver", "display_name": "C++ Build Resolver", "mission": "负责 C++ 构建、链接和测试失败归因。", "triggers": [ "C++ 编译失败", "链接失败", "CTest 或构建日志不明确" ], "outputs": [ "失败归因", "修复建议", "验证命令" ], "default_commands": [ "/build-fix" ], "focus_rules": [ "rules/common/testing.md" ], "focus_skills": [] }, { "name": "go-reviewer", "display_name": "Go Reviewer", "mission": "负责 Go 代码质量、接口和并发行为评审。", "triggers": [ "需要 Go review", "怀疑 goroutine、context 或接口边界问题" ], "outputs": [ "Go 评审结论", "风险项", "建议修复" ], "default_commands": [ "/code-review" ], "focus_rules": [ "rules/golang/coding-style.md", "rules/golang/testing.md" ], "focus_skills": [] }, { "name": "go-build-resolver", "display_name": "Go Build Resolver", "mission": "负责 Go 构建、依赖和测试失败归因。", "triggers": [ "Go build/test 失败", "模块或依赖错误", "构建日志需要快速定位" ], "outputs": [ "失败归因", "修复建议", "验证命令" ], "default_commands": [ "/build-fix" ], "focus_rules": [ "rules/golang/testing.md" ], "focus_skills": [] }, { "name": "python-reviewer", "display_name": "Python Reviewer", "mission": "负责 Python 代码质量、边界和安全性评审。", "triggers": [ "需要 Python review", "怀疑 Python 改动有边界或测试问题" ], "outputs": [ "Python 评审结论", "风险项", "建议修复" ], "default_commands": [ "/code-review" ], "focus_rules": [ "rules/python/coding-style.md", "rules/python/security.md" ], "focus_skills": [] }, { "name": "database-reviewer", "display_name": "Database Reviewer", "mission": "负责数据库 schema、查询、事务和迁移风险评审。", "triggers": [ "涉及 SQL 或 schema 变更", "需要数据库 review", "担心迁移或查询性能" ], "outputs": [ "数据库风险结论", "迁移建议", "性能或一致性提醒" ], "default_commands": [ "/code-review", "/multi-backend" ], "focus_rules": [ "rules/common/security.md", "rules/java/jpa.md" ], "focus_skills": [] }, { "name": "typescript-reviewer", "display_name": "TypeScript Reviewer", "mission": "负责 TypeScript/JavaScript 代码质量、类型边界和前端实现评审。", "triggers": [ "需要 TypeScript review", "怀疑类型边界或前端实现有问题" ], "outputs": [ "TypeScript 评审结论", "风险项", "建议修复" ], "default_commands": [ "/code-review", "/multi-frontend" ], "focus_rules": [ "rules/typescript/coding-style.md", "rules/typescript/frontend.md" ], "focus_skills": [] }, { "name": "java-reviewer", "display_name": "Java Reviewer", "mission": "负责 Java / Spring Boot 代码质量、分层和事务边界评审。", "triggers": [ "需要 Java review", "怀疑 Spring Boot/JPA 设计或边界问题" ], "outputs": [ "Java 评审结论", "风险项", "建议修复" ], "default_commands": [ "/code-review", "/multi-backend" ], "focus_rules": [ "rules/java/coding-style.md", "rules/java/springboot.md", "rules/java/jpa.md" ], "focus_skills": [] }, { "name": "java-build-resolver", "display_name": "Java Build Resolver", "mission": "负责 Java / Maven / Gradle 构建和测试失败归因。", "triggers": [ "Java build/test 失败", "Maven/Gradle 日志难定位", "依赖或编译错误" ], "outputs": [ "失败归因", "修复建议", "验证命令" ], "default_commands": [ "/build-fix" ], "focus_rules": [ "rules/java/testing.md" ], "focus_skills": [] }, { "name": "kotlin-reviewer", "display_name": "Kotlin Reviewer", "mission": "负责 Kotlin 代码质量、架构和协程使用评审。", "triggers": [ "需要 Kotlin review", "怀疑 Kotlin/Android/KMP 设计问题" ], "outputs": [ "Kotlin 评审结论", "风险项", "建议修复" ], "default_commands": [ "/code-review" ], "focus_rules": [ "rules/common/coding-style.md" ], "focus_skills": [] }, { "name": "kotlin-build-resolver", "display_name": "Kotlin Build Resolver", "mission": "负责 Kotlin / Gradle 构建失败归因。", "triggers": [ "Kotlin build 失败", "Gradle 失败", "需要快速定位构建问题" ], "outputs": [ "失败归因", "修复建议", "验证命令" ], "default_commands": [ "/build-fix" ], "focus_rules": [ "rules/common/testing.md" ], "focus_skills": [] }, { "name": "rust-reviewer", "display_name": "Rust Reviewer", "mission": "负责 Rust 代码质量、所有权边界和错误处理评审。", "triggers": [ "需要 Rust review", "怀疑 Rust 设计或错误处理问题" ], "outputs": [ "Rust 评审结论", "风险项", "建议修复" ], "default_commands": [ "/code-review" ], "focus_rules": [ "rules/common/coding-style.md" ], "focus_skills": [] }, { "name": "rust-build-resolver", "display_name": "Rust Build Resolver", "mission": "负责 Rust 构建、borrow checker 和测试失败归因。", "triggers": [ "Rust 编译失败", "borrow checker 报错", "Cargo test 失败" ], "outputs": [ "失败归因", "修复建议", "验证命令" ], "default_commands": [ "/build-fix" ], "focus_rules": [ "rules/common/testing.md" ], "focus_skills": [] }, { "name": "pytorch-build-resolver", "display_name": "PyTorch Build Resolver", "mission": "负责 PyTorch / CUDA 训练、依赖和运行时错误归因。", "triggers": [ "PyTorch/CUDA 报错", "训练环境异常", "需要快速定位框架或算子问题" ], "outputs": [ "失败归因", "修复建议", "环境检查项" ], "default_commands": [ "/build-fix" ], "focus_rules": [ "rules/python/testing.md" ], "focus_skills": [] } ], "requiredTemplateFiles": [ "templates/api-contract.md", "templates/design-system-brief.md", "templates/ui-implementation-plan.md", "templates/ui-review-checklist.md", "templates/release-plan.md", "templates/system/role-skill.md.tmpl", "templates/system/agent-role.md.tmpl", "templates/system/command.md.tmpl", "templates/system/specialist-agent.md.tmpl" ], "requiredSharedSkills": [ "api-contract", "frontend-engineering", "frontend-ui-ux-system", "doc-architecture" ], "requiredEccSkills": [ "browser-smoke-testing", "pairwise-test-design", "testcontainers-integration-testing", "systematic-debugging", "error-experience-library", "karpathy-guidelines", "parallel-execution", "java-unit-test", "maven-qa", "mysql-query", "langfuse-coding-trace", "harness-audit" ], "sharedSkillReferenceFiles": { "doc-architecture": [ "references/discovery-questionnaire.md", "references/service-decomposition-guide.md", "references/audit-checklist.md", "references/doc-evolution-guide.md", "references/artifact-mapping.md", "references/tech-stack-profiles.md", "references/templates/agents-md.tmpl.md", "references/templates/architecture.tmpl.md", "references/templates/domain.tmpl.md", "references/templates/spec.tmpl.md", "references/templates/plan.tmpl.md", "references/templates/runbook.tmpl.md", "references/templates/frontend.tmpl.md" ], "frontend-engineering": [ "references/react-next-baseline.md", "references/component-patterns.md", "references/quality-checklist.md" ], "frontend-ui-ux-system": [ "references/product-style-map.md", "references/design-tokens.md", "references/interaction-accessibility.md", "references/delivery-checklist.md" ] }, "requiredRules": [ "rules/team-operating-model.md", "rules/handoff-contract.md", "rules/artifact-standards.md", "rules/escalation-policy.md", "rules/frontend-engineering-standards.md", "rules/frontend-ui-ux-standards.md", "rules/frontend-quality-gates.md", "rules/frontend-design-knowledge-base.md" ], "requiredRulePackFiles": [ "rules/README.md", "rules/common/coding-style.md", "rules/common/git-workflow.md", "rules/common/testing.md", "rules/common/performance.md", "rules/common/patterns.md", "rules/common/hooks.md", "rules/common/agents.md", "rules/common/security.md", "rules/typescript/README.md", "rules/typescript/coding-style.md", "rules/typescript/testing.md", "rules/typescript/frontend.md", "rules/java/README.md", "rules/java/coding-style.md", "rules/java/springboot.md", "rules/java/jpa.md", "rules/java/testing.md", "rules/java/security.md", "rules/python/README.md", "rules/python/coding-style.md", "rules/python/testing.md", "rules/python/security.md", "rules/golang/README.md", "rules/golang/coding-style.md", "rules/golang/testing.md" ], "requiredExtraFiles": [ "hooks/README.md", "hooks/hooks.json", "hooks/memory-persistence/README.md", "hooks/strategic-compact/README.md", "contexts/dev.md", "contexts/review.md", "contexts/research.md", "examples/project-CLAUDE.md", "examples/user-CLAUDE.md", "examples/saas-nextjs-CLAUDE.md", "examples/springboot-service-CLAUDE.md", "mcp-configs/mcp-servers.json", "tests/test_layout.py", "scripts/lib/audit-logger.js", "scripts/lib/team-skills-data.json", "scripts/lib/team-skills-platform.js", "scripts/build-platform-artifacts.js", "scripts/validate-library.js", "scripts/validate-workflow-state.js", "scripts/query-audit-logs.js", "scripts/hooks/session-start.js", "scripts/hooks/session-end.js", "scripts/hooks/pre-compact.js", "scripts/hooks/suggest-compact.js" ] }