Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/flow-spec
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
NLSpec authoring — use when you need a structured specification from multi-AI research and consensus
📊 Stats
Stars3,869
Forks362
LanguageShell
LicenseMIT
📦 Ships with octo
</> SKILL.md
flow-spec.SKILL.md
---name: flow-spec
effort: high
aliases:
- spec
- nlspec
- specification
description: NLSpec authoring — use when you need a structured specification from multi-AI research and consensus
execution_mode: enforced
validation_gates:
- orchestrate_sh_executed
- synthesis_file_exists
- nlspec_completeness_validated
---# STOP - SKILL ALREADY LOADED
**DO NOT call Skill() again. DO NOT load any more skills. Execute directly.**
---## EXECUTION CONTRACT (MANDATORY - CANNOT SKIP)
This skill uses **ENFORCED execution mode**. You MUST follow this exact 8-step sequence.
---### STEP 1: Clarifying Questions (MANDATORY)
**Ask via AskUserQuestion BEFORE any other action.**
You MUST gather these inputs from the user — spec quality depends on knowing actors, constraints, and complexity upfront; without these the research query is too broad and the spec will have gaps:
```
AskUserQuestion with these questions:
1. **What to specify**: Project or feature name + brief description
If user provided a description inline with the command (e.g., `/octo:spec user authentication system`), use that as the project description but STILL ask remaining questions (actors, constraints, complexity).
If user says "skip" for any question, note assumptions and proceed.
**DO NOT PROCEED TO STEP 2 until questions answered.**
Incorporate the user's answers from Step 1 into the probe query to focus the research.
**CRITICAL: You are PROHIBITED from:**
- Researching directly without calling orchestrate.sh — direct spec writing skips the multi-AI research that surfaces edge cases, alternative architectures, and constraint interactions
- Using web search instead of orchestrate.sh
- Claiming you're "simulating" the workflow
- Proceeding to Step 5 without running this command
- Substituting with direct Claude analysis
**You MUST use the Bash tool to invoke orchestrate.sh.**
**After orchestrate.sh completes, verify it succeeded:**
```bash
# Find the latest synthesis file (created within last 10 minutes)
SYNTHESIS_FILE=$(find ~/.claude-octopus/results -name "probe-synthesis-*.md" -mmin -10 2>/dev/null | head -n1)
if [[ -z "$SYNTHESIS_FILE" ]]; then
echo "VALIDATION FAILED: No synthesis file found"
echo "orchestrate.sh did not execute properly"
exit 1
fi
echo "VALIDATION PASSED: $SYNTHESIS_FILE"
cat "$SYNTHESIS_FILE"
```
**If validation fails:**
1. Report error to user
2. Show logs from `~/.claude-octopus/logs/`
3. DO NOT proceed with generating NLSpec
4. DO NOT substitute with direct research — fallback to single-model analysis skips the multi-provider synthesis that surfaces edge cases and alternative approaches
---
### STEP 6: Synthesize into NLSpec Format (MANDATORY)
**Read the probe synthesis file from Step 5 and the user's answers from Step 1.**
Synthesize into the NLSpec template below. This is YOUR (Claude's) synthesis role - you read the multi-AI research and structure it into the specification format.
**NLSpec Template:**
```markdown
# NLSpec: [Project Name]
## Meta
- Version: 1.0.0
- Author: [human author from user context, or "TBD"]
**After generating the NLSpec draft but BEFORE validation, challenge its completeness using a different provider.** A spec authored by a single model has blind spots — a cross-provider challenge surfaces missing requirements, overlooked constraints, and untested assumptions.
**Dispatch the NLSpec draft through Octopus routing to a different provider:**
"Challenge this specification. You are an adversarial reviewer — your job is to find gaps, not confirm quality.
1. What requirements are MISSING that users will need on day one?
2. What constraints are overlooked that will cause production failures?
3. What edge cases would break this system?
4. What assumptions are wrong or unstated?
5. Which behaviors have vague postconditions that can't be tested?
SPECIFICATION:
<paste NLSpec content here>"
fi
```
If neither external provider is available, launch a Sonnet challenge instead:
```
Agent(
model: "sonnet",
description: "Adversarial spec review",
prompt: "Challenge this specification. Your job is to find gaps, not confirm quality. What requirements are missing? What constraints are overlooked? What edge cases would break this? What assumptions are wrong?
SPECIFICATION:
<NLSpec content>"
)
```
**After receiving the challenge response:**
- Review each challenge point
- Revise the NLSpec to address valid challenges (add missing behaviors, tighten constraints, add edge cases)
- Dismiss challenges that are out of scope — but note WHY in the spec's Non-Goals or Constraints section
- Track changes: note in the spec's Meta section `Adversarial review: applied (N challenges addressed, M dismissed)`
**Skip with `--fast` or when user requests speed over thoroughness.**
