Skill Commands

Specialized capabilities: debate, review, security, TDD, factory, and more

Skill Commands

Skill commands provide specialized capabilities beyond the core Double Diamond workflow. Each skill focuses on a specific domain expertise.

---

/octo:debate - AI Debate Hub

Structured three-way debates between Claude, Gemini, and Codex.

Syntax

/octo:debate "<debate topic>"
/octo:debate should we use Redis or Memcached?
/octo:debate TypeScript vs JavaScript for this project

What It Does

Orchestrates a structured debate with:

• Three participants: Claude (moderator), Gemini, Codex
• Multiple rounds: Opening, rebuttals, synthesis
• Consensus building: Final recommendation with confidence score
• Adversarial mode: Red team vs blue team critique

Debate Structure

1. Round 1 - Opening Statements
   • Each AI presents their position
   • Initial arguments and evidence
2. Round 2 - Rebuttals
   • Respond to other perspectives
   • Address counterarguments
3. Round 3 - Synthesis
   • Claude moderates consensus
   • Final recommendation with reasoning

Interactive Questions

Before debate, you’ll be asked:

1. Debate style: Collaborative vs Adversarial
2. Depth: Quick (2 rounds) vs Deep (3+ rounds)
3. Decision urgency: High stakes vs exploratory

Examples

Technology Choice

/octo:debate "Should we use PostgreSQL or MongoDB?"
# Three-way analysis of trade-offs

/octo:debate "Microservices vs monolith for our scale?"
# Multi-perspective architectural analysis

/octo:debate "JWT vs session tokens for authentication?"
# Security-focused debate with trade-offs

/octo:debate --mode adversarial "Review this authentication logic"
# Red team vs blue team security critique

When to Use

Use debate for:

• Comparing technology options
• Architecture decisions with trade-offs
• Security approach evaluation
• Adversarial code review
• High-stakes technical choices

Output

🐙 AI DEBATE: Redis vs Memcached

🔴 Codex Perspective:
[Technical implementation focus...]

🟡 Gemini Perspective:
[Ecosystem and operational focus...]

🔵 Claude Synthesis:
[Balanced recommendation...]

Consensus: 85% confidence
Recommendation: Redis for persistent caching with rich data structures

Natural Language Triggers

Auto-activates when you say:

• “should”, “vs”, “or”, “compare”
• “versus”, “decide”, “which is better”
• “debate”, “argue for/against”

---

/octo:review - Code Review

Expert code review with comprehensive quality assessment.

Syntax

/octo:review "<code or path>"
/octo:review src/auth.ts
/octo:review "review this authentication module"

What Gets Reviewed

Code Quality

• Design patterns and architecture
• Code complexity (cyclomatic)
• Maintainability and readability
• Naming conventions
• Code duplication

Security

• OWASP Top 10 vulnerabilities
• Authentication/authorization flaws
• Input validation
• SQL injection and XSS risks
• Sensitive data exposure

Performance

• Algorithm efficiency
• Database query optimization
• Memory usage
• Caching opportunities
• Scalability issues

Best Practices

• Industry standards
• Framework conventions
• Error handling
• Logging and monitoring
• Test coverage

Interactive Questions

Before review, you’ll be asked:

1. Goal: Pre-commit / Security focus / Performance / Architecture
2. Priority concerns: Security / Performance / Maintainability / Testing
3. Audience: Just me / Team review / Production release / External audit

Review Types

Quick Review

Pre-commit checks - Fast validation before committing

/octo:quick-review

• Surface-level checks (5-10 sec)
• Critical issues only
• Best for small changes

Full Review

Comprehensive analysis - Deep dive with multiple AI perspectives

/octo:review src/api/

• Multi-AI validation
• Security + performance + quality
• Best for feature completion

Security Focus

Security-first audit - OWASP compliance and vulnerability detection

/octo:review --focus security src/auth/

• Vulnerability scanning
• Threat modeling
• Best for critical paths

Examples

Pre-Commit Check

/octo:review "quick review before I commit this"
# Fast validation of staged changes

/octo:review "review auth.ts for security vulnerabilities"
# Deep security-focused analysis

/octo:review src/api/endpoints/
# Comprehensive quality, security, and performance review

/octo:review "validate payment processing for production"
# All-aspects review for deployment

Output Format

🐙 Code Review Results

📊 Overall Score: 8.2/10

🔴 Critical Issues (2):
  - SQL injection vulnerability in query builder (line 45)
  - Unvalidated user input in API endpoint (line 78)

🟡 Warnings (5):
  - Missing error handling in async function (line 23)
  - Performance: N+1 query pattern (line 102)
  ...

🟢 Strengths:
  - Good separation of concerns
  - Comprehensive test coverage (87%)
  - Clear documentation

💡 Recommendations:
  1. Use parameterized queries for SQL (priority: HIGH)
  2. Add input validation middleware (priority: HIGH)
  3. Implement query caching (priority: MEDIUM)

---

/octo:security - Security Audit

OWASP compliance and vulnerability detection.

Syntax

/octo:security "<code or path>"
/octo:security src/auth/
/octo:security "audit the payment processing module"

What Gets Audited

OWASP Top 10

• Injection flaws
• Broken authentication
• Sensitive data exposure
• XML external entities
• Broken access control
• Security misconfiguration
• XSS vulnerabilities
• Insecure deserialization
• Known vulnerable components
• Insufficient logging

Authentication & Auth

• Password storage (hashing/salting)
• Session management
• Token security (JWT/OAuth)
• Authorization logic
• Multi-factor authentication

Input Validation

• SQL injection prevention
• XSS protection
• Command injection
• Path traversal
• LDAP/XML injection

Data Protection

• Encryption at rest/transit
• Cryptographic implementations
• Key management
• PII handling
• GDPR/HIPAA compliance

Interactive Questions

1. Threat model: Standard web app / High-value target / Compliance-driven / API-focused
2. Compliance requirements: None / OWASP / GDPR/HIPAA/PCI / SOC2/ISO27001
3. Risk tolerance: Strict zero-trust / Balanced / Pragmatic / Development-only

Examples

Authentication Audit

/octo:security "audit authentication module for OWASP compliance"
# Comprehensive auth security review

/octo:security src/api/ --compliance PCI
# API security with payment card compliance

/octo:security --mode adversarial src/
# Red team security testing

Output Format

🛡️ Security Audit Report

Threat Level: MEDIUM
Compliance: OWASP Top 10

🔴 CRITICAL (1):
  - SQL Injection vulnerability (CWE-89)
    Location: src/db/query.ts:45
    Fix: Use parameterized queries
    
🟠 HIGH (3):
  - Weak password hashing (bcrypt rounds < 10)
  - Missing CSRF protection
  - Sensitive data in logs
  
🟡 MEDIUM (7):
  ...

Recommendations:
  1. Implement prepared statements (IMMEDIATE)
  2. Increase bcrypt work factor to 12 (HIGH)
  3. Add CSRF tokens to forms (HIGH)

---

/octo:tdd - Test-Driven Development

Red-green-refactor discipline with multi-AI test generation.

Syntax

/octo:tdd "<feature to implement>"
/octo:tdd implement user registration
/octo:tdd "build JWT authentication with tests first"

TDD Workflow

What You Get

1. Test-First: Failing tests written before implementation
2. Minimal Code: Only enough code to pass tests
3. Refactor: Clean up with confidence (tests protect you)
4. Coverage: High test coverage by design
5. Regression Protection: Catch breaks early

Interactive Questions

1. Coverage goal: Critical paths / Standard ~80% / Comprehensive >90% / Mutation testing
2. Test style: Unit tests / Integration / E2E / Mix of all
3. Complexity: Simple CRUD / Moderate logic / Complex algorithms / Distributed systems

Examples

Simple Feature

/octo:tdd "implement user registration with validation"
# Test-first development with red-green-refactor

/octo:tdd "create RESTful user management API"
# Tests before implementation

/octo:tdd "build rate limiting with Redis"
# TDD for complex distributed feature

TDD Cycle Example

1. Red: Write Failing Test

   // test/auth.test.ts
   describe('User Registration', () => {
     it('should reject weak passwords', async () => {
       const result = await register({ password: '123' });
       expect(result.error).toBe('Password too weak');
     });
   });
   

   Test fails ❌ (no implementation yet)

2. Green: Write Minimal Code

   // src/auth.ts
   export function register({ password }) {
     if (password.length < 8) {
       return { error: 'Password too weak' };
     }
     return { success: true };
   }
   

   Test passes ✅

3. Refactor: Improve Quality

   // src/auth.ts
   const MIN_PASSWORD_LENGTH = 8;
   
   export function register({ password }: RegisterInput): RegisterResult {
     const validation = validatePassword(password);
     if (!validation.isValid) {
       return { error: validation.message };
     }
     return { success: true };
   }
   

   Tests still pass ✅, code is cleaner

4. Repeat

   Add next failing test, implement, refactor…

When to Use TDD

Use TDD for:

• Critical business logic
• Complex algorithms
• Features with clear requirements
• When you need high confidence
• Legacy code refactoring

Consider alternatives for:

• Prototypes and spikes
• UI/UX experimentation
• Unclear requirements (use /octo:discover first)

---

/octo:factory - Dark Factory Mode

Spec-in, software-out autonomous pipeline.

Syntax

/octo:factory --spec <path-to-spec>
/octo:factory --spec specs/auth-system.md

What It Does

7-phase autonomous pipeline:

1. 1. Parse Spec

   Validates NLSpec format and extracts:

   • Satisfaction target (0.80-0.99)
   • Complexity estimate
   • Behaviors and constraints
2. 2. Generate Scenarios

   Multi-provider scenario generation:

   • Codex: Technical scenarios
   • Gemini: User scenarios
   • Claude: Edge cases
3. 3. Split Holdout

   80/20 train/test split:

   • 80% used for implementation
   • 20% held back for blind validation
4. 4. Embrace Workflow

   Full 4-phase implementation:

   • Discover → Define → Develop → Deliver
   • Fully autonomous (no phase approval)
5. 5. Holdout Tests

   Blind evaluation:

   • Test implementation against withheld scenarios
   • Measure actual vs expected behavior
6. 6. Score Satisfaction

   Weighted scoring:

   • Behavior coverage: 40%
   • Constraint adherence: 20%
   • Holdout pass rate: 25%
   • Code quality: 15%
7. 7. Generate Report

   Verdict with evidence:

   • PASS (>= target)
   • WARN (>= target - 0.05)
   • FAIL (< target - 0.05)

Interactive Questions

1. Spec path: Where is the NLSpec file?
2. Satisfaction target: Use spec default or override? (0.80-0.99)
3. Cost confirmation: Proceed with ~$0.50-2.00 cost? (~20-30 agent calls)

Options

--spec · string · required

Path to NLSpec file defining the feature

--holdout-ratio · number · default: "0.25"

Percentage of scenarios for blind validation (0.20-0.30)

--max-retries · number · default: "2"

Number of retry attempts on FAIL verdict

--ci · boolean

Non-interactive mode for automation pipelines

Examples

Standard Factory Run

/octo:factory --spec specs/user-auth.md
# Full autonomous pipeline with default settings

/octo:factory --spec specs/api.md --ci
# Non-interactive mode for automated pipelines

/octo:factory --spec specs/payment.md --holdout-ratio 0.30
# Use 30% holdout for extra validation rigor

Output Structure

.octo/factory/<run-id>/
  ├── factory-report.md           # Human-readable report
  ├── factory-session.json        # Machine-readable summary
  ├── scenarios.json              # All generated scenarios
  ├── holdout.json               # Withheld scenarios
  ├── embrace-results/           # Implementation artifacts
  └── validation-results.json    # Holdout test results

When to Use Factory

Use factory for:

• Features with clear specifications
• Autonomous development pipelines
• CI/CD integration
• When you have a complete NLSpec
• Spec-driven development

Don’t use for:

• Simple bug fixes
• Exploratory coding
• Unclear requirements (use /octo:plan first)
• Tasks without specifications

Cost & Duration

• Cost: ~$0.50-2.00 per run (20-30 agent calls)
• Duration: 15-30 minutes depending on complexity
• Retries: Auto-retry on FAIL (up to max-retries)

---

/octo:prd - PRD Generation

AI-optimized Product Requirements Document with 100-point scoring.

Syntax

/octo:prd "<feature description>"
/octo:prd "user authentication system"
/octo:prd "build a notification center"

What You Get

Comprehensive PRD with:

1. Executive Summary - Vision and key value proposition
2. Problem Statement - Quantified by user segment
3. Goals & Metrics - SMART goals with P0/P1/P2 priorities
4. Non-Goals - Explicit scope boundaries
5. User Personas - 2-3 specific personas with needs
6. Functional Requirements - FR-001 format with acceptance criteria
7. Implementation Phases - Dependency-ordered rollout
8. Risks & Mitigations - Identified risks with mitigation plans

Interactive Questions

Phase 0 clarification (mandatory):

1. Target Users: Who will use this? (developers/end-users/admins/agencies)
2. Core Problem: What pain point does this solve? Metrics?
3. Success Criteria: How will you measure success? KPIs?
4. Constraints: Technical, budget, timeline, platform constraints?
5. Existing Context: Greenfield or integrating with existing systems?

Scoring Framework (100 points)

Category	Points	Criteria
AI-Specific Optimization	25	Structured for AI consumption, clear acceptance criteria
Traditional PRD Core	25	Problem statement, goals, requirements clarity
Implementation Clarity	30	Phasing, dependencies, technical feasibility
Completeness	20	All sections present, personas defined, risks identified

Examples

User Feature

/octo:prd "build user profile management system"
# Complete PRD with personas and requirements

/octo:prd "implement real-time notification service"
# PRD with technical architecture and phasing

/octo:prd "create admin dashboard for analytics"
# PRD with multiple user personas and use cases

Output Example

# PRD: User Authentication System

## Executive Summary
[Vision and value proposition...]

## Problem Statement
Current state: Users authenticate via third-party OAuth only...
Target state: Support multiple auth methods with SSO...
Metrics: 30% of users request alternative login methods...

## Goals & Metrics
| Priority | Goal | Metric | Target |
|----------|------|--------|--------|
| P0 | Support email/password | Adoption rate | 40% of users |
| P1 | Implement SSO | Enterprise signups | +25% |
| P2 | Add 2FA | Security incidents | -50% |

## Functional Requirements
FR-001: User Registration
  - User can create account with email + password
  - Acceptance: Email verification sent within 30s
  ...

[Self-Score: 87/100]

---

/octo:claw - OpenClaw Administration

Manage OpenClaw gateway instances across platforms.

Syntax

/octo:claw "<admin task>"
/octo:claw check health
/octo:claw update to latest
/octo:claw setup on docker

What It Manages

Gateway Lifecycle

• Start/stop/restart gateway
• Health checks and diagnostics
• Daemon installation
• Version updates and rollback

5 Platforms

• macOS: launchd service
• Ubuntu/Debian: systemd service
• Docker: compose orchestration
• OCI (ARM): ARM-optimized containers
• Proxmox: LXC containers

6 Channels

• WhatsApp
• Telegram
• Discord
• Slack
• Signal
• iMessage

Security

• Security audit and hardening
• Firewall configuration
• Tailscale VPN setup
• Credential management
• SSL/TLS configuration

Methodology

Every claw action follows:

1. DETECT - Identify platform (never assume OS)
2. DIAGNOSE - Non-destructive checks before changes
3. EXECUTE - Platform-specific commands
4. VERIFY - Confirm the change took effect

Examples

Health Check

/octo:claw "check if my gateway is healthy"
# Platform detection + diagnostics

/octo:claw "update openclaw to latest stable"
# Backup + upgrade + verify

/octo:claw "configure telegram channel"
# Bot token setup + webhook config

/octo:claw "harden my server"
# Firewall + fail2ban + SSH hardening

/octo:claw "setup tailscale for remote access"
# Tailscale install + auth + routing

Platform-Specific Commands

macOS

# Start/stop gateway (launchd)
launchctl load ~/Library/LaunchAgents/com.openclaw.gateway.plist
launchctl unload ~/Library/LaunchAgents/com.openclaw.gateway.plist

# Check logs
log show --predicate 'subsystem == "com.openclaw.gateway"' --last 1h

Ubuntu/Debian

# Start/stop gateway (systemd)
sudo systemctl start openclaw-gateway
sudo systemctl stop openclaw-gateway

# Check status
sudo systemctl status openclaw-gateway
sudo journalctl -u openclaw-gateway --since "1 hour ago"

Docker

# Start/stop gateway (compose)
docker-compose -f openclaw-gateway.yml up -d
docker-compose -f openclaw-gateway.yml down

# Check logs
docker-compose logs -f gateway

When to Use Claw

• Managing OpenClaw gateway instances
• Platform-specific administration tasks
• Channel configuration (WhatsApp, Telegram, etc.)
• Security hardening and VPN setup
• Troubleshooting gateway issues
• Multi-platform deployments

/octo:claw is specifically for OpenClaw gateway administration. For general system commands, use /octo:setup or /octo:doctor.

---

Planning & Orchestration Skills

/octo:plan - Strategic Planning

Create execution plans without running them.

See Workflow Commands - Plan for details.

/octo:parallel - Team of Teams

Decompose work into parallel packages.

/octo:parallel "build e-commerce platform"
# Breaks into: auth, catalog, cart, payment, shipping packages

/octo:multi - Force Multi-Provider

Manual override for parallel execution.

/octo:multi "What is OAuth?"
# Forces Codex + Gemini + Claude even for simple question

/octo:spec - NLSpec Authoring

Write structured natural language specifications.

/octo:spec "authentication system"
# Generates NLSpec with behaviors, actors, constraints

---

Skill Comparison

Skill	Multi-AI	Duration	Cost	Use Case
/octo:debate	Yes	5-10 min	~$0.08-0.20	Compare options, adversarial review
/octo:review	Yes	3-8 min	~$0.05-0.15	Code quality assessment
/octo:security	Yes	3-8 min	~$0.05-0.15	OWASP audit, vulnerability scan
/octo:tdd	Yes	10-20 min	~$0.15-0.40	Test-first implementation
/octo:factory	Yes	15-30 min	~$0.50-2.00	Spec-to-software pipeline
/octo:prd	Yes	5-10 min	~$0.08-0.20	Product requirements
/octo:claw	No	2-5 min	Free	OpenClaw administration

---

Next Steps

Try a Debate

Compare options with multi-AI perspectives

Code Review

Get comprehensive quality assessment

Workflow Commands

Learn the core Double Diamond phases