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

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

Interactive Questions

Before debate, you’ll be asked:

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

Examples

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

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:

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

Review Types

Quick Review
Full Review
Security Focus

Pre-commit checks - Fast validation before committing

/octo:quick-review

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

Comprehensive analysis - Deep dive with multiple AI perspectives

/octo:review src/api/

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

Security-first audit - OWASP compliance and vulnerability detection

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

Vulnerability scanning
Threat modeling
Best for critical paths

Examples

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

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

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

Examples

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

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

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

Interactive Questions

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

Examples

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

TDD Cycle Example

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)

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 ✅

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

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. Parse Spec

Validates NLSpec format and extracts:

Satisfaction target (0.80-0.99)
Complexity estimate
Behaviors and constraints

2. Generate Scenarios

Multi-provider scenario generation:

Codex: Technical scenarios
Gemini: User scenarios
Claude: Edge cases

3. Split Holdout

80/20 train/test split:

80% used for implementation
20% held back for blind validation

4. Embrace Workflow

Full 4-phase implementation:

Discover → Define → Develop → Deliver
Fully autonomous (no phase approval)

5. Holdout Tests

Blind evaluation:

Test implementation against withheld scenarios
Measure actual vs expected behavior

6. Score Satisfaction

Weighted scoring:

Behavior coverage: 40%
Constraint adherence: 20%
Holdout pass rate: 25%
Code quality: 15%

7. Generate Report

Verdict with evidence:

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

Interactive Questions

Spec path: Where is the NLSpec file?
Satisfaction target: Use spec default or override? (0.80-0.99)
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

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

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:

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

Interactive Questions

Phase 0 clarification (mandatory):

Target Users: Who will use this? (developers/end-users/admins/agencies)
Core Problem: What pain point does this solve? Metrics?
Success Criteria: How will you measure success? KPIs?
Constraints: Technical, budget, timeline, platform constraints?
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

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

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:

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

Examples

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

Platform-Specific Commands

macOS
Ubuntu/Debian
Docker

# 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

# 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"

# 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

Command Reference

​Skill Commands

​/octo:debate - AI Debate Hub

​Syntax

​What It Does

​Debate Structure

​Interactive Questions

​Examples

​When to Use

​Output

​Natural Language Triggers

​/octo:review - Code Review

​Syntax

​What Gets Reviewed

​Interactive Questions

​Review Types

​Examples

​Output Format

​/octo:security - Security Audit

​Syntax

​What Gets Audited

OWASP Top 10

Authentication & Auth

Input Validation

Data Protection

​Interactive Questions

​Examples

​Output Format

​/octo:tdd - Test-Driven Development

​Syntax

​TDD Workflow

​What You Get

​Interactive Questions

​Examples

​TDD Cycle Example

​When to Use TDD

​/octo:factory - Dark Factory Mode

​Syntax

​What It Does

​Interactive Questions

​Options

​Examples

​Output Structure

​When to Use Factory

​Cost & Duration

​/octo:prd - PRD Generation

​Syntax

​What You Get

​Interactive Questions

​Scoring Framework (100 points)

​Examples

​Output Example

​/octo:claw - OpenClaw Administration

​Syntax

​What It Manages

Gateway Lifecycle

5 Platforms

6 Channels

Security

​Methodology

​Examples

​Platform-Specific Commands

​When to Use Claw

​Planning & Orchestration Skills

​/octo:plan - Strategic Planning

​/octo:parallel - Team of Teams

​/octo:multi - Force Multi-Provider

​/octo:spec - NLSpec Authoring

​Skill Comparison

​Next Steps

Try a Debate

Code Review

Workflow Commands

Build docs developers (and LLMs) love

Skill Commands

`/octo:debate` - AI Debate Hub

Syntax

What It Does

Debate Structure

Interactive Questions

Examples

When to Use

Output

Natural Language Triggers

`/octo:review` - Code Review

Syntax

What Gets Reviewed

Interactive Questions

Review Types

Examples

Output Format

`/octo:security` - Security Audit

Syntax

What Gets Audited

Interactive Questions

Examples

Output Format

`/octo:tdd` - Test-Driven Development

Syntax

TDD Workflow

What You Get

Interactive Questions

Examples

TDD Cycle Example

When to Use TDD

`/octo:factory` - Dark Factory Mode

Syntax

What It Does

Interactive Questions

Options

Examples

Output Structure

When to Use Factory

Cost & Duration

`/octo:prd` - PRD Generation

Syntax

What You Get

Interactive Questions

Scoring Framework (100 points)

Examples

Output Example

`/octo:claw` - OpenClaw Administration

Syntax

What It Manages

Methodology

Examples

Platform-Specific Commands

When to Use Claw

Planning & Orchestration Skills

`/octo:plan` - Strategic Planning

`/octo:parallel` - Team of Teams

`/octo:multi` - Force Multi-Provider

`/octo:spec` - NLSpec Authoring

Skill Comparison

Next Steps