/prd
The feature or system to write a PRD for
> /plugin marketplace add nyldn/claude-octopus
Command definition
prd.mdcommand: prd
disable-model-invocation: true
description: Write an AI-optimized PRD using multi-AI orchestration and 100-point scoring framework
arguments:
- name: feature
description: The feature or system to write a PRD for
required: trueMANDATORY COMPLIANCE — DO NOT SKIP
**When the user explicitly invokes `/octo:prd`, you MUST follow the orchestrated PRD workflow below.** You are PROHIBITED from writing the PRD directly without the required clarification, research, scoring, and `orchestrate.sh` steps.
EXECUTION MECHANISM — NON-NEGOTIABLE
**You MUST execute this command by calling `orchestrate.sh` as documented below. You are PROHIBITED from:**
- ❌ Doing the work yourself using only Claude-native tools (Agent, Read, Grep, Write)
- ❌ Using a single Claude subagent instead of multi-provider dispatch via orchestrate.sh
- ❌ Skipping orchestrate.sh because "I can do this faster directly"
**Multi-LLM orchestration is the purpose of this command.** If you execute using only Claude, you've violated the command's contract.
STOP - DO NOT INVOKE /skill OR Skill() AGAIN
This command is already executing. The feature to document is: **$ARGUMENTS.feature**
---
PHASE 0: CLARIFICATION (MANDATORY - DO THIS FIRST)
Read the supplied target users, problem, success criteria, constraints, and existing context. Reuse explicit answers. Ask only material unresolved or contradictory fields from this checklist, omitting answered fields:
I'll create a PRD for: **$ARGUMENTS.feature**
To make this PRD highly targeted, please answer briefly:
1. **Target Users**: Who will use this? (developers, end-users, admins, agencies?)
2. **Core Problem**: What pain point does this solve? Any metrics on current impact?
3. **Success Criteria**: How will you measure success? (KPIs, adoption rate, time saved?)
4. **Constraints**: Any technical, budget, timeline, or platform constraints?
5. **Existing Context**: Greenfield project or integrating with existing systems?
(Type "skip" to proceed with assumptions, or answer inline)
Wait only for material missing or contradictory answers. When the supplied information is clear, proceed directly to research. Record minor assumptions. Clarification does not authorize implementation, publication, additional provider spending, or approval decisions; preserve the user's existing boundaries.
---
PHASE 1: QUICK RESEARCH (Max 60 seconds)
**Check provider availability first:**
set -euo pipefail
OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-${OCTO_ROOT:-${HOME}/.claude-octopus/plugin}}}"
# Check if multi-provider research is available
CODEX_AVAILABLE="false"
if command -v codex >/dev/null 2>&1; then
CODEX_AVAILABLE="true"
fi
AGY_AVAILABLE="false"
if command -v agy >/dev/null 2>&1; then
AGY_AVAILABLE="true"
fi**If multiple providers are available**, dispatch parallel research for richer context:
🐙 **Multi-provider research mode:**
- 🔴 Codex CLI — Technical implementation patterns and architecture precedents
- 🧭 Antigravity CLI — Market landscape, competitive products, industry trends
- 🔵 Claude — Domain analysis and strategic synthesis
# Parallel research dispatch (if providers available)
if [[ "$CODEX_AVAILABLE" == "true" ]]; then
"${OCTO_ROOT}/scripts/orchestrate.sh" prd-research "<feature>" codex &
fi
if [[ "$AGY_AVAILABLE" == "true" ]]; then
"${OCTO_ROOT}/scripts/orchestrate.sh" prd-research "<feature>" agy &
fi
wait**If single-provider only**, do MAX 2 web searches:
- One for domain/market context
- One for technical patterns (only if needed)
Do NOT over-research. Move to writing quickly.
---
PHASE 2: WRITE PRD
Include these sections: 1. Executive Summary (vision + key value) 2. Problem Statement (quantified, by user segment) 3. Goals & Metrics (SMART, P0/P1/P2, success metrics table) 4. Non-Goals (explicit boundaries) 5. User Personas (2-3 specific personas) 6. Functional Requirements (FR-001 format) 7. Implementation Phases (dependency-ordered) 8. Risks & Mitigations
---
PHASE 2.5: ADVERSARIAL PRD REVIEW (RECOMMENDED)
**After drafting the PRD but BEFORE self-scoring, dispatch the draft to a second provider for adversarial review.** A single-model PRD has blind spots — cross-provider challenge surfaces wrong assumptions, uncovered scenarios, and contradictory requirements.
**If an external provider is available, dispatch through Octopus routing:**
OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-${OCTO_ROOT:-${HOME}/.claude-octopus/plugin}}}"
review_provider=""
command -v codex >/dev/null 2>&1 && review_provider="codex"
[[ -z "$review_provider" ]] && command -v agy >/dev/null 2>&1 && review_provider="agy"
if [[ -n "$review_provider" ]]; then
"${OCTO_ROOT}/scripts/orchestrate.sh" spawn "$review_provider" \
"You are a skeptical product reviewer. Challenge this PRD:
1. What ASSUMPTIONS are wrong or untested? (e.g., assumed user behavior, market conditions, technical feasibility)
2. What USER SCENARIOS are missing? (edge cases, error states, migration paths, day-2 operations)
3. What REQUIREMENTS CONTRADICT each other? (e.g., 'real-time' + 'offline-first', 'simple' + 'enterprise-grade')
4. What will the FIRST user complaint be?
5. What is the biggest RISK this PRD ignores?
PRD DRAFT:
<paste PRD content>"
fi**If no external provider is available**, launch Sonnet:
Agent(
model: "sonnet",
description: "Adversarial PRD review",
prompt: "Challenge this PRD. What assumptions are wrong? What scenarios are missing? What requirements contradict? What will the first user complaint be?
PRD DRAFT:
<PRD content>"
)
**After receiving the challenge:**
- Revise the PRD to address valid challenges (add missing scenarios, resolve contradictions, note assumptions)
- Dismiss irrelevant challenges but note them in the Risks section if they have partial merit
- Add to the PRD footer: `Adversarial review: applied (provider: <provider>)`
**Skip with
Read more
command: prd
disable-model-invocation: true
description: Write an AI-optimized PRD using multi-AI orchestration and 100-point scoring framework
arguments:
- name: feature
description: The feature or system to write a PRD for
required: trueMANDATORY COMPLIANCE — DO NOT SKIP
**When the user explicitly invokes `/octo:prd`, you MUST follow the orchestrated PRD workflow below.** You are PROHIBITED from writing the PRD directly without the required clarification, research, scoring, and `orchestrate.sh` steps.
EXECUTION MECHANISM — NON-NEGOTIABLE
**You MUST execute this command by calling `orchestrate.sh` as documented below. You are PROHIBITED from:**
- ❌ Doing the work yourself using only Claude-native tools (Agent, Read, Grep, Write)
- ❌ Using a single Claude subagent instead of multi-provider dispatch via orchestrate.sh
- ❌ Skipping orchestrate.sh because "I can do this faster directly"
**Multi-LLM orchestration is the purpose of this command.** If you execute using only Claude, you've violated the command's contract.
STOP - DO NOT INVOKE /skill OR Skill() AGAIN
This command is already executing. The feature to document is: **$ARGUMENTS.feature**
---
PHASE 0: CLARIFICATION (MANDATORY - DO THIS FIRST)
Read the supplied target users, problem, success criteria, constraints, and existing context. Reuse explicit answers. Ask only material unresolved or contradictory fields from this checklist, omitting answered fields:
I'll create a PRD for: **$ARGUMENTS.feature** To make this PRD highly targeted, please answer briefly: 1. **Target Users**: Who will use this? (developers, end-users, admins, agencies?) 2. **Core Problem**: What pain point does this solve? Any metrics on current impact? 3. **Success Criteria**: How will you measure success? (KPIs, adoption rate, time saved?) 4. **Constraints**: Any technical, budget, timeline, or platform constraints? 5. **Existing Context**: Greenfield project or integrating with existing systems? (Type "skip" to proceed with assumptions, or answer inline)
Wait only for material missing or contradictory answers. When the supplied information is clear, proceed directly to research. Record minor assumptions. Clarification does not authorize implementation, publication, additional provider spending, or approval decisions; preserve the user's existing boundaries.
---
PHASE 1: QUICK RESEARCH (Max 60 seconds)
**Check provider availability first:**
set -euo pipefail
OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-${OCTO_ROOT:-${HOME}/.claude-octopus/plugin}}}"
# Check if multi-provider research is available
CODEX_AVAILABLE="false"
if command -v codex >/dev/null 2>&1; then
CODEX_AVAILABLE="true"
fi
AGY_AVAILABLE="false"
if command -v agy >/dev/null 2>&1; then
AGY_AVAILABLE="true"
fi**If multiple providers are available**, dispatch parallel research for richer context:
🐙 **Multi-provider research mode:**
- 🔴 Codex CLI — Technical implementation patterns and architecture precedents
- 🧭 Antigravity CLI — Market landscape, competitive products, industry trends
- 🔵 Claude — Domain analysis and strategic synthesis
# Parallel research dispatch (if providers available)
if [[ "$CODEX_AVAILABLE" == "true" ]]; then
"${OCTO_ROOT}/scripts/orchestrate.sh" prd-research "<feature>" codex &
fi
if [[ "$AGY_AVAILABLE" == "true" ]]; then
"${OCTO_ROOT}/scripts/orchestrate.sh" prd-research "<feature>" agy &
fi
wait**If single-provider only**, do MAX 2 web searches:
- One for domain/market context
- One for technical patterns (only if needed)
Do NOT over-research. Move to writing quickly.
---
PHASE 2: WRITE PRD
Include these sections: 1. Executive Summary (vision + key value) 2. Problem Statement (quantified, by user segment) 3. Goals & Metrics (SMART, P0/P1/P2, success metrics table) 4. Non-Goals (explicit boundaries) 5. User Personas (2-3 specific personas) 6. Functional Requirements (FR-001 format) 7. Implementation Phases (dependency-ordered) 8. Risks & Mitigations
---
PHASE 2.5: ADVERSARIAL PRD REVIEW (RECOMMENDED)
**After drafting the PRD but BEFORE self-scoring, dispatch the draft to a second provider for adversarial review.** A single-model PRD has blind spots — cross-provider challenge surfaces wrong assumptions, uncovered scenarios, and contradictory requirements.
**If an external provider is available, dispatch through Octopus routing:**
OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-${OCTO_ROOT:-${HOME}/.claude-octopus/plugin}}}"
review_provider=""
command -v codex >/dev/null 2>&1 && review_provider="codex"
[[ -z "$review_provider" ]] && command -v agy >/dev/null 2>&1 && review_provider="agy"
if [[ -n "$review_provider" ]]; then
"${OCTO_ROOT}/scripts/orchestrate.sh" spawn "$review_provider" \
"You are a skeptical product reviewer. Challenge this PRD:
1. What ASSUMPTIONS are wrong or untested? (e.g., assumed user behavior, market conditions, technical feasibility)
2. What USER SCENARIOS are missing? (edge cases, error states, migration paths, day-2 operations)
3. What REQUIREMENTS CONTRADICT each other? (e.g., 'real-time' + 'offline-first', 'simple' + 'enterprise-grade')
4. What will the FIRST user complaint be?
5. What is the biggest RISK this PRD ignores?
PRD DRAFT:
<paste PRD content>"
fi**If no external provider is available**, launch Sonnet:
Agent( model: "sonnet", description: "Adversarial PRD review", prompt: "Challenge this PRD. What assumptions are wrong? What scenarios are missing? What requirements contradict? What will the first user complaint be? PRD DRAFT: <PRD content>" )
**After receiving the challenge:**
- Revise the PRD to address valid challenges (add missing scenarios, resolve contradictions, note assumptions)
- Dismiss irrelevant challenges but note them in the Risks section if they have partial merit
- Add to the PRD footer: `Adversarial review: applied (provider: <provider>)`
**Skip with
Every AI model has blind spots. Claude Octopus supports twelve external provider integrations — Codex, Antigravity CLI, Copilot, Qwen, Ollama, Perplexity, OpenRouter, OrcaRouter, OpenCode, Cursor CLI, Grok, and Kimi Code — alongside the built-in Claude Code
Other commands on octo.
More commands from other plugins.
setup
CommandOne-time setup after installing ARIS as a Claude Code plugin — registers the Codex reviewer MCP server from the plugin directory…
autoresearch
CommandAutonomous iteration loop: modify, verify, keep/discard against any metric
agent
Commandname: sc:agent description: SC Agent — session controller that orchestrates investigation, implementation, and review category:…

