القائمة
CC_GodMode Full-Gates workflow definitions — used for high-risk work and when Smart Routing escalates. Default routing is Smart Routing (skills/cost-efficiency/).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Ultracode / Max-Parallel mode — dynamic workflows fan work out across tens–hundreds of adversarially-verified parallel subagents for large, decomposable jobs (codebase-wide audits, big migrations, cross-checked research). Opt-in; higher token spend.
Smart Routing — the DEFAULT CC_GodMode routing policy. Risk-based, minimal-agent paths that preserve required safety gates for the changed scope.
Release sprint workflow: version-at-release via tooling, CHANGELOG [Unreleased] flow, release invariant checks, tags, GitHub Releases, RCs. Authoritative law: docs/orchestrator/VERSIONING.md
Plan-first orchestration (ADR-004): comprehensive PLAN.md, sprint files with write-scope ownership, preflight checks, serialized integration, and the release sprint. Use for any non-trivial or multi-part request BEFORE dispatching agents.
Expanded department-based orchestration for large cross-domain CC_GodMode work. Freezes ownership, handoffs, and write scopes before implementation.
Bootstrap repo-local governance before CC_GodMode workflows run in an empty, newly initialized, or undocumented workspace. Use proactively when a project has no CLAUDE.md, no README, or no clear structure yet.
| name | workflows |
| description | CC_GodMode Full-Gates workflow definitions — used for high-risk work and when Smart Routing escalates. Default routing is Smart Routing (skills/cost-efficiency/). |
These are the Full-Gates workflows, used for high-risk work and when Smart Routing escalates. Default routing is Smart Routing (skills/cost-efficiency/).
Architecture gate split: For small/medium tasks (no new modules, no breaking changes) the Orchestrator writes a 3–5 bullet inline architecture brief into reports/vX.Y.Z/sprint-NN/01-architect-report.md without invoking @architect. For new modules, breaking changes, cross-domain designs, or uncertain scope, invoke @architect (Opus) via Task tool.
Use docs/orchestrator/MODES.md and the relevant mode skill when the request
is a prototype, cross-domain department run, or explicit Agent Teams run.
| Command Pattern | Workflow | Agents |
|---|---|---|
| "New Feature: [X]" | Feature | (@researcher) → @architect → @builder → @validator ∥ @tester → @scribe |
| "Bug Fix: [X]" | Bug Fix | @builder → @validator ∥ @tester |
| "API Change: [X]" | API Change | (@researcher) → @architect → @api-guardian → @builder → @validator ∥ @tester → @scribe |
| "Refactor: [X]" | Refactor | @architect → @builder → @validator ∥ @tester |
| "Research: [X]" | Research | @researcher → report |
| "Process Issue #X" | Issue | @github-manager loads → analyze → select workflow → PR |
| "Prepare Release" | Release | @scribe → @github-manager |
(@researcher) = optional, use when new tech/libraries need evaluation
User Request → "New Feature: [X]"
↓
1. @researcher (OPTIONAL — if new tech involved)
→ Report: technology evaluation, best practices, risks
↓
2. @architect
→ Architecture Decision Record (ADR)
→ Module structure, interfaces, tech choices
↓
3. @builder
→ Implementation following @architect specs
→ All code changes, tests, types
↓
4. @validator ∥ @tester (PARALLEL — both MUST pass)
→ See quality-gates skill for decision matrix
↓
5. @scribe
→ VERSION bump, CHANGELOG, documentation
User Request → "Bug Fix: [X]"
↓
1. @builder (fix implementation)
↓
2. @validator ∥ @tester (PARALLEL)
↓
3. INTEGRATE — @scribe adds the `[Unreleased]` CHANGELOG entry (Core Rule 11: every sprint, even one-line fixes)
MANDATORY @api-guardian — never skip for API changes.
User Request → "API Change: [X]"
↓
1. @researcher (OPTIONAL)
↓
2. @architect (API design, contract definition)
↓
3. @api-guardian (MANDATORY)
→ Consumer impact analysis
→ Breaking change detection
→ Migration strategy
↓
4. @builder (implementation + consumer updates)
↓
5. @validator ∥ @tester (PARALLEL)
↓
6. @scribe (document breaking changes)
These file patterns always trigger @api-guardian:
src/api/**backend/routes/**shared/types/***.d.tsopenapi.yaml / schema.graphql**/interfaces/**User Request → "Research: [X]"
↓
1. @researcher
→ Web research, documentation lookup
→ Technology evaluation matrix
→ Report with sources and recommendations
↓
2. Report saved to reports/vX.Y.Z/sprint-NN/00-researcher-report.md
User Request → "Process Issue #X"
↓
1. @github-manager loads issue from GitHub
↓
2. Orchestrator analyzes:
→ Type: Bug / Feature / Enhancement
→ Complexity: Low / Medium / High
→ Areas: API / UI / Backend / Infrastructure
↓
3. Select appropriate workflow (Feature/Bug/API)
↓
4. Execute workflow
↓
5. @github-manager creates PR with "Fixes #X"
User Request → "Prepare Release"
↓
1. @scribe
→ Verify VERSION is incremented
→ Verify CHANGELOG is updated
→ Verify all reports are in place
↓
2. @github-manager
→ Create release PR
→ Tag version
→ Create GitHub Release
All agents are called via the Task tool with subagent_type:
Task tool → subagent_type: "architect" → @architect
Task tool → subagent_type: "api-guardian" → @api-guardian
Task tool → subagent_type: "builder" → @builder
Task tool → subagent_type: "validator" → @validator
Task tool → subagent_type: "tester" → @tester
Task tool → subagent_type: "scribe" → @scribe
Task tool → subagent_type: "github-manager" → @github-manager
Task tool → subagent_type: "researcher" → @researcher