技能介绍

要解决什么问题

在 AI 辅助开发里，常见痛点是：同一会话里既要做架构又写代码又跑测试，角色边界模糊，API 改动漏扫调用方，或 UI 改完没有统一的可视化与性能验收。CC GodMode 把宿主模型定位为 Orchestrator：你只描述「做什么」（新功能、修 Bug、改 API、发版等），由编排逻辑决定如何拆给专职子智能体，并约束交接顺序与质量门禁。

技能如何工作

这是 纯文档包（安装阶段无可执行文件），运行时通过 Task 工具按 subagent_type 调用 8 个角色，例如：

@researcher：Web 检索与资料评估（可选，用于陌生技术）
@architect：架构决策与 handoff 规格（新功能必经）
@api-guardian：REST/GraphQL/类型契约与消费者影响分析（API 变更强制）
@builder：按 Types → Backend → Services → Components → Tests 顺序实现
@validator 与 @tester：实现后并行双门禁（tsc/单测 vs Playwright/Lighthouse/A11y）
@scribe：VERSION、CHANGELOG、README 等发布前文档
@github-manager：Issue/PR/Release（未经许可不得 push）

标准入口包括 New Feature、Bug Fix、API Change、Research、Process Issue #X、Prepare Release。各智能体报告建议落在 reports/vX.X.X/；版本需先定 semver，再开工。

适用边界与注意点

工作流会指示代理在运行时执行 Bash、测试、GitHub、WebFetch 等，需本机二进制、网络与凭据，模型名（opus/sonnet/haiku）仅为示例，以 OpenClaw 配置为准。
触及 src/api/**、openapi.yaml 等 Critical Paths 必须走 @api-guardian；双门禁未双绿会打回 @builder。
@tester 要求每页三视口截图与控制台错误采集，属于硬性验收项，不适合只想「快速改两行」且跳过 E2E 的场景。

截图预览

使用场景

在 React/TypeScript 全栈仓库里，你要从调研、架构到实现完整交付一个新功能，并要求 @architect 与 @validator/@tester 双门禁都按流程执行。
计划改动 `openapi.yaml` 或 `shared/types` 中的类型与路由，需要先由 @api-guardian 做调用方发现与破坏性变更分类，再交给 @builder 改代码。
仓库里已有 GitHub Issue，你想用「Process Issue #X」加载议题内容，按修 Bug 或功能流程实现并在 `reports/vX.X.X/` 留存各角色报告。
准备 semver 发版时，需要 @scribe 更新 VERSION 与 CHANGELOG，并由 @github-manager 打标签创建 Release，且全程不擅自 git push。

适合人员

维护对外 REST/GraphQL 与共享 TypeScript 类型的平台工程师，改字段前必须查清所有 consumer 并避免漏改调用方。
带 React 产品交付的 Tech Lead，要求合并前既有 `tsc`/单测门禁，也有 Playwright 三视口截图与 Lighthouse 指标验收。
已在 OpenClaw 里用 Task 调度子代理的开发者，需要 Orchestrator 只委派、不亲自写代码的固定工作流说明。
开源仓库维护者，希望 Issue 分拣、PR 协作与 Prepare Release 由 @github-manager 与 @scribe 分工且版本号先行。

CC GodMode 多智能体开发编排