Requirements
rizsotto/Bear
Write, modify, or review a requirement file under docs/requirements -- pick the single owning file, keep the text contract-only, name IDs so they need no explanation, and verify cross-references and…
Multi-AI requirements scoping using available external providers (Double Diamond Define phase).
$ npx skills add nyldn/claude-octopus --skill flow-define -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install nyldn/claude-octopus flow-define --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/nyldn/claude-octopus.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/flow-define .claude/skills/flow-define && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "flow-define" agent skill from https://github.com/nyldn/claude-octopus/tree/main/skills/flow-define into .claude/skills/flow-define/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "flow-define", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/nyldn/claude-octopus/tree/main/skills/flow-defineType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add nyldn/claude-octopus --skill flow-define -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install nyldn/claude-octopus flow-define --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nyldn/claude-octopus.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/flow-define .agents/skills/flow-define && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "flow-define" agent skill from https://github.com/nyldn/claude-octopus/tree/main/skills/flow-define into .agents/skills/flow-define/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "flow-define", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add nyldn/claude-octopus --skill flow-define -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install nyldn/claude-octopus flow-define --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nyldn/claude-octopus.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/flow-define .cursor/skills/flow-define && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "flow-define" agent skill from https://github.com/nyldn/claude-octopus/tree/main/skills/flow-define into .cursor/skills/flow-define/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "flow-define", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/nyldn/claude-octopus.git --path skills/flow-define--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add nyldn/claude-octopus --skill flow-define -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install nyldn/claude-octopus flow-define --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nyldn/claude-octopus.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/flow-define .gemini/skills/flow-define && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "flow-define" agent skill from https://github.com/nyldn/claude-octopus/tree/main/skills/flow-define into .gemini/skills/flow-define/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "flow-define", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install nyldn/claude-octopus flow-defineInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add nyldn/claude-octopus --skill flow-define -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/nyldn/claude-octopus.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/flow-define .github/skills/flow-define && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "flow-define" agent skill from https://github.com/nyldn/claude-octopus/tree/main/skills/flow-define into .github/skills/flow-define/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "flow-define", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add nyldn/claude-octopus --skill flow-define -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install nyldn/claude-octopus flow-define --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nyldn/claude-octopus.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/flow-define .opencode/skills/flow-define && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "flow-define" agent skill from https://github.com/nyldn/claude-octopus/tree/main/skills/flow-define into .opencode/skills/flow-define/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "flow-define", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
flow-defineMulti-AI requirements scoping using available external providers (Double Diamond Define phase).
Flow Define is an agent skill from nyldn/claude-octopus. Multi-AI requirements scoping using available external providers (Double Diamond Define phase). Priority triggers: octo define, octo scope, co-define, co-scope. DO NOT use for implementation, research, review/validation, or built-in commands.
Its SKILL.md is about 6.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `agents/openai.yaml`).
The repository describes itself as: Run multiple AI models against the same research, design, or coding task. Surface disagreements before you ship. The licence is MIT.
7 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 4d152db. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
bashjqFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names these keys or tokens, usually read from environment variables:
OPENAI_API_KEYAGY_AUTH_TOKENFrom names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Flow Define loads about 6.5k tokens when it runs. Until then it costs about 64 tokens; SKILL.md has 1,496 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from nyldn/claude-octopus at commit 4d152db, republished under its MIT licence (© nyldn). 1,496 words, ~6,464 tokens.
.claude/skills/flow-define/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
{{PREAMBLE}}
Load skills/blocks/engineering-method-selection.md from the installed plugin
and apply only the methods relevant to this task. Preserve this entry point's
execution contract and output format. Read referenced skills as instructions;
do not invoke the current command recursively or add provider calls from a seat.
Load the project's existing glossary and decisions when they apply. If none
exists, use skills/blocks/domain-modeling.md and add a short definitions section
to the current design artifact. Do not create a parallel context or memory file.
Keep installation, authentication, entitlement, readiness, billing, quota, seat,
contribution, and vote distinct.
Before starting definition:
.octo/STATE.md to verify Discover phase complete# Verify Discover phase is complete
if [[ -f ".octo/STATE.md" ]]; then
discover_status=$("${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" get_phase_status 1)
if [[ "$discover_status" != "complete" ]]; then
echo "⚠️ Warning: Discover phase not marked complete. Consider running discovery first."
fi
fi
# Update state for Definition phase
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
--phase 2 \
--position "Definition" \
--status "in_progress"This skill uses ENFORCED execution mode. You MUST follow this exact sequence.
MANDATORY: You MUST use the native shell command tool to run this provider check BEFORE displaying the banner. Do NOT skip it. Do NOT assume availability.
provider_check_output=$(bash "${HOME}/.claude-octopus/plugin/scripts/helpers/check-providers.sh")
provider_status_lines=$(printf '%s\n' "$provider_check_output" | awk '
/^PROVIDER_CHECK_START$/ { capture=1; next }
/^PROVIDER_CHECK_END$/ { capture=0 }
capture && /^[a-z0-9-]+:(available|missing|degraded)$/ { print }
')
if [[ -z "$provider_status_lines" ]]; then
echo "Provider availability check returned no usable status lines."
exit 1
fi
# Exclude providers intentionally disabled by environment, session, or global
# allowlist policy; show every allowed provider, including missing/degraded.
source "${HOME}/.claude-octopus/plugin/scripts/lib/provider-allowlist.sh"
provider_availability=""
available_provider_count=0
while IFS=: read -r provider status; do
octo_provider_allowed "$provider" || continue
case "$status" in
available)
provider_availability="${provider_availability}🟢 ${provider}: Available ✓"$'\n'
available_provider_count=$((available_provider_count + 1))
;;
degraded)
provider_availability="${provider_availability}🟠 ${provider}: Degraded ⚠"$'\n'
;;
missing)
provider_availability="${provider_availability}🔴 ${provider}: Missing/unavailable ✗"$'\n'
;;
esac
done <<< "$provider_status_lines"
if [[ "$available_provider_count" -eq 0 ]]; then
printf '%s' "$provider_availability"
echo "No external provider is available. Run /octo:setup and retry."
exit 1
fi
# Task status for the banner's Tasks line, if the session has one.
task_status=$("${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh" get-task-status 2>/dev/null || echo "")List every provider the check reports, not only Claude. A banner showing one seat when several ran misrepresents what the user is paying for.
If OCTO_ALLOWED_PROVIDERS is set, treat it as the source of truth for which providers may participate. Providers filtered out by that allowlist are intentionally reported as unavailable; do not invoke or recommend them in the workflow.
Display this banner BEFORE orchestrate.sh execution:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider definition mode
🎯 Define Phase: [Brief description of what you're defining/scoping]
📋 Session: ${CLAUDE_SESSION_ID}
📝 Tasks: ${task_status}
Provider Availability:
${provider_availability}
🔵 Claude: Available ✓ - Consensus building and synthesis
💰 Estimated Cost: 0.01-0.05 USD
⏱️ Estimated Time: 2-5 minutesDO NOT PROCEED TO STEP 2 until banner displayed. The banner shows users which providers will run and what costs they'll incur — starting API calls without this visibility violates cost transparency.
Before executing the workflow, read any prior context:
# Initialize state if needed
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" init_state
# Set current workflow
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" set_current_workflow "flow-define" "define"
# Get prior decisions (if any)
prior_decisions=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_decisions "all")
# Get context from discover phase
discover_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "discover")
# Display what you found (if any)
if [[ "$discover_context" != "null" ]]; then
echo "📋 Building on discovery findings:"
echo " $discover_context"
fi
if [[ "$prior_decisions" != "[]" && "$prior_decisions" != "null" ]]; then
echo "📋 Respecting prior decisions:"
echo "$prior_decisions" | jq -r '.[] | " - \(.decision) (\(.phase)): \(.rationale)"'
fiThis provides context from:
search, timeline, get_observations) are available — use them to find past decisions on similar topicsDO NOT PROCEED TO STEP 3 until state read.
Before executing expensive multi-AI orchestration, capture the user's vision to scope the work effectively.
Ask clarifying questions using AskUserQuestion:
Use AskUserQuestion tool to ask:
1. **User Experience**
Question: "How should users interact with this feature?"
Header: "User Flow"
Options:
- label: "API-first (programmatic access)"
description: "Build API endpoints first, UI later"
- label: "UI-first (user-facing interface)"
description: "Build user interface first, API supports it"
- label: "Both simultaneously"
description: "Develop API and UI in parallel"
- label: "Not applicable"
description: "This feature doesn't have a user interaction"
2. **Implementation Approach**
Question: "What technical approach do you prefer?"
Header: "Approach"
Options:
- label: "Fastest to market"
description: "Prioritize speed, use existing libraries"
- label: "Most maintainable"
description: "Focus on clean architecture, may take longer"
- label: "Best performance"
description: "Optimize for speed and efficiency"
- label: "Multi-LLM debate (Claude + available providers)"
description: "Multiple AI models debate the best approach — may use external provider credits or subscriptions"
3. **Scope Boundaries**
Question: "What's explicitly OUT of scope for this phase?"
Header: "Out of Scope"
Options:
- label: "Testing and QA"
description: "Focus on implementation, test later"
- label: "Performance optimization"
description: "Get it working first, optimize later"
- label: "Edge cases"
description: "Handle happy path only initially"
- label: "Nothing excluded"
description: "Everything is in scope"
multiSelect: trueIf user selected "Multi-LLM debate (Claude + available providers)" for approach: Before proceeding with orchestrate.sh, run a Multi-LLM debate to determine the technical approach:
/octo:debate --rounds 2 --debate-style collaborative "What is the best technical approach for [feature]? Consider: speed to market, maintainability, performance, and the existing codebase patterns."Use the debate synthesis to set the approach context for the Define phase.
After gathering answers, create context file:
# Source context manager
source "${HOME}/.claude-octopus/plugin/scripts/context-manager.sh"
# Extract user answers from AskUserQuestion results
user_flow="[Answer from question 1]"
approach="[Answer from question 2]"
out_of_scope="[Answer from question 3]"
# Create context file with user vision
create_templated_context \
"define" \
"$(echo "$USER_REQUEST" | head -c 50)..." \
"User wants: $user_flow approach with $approach priority" \
"$approach" \
"Implementation of requested feature" \
"$out_of_scope"
echo "📋 Context captured and saved to .claude-octopus/context/define-context.md"This context will be used to:
DO NOT PROCEED TO STEP 4 until context captured. User vision (UX approach, priorities, out-of-scope items) scopes the multi-AI research — without it, providers research too broadly and the definition misses the user's actual intent.
You MUST execute this command via the native shell command tool:
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh define "<user's clarification request>"CRITICAL: You are PROHIBITED from:
You MUST use the native shell command tool to invoke orchestrate.sh.
If running in Claude Code v2.1.16+, users will see real-time progress indicators in the task spinner:
Phase 1 - External Provider Execution (Parallel):
Phase 2 - Synthesis (Sequential):
These spinner verb updates happen automatically - orchestrate.sh calls update_task_progress() before each agent execution. Users see exactly which provider is working and what it's doing.
If NOT running in Claude Code v2.1.16+: Progress indicators are silently skipped, no errors shown.
After orchestrate.sh completes, verify it succeeded:
# Find the latest synthesis file (created within last 10 minutes)
SYNTHESIS_FILE=$(find ~/.claude-octopus/results -name "grasp-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:
~/.claude-octopus/logs/After synthesis is verified, record findings and decisions in state:
# Extract key definition from synthesis
key_definition=$(head -50 "$SYNTHESIS_FILE" | grep -A 3 "## Problem Definition\|## Summary" | tail -3 | tr '\n' ' ')
# Record any architectural decisions made
# (You should identify these from the synthesis - e.g., tech stack, approach, patterns)
decision_made=$(echo "$key_definition" | grep -o "decided to\|chose to\|selected\|using [A-Za-z0-9 ]*" | head -1)
if [[ -n "$decision_made" ]]; then
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" write_decision \
"define" \
"$decision_made" \
"Consensus from multi-AI definition phase"
fi
# Update define phase context
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_context \
"define" \
"$key_definition"
# Update metrics
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_metrics "phases_completed" "1"DO NOT PROCEED TO STEP 7 until state updated.
Read the synthesis file and present:
Include attribution:
*Multi-AI Problem Definition powered by Claude Octopus*
*Providers: available external providers + 🔵 Claude*
*Full problem definition: $SYNTHESIS_FILE*<!-- Banner requirement lives in Execution Contract STEP 1 above. -->
The define phase clarifies and scopes problems using external CLI providers:
This is the convergent phase after discovery - we narrow down from broad research to specific problem definition.
Use define when you need:
Don't use define for:
Before execution, you'll see a banner in this shape. The provider rows below are illustrative; replace them with every live status from Step 1 and omit only providers excluded by the active allowlist:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider problem definition
🎯 Define Phase: Clarifying requirements and scope
📋 Session: ${CLAUDE_SESSION_ID}
📝 Tasks: ${task_status}
Provider Availability:
🟢 codex: Available ✓
🧭 agy: Degraded ⚠
🔴 agy: Missing/unavailable ✗
🔵 Claude: Available ✓ - Consensus building and synthesis${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh define "<user's clarification request>"The orchestrate.sh script will:
Results are saved to:
~/.claude-octopus/results/${SESSION_ID}/grasp-synthesis-<timestamp>.mdRead the synthesis and present clear, actionable requirements to the user.
When this skill is invoked, follow the EXECUTION CONTRACT above exactly. The contract includes:
Each step is mandatory and blocking - you cannot proceed to the next step until the current one completes successfully.
Create tasks to track execution progress:
// At start of skill execution
TaskCreate({
subject: "Execute define workflow with multi-AI providers",
description: "Run orchestrate.sh define for problem clarification",
activeForm: "Running multi-AI define workflow"
})
// Mark in_progress when calling orchestrate.sh
TaskUpdate({taskId: "...", status: "in_progress"})
// Mark completed ONLY after synthesis file verified
TaskUpdate({taskId: "...", status: "completed"})If any step fails:
/octo:setup and STOPNever fall back to direct analysis if orchestrate.sh execution fails. Report the failure and let the user decide how to proceed.
After successful execution, present problem definition with:
# Problem Definition: <task>
## Core Requirements
[Essential requirements that must be met]
## Technical Constraints
[Technical limitations and considerations]
## User Needs
[What users actually need from this]
## Edge Cases to Handle
[Specific edge cases identified]
## Out of Scope
[What is explicitly NOT included]
## Perspectives
### Codex Analysis (Technical)
[Technical requirements and constraints]
### Antigravity Analysis (Business/User)
[User needs and business context]
### Claude Synthesis
[Integrated problem definition]
## Requirements Checklist
- [ ] Functional requirements defined
- [ ] Non-functional requirements defined
- [ ] Technical constraints identified
- [ ] Edge cases documented
- [ ] Out-of-scope items clarified
- [ ] Success criteria established
## Next Steps
[Recommended next actions - usually tangle phase for implementation]
Full problem definition saved to: <synthesis file path>User: Define the exact requirements for our user authentication system
Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider problem definition
🎯 Define Phase: Clarifying authentication requirements
[Executes: ${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh define "Define exact requirements for user authentication system"]
[After completion, reads synthesis and presents:]
# Problem Definition: User Authentication System
## Core Requirements
### Must Have (P0)
1. User registration with email + password
2. Secure login with JWT token generation
3. Password reset via email
4. Session management with token refresh
5. Logout (token invalidation)
### Should Have (P1)
6. Remember me functionality
7. Account lockout after failed attempts
8. Email verification on signup
9. Password strength requirements
### Nice to Have (P2)
10. OAuth social login (Google, GitHub)
11. Two-factor authentication
12. Single sign-on (SSO)
## Technical Constraints
- Must work with existing Express.js backend
- Token storage: Redis for production, in-memory for dev
- Password hashing: bcrypt (min 12 rounds)
- Token expiry: Access token 15min, refresh token 7 days
- Rate limiting: Max 5 login attempts per 15min per IP
## User Needs
- Simple registration process (< 2 minutes)
- Secure password recovery without support tickets
- Stay logged in across browser sessions (remember me)
- Clear error messages for failed login
- Ability to log out from all devices
## Edge Cases to Handle
1. **Concurrent logins**: Same user, multiple devices
2. **Expired tokens**: Graceful refresh without re-login
3. **Password reset race condition**: Multiple reset requests
4. **Account enumeration**: Don't reveal if email exists
5. **Token theft**: Detect suspicious login locations
6. **Deleted users**: Handle auth for soft-deleted accounts
## Out of Scope
- ❌ Biometric authentication (fingerprint, face ID)
- ❌ LDAP/Active Directory integration
- ❌ Custom OAuth provider implementation
- ❌ Device fingerprinting
- ❌ Passwordless email magic links
## Perspectives
### Codex Analysis (Technical)
- JWT structure: { userId, role, exp, iat, jti }
- Database schema for users, refresh_tokens, password_resets
- API endpoints: POST /register, POST /login, POST /logout, POST /refresh, POST /reset-password
- Middleware for auth verification
- Security: HTTPS only, secure cookies, CSRF protection
### Antigravity Analysis (Business/User)
- User journey: Registration -> Email verification -> Login -> Access app
- Error handling: Clear messages without security leaks
- Performance: Auth checks < 50ms
- Compliance: GDPR (data deletion), password policies
- Analytics: Track signup conversion, failed login rates
### Claude Synthesis
- Hybrid approach: Core auth (P0) first, iterate on P1/P2
- Security-first: All requirements validated against OWASP
- User experience: Balance security with convenience
- Scalable: Design for 100K users, plan for 1M+
## Requirements Checklist
- ✅ Functional requirements defined (registration, login, reset)
- ✅ Non-functional requirements defined (performance, security)
- ✅ Technical constraints identified (Express, Redis, bcrypt)
- ✅ Edge cases documented (6 critical cases)
- ✅ Out-of-scope items clarified (4 items)
- ✅ Success criteria established (< 2min registration, < 50ms auth)
## Next Steps
1. **Immediate**: Review and confirm requirements with stakeholders
2. **Then**: Use **tangle-workflow** to implement the auth system
3. **Finally**: Use **ink-workflow** to validate implementation
Ready to proceed to implementation?
Full problem definition saved to: ~/.claude-octopus/results/abc-123/grasp-synthesis-20250118-144530.mdUser: What exactly does the notification feature need to do?
Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider problem definition
🎯 Define Phase: Clarifying notification requirements
[Executes grasp workflow]
[Presents detailed problem definition with:]
- Core notification types (email, push, in-app)
- Delivery requirements (real-time vs batched)
- User preferences (opt-in/out, frequency)
- Technical constraints (message queue, delivery tracking)
- Edge cases (offline users, rate limits)
Ready to build once requirements are confirmed.Grasp is the second phase of the Double Diamond:
PROBE (Discover) → GRASP (Define) → TANGLE (Develop) → INK (Deliver)Typical flow:
Or use grasp standalone when requirements are unclear.
Before completing grasp workflow, ensure:
External API Usage:
Grasp workflows typically cost 0.01-0.05 USD per task depending on complexity.
After definition completes:
.octo/STATE.md with completion.octo/ROADMAP.md with defined phases and success criteria# Update state after Definition completion
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
--status "complete" \
--history "Define phase completed"
# Populate ROADMAP.md with defined requirements
if [[ -f "$SYNTHESIS_FILE" ]]; then
echo "📝 Updating .octo/ROADMAP.md with defined phases..."
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_roadmap \
--from-synthesis "$SYNTHESIS_FILE"
fiThe Define phase is complete ONLY when requirements are synthesized and the user has
approved the scope. After approval, invoke flow-develop if implementation is requested.
Otherwise, deliver the requirements document and stop. Do NOT begin
implementation from here without an approved scope.
Ready to define! This skill is used after explicit invocation when users request requirement clarification or problem definition.
© nyldn, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 1 other file in skills/flow-define of nyldn/claude-octopus.
Open the folder on GitHubat commit 4d152db
We found 2 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in nyldn/claude-octopus, which our catalogue first saw on October 7, 2026.
Flow Define next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Flow Define this skillnyldn/claude-octopus | 4.2k | 1 repos | ~6.5k | Automated safety check: Pass | MIT | |
| Requirementsrizsotto/Bear | 6.5k | — | ~2k | Automated safety check: Pass | GPL-3.0 | |
| Add Model Provideropenclaw/openclaw | 392k | — | ~1.1k | Automated safety check: Pass | MIT | |
| OmniRoute Provider Managementdiegosouzapw/OmniRoute | 74k | — | ~2.4k | Automated safety check: Pass | MIT | |
| OmniRoute Providers CLIdiegosouzapw/OmniRoute | 74k | 1 repos | ~2.2k | Automated safety check: Pass | MIT | |
| External Linksthedaviddias/Front-End-Checklist | 74k | — | ~773 | Automated safety check: Pass | MIT |
rizsotto/Bear
Write, modify, or review a requirement file under docs/requirements -- pick the single owning file, keep the text contract-only, name IDs so they need no explanation, and verify cross-references and…
openclaw/openclaw
Add and live-prove a model provider with non-interactive config one-liners, without exposing credentials.
diegosouzapw/OmniRoute
Manages AI provider connections, API keys, OAuth flows and connection tests through OmniRoute's REST API across its 327-provider catalog.
diegosouzapw/OmniRoute
Command reference for managing provider connections in the omniroute gateway: browse the catalog, test and validate connections, rotate API keys and read per-provider metrics.
thedaviddias/Front-End-Checklist
A skill your agent uses when auditing content pages for citation quality, suggesting authoritative sources to link for factual claims, or reviewing whether a page's external link attributes…
mem0ai/mem0
Shows or changes the default Mem0 memory scope, project, session or global, which decides where memories are saved and searched.
nyldn/claude-octopus
Quick execution for ad-hoc tasks without full workflow overhead — use for small, self-contained requests
nyldn/claude-octopus
Thorough research across multiple sources — use for complex topics needing broad synthesis
nyldn/claude-octopus
OWASP compliance, vulnerability scanning, and adversarial red team testing — use for security reviews
nyldn/claude-octopus
Audit codebases for quality, consistency, and broken patterns — use for pre-release or tech debt review
nyldn/claude-octopus
Extract patterns and anatomy from URLs — use to reverse-engineer content strategies from live pages
nyldn/claude-octopus
Auto-detect work context (Dev vs Knowledge) — use to tailor workflows based on current task type
Multi-AI requirements scoping using available external providers (Double Diamond Define phase). Flow Define is an agent skill from nyldn/claude-octopus. Multi-AI requirements scoping using available external providers (Double Diamond Define phase).
Flow Define fits situations like: review/validation; built-in commands.
Run `npx skills add nyldn/claude-octopus --skill flow-define -a claude-code`. Or copy the skill folder (skills/flow-define in nyldn/claude-octopus) into .claude/skills/flow-define in your project. Claude Code loads it when a task matches its description.
Run `npx skills add nyldn/claude-octopus --skill flow-define -a codex`. Or copy the skill folder (skills/flow-define in nyldn/claude-octopus) into .agents/skills/flow-define in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add nyldn/claude-octopus --skill flow-define -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/flow-define, .gemini/skills/flow-define, .github/skills/flow-define and .opencode/skills/flow-define in your project.
Going by SKILL.md and its folder, Flow Define needs the command-line tools its instructions call (bash and jq) and credentials named OPENAI_API_KEY and AGY_AUTH_TOKEN.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Flow Define is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 6.5k tokens (SKILL.md is roughly 26k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Flow Define: Requirements (rizsotto/Bear, 6.5k stars), Add Model Provider (openclaw/openclaw, 392k stars), OmniRoute Provider Management (diegosouzapw/OmniRoute, 74k stars) and OmniRoute Providers CLI (diegosouzapw/OmniRoute, 74k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
nyldn (a GitHub user) maintains it in nyldn/claude-octopus, which has 4,182 GitHub stars. The repository holds 62 skills in this directory. The repository was last updated on October 7, 2026.
Source: nyldn/claude-octopus on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.