Skill: cubetribe/cc-godmode (version 5.11.3)

--- name: cc-godmode description: "Self-orchestrating multi-agent development workflows. You say WHAT, the AI decides HOW." metadata: clawdbot: emoji: "🚀" author: "cubetribe" version: "5.11.3" tags: - orchestration - multi-agent - development - workflow - documentation - automation repository: "https://github.com/cubetribe/openclaw-godmode-skill" license: "MIT" type: "orchestration-docs" runtime: requires_binaries: true requires_credentials: true requires_network: true tools: - Read - Write - Edit - Bash - Glob - Grep - WebSearch - WebFetch --- # CC_GodMode 🚀 > **Self-Orchestrating Development Workflows - You say WHAT, the AI decides HOW.** > ⚠️ **Note:** This is a **documentation-only package** (no install-time executables). However, workflows in this skill instruct agents to run shell/tools at **runtime** (e.g., Bash, tests, GitHub, Playwright, WebFetch/WebSearch), which may require network access, local binaries, and credentials depending on your environment. Model names (opus, sonnet, haiku) are illustrative examples; actual models depend on your OpenClaw configuration. You are the **Orchestrator** for CC_GodMode - a multi-agent system that automatically delegates and orchestrates development workflows. You plan, coordinate, and delegate. You NEVER implement yourself. --- ## Quick Start **Commands you can use:** | Command | What happens | |---------|--------------| | `New Feature: [X]` | Full workflow: research → design → implement → test → document | | `Bug Fix: [X]` | Quick fix: implement → validate → test | | `API Change: [X]` | Safe API change with consumer analysis | | `Research: [X]` | Investigate technologies/best practices | | `Process Issue #X` | Load and process a GitHub issue | | `Prepare Release` | Document and publish release | --- ## Your Subagents You have 8 specialized agents. Call them via the Task tool with `subagent_type`: | Agent | Role | Model | Key Tools | |-------|------|-------|-----------| | `@researcher` | Knowledge Discovery | haiku | WebSearch, WebFetch | | `@architect` | System Design | opus | Read, Grep, Glob | | `@api-guardian` | API Lifecycle | sonnet | Grep, Bash (git diff) | | `@builder` | Implementation | sonnet | Read, Write, Edit, Bash | | `@validator` | Code Quality Gate | sonnet | Bash (tsc, tests) | | `@tester` | UX Quality Gate | sonnet | Playwright, Lighthouse | | `@scribe` | Documentation | sonnet | Read, Write, Edit | | `@github-manager` | GitHub Ops | haiku | GitHub MCP, Bash (gh) | --- ## Standard Workflows ### 1. New Feature (Full Workflow) ``` ┌──▶ @validator ──┐ User ──▶ (@researcher)* ──▶ @architect ──▶ @builder ├──▶ @scribe └──▶ @tester ──┘ (PARALLEL) ``` *@researcher is optional - use when new tech research is needed ### 2. Bug Fix (Quick) ``` ┌──▶ @validator ──┐ User ──▶ @builder ├──▶ (done) └──▶ @tester ──┘ ``` ### 3. API Change (Critical!) ``` ┌──▶ @validator ──┐ User ──▶ (@researcher)* ──▶ @architect ──▶ @api-guardian ──▶ @builder ├──▶ @scribe └──▶ @tester ──┘ ``` **@api-guardian is MANDATORY for API changes!** ### 4. Refactoring ``` ┌──▶ @validator ──┐ User ──▶ @architect ──▶ @builder ├──▶ (done) └──▶ @tester ──┘ ``` ### 5. Release ``` User ──▶ @scribe ──▶ @github-manager ``` ### 6. Process Issue ``` User: "Process Issue #X" → @github-manager loads → Orchestrator analyzes → Appropriate workflow ``` ### 7. Research Task ``` User: "Research [topic]" → @researcher → Report with findings + sources ``` --- ## The 10 Golden Rules 1. **Version-First** - Determine target version BEFORE any work starts 2. **@researcher for Unknown Tech** - Use when new technologies need evaluation 3. **@architect is the Gate** - No feature starts without architecture decision 4. **@api-guardian is MANDATORY for API changes** - No exceptions 5. **Dual Quality Gates** - @validator (Code) AND @tester (UX) must BOTH be green 6. **@tester MUST create Screenshots** - Every page at 3 viewports (mobile, tablet, desktop) 7. **Use Task Tool** - Call agents via Task tool with `subagent_type` 8. **No Skipping** - Every agent in the workflow must be executed 9. **Reports in reports/vX.X.X/** - All agents save reports under version folder 10. **NEVER git push without permission** - Applies to ALL agents! --- ## Dual Quality Gates After @builder completes, BOTH gates run **in parallel** for 40% faster validation: ``` @builder │ ├────────────────────┐ ▼ ▼ @validator @tester (Code Quality) (UX Quality) │ │ └────────┬───────────┘ │ SYNC POINT │ ┌────────┴────────┐ │ │ BOTH APPROVED ANY BLOCKED │ │ ▼ ▼ @scribe @builder (fix) ``` **Decision Matrix:** | @validator | @tester | Action | |------------|---------|--------| | ✅ APPROVED | ✅ APPROVED | → @scribe | | ✅ APPROVED | 🔴 BLOCKED | → @builder (tester concerns) | | 🔴 BLOCKED | ✅ APPROVED | → @builder (code concerns) | | 🔴 BLOCKED | 🔴 BLOCKED | → @builder (merged feedback) | ### Gate 1: @validator (Code Quality) - TypeScript compiles (`tsc --noEmit`) - Unit tests pass - No security issues - All consumers updated (for API changes) ### Gate 2: @tester (UX Quality) - E2E tests pass - Screenshots at 3 viewports - A11y compliant (WCAG 2.1 AA) - Core Web Vitals OK (LCP, CLS, INP, FCP) --- ## Critical Paths (API Changes) Changes in these paths **MUST** go through @api-guardian: - `src/api/**` - `backend/routes/**` - `shared/types/**` - `types/` - `*.d.ts` - `openapi.yaml` / `openapi.json` - `schema.graphql` --- ## File Structure for Reports ``` reports/ └── v[VERSION]/ ├── 00-researcher-report.md (optional) ├── 01-architect-report.md ├── 02-api-guardian-report.md ├── 03-builder-report.md ├── 04-validator-report.md ├── 05-tester-report.md └── 06-scribe-report.md ``` --- ## Handoff Matrix | Agent | Receives from | Passes to | |-------|---------------|-----------| | @researcher | User/Orchestrator | @architect | | @architect | User/@researcher | @api-guardian or @builder | | @api-guardian | @architect | @builder | | @builder | @architect/@api-guardian | @validator AND @tester (PARALLEL) | | @validator | @builder | SYNC POINT | | @tester | @builder | SYNC POINT | | @scribe | Both gates approved | @github-manager (for release) | | @github-manager | @scribe/User | Done | --- ## Pre-Push Requirements **Before ANY push:** 1. **VERSION file MUST be updated** (project root) 2. **CHANGELOG.md MUST be updated** 3. **README.md updated if needed** (user-facing changes) 4. **NEVER push the same version twice** **Versioning Schema (Semantic Versioning):** - **MAJOR** (X.0.0): Breaking changes - **MINOR** (0.X.0): New features - **PATCH** (0.0.X): Bug fixes --- ## Detailed Agent Specifications <details> <summary><strong>@researcher</strong> - Knowledge Discovery Specialist</summary> ### Role Knowledge Discovery Specialist - expert in web research, documentation lookup, and technology evaluation. ### Tools | Tool | Usage | |------|-------| | WebSearch | Search internet for current information | | WebFetch | Fetch specific URLs, documentation pages | | Read | Read local documentation, previous research | | Glob | Find existing documentation in codebase | | memory MCP | Store key findings, no-go technologies | ### What I Do 1. **Technology Research** - Evaluate technologies with pros/cons 2. **Best Practices Lookup** - Find current patterns (2024/2025) 3. **Security Research** - Check CVE databases, security advisories 4. **Documentation Discovery** - Find official API docs, guides 5. **Competitive Analysis** - How do similar projects solve this? ### Output Format ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔍 RESEARCH COMPLETE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ## Topic: [Research Topic] ### Key Findings 1. Finding 1 [Source](url) 2. Finding 2 [Source](url) ### Recommendation for @architect [Clear recommendation with rationale] ### Sources - [Source 1](url) - [Source 2](url) ### Handoff → @architect for architecture decisions ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### Timeout & Graceful Degradation - **Hard timeout: 30 seconds MAX** per research task - If timeout reached: STOP → Report partial results → Indicate what's incomplete - Uses graceful degradation: Full → Partial → Search Results Only → Failure Report **Model:** haiku (fast & cost-effective) </details> <details> <summary><strong>@architect</strong> - System Architect</summary> ### Role System Architect - strategic planner for React/Node.js/TypeScript enterprise applications. ### Tools | Tool | Usage | |------|-------| | Read | Analyze existing architecture docs | | Grep | Code pattern and dependency search | | Glob | Capture module structures | | WebFetch | Research best practices | ### What I Do 1. **Design high-level architecture** - Module structure, dependency graphs 2. **Make technical decisions** - Stack selection, state management, patterns 3. **Create handoff specifications** - Clear specs for @api-guardian and @builder ### Decision Template ```markdown ## Decision: [Title] ### Context [Why this decision is necessary] ### Options Analyzed 1. Option A: [Pros/Cons] 2. Option B: [Pros/Cons] ### Chosen Solution [Rationale] ### Affected Modules - [ ] `src/module/...` - Type of change ### Next Steps - [ ] @api-guardian for API contract (if API change) - [ ] @builder for implementation ``` ### Design Principles - Single Responsibility Principle - Composition over Inheritance - Props Drilling Max 2 Levels (then Context) - Server State Separation (React Query/SWR) **Model:** opus (complex reasoning, high-impact decisions) </details> <details> <summary><strong>@api-guardian</strong> - API Lifecycle Expert</summary> ### Role API Lifecycle Expert - specialist for REST/GraphQL APIs, TypeScript type systems, and cross-service contract management. ### Tools | Tool | Usage | |------|-------| | Read | Read API files and type definitions | | Grep | Consumer discovery (find all imports/usages) | | Glob | Locate API/type files | | Bash | TypeScript compilation, git diff, schema validation | ### What I Do 1. **Identify change type** - Additive, Modification, Removal 2. **Perform consumer discovery** - Find ALL usages of changed types/endpoints 3. **Create impact report** - List affected consumers, migration checklist ### Change Classification | Type | Example | Breaking? | |------|---------|-----------| | Additive | New fields, new endpoints | Usually safe | | Modification | Type changes, renamed fields | ⚠️ BREAKING | | Removal | Deleted fields/endpoints | ⚠️ BREAKING | ### Output Format ```markdown ## API Impact Analysis Report ### Breaking Changes Detected - `User.email` → `User.emailAddress` (5 consumers affected) ### Consumer Impact Matrix | Consumer | File:Line | Required Action | |----------|-----------|-----------------| | UserCard | src/UserCard.tsx:23 | Update field access | ### Migration Checklist - [ ] Update src/UserCard.tsx line 23 - [ ] Run `npm run typecheck` ``` **Model:** sonnet (balanced analysis + documentation) </details> <details> <summary><strong>@builder</strong> - Full-Stack Developer</summary> ### Role Senior Full-Stack Developer - specialist for React/Node.js/TypeScript implementation. ### Tools | Tool | Usage | |------|-------| | Read | Read existing code, analyze specs | | Write | Create new files | | Edit | Modify existing files | | Bash | Run TypeCheck, Tests, Lint | | Glob | Find affected files | | Grep | Search code patterns | ### What I Do 1. **Process specifications** from @architect and @api-guardian 2. **Implement code** in order: Types → Backend → Services → Components → Tests 3. **Pass quality gates** - TypeScript, tests, lint must pass ### Implementation Order 1. TypeScript Types (`shared/types/`) 2. Backend API (if relevant) 3. Frontend Services/Hooks 4. UI Components 5. Tests ### Code Standards - Functional Components with Hooks (no Classes) - Named Exports preferred - Barrel Files (`index.ts`) for modules - All Promises with try/catch - No `any` Types ### Output Format ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 💻 IMPLEMENTATION COMPLETE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### Files Created - `src/components/UserCard.tsx` ### Files Modified - `src/hooks/useUser.ts:15-20` ### Quality Gates - [x] `npm run typecheck` passes - [x] `npm test` passes - [x] `npm run lint` passes ### Ready for @validator ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` **Model:** sonnet (optimal for implementation) </details> <details> <summary><strong>@validator</strong> - Code Quality Engineer</summary> ### Role Code Quality Engineer - specialist for verification and quality assurance. ### Tools | Tool | Usage | |------|-------| | Read | Read implementation reports | | Grep | Verify consumer updates | | Glob | Locate changed files | | Bash | Run TypeCheck, Tests, Lint, git diff | ### What I Do 1. **Verify TypeScript compilation** - `tsc --noEmit` 2. **Verify tests** - All pass, adequate coverage 3. **Verify consumer updates** - Cross-reference @api-guardian's list 4. **Security checks** - No hardcoded secrets, auth on protected routes 5. **Performance checks** - No N+1 patterns, reasonable bundle size ### Checklist - [ ] TypeScript compiles (no errors) - [ ] Unit tests pass - [ ] All listed consumers were updated - [ ] No security issues - [ ] No performance anti-patterns ### Output (Success) ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ VALIDATION PASSED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ APPROVED - Ready for @scribe and commit ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### Output (Failure) ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ❌ VALIDATION FAILED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### Issues Found 1. [CRITICAL] TypeScript Error in src/hooks/useUser.ts:15 → Returning to @builder for fixes ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` **Model:** sonnet (balanced verification) </details> <details> <summary><strong>@tester</strong> - UX Quality Engineer</summary> ### Role UX Quality Engineer - specialist for E2E testing, visual regression, accessibility, and performance. ### Tools | Tool | Usage | |------|-------| | Playwright MCP | Browser automation, E2E tests, screenshots | | Lighthouse MCP | Performance & accessibility audits | | A11y MCP | WCAG compliance | | Read | Read test reports | | Bash | Run tests, start server | ### MANDATORY Requirements **Screenshots (NON-NEGOTIABLE):** - Create screenshots for EVERY page tested - Test at 3 viewports: mobile (375px), tablet (768px), desktop (1920px) - Format: `[page]-[viewport].png` saved to `.playwright-mcp/` **Console Errors (MANDATORY):** - Capture browser console for every page - Report ALL JavaScript errors **Performance Metrics (MANDATORY):** | Metric | Good | Acceptable | Fail | |--------|------|------------|------| | LCP | ≤2.5s | ≤4s | >4s | | INP | ≤200ms | ≤500ms | >500ms | | CLS | ≤0.1 | ≤0.25 | >0.25 | | FCP | ≤1.8s | ≤3s | >3s | ### Output Format ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🎭 UX TESTING COMPLETE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ## Screenshots Created | Page | Mobile | Tablet | Desktop | |------|--------|--------|---------| | Home | ✓ | ✓ | ✓ | ## Console Errors: 0 detected ## A11y Status: PASS ## Performance: All metrics within thresholds ✅ APPROVED - Ready for @scribe ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### Blocking vs Non-Blocking Issues **BLOCKING:** Console errors, E2E failures, LCP > 4s, CLS > 0.25 **NON-BLOCKING:** Minor A11y issues, "needs improvement" performance **Model:** sonnet (MCP coordination + analysis) </details> <details> <summary><strong>@scribe</strong> - Technical Writer</summary> ### Role Technical Writer - specialist for developer documentation. ### Tools | Tool | Usage | |------|-------| | Read | Read agent reports | | Write | Create new docs | | Edit | Update existing docs | | Grep | Find undocumented endpoints | | Glob | Locate doc files | ### What I Do (MANDATORY before push!) 1. **Update VERSION file** - Semantic versioning 2. **Update CHANGELOG.md** - Document ALL changes 3. **Update API_CONSUMERS.md** - Based on @api-guardian report 4. **Update README.md** - For user-facing changes 5. **Add JSDoc** - For new complex functions ### Changelog Format (Keep a Changelog) ```markdown ## [X.X.X] - YYYY-MM-DD ### Added - New features ### Changed - Changes to existing code ### Fixed - Bug fixes ### Breaking Changes - ⚠️ Breaking change description ``` ### Output Format ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📚 DOCUMENTATION COMPLETE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### Version Update - VERSION: X.X.X → Y.Y.Y - CHANGELOG: Updated ### Files Updated - VERSION - CHANGELOG.md ✅ Ready for push ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` **Model:** sonnet (reading + writing capability) </details> <details> <summary><strong>@github-manager</strong> - GitHub Project Manager</summary> ### Role GitHub Project Management Specialist - with full access to GitHub MCP Server. ### Tools | Tool | Usage | |------|-------| | GitHub MCP | Repository API, issue/PR management | | Read | Read reports, CHANGELOG | | Bash | `gh` CLI as fallback | | Grep | Search commit messages | ### What I Do 1. **Issue Lifecycle** - Create, label, assign, close issues 2. **Pull Request Workflow** - Create PRs, request reviews, merge 3. **Release Management** - Tag, create GitHub releases 4. **Repository Sync** - Sync forks, fetch upstream 5. **CI/CD Monitoring** - Watch workflows, rerun failed jobs ### Quick Commands ```bash # Create issue gh issue create --title "Bug: [desc]" --label "bug" # Create PR gh pr create --title "[type]: [desc]" # Create release gh release create "v$VERSION" --notes-file CHANGELOG.md # Monitor CI gh run list --limit 10 gh run view [run-id] --log-failed ``` ### Commit Message Format ``` <type>(<scope>): <description> Types: feat, fix, docs, style, refactor, test, chore ``` **Model:** haiku (simple operations, cost-optimized) </details> --- ## Version **CC_GodMode v5.11.1 - The Fail-Safe Release** ### Key Features - 8 Specialized Agents with role-based models - Dual Quality Gates (40% faster with parallel execution) - Fail-Safe Reporting for @researcher and @tester - Graceful Degradation with timeout handling - MCP Health Check System - Meta-Decision Logic (5 auto-trigger rules) - Domain-Pack Architecture (Project > Global > Core) ### MCP Servers Used - `playwright` - REQUIRED for @tester - `github` - REQUIRED for @github-manager - `lighthouse` - OPTIONAL for @tester (Performance) - `a11y` - OPTIONAL for @tester (Accessibility) - `memory` - OPTIONAL for @researcher, @architect --- ## Start When the user makes a request: 1. **Analyze** the request type (Feature/Bug/API/Refactor/Issue) 2. **Determine version** → Read VERSION file, decide increment 3. **Create report folder** → `mkdir -p reports/vX.X.X/` 4. **Announce version** → "Working on vX.X.X - [description]" 5. **Check** MCP server availability 6. **Select** the appropriate workflow 7. **Activate** agents → All reports saved to `reports/vX.X.X/` 8. **Complete** → @scribe updates VERSION + CHANGELOG

path: CHANGELOG.md
content: # Changelog

All notable changes to the CC_GodMode Skill will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [5.11.3] - 2026-02-16

### Changed
- Resolved remaining ClawHub scan ambiguity by aligning runtime declarations with actual workflow instructions.
- Updated `SKILL.md` note to distinguish **docs-only package** from **runtime agent actions**.

### Runtime/Permission Transparency
- Declared runtime expectations for full workflow usage:
  - `requires_binaries: true`
  - `requires_credentials: true`
  - `requires_network: true`
- Added explicit `runtime_binaries` (required/optional) and `runtime_credentials` (optional) sections.
- Clarified security semantics:
  - No install-time executable payload
  - Agent runtime may execute shell/network operations when user invokes workflows.

## [5.11.2] - 2026-02-16

### Changed
- Added `clawdis.yaml` with explicit runtime/security declarations to reduce scanner ambiguity.
- Clarified `SKILL.md` metadata (`author`, `repository`, tags) and bumped version to `5.11.2`.
- Added top-level disclaimer: skill is documentation-only (no bundled executables, no credentials required).

### Security/Transparency
- Declared `type: orchestration-docs`.
- Declared `runtime.requires_binaries: false` and `runtime.requires_credentials: false`.
- Added explicit notes that model names are examples and depend on user OpenClaw configuration.

## [5.11.1] - 2026-02-04

### Added
- Initial OpenClaw Skill release
- Complete SKILL.md with all 8 agent specifications
- Collapsible `<details>` sections for detailed agent docs
- Quick Start section for immediate usage
- Dual Quality Gates documentation
- Workflow diagrams in ASCII art
- ClawHub publishing workflow

### Features from CC_GodMode v5.11.1
- **@tester Fail-Safe Reporting**
  - Graceful degradation chain: Full → Partial → Failure Report
  - Structured error output (JSON) for programmatic handling
  - Screenshot-on-failure best practice
  - MCP Health Check (Pre-Test) instructions

- **@researcher Timeout & Graceful Degradation**
  - Hard timeout: 30 seconds MAX per task
  - Partial results format for incomplete research
  - Memory usage guidelines

- **8 Specialized Agents**
  - @researcher (haiku) - Knowledge Discovery
  - @architect (opus) - System Design
  - @api-guardian (sonnet) - API Lifecycle
  - @builder (sonnet) - Implementation
  - @validator (sonnet) - Code Quality
  - @tester (sonnet) - UX Quality
  - @scribe (sonnet) - Documentation
  - @github-manager (haiku) - GitHub Operations

- **Dual Quality Gates**
  - 40% faster validation with parallel execution
  - @validator (Code) + @tester (UX) run simultaneously
  - Decision matrix for result coordination

- **7 Standard Workflows**
  - New Feature
  - Bug Fix
  - API Change
  - Refactoring
  - Release
  - Process Issue
  - Research Task

### Technical Details
- YAML frontmatter for ClawHub metadata
- Version 1:1 mapping with CC_GodMode versions
- Self-contained documentation (no external dependencies)
- Context-window optimized with collapsible sections

## [Unreleased]

### Planned
- Extended workflow customization
- Domain pack integration
- Custom agent model selection


path: README.md
content: # 🚀 OpenClaw GodMode Skill

> **Self-Orchestrating Multi-Agent Development Workflows for Claude Code**
>
> *You say WHAT, the AI decides HOW.*

[![ClawHub](https://img.shields.io/badge/ClawHub-cc--godmode-blue)](https://clawhub.ai/skills/cc-godmode)
[![Version](https://img.shields.io/badge/version-5.11.1-green)](./CHANGELOG.md)
[![License](https://img.shields.io/badge/license-MIT-blue)](./LICENSE)
[![OpenClaw](https://img.shields.io/badge/OpenClaw-compatible-orange)](https://openclaw.ai)
[![Claude Code](https://img.shields.io/badge/Claude_Code-required-purple)](https://claude.ai/code)

---

## ⚠️ Important: Requirements

### 🔧 Claude Code Required
This skill **requires [Claude Code](https://claude.ai/code)** (Anthropic's CLI agent). It will not work with the web interface or API alone.

### 💳 Paid Account Recommended
GodMode spawns multiple sub-agents that consume tokens quickly. We **strongly recommend**:

| Plan | Recommendation |
|------|----------------|
| Free | ❌ Not recommended (tokens exhaust very quickly) |
| Pro ($20/mo) | ✅ Good for smaller projects |
| **Max ($200/mo)** | ⭐ **Recommended** for heavy use |

The multi-agent orchestration is powerful but token-intensive. With a free account, you'll hit limits within minutes.

---

## 🔀 Two Versions of GodMode

### This Repo: OpenClaw GodMode Skill
**Optimized for [OpenClaw](https://openclaw.ai)** — the AI agent framework that extends Claude Code with messaging, cron jobs, and more.

- 📦 Installable via ClawHub
- 🔗 Integrates with OpenClaw's skill system
- 💬 Works with Telegram, WhatsApp, Discord channels
- ⏰ Can be triggered via cron jobs

### Original: [ClawdBot-GodMode](https://github.com/cubetribe/ClawdBot-GodMode)
**The standalone CLAUDE.md version** — perfect for server administration from your local machine.

- 🖥️ Ideal for managing VPS and remote servers
- 🔧 Great for administering machines running OpenClaw
- 📝 Documentation-first approach with excellent versioning
- 🚀 Battle-tested on multiple production servers

**Both repos are valuable** — choose based on your use case:
- Running OpenClaw? → Use this skill
- Managing servers via Claude Code locally? → Use the [original GodMode](https://github.com/cubetribe/ClawdBot-GodMode)

---

## ✨ What is GodMode?

GodMode transforms your **Claude Code** agent into a **multi-agent development orchestrator**. Instead of manually managing every step of development, you simply describe what you want — and a team of specialized AI agents figures out how to build it.

This isn't just another coding assistant. It's a complete **autonomous development workflow** that has been battle-tested over multiple weeks in real-world production projects.

### 🎯 The Magic

```
You: "Add user authentication with JWT and refresh tokens"

GodMode: *spawns @researcher to evaluate best practices*
         *@architect designs the system*
         *@builder implements it*
         *@validator + @tester run quality checks in parallel*
         *@scribe updates documentation*
         
Result: Production-ready feature with tests, docs, and proper architecture.
```

---

## 🤖 Meet the Team

GodMode orchestrates **8 specialized agents**, each with a specific role:

| Agent | Role | What They Do |
|-------|------|--------------|
| 🔬 **@researcher** | Knowledge Discovery | Web research, tech evaluation, best practices |
| 🏗️ **@architect** | System Design | Architecture decisions, ADRs, system design |
| 🛡️ **@api-guardian** | API Lifecycle | Breaking change detection, versioning |
| 👷 **@builder** | Implementation | Code writing, refactoring |
| ✅ **@validator** | Code Quality | TypeScript, linting, security checks |
| 🧪 **@tester** | UX Quality | E2E tests, visual regression, a11y |
| 📝 **@scribe** | Documentation | Changelog, README, API docs |
| 🐙 **@github-manager** | GitHub Ops | Issues, PRs, releases, CI/CD |

---

## 📦 Installation

### Via ClawHub (Recommended)

```bash
clawdhub install cc-godmode
```

### Manual Installation

```bash
# Clone this repository
git clone https://github.com/cubetribe/openclaw-godmode-skill.git

# Copy to your OpenClaw skills directory
cp -r openclaw-godmode-skill ~/.openclaw/skills/cc-godmode

# Or for Clawdbot:
cp -r openclaw-godmode-skill ~/.clawdbot/skills/cc-godmode

# Verify installation
ls ~/.openclaw/skills/cc-godmode/SKILL.md
```

---

## 🎮 Usage

Once installed, just describe what you want in natural language:

### New Feature
```
New Feature: Add user authentication with JWT
```

### Bug Fix
```
Bug Fix: Login form validation not working
```

### API Change
```
API Change: Add email field to User type
```

### Research Task
```
Research: Best practices for React state management 2025
```

### Release
```
Prepare Release
```

---

## 🔄 Workflows

GodMode automatically selects the right workflow based on your request:

### 🆕 New Feature (Full Pipeline)
```
You → @researcher* → @architect → @builder → [@validator + @tester] → @scribe
                                                   (parallel)
```

### 🐛 Bug Fix (Quick)
```
You → @builder → [@validator + @tester] → done
```

### ⚠️ API Change (Critical Path)
```
You → @architect → @api-guardian → @builder → [@validator + @tester] → @scribe
```

### 🔬 Research Only
```
You → @researcher → Report
```

*Agents marked with `*` are optional and context-dependent*

---

## 🏆 Why GodMode?

### Battle-Tested
This system has been developed and refined over **multiple weeks** of intensive real-world testing. It's not theoretical — it's proven to work on production projects.

### True Autonomy
Unlike simple prompt chains, GodMode agents make intelligent decisions about:
- Which agents to involve
- When to parallelize tasks
- How to handle failures and edge cases
- What quality gates to apply

### Documentation-First
Every change is documented. Every decision is recorded. The versioning and documentation workflow is **extremely reliable** — crucial for maintaining production systems.

### Dual Quality Gates
Every feature passes through **two independent quality checks** running in parallel — because catching bugs early saves hours of debugging later.

---

## ⚙️ Requirements

### Required
- **[Claude Code](https://claude.ai/code)** — Anthropic's CLI agent
- **Paid Claude Account** — Pro ($20) or Max ($200) recommended

### Required MCP Servers
- `playwright` — For @tester E2E testing
- `github` — For @github-manager operations

### Optional (Enhanced Features)
- `lighthouse` — Performance audits
- `a11y` — Accessibility testing
- `memory` — Context persistence across sessions

Check your MCP status:
```bash
openclaw mcp list
# or
claude mcp list
```

---

## 🔒 Security

This skill is **documentation-only** and contains no executable code:

- ✅ No bash scripts that run automatically
- ✅ No external API calls from the skill itself
- ✅ No file modifications without explicit agent action
- ✅ Full source transparency — read every line
- ✅ MIT licensed

All orchestration happens through your existing Claude Code agent using standard tool calls.

---

## 📚 Documentation

| Document | Description |
|----------|-------------|
| [SKILL.md](./SKILL.md) | Main skill documentation (loaded by OpenClaw) |
| [docs/WORKFLOWS.md](./docs/WORKFLOWS.md) | Detailed workflow documentation |
| [docs/AGENTS.md](./docs/AGENTS.md) | Complete agent specifications |
| [docs/TROUBLESHOOTING.md](./docs/TROUBLESHOOTING.md) | FAQ and problem solving |
| [docs/MIGRATION.md](./docs/MIGRATION.md) | Migrating from CLAUDE.md |

---

## 🔗 Links

- **Original GodMode:** [ClawdBot-GodMode](https://github.com/cubetribe/ClawdBot-GodMode) — Standalone version for server administration
- **OpenClaw:** [openclaw.ai](https://openclaw.ai) — The AI agent framework
- **ClawHub:** [clawhub.ai](https://clawhub.ai) — Skill marketplace
- **Claude Code:** [claude.ai/code](https://claude.ai/code) — Anthropic's CLI agent

---

## 🤝 Contributing

Contributions are welcome! This project is open source and we'd love your help making it even better.

1. Fork this repository
2. Create a feature branch: `git checkout -b feature/my-feature`
3. Make your changes
4. Test locally by copying to your skills directory
5. Submit a pull request

---

## 📄 License

MIT License — see [LICENSE](./LICENSE)

---

## 💬 A Note from the Creator

> I've been working on GodMode for weeks, testing it on real projects, refining the agent interactions, and optimizing the workflows. The results have been **sensational** — tasks that used to take hours now complete in minutes with higher quality.
>
> I use the original GodMode daily to manage multiple VPS and production servers. The documentation-first approach and reliable versioning make it a dream for server administration. This OpenClaw version brings the same power to the OpenClaw ecosystem.
>
> I'm sharing this with the open-source community because I believe this approach to AI-assisted development is the future. Try it, break it, improve it, and let's build something amazing together.
>
> **Pro tip:** Get the Max plan ($200/mo) if you're serious about multi-agent workflows. The token headroom makes all the difference.
>
> — Dennis @ [cubetribe](https://github.com/cubetribe)

---

**Built with 🚀 by humans and Claude Code working together**


path: clawdis.yaml
content: # CC_GodMode Skill - ClawHub Manifest
# This skill is a documentation/orchestration layer only.
# It guides the agent's workflow but does NOT execute code itself.

name: cc-godmode
version: 5.11.3
description: "Self-orchestrating multi-agent development workflows. You say WHAT, the AI decides HOW."

author:
  name: cubetribe
  github: https://github.com/cubetribe

license: MIT
repository: https://github.com/cubetribe/openclaw-godmode-skill

# Skill type: documentation-only orchestrator
# This package itself is docs-only (no install-time executable payload).
# At runtime, agents following these workflows can use shell/network tools.
type: orchestration-docs

# Runtime expectations for FULL workflow usage
runtime:
  requires_binaries: true
  requires_credentials: true
  requires_network: true

runtime_binaries:
  required:
    - bash
    - git
    - grep
  optional:
    - node
    - npm
    - tsc
    - gh
    - playwright
    - lighthouse

runtime_credentials:
  optional:
    - GH_TOKEN (for GitHub operations)
    - Claude/Anthropic auth (if using Claude Code workflows)
    - MCP server auth/config (if applicable)
  
# Tools referenced in documentation (for transparency)
# These are standard OpenClaw tools, not external dependencies
documented_tools:
  - Read        # Standard file reading
  - Write       # Standard file writing  
  - Edit        # Standard file editing
  - Bash        # Standard shell (exec)
  - Glob        # File pattern matching
  - Grep        # Text search
  - WebSearch   # Built-in web search
  - WebFetch    # Built-in URL fetching

# Agent models mentioned are EXAMPLES
# Users configure their own models in OpenClaw config
model_examples:
  note: "Model names (opus, sonnet, haiku) are illustrative examples. Actual models depend on user's OpenClaw configuration."

# Security notes
security:
  install_time_executes_code: false
  runtime_agent_executes_code: true
  runtime_agent_network_access: true
  file_operations: "agent-runtime only; package itself is docs"
  
tags:
  - orchestration
  - multi-agent
  - development
  - workflow
  - documentation


path: docs/WORKFLOWS.md
content: # CC_GodMode Workflows

Detailed documentation of all 7 standard workflows.

## Table of Contents

1. [New Feature](#1-new-feature)
2. [Bug Fix](#2-bug-fix)
3. [API Change](#3-api-change)
4. [Refactoring](#4-refactoring)
5. [Release](#5-release)
6. [Process Issue](#6-process-issue)
7. [Research Task](#7-research-task)

---

## 1. New Feature

**Trigger:** `New Feature: [description]`

### Flow
```
                                          ┌──▶ @validator ──┐
User ──▶ (@researcher)* ──▶ @architect ──▶ @builder              ├──▶ @scribe
                                          └──▶ @tester   ──┘
                                               (PARALLEL)
```

### Steps

1. **@researcher** (optional) - If new technology research is needed
   - Evaluates technologies
   - Finds best practices
   - Creates research report

2. **@architect** - Design phase
   - Analyzes requirements
   - Creates module structure
   - Documents trade-offs
   - Produces architecture decision

3. **@builder** - Implementation
   - Implements types first
   - Then backend (if needed)
   - Then frontend
   - Writes tests

4. **@validator + @tester** (parallel)
   - @validator: TypeScript, unit tests, security
   - @tester: E2E, screenshots, a11y, performance

5. **@scribe** - Documentation
   - Updates VERSION
   - Updates CHANGELOG
   - Updates README if needed

### Example

```
User: "New Feature: Add dark mode toggle to settings page"

Orchestrator:
→ @architect: Design state management for theme, component structure
→ @builder: Implement ThemeContext, SettingsToggle component
→ @validator: Verify TypeScript, run unit tests
→ @tester: Screenshot dark/light modes at 3 viewports
→ @scribe: Update CHANGELOG with dark mode feature
```

---

## 2. Bug Fix

**Trigger:** `Bug Fix: [description]`

### Flow
```
                ┌──▶ @validator ──┐
User ──▶ @builder                  ├──▶ (done)
                └──▶ @tester   ──┘
                     (PARALLEL)
```

### Steps

1. **@builder** - Fix implementation
   - Locate bug
   - Implement fix
   - Add regression test

2. **@validator + @tester** (parallel)
   - Verify fix doesn't break anything
   - Run relevant E2E tests

### Example

```
User: "Bug Fix: Login button not responding on mobile"

Orchestrator:
→ @builder: Fix click handler, add touch event support
→ @validator: Run existing tests
→ @tester: Test login flow on mobile viewport
```

---

## 3. API Change

**Trigger:** `API Change: [description]`

### Flow
```
                                                              ┌──▶ @validator ──┐
User ──▶ (@researcher)* ──▶ @architect ──▶ @api-guardian ──▶ @builder              ├──▶ @scribe
                                                              └──▶ @tester   ──┘
                                                                   (PARALLEL)
```

### Steps

1. **@architect** - Design API change
   - Define new schema
   - Plan migration

2. **@api-guardian** - Impact analysis (MANDATORY!)
   - Find ALL consumers
   - Classify breaking changes
   - Create migration checklist

3. **@builder** - Implement with consumer updates
   - Update API/types first
   - Update ALL consumers from checklist

4. **@validator + @tester** (parallel)
   - Verify ALL consumers updated
   - Test API endpoints

5. **@scribe** - Document breaking changes
   - Add breaking change section to CHANGELOG
   - Update API_CONSUMERS.md

### Critical Paths

These file patterns trigger @api-guardian:

- `src/api/**`
- `backend/routes/**`
- `shared/types/**`
- `types/`
- `*.d.ts`
- `openapi.yaml` / `openapi.json`
- `schema.graphql`

### Example

```
User: "API Change: Rename User.email to User.emailAddress"

Orchestrator:
→ @architect: Plan schema migration
→ @api-guardian: Find 5 consumers, mark as BREAKING
→ @builder: Update type + all 5 consumer files
→ @validator: Verify all imports correct, TypeScript passes
→ @tester: Test user-related flows
→ @scribe: Document breaking change, update API_CONSUMERS.md
```

---

## 4. Refactoring

**Trigger:** `Refactor: [description]`

### Flow
```
                            ┌──▶ @validator ──┐
User ──▶ @architect ──▶ @builder              ├──▶ (done)
                            └──▶ @tester   ──┘
                                 (PARALLEL)
```

### Steps

1. **@architect** - Plan refactoring
   - Analyze current structure
   - Design improved structure
   - Document affected modules

2. **@builder** - Execute refactoring
   - Move/rename files
   - Update imports
   - Keep tests passing

3. **@validator + @tester** (parallel)
   - Verify behavior unchanged
   - No regressions

---

## 5. Release

**Trigger:** `Prepare Release`

### Flow
```
User ──▶ @scribe ──▶ @github-manager
```

### Steps

1. **@scribe** - Prepare release
   - Finalize VERSION
   - Complete CHANGELOG
   - Update README

2. **@github-manager** - Publish
   - Create git tag
   - Create GitHub release
   - Trigger CI/CD

---

## 6. Process Issue

**Trigger:** `Process Issue #X`

### Flow
```
User: "Process Issue #X"
  │
  ▼
@github-manager loads Issue
  │
  ▼
Orchestrator analyzes: Type, Complexity, Areas
  │
  ▼
Appropriate workflow is executed
  │
  ▼
@github-manager creates PR with "Fixes #X"
```

### Issue Classification

| Type | Workflow |
|------|----------|
| Bug | Bug Fix workflow |
| Feature | New Feature workflow |
| Enhancement | Refactoring or Feature workflow |
| Documentation | @scribe only |

---

## 7. Research Task

**Trigger:** `Research: [topic]`

### Flow
```
User: "Research [topic]"
  │
  ▼
@researcher gathers knowledge
  │
  ▼
Report with findings + sources
```

### Steps

1. **@researcher** - Gather knowledge
   - WebSearch for current info
   - WebFetch documentation
   - Compare alternatives
   - Check security advisories

2. **Report** - Actionable findings
   - Key findings with sources
   - Recommendation
   - Next steps

### Example

```
User: "Research: Best state management for React in 2026"

@researcher:
→ Search: "React state management comparison 2026"
→ Fetch: Official docs for Zustand, Jotai, Redux
→ Compare: Bundle size, learning curve, performance
→ Report: Recommend Zustand for this project size
```

---

## Parallel Quality Gates

All workflows (except Release and Research) end with parallel quality gates:

```
                    ┌────────────────────┐
                    │      @builder      │
                    └─────────┬──────────┘
                              │
              ┌───────────────┼───────────────┐
              │               │               │
              ▼               │               ▼
    ┌─────────────────┐       │     ┌─────────────────┐
    │   @validator    │       │     │    @tester      │
    │ (Code Quality)  │       │     │  (UX Quality)   │
    └────────┬────────┘       │     └────────┬────────┘
              │               │               │
              └───────────────┼───────────────┘
                              │
                        SYNC POINT
                              │
                    ┌─────────┴─────────┐
                    │                   │
                    ▼                   ▼
              BOTH PASS            ANY FAIL
                    │                   │
                    ▼                   ▼
               @scribe             @builder
                                   (fix it)
```

**Performance:** 40% faster than sequential execution!


path: docs/TROUBLESHOOTING.md
content: # CC_GodMode Troubleshooting

Common issues and solutions when using the CC_GodMode skill.

## Table of Contents

1. [Installation Issues](#installation-issues)
2. [MCP Server Issues](#mcp-server-issues)
3. [Agent Issues](#agent-issues)
4. [Workflow Issues](#workflow-issues)
5. [Quality Gate Issues](#quality-gate-issues)

---

## Installation Issues

### Skill not found after installation

**Symptoms:**
- `clawdhub list` doesn't show cc-godmode
- Agent doesn't recognize CC_GodMode commands

**Solutions:**

1. Verify installation:
```bash
clawdhub list | grep cc-godmode
```

2. Try reinstalling:
```bash
clawdhub uninstall cc-godmode
clawdhub install cc-godmode
```

3. Check skill directory:
```bash
ls ~/.clawdbot/skills/cc-godmode/
```

### Version mismatch

**Symptoms:**
- Skill reports different version than expected
- Features from newer version not working

**Solutions:**

1. Check installed version:
```bash
grep "version:" ~/.clawdbot/skills/cc-godmode/SKILL.md
```

2. Update to latest:
```bash
clawdhub update cc-godmode
```

---

## MCP Server Issues

### Playwright MCP not available

**Symptoms:**
- @tester fails to start
- "Playwright MCP not responding" error
- No screenshots generated

**Solutions:**

1. Check MCP status:
```bash
claude mcp list
```

2. Verify Playwright is configured:
```bash
# In your MCP config (mcp.json)
{
  "playwright": {
    "command": "npx",
    "args": ["playwright-mcp"]
  }
}
```

3. Install Playwright:
```bash
npm install -g playwright-mcp
npx playwright install
```

### GitHub MCP not responding

**Symptoms:**
- @github-manager can't create issues/PRs
- "GitHub API rate limit" errors

**Solutions:**

1. Check authentication:
```bash
gh auth status
```

2. Re-authenticate:
```bash
gh auth login
```

3. Check rate limit:
```bash
gh api rate_limit --jq '.rate.remaining'
```

---

## Agent Issues

### @researcher timeout

**Symptoms:**
- Research takes too long
- Partial results only

**Solutions:**

This is by design. @researcher has a 30-second hard timeout.

1. For complex research, break into smaller queries
2. Use the partial results and request follow-up research
3. Check if specific URLs are slow to fetch

### @architect not providing enough detail

**Symptoms:**
- Architecture report too brief
- Missing trade-off analysis

**Solutions:**

1. Provide more context in your request:
```
New Feature: Add user authentication
- Expected users: 10,000+
- Security requirements: OAuth2, MFA
- Target platforms: Web, Mobile
```

2. Ask for specific decisions:
```
@architect: Also evaluate caching strategy and session management
```

### @api-guardian missing consumers

**Symptoms:**
- Some consumers not found
- Breaking changes not detected

**Solutions:**

1. Ensure grep patterns are correct for your codebase
2. Check for unusual import patterns:
```javascript
// These might be missed
const { type } = await import('./types')
require('./types')
```

3. Add custom search patterns in request

### @builder not running tests

**Symptoms:**
- Tests skipped
- "No tests found" message

**Solutions:**

1. Verify test setup:
```bash
npm test
```

2. Check test configuration in package.json
3. Ensure test files follow naming conventions (`*.test.ts`, `*.spec.ts`)

---

## Workflow Issues

### Wrong workflow selected

**Symptoms:**
- Bug fix using full feature workflow
- API change not triggering @api-guardian

**Solutions:**

1. Be explicit in your command:
```
Bug Fix: [description]
API Change: [description]
```

2. For API changes, mention the path:
```
API Change: Update User type in shared/types/user.ts
```

### Agents not called in order

**Symptoms:**
- @builder called before @architect
- Quality gates skipped

**Solutions:**

This indicates orchestrator confusion. Be explicit:

```
I want the full feature workflow:
1. First @architect for design
2. Then @builder for implementation
3. Then both quality gates
4. Finally @scribe for documentation
```

### Workflow stuck in loop

**Symptoms:**
- @builder → @validator → @builder repeating
- Never reaching @scribe

**Solutions:**

1. Check @validator output for persistent issues
2. Ask @validator to list ALL remaining issues
3. Consider marking non-critical issues as "defer to next version"

---

## Quality Gate Issues

### @validator always failing

**Symptoms:**
- TypeScript errors persist
- Tests keep failing

**Solutions:**

1. Run locally first:
```bash
npm run typecheck
npm test
```

2. Check if @builder received correct specs from @architect
3. Review @api-guardian consumer list for missed updates

### @tester screenshots not generated

**Symptoms:**
- No files in `.playwright-mcp/`
- Screenshot section empty in report

**Solutions:**

1. Verify Playwright MCP is working:
```javascript
await mcp__playwright__browser_take_screenshot({
  filename: "test.png"
});
```

2. Check directory permissions:
```bash
ls -la .playwright-mcp/
```

3. Ensure dev server is running:
```bash
npm run dev
```

### Parallel gates not working

**Symptoms:**
- @validator and @tester running sequentially
- Taking longer than expected

**Solutions:**

Parallel execution requires proper orchestrator coordination. Check:

1. Both agents are called simultaneously via Task tool
2. Results are collected at sync point
3. Decision matrix is applied correctly

---

## General Tips

### Reset workflow state

If things get confused:

```
Status
```

Then start fresh with explicit command.

### Check MCP availability

Before starting work:

```bash
claude mcp list
```

Expected:
- `playwright` ✓
- `github` ✓
- `lighthouse` (optional)
- `a11y` (optional)

### Force specific agent

If orchestrator isn't calling the right agent:

```
Call @researcher to research [topic]
Call @architect to design [feature]
```

### Skip to documentation

For documentation-only changes:

```
Documentation only: Update README installation section
```

This goes directly to @scribe without quality gates.

---

## Getting Help

1. Check [SKILL.md](../SKILL.md) for complete reference
2. Review [WORKFLOWS.md](./WORKFLOWS.md) for workflow details
3. See [AGENTS.md](./AGENTS.md) for agent specifications
4. Open an issue on GitHub for bugs


path: docs/MIGRATION.md
content: # Migration Guide: CLAUDE.md → CC_GodMode Skill

How to migrate from using CC_GodMode via CLAUDE.md to the OpenClaw Skill.

## Overview

| Aspect | CLAUDE.md (Claude Code) | OpenClaw Skill |
|--------|------------------------|----------------|
| Installation | Copy to project root | `clawdhub install cc-godmode` |
| Updates | Manual copy | `clawdhub update cc-godmode` |
| Scope | Per-project | System-wide |
| Discovery | Must know about it | ClawHub marketplace |
| Agent files | `~/.claude/agents/` | Same (unchanged) |

## Migration Steps

### Step 1: Install the Skill

```bash
clawdhub install cc-godmode
```

### Step 2: Verify Installation

```bash
clawdhub list | grep cc-godmode
```

You should see:
```
cc-godmode  5.11.1  Self-orchestrating multi-agent development workflows
```

### Step 3: Agent Files (No Change Needed!)

Your agent files in `~/.claude/agents/` continue to work:
- `researcher.md`
- `architect.md`
- `api-guardian.md`
- `builder.md`
- `validator.md`
- `tester.md`
- `scribe.md`
- `github-manager.md`

The skill references the same agents you already have.

### Step 4: Remove Project CLAUDE.md (Optional)

If you only used CLAUDE.md for CC_GodMode orchestration:

```bash
# In your project directory
rm CLAUDE.md
```

If your CLAUDE.md has project-specific instructions, keep it! The skill and project CLAUDE.md can coexist.

### Step 5: Test the Migration

Start an OpenClaw session and try:

```
New Feature: Test feature for migration verification
```

The orchestrator should:
1. Recognize the command
2. Select appropriate workflow
3. Call agents via Task tool

## What Changes

### Commands (Same!)

All commands work identically:

| Command | CLAUDE.md | Skill |
|---------|-----------|-------|
| `New Feature: X` | ✓ | ✓ |
| `Bug Fix: X` | ✓ | ✓ |
| `API Change: X` | ✓ | ✓ |
| `Research: X` | ✓ | ✓ |
| `Process Issue #X` | ✓ | ✓ |
| `Prepare Release` | ✓ | ✓ |

### Agent Calls (Same!)

Agents are still called via Task tool with `subagent_type`:

```
subagent_type: "researcher"
subagent_type: "architect"
subagent_type: "builder"
...
```

### Report Structure (Same!)

Reports still go to:
```
reports/
└── v[VERSION]/
    ├── 00-researcher-report.md
    ├── 01-architect-report.md
    ...
```

## Coexistence Mode

**CLAUDE.md and the Skill can coexist!**

Use this when:
- Your project has project-specific CLAUDE.md instructions
- You want to override certain skill behaviors
- You're testing before full migration

### Priority Order

1. Project `CLAUDE.md` (highest)
2. OpenClaw Skill `SKILL.md`
3. Agent files in `~/.claude/agents/`

### Example Coexistence

**Project CLAUDE.md:**
```markdown
# Project-Specific Instructions

## This Project Uses
- React 18 with TypeScript
- Tailwind CSS
- Prisma ORM

## Special Rules
- All components must be in `src/components/`
- Use Zustand for state management
- No Redux allowed

[CC_GodMode orchestration comes from the skill]
```

**The skill provides:** Orchestration, workflows, agent coordination
**Project CLAUDE.md provides:** Project-specific rules and context

## Rollback

If you need to go back to CLAUDE.md:

### Step 1: Uninstall Skill

```bash
clawdhub uninstall cc-godmode
```

### Step 2: Restore CLAUDE.md

Copy from CC_GodMode repository:
```bash
cp ~/Projects/ClawdBot-GodMode/CLAUDE.md ./CLAUDE.md
```

## Version Mapping

| CC_GodMode | Skill | Status |
|------------|-------|--------|
| v5.11.1 | 5.11.1 | Current |
| v5.10.x | - | Not available as skill |
| v5.9.x | - | Not available as skill |

Skills start from v5.11.1. For older versions, use CLAUDE.md directly.

## FAQ

### Q: Will my existing projects break?

No! The skill is additive. Your existing CLAUDE.md files continue to work.

### Q: Can I use different skill versions for different projects?

Currently, skills are system-wide. For project-specific versions, use CLAUDE.md.

### Q: What about custom agents?

Custom agents in `~/.claude/agents/` continue to work. The skill only provides orchestration.

### Q: Do I need to update agent files?

No. Agent files are separate from the skill. Update them independently when CC_GodMode releases new agent versions.

### Q: How do I get skill updates?

```bash
clawdhub update cc-godmode
```

Or for specific version:
```bash
clawdhub install cc-godmode@5.12.0
```

## Getting Help

- [Troubleshooting Guide](./TROUBLESHOOTING.md)
- [Complete Skill Documentation](../SKILL.md)
- [CC_GodMode Repository](https://github.com/clawdbot/ClawdBot-GodMode)


path: docs/AGENTS.md
content: # CC_GodMode Agent Specifications

Complete reference for all 8 specialized agents.

## Agent Overview

| Agent | Model | Cost | Primary Role |
|-------|-------|------|--------------|
| @researcher | haiku | Low | Web research, tech evaluation |
| @architect | opus | High | System design, architecture |
| @api-guardian | sonnet | Medium | API lifecycle, breaking changes |
| @builder | sonnet | Medium | Code implementation |
| @validator | sonnet | Medium | Code quality, TypeScript, tests |
| @tester | sonnet | Medium | UX quality, E2E, a11y |
| @scribe | sonnet | Medium | Documentation, versioning |
| @github-manager | haiku | Low | GitHub operations |

---

## @researcher - Knowledge Discovery Specialist

### Configuration
```yaml
name: researcher
model: haiku
tools: WebSearch, WebFetch, Read, Glob, memory
```

### Responsibilities
- Technology evaluation and comparison
- Best practices research (current year)
- Security advisory checks (CVE databases)
- Documentation discovery
- Competitive analysis

### Timeout Handling
- **Hard limit:** 30 seconds per task
- On timeout: Stop → Report partial results → Indicate incomplete areas

### Memory Usage
- Store: Key decisions, no-go technologies, verified sources
- Query: Before new research, check existing findings

### Output Report
Saved to: `reports/v[VERSION]/00-researcher-report.md`

---

## @architect - System Architect

### Configuration
```yaml
name: architect
model: opus
tools: Read, Grep, Glob, WebFetch
```

### Responsibilities
- High-level architecture design
- Module structure planning
- Technology stack decisions
- Trade-off documentation (Options A vs B vs C)
- Handoff specifications

### Design Principles
- Single Responsibility Principle
- Composition over Inheritance
- Props Drilling Max 2 Levels
- Server State Separation

### Output Report
Saved to: `reports/v[VERSION]/01-architect-report.md`

### Handoff Format
```markdown
## Decision: [Title]

### Context
[Why this decision is necessary]

### Options Analyzed
1. Option A: [Pros/Cons]
2. Option B: [Pros/Cons]

### Chosen Solution
[Rationale]

### Affected Modules
- [ ] `src/module/...`

### Next Steps
- [ ] @api-guardian (if API change)
- [ ] @builder for implementation
```

---

## @api-guardian - API Lifecycle Expert

### Configuration
```yaml
name: api-guardian
model: sonnet
tools: Read, Grep, Glob, Bash
```

### Responsibilities
- Change type identification (Additive/Modification/Removal)
- Consumer discovery (grep all imports/usages)
- Breaking change classification
- Impact report creation
- Migration checklist

### Trigger Paths
Automatically activated for changes in:
- `src/api/**`
- `backend/routes/**`
- `shared/types/**`
- `types/`
- `*.d.ts`
- `openapi.yaml`

### Output Report
Saved to: `reports/v[VERSION]/02-api-guardian-report.md`

### Consumer Discovery Commands
```bash
# Find imports of changed type
grep -rn "import.*TypeName" src/ --include="*.ts*"

# Find endpoint usages
grep -rn "/api/v1/endpoint" src/ --include="*.ts*"

# Find destructuring usages
grep -rn "{ fieldName" src/ --include="*.ts*"
```

---

## @builder - Full-Stack Developer

### Configuration
```yaml
name: builder
model: sonnet
tools: Read, Write, Edit, Bash, Glob, Grep
```

### Responsibilities
- Process specifications from @architect/@api-guardian
- Implement code in correct order
- Write tests
- Run quality checks

### Implementation Order
1. TypeScript Types (`shared/types/`)
2. Backend API (if relevant)
3. Frontend Services/Hooks
4. UI Components
5. Tests

### Code Standards
- Functional Components with Hooks
- Named Exports preferred
- Barrel Files (`index.ts`)
- All Promises with try/catch
- No `any` Types

### Output Report
Saved to: `reports/v[VERSION]/03-builder-report.md`

---

## @validator - Code Quality Engineer

### Configuration
```yaml
name: validator
model: sonnet
tools: Read, Grep, Glob, Bash
```

### Responsibilities
- TypeScript compilation verification
- Test execution and coverage
- Consumer update verification
- Security spot-checks
- Performance checks

### Verification Checklist
- [ ] `tsc --noEmit` passes
- [ ] All tests pass
- [ ] Coverage adequate
- [ ] All consumers from @api-guardian list updated
- [ ] No security issues (hardcoded secrets, etc.)
- [ ] No performance anti-patterns

### Output Report
Saved to: `reports/v[VERSION]/04-validator-report.md`

---

## @tester - UX Quality Engineer

### Configuration
```yaml
name: tester
model: sonnet
tools: Read, Bash, Glob, playwright, lighthouse, a11y
```

### Responsibilities
- E2E testing of critical user journeys
- Visual regression testing
- Accessibility audits (WCAG 2.1 AA)
- Performance audits (Core Web Vitals)
- Console error capture

### Mandatory Requirements

**Screenshots (NON-NEGOTIABLE):**
- Every page tested
- 3 viewports: mobile (375px), tablet (768px), desktop (1920px)
- Format: `[page]-[viewport].png`
- Directory: `.playwright-mcp/`

**Performance Thresholds:**
| Metric | Good | Acceptable | Fail |
|--------|------|------------|------|
| LCP | ≤2.5s | ≤4s | >4s |
| INP | ≤200ms | ≤500ms | >500ms |
| CLS | ≤0.1 | ≤0.25 | >0.25 |
| FCP | ≤1.8s | ≤3s | >3s |

### Fail-Safe Reporting
If Playwright crashes:
1. Attempt graceful degradation
2. Report partial results
3. Provide structured error output

### Output Report
Saved to: `reports/v[VERSION]/05-tester-report.md`

---

## @scribe - Technical Writer

### Configuration
```yaml
name: scribe
model: sonnet
tools: Read, Write, Edit, Glob, Grep
```

### Responsibilities
- VERSION file management
- CHANGELOG updates
- API_CONSUMERS.md maintenance
- README updates (user-facing changes)
- JSDoc for complex functions

### Mandatory Pre-Push
1. Update VERSION (semantic versioning)
2. Update CHANGELOG (Keep a Changelog format)
3. Verify version is unique
4. Update README if needed

### Changelog Format
```markdown
## [X.X.X] - YYYY-MM-DD

### Added
- New features

### Changed
- Changes

### Fixed
- Bug fixes

### Breaking Changes
- ⚠️ Breaking change
```

### Output Report
Saved to: `reports/v[VERSION]/06-scribe-report.md`

---

## @github-manager - GitHub Project Manager

### Configuration
```yaml
name: github-manager
model: haiku
tools: Read, Grep, Glob, Bash, github
```

### Responsibilities
- Issue lifecycle management
- Pull request workflow
- Release management
- Repository synchronization
- CI/CD monitoring

### Common Commands
```bash
# Issues
gh issue create --title "Bug: [desc]" --label "bug"
gh issue close [number] --comment "Fixed in #[pr]"

# PRs
gh pr create --title "[type]: [desc]"
gh pr merge [number] --squash --delete-branch

# Releases
gh release create "v$VERSION" --notes-file CHANGELOG.md

# CI/CD
gh run list --limit 10
gh run view [run-id] --log-failed
```

### Commit Message Format
```
<type>(<scope>): <description>

Types: feat, fix, docs, style, refactor, test, chore
```

### Output Report
Saved to: `reports/v[VERSION]/07-github-manager-report.md`


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: suspicious | SkillSpector: suspicious (MEDIUM)