🚀 OMX + Superpowers + Gstack Complete Guide
Version: v1.0 | Updated: 2026-04-30
Complete guide to the three-layer architecture of Claude Code, making your AI assistant more powerful!
📐 1. Three-Layer Architecture Overview
┌──────────────────────────────────────────────────────────────┐
│ 🎯 OMX Orchestration Layer │
│ Unified Entry · Task Distribution · State Persistence │
└──────────────────────────────────────────────────────────────┘
↓
┌─────────────────┬─────────────────┬─────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│🧠 Thinking Layer│ │⚡ Execution Layer│ │🌐 Interaction Layer│ │🛡️ Guard Layer│
│Super- │ │OMX Team │ │Gstack │ │Guard │
│powers │ │ │ │ │ │ │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
🎯 Division of Responsibilities Across Layers
| Layer | 🎨 Responsibility | ⚡ Core Capability | 🔥 Representative Command |
|---|---|---|---|
| OMX Orchestration Layer | Unified Entry · Task Distribution · State Persistence | Multi-Agent Parallel Scheduling | omx team / omx resume |
| Superpowers Thinking Layer | Thinking Patterns · Design Verification | Structured Thinking Process | brainstorm / plan / TDD / debug |
| Gstack Interaction Layer | External World · Browser Operations | Automated QA & Deployment | /browse / /qa / /ship / /deploy |
💡 Division Principle: Superpowers thinks → OMX orchestrates → Gstack executes
🎯 2. Task Routing Decision Flow
User Task Input
↓
┌────────────────┐
│ 🤔 Assess Task Size │
└────────────────┘
↓
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│🟢 Lightweight │ │🟡 Medium │ │🔴 Large │
│ Task │ │ Task │ │ Task │
└────────┘ └────────┘ └────────┘
│ │ │
│ │ │
▼ ▼ ▼
Implement Directly Brainstorm + Plan Full Closed Loop
│ │ │
▼ ▼ ▼
/browse /qa Verify omx team
📊 Task Type Quick Reference
| Type | Characteristics | Process | Trigger |
|---|---|---|---|
| 🟢 Lightweight Task | Single file, small scope change | Direct Implementation → Verify | /browse |
| 🟡 Medium Task | Multiple files, clear boundaries | brainstorm → plan → implement → QA | /brainstorming |
| 🔴 Large Task | Cross-module, architecture changes | Full Closed Loop | omx team |
🔄 3. Full Closed Loop Process
┌──────────────────────────────────────────────────────────────┐
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │🎨Design│→ │📋Review│→ │🔒Isolate│→ │⚡Parallel│→ │✅Verify│→ │🚀Deploy│ │
│ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │
│ │
│ brainstorm plan-ceo worktrees omx team qa ship │
│ writing- plan-eng TDD verify deploy│
│ plans plan-design canary│
│ │
└──────────────────────────────────────────────────────────────┘
🎬 Detailed Phase Descriptions
| Phase | 🎯 Objective | 🔧 Skills | 📝 Description |
|---|---|---|---|
| 1️⃣ Design | Clarify requirements | brainstorm / writing-plans |
Refine requirements through Q&A, break down tasks |
| 2️⃣ Plan Review | Multi-perspective review | plan-ceo / plan-eng / plan-design |
CEO re-evaluates, Eng locks details, Design reviews experience |
| 3️⃣ Isolate | Avoid conflicts | worktrees / TDD |
Independent branches + test-driven development |
| 4️⃣ Parallel Execution | Increase efficiency | omx team |
Multi-agent parallel execution, independent worktrees |
| 5️⃣ Verification | Quality gate | qa / verification |
Automated testing + manual verification |
| 6️⃣ Deployment | Safe rollout | review / ship / deploy / canary |
Code review → Merge → Deploy → Monitor |
🤖 4. OMX Team Mode Details
4.1 🎭 Team Workflow
omx team N:agent "task"
┌─────────────────────────────────────────────┐
│ 🎯 Leader (tmux main pane) │
│ Task Distribution · Result Integration · Final Verification │
└─────────────────────────────────────────────┘
↓ Distribute tasks
┌───────────┬───────────┬───────────┐
│ │ │ │
▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│Worker 1│ │Worker 2│ │Worker 3│ │Worker N│
│executor│ │debugger│ │designer│ │ ... │
│indep tree│ │indep tree│ │indep tree│ │indep tree│
└────────┘ └────────┘ └────────┘ └────────┘
↓ ↓ ↓ ↓
└───────────┴───────────┴───────────┘
↓ Each finishes
┌─────────────────────────────────────────────┐
│ ✅ Leader integrates + verifies │
│ omx team await / omx team shutdown │
└─────────────────────────────────────────────┘
4.2 🧠 Agent Selection Guide
| Agent | 🎯 Use Case | 📊 Complexity | 💡 Reasoning Suggestion |
|---|---|---|---|
explore |
Code search, structure mapping | 🟢 Low | low / spark |
executor |
Feature implementation, refactoring | 🟡 Medium | medium |
debugger |
Bug investigation, root cause analysis | 🟡 Medium | medium → high |
architect |
Architecture design, trade-off decisions | 🔴 High | high / xhigh |
test-engineer |
Test writing, verification | 🟡 Medium | medium |
designer |
Frontend UI/UX implementation | 🟡 Medium | medium |
4.3 ⌨️ Team Command Quick Reference
# 🚀 Start a team
omx team 3:executor "task" # Start 3 executor workers
# 📊 Status management
omx team status my-team # View team running status
omx team await my-team # Wait for all workers to complete
# 🔄 Resume mechanism
omx team resume my-team # Resume an interrupted team
# 🛑 Shut down team
omx team shutdown my-team # Shut down team
🧠 5. Superpowers Core Skills
5.1 🎯 Core Process Skills
| Skill | 🎯 Purpose | ⏰ Trigger Timing | 🔥 Use Case |
|---|---|---|---|
/brainstorming |
Design refinement, clarify requirements and boundaries | 🟢 At task start | Before any creative work |
/writing-plans |
Write implementation plan, break down small tasks | 🔵 After design is complete | Multi-step tasks |
/test-driven-development |
RED-GREEN-REFACTOR cycle | 🟡 During implementation phase | Feature development, refactoring |
/systematic-debugging |
4-stage root cause analysis | 🔴 Encountering bugs | Complex problem troubleshooting |
/verification-before-completion |
Verify before completion | 🟠 Before claiming completion | Quality gate |
/requesting-code-review |
Request code review | 🟣 After implementation is done | Pre-merge review |
5.2 👁️ Three Perspectives of Plan Review
┌─────────────────┬─────────────────┬─────────────────┐
│ 👔 CEO Perspective │ 🔧 Engineering Perspective │ 🎨 Design Perspective │
│ │ │ │
│ /plan-ceo- │ /plan-eng- │ /plan-design- │
│ review │ review │ review │
│ │ │ │
│ Re-examine problem │ Lock execution details │ UX review │
│ Find better solutions │ Check feasibility │ Interaction rationality │
└─────────────────┴─────────────────┴─────────────────┘
🌐 6. Gstack Execution Layer Details
6.1 🌍 Browser as the Only Entry Point
⚠️ Only entry point:
/browseDo not use other browser MCP tools like
mcp__claude-in-chrome__*ormcp__computer-use__*
6.2 ✅ QA Verification Process
| Command | 🎯 Description | 🔥 Use Case |
|---|---|---|
/qa |
Systematic QA testing and auto-fix bugs | Feature verification, regression testing |
/qa-only |
Report issues only, no auto-fix | Problem investigation, auditing |
/design-review |
Visual consistency, layout review | UI/UX verification |
6.3 🚀 Deployment Process
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ /ship │ ──→ │ /land-and- │ ──→ │ /canary │
│ │ │ deploy │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
↓ ↓ ↓
Detect changes Merge PR Monitor after deployment
Merge base Wait CI Observe production
Run tests Trigger deployment Alert on anomalies
6.4 🛡️ Safety Guards
🚨 Dangerous commands must pass guards first
The following commands must use
/carefulor/guardor/freezebefore execution:
rm -rf/DROP TABLE/git push --forcegit reset --hard/kubectl delete- Any destructive operation
💾 7. Ensuring Uninterrupted Operation
7.1 🗄️ State Persistence
| Component | 📁 Path | 🎯 Function |
|---|---|---|
| OMX State | .omx/state/ |
Task state tracking |
| OMX Memory | omx_memory MCP |
Project memory storage |
| OMX Wiki | omx_wiki MCP |
Knowledge base persistence |
| Claude Memory | .claude/memory/ |
User preference recording |
7.2 🔄 Resume Mechanism
# Resume last session
omx resume
# Resume interrupted team
omx team resume my-team
# View historical sessions
omx session
7.3 📢 Notification Configuration
| Platform | Command | Purpose |
|---|---|---|
| 💬 Discord | omx --discord |
Team notifications |
| 📱 Telegram | omx --telegram |
Instant messaging |
| 🔔 Slack | omx --slack |
Workflow integration |
✅ 8. Configuration Checklist
| Component | 📦 Version | 📝 Description | ✅ Status |
|---|---|---|---|
| Codex CLI | v0.125.0 | Core dependency | ✅ Installed |
| OMX | v0.15.0 | 42 skills, 30 agents | ✅ Normal |
| Superpowers | v5.0.7 | 16 skills | ✅ Normal |
| Gstack | Full version | browser/QA/deploy | ✅ Normal |
| MCP Servers | 7 servers | OMX + Figma + code-review-graph | ✅ Running |
❓ 9. Frequently Asked Questions
🎯 Q: Difference between Team mode and regular Subagent?A:
- Team mode: Persistent parallel execution (tmux split screen, independent worktree), suitable for large tasks
- Regular Subagent: Small-scale parallel within a session, suitable for lightweight tasks
A:
- OMX: Responsible for orchestration (how to distribute tasks)
- Superpowers: Responsible for thinking (how to do things correctly)
- For large tasks, use both together
A:
omx resume # Resume last session
omx team resume my-team # Resume team
🔀 Q: How to avoid file conflicts?
A: OMX Team uses independent worktrees by default, each worker has an independent branch, automatically avoiding conflicts.
🎯 Quick Start
# 1️⃣ Start a simple task
omx task "Implement user login functionality"
# 2️⃣ Start parallel team development
omx team 3:executor "Refactor API module"
# 3️⃣ Full process: Design → Implement → Verify → Deploy
/brainstorming # Design
/writing-plans # Plan
/plan-ceo-review # Review
omx team 2:executor "Implement" # Parallel
/qa # Verify
/ship # Deploy
💡 Tip: This document is continuously updated. For questions, please refer to the latest version or contact the maintainer.
暂无评论。