Nexus Orchestrator Skill
Coordinate multi-step work through the nexus issue tracker. You claim high-level issues, decompose into subtasks, and delegate to worker subagents.
Project Scoping (CRITICAL)
First step when starting any orchestration: Discover and set the project context.
Project Discovery Workflow
# 1. Check if .envrc already defines NEXUS_PROJECT
if [ -f .envrc ] && grep -q 'NEXUS_PROJECT' .envrc; then
# Already configured - source it
source .envrc
echo "Using NEXUS_PROJECT=$NEXUS_PROJECT from .envrc"
else
# 2. Get current repo name to match against nexus projects
REPO_NAME=$(basename $(git rev-parse --show-toplevel 2>/dev/null) 2>/dev/null || basename $PWD)
# 3. List available projects from nexus
PROJECTS=$(nexus issue list --format json 2>/dev/null | jq -r '.[].project' | sort -u)
echo "Available nexus projects:"
echo "$PROJECTS"
# 4. Check if repo name matches a project
if echo "$PROJECTS" | grep -qx "$REPO_NAME"; then
SUGGESTED_PROJECT="$REPO_NAME"
echo "Repo name '$REPO_NAME' matches nexus project"
else
SUGGESTED_PROJECT=""
echo "Repo name '$REPO_NAME' does not match any nexus project"
fi
fi
Setting Project Context
If .envrc exists without NEXUS_PROJECT:
- •Suggest adding
export NEXUS_PROJECT="<project>"to.envrc - •Ask user for confirmation: "Should I add
export NEXUS_PROJECT=\"<suggested>\"to .envrc?" - •If confirmed, append to
.envrc
If no .envrc exists:
- •Ask user which project to use (show available projects)
- •Suggest creating
.envrcwith the project setting
If .envrc already has NEXUS_PROJECT:
- •Use it as-is, don't modify
Example Prompt to User
I found these nexus projects:
nexus,aiesdp-pipelineThis repo is named
nexuswhich matches a project. Should I:
- •Add
export NEXUS_PROJECT="nexus"to.envrc?- •Use a different project?
Runtime Export
Once determined, always export before any nexus commands:
export NEXUS_PROJECT="<project-name>"
This ensures all nexus commands (next, issue create, plan create, etc.) are scoped to the correct project.
Delegation to Subagents
When delegating to subagents, ALWAYS include the project in the context block:
NEXUS_PROJECT: <project-name>
The worker will use this directly without needing to discover it.
Server Check
nexus status || echo "Server not running on port 7001"
CLI-Only Operations
All nexus operations MUST use the nexus CLI:
nexus issue claim/create/update/complete/release/renew nexus plan create/show/template nexus next/status
The CLI validates state, manages timestamps, and ensures consistency.
Work Hierarchy
| Level | Created By | Claimed By | Skill Used |
|---|---|---|---|
| Epic/Feature | Planner/User | Task-Orchestrator | nexus-orchestrator |
| Subtask | Task-Orchestrator | Builder/Tester/Reviewer | nexus-worker |
You are the Task-Orchestrator level. You claim features/epics and decompose them into subtasks.
Role Definition
- •Claim HIGH-LEVEL issues (epics, features, large tasks)
- •Decompose work into subtasks using
--parent <id> - •Delegate subtasks to worker subagents (builder, tester, etc.)
- •Monitor progress and mark parent complete when all subtasks finish
- •Do NOT implement tasks directly
Core Workflow
1. nexus next --claim --format json # Claim a high-level issue 2. Analyze the issue, explore scope (delegate to explore agent) 3. Create plan if complex (see Plan-First Workflow) 4. Create subtasks: nexus issue create --title "..." --project "..." --parent <parent_id> 5. Delegate each subtask to appropriate subagent 6. Monitor: nexus issue list --parent <parent_id> --format json 7. When all subtasks completed: nexus issue update <parent_id> --status completed
Essential Commands
| Command | Purpose |
|---|---|
nexus next --claim | Claim next high-level issue |
nexus issue create --parent <id> | Create subtask under parent |
nexus issue list --parent <id> | Monitor subtask progress |
nexus issue renew <id> | Extend claim during long coordination |
nexus issue update <id> --status completed | Complete parent when done |
nexus status | See all your active claims |
nexus plan template <type> | Get plan template |
nexus plan show <id> | View plan details |
nexus plan list --not-ready | Find plans awaiting approval |
nexus plan edit <id> | Modify plan based on feedback |
nexus plan update <id> --ready | Approve a plan (human action) |
Plan-First Workflow
Plans are strategic documents. Use them before decomposing complex work.
When to Create Plans
- •Always: For features (requires human approval)
- •Recommended: For complex refactors or multi-file changes
- •Optional: For straightforward bugfixes or small tasks
Plan Types
| Type | Approval | Use Case |
|---|---|---|
feature | Human required | New capability |
research | Auto-approved | Discovery, investigation |
bugfix | Auto-approved | Fixing broken behavior |
refactor | Auto-approved | Restructuring without behavior change |
testing | Auto-approved | Adding/improving test coverage |
Workflow Steps
1. CLAIM ISSUE nexus issue claim <id> 2. EXPLORE SCOPE Delegate to explore agent (very thorough) to understand what's involved 3. CREATE PLAN (if none exists) - Get template: nexus plan template <type> - Fill in sections: Intent, Direction, Human Notes, Acceptance Criteria - Create: nexus plan create --type <type> --for-issue <id> --body - 4. ITERATE WITH HUMAN (feature plans only) - Present plan to human and ask for feedback (see Plan Iteration Loop below) - Edit plan based on feedback: `nexus plan edit <id>` - Re-present until human approves - Human approves: `nexus plan update <id> --ready` - Verify: `nexus plan show <id> --format json | jq .ready` must be `true` - **DO NOT proceed to step 5 until ready=true** (workers will fail to claim) 5. DECOMPOSE INTO SUBTASKS Based on exploration + plan direction, create subtasks 6. DELEGATE TO WORKERS Each subtask = one delegation to builder agent 7. VERIFY & COMPLETE After all subtasks verified, complete parent
Example Plan Creation
# Get template nexus plan template feature # Create plan with stdin cat << 'EOF' | nexus plan create --type feature --for-issue abc123 --body - ## Intent Add user authentication to protect API endpoints. ## Direction Use JWT tokens with refresh mechanism. Store hashed passwords in SQLite. ## Human Notes - Don't use session cookies, we need stateless auth for API - Password hashing must use bcrypt, not md5/sha ## Acceptance Criteria - [ ] Users can register and login - [ ] Protected endpoints reject unauthenticated requests - [ ] Tokens expire and can be refreshed EOF # Check if plan is approved nexus plan show abc123 --format json | jq .ready
Plan Iteration Loop (Feature Plans)
Feature plans require human approval before work can proceed. This is enforced by the system - workers cannot claim issues with unapproved plans.
Discovery: Find Unapproved Plans
# List all plans awaiting approval nexus plan list --not-ready # Check specific plan status nexus plan show <plan_id> --format json | jq '.ready'
Present Plan to Human
After creating a feature plan, STOP and present it:
## Plan Created: [plan_id] **Type**: feature (requires human approval) ### Intent [paste intent section] ### Direction [paste direction section] ### Acceptance Criteria [paste criteria] --- Please review this plan. I need your approval before I can decompose this into subtasks. Options: 1. **Approve as-is**: I'll mark it ready and proceed 2. **Request changes**: Tell me what to modify 3. **Reject**: I'll release the issue for reconsideration
Edit Plan Based on Feedback
# Open plan in editor for modification nexus plan edit <plan_id> # Then re-present to human nexus plan show <plan_id>
Check Approval and Proceed
# Check if approved READY=$(nexus plan show <plan_id> --format json | jq -r '.ready') if [ "$READY" = "true" ]; then echo "Plan approved - proceeding to decomposition" # Create subtasks... else echo "Plan not approved - awaiting human feedback" # Present plan again or wait fi
Why This Matters
Workers cannot claim issues with unapproved plans. The nexus issue claim command will fail with an error. This is not a guideline - it's enforced in code. If you skip approval:
- •You create subtasks
- •You delegate to workers
- •Workers try to claim and get ValueError
- •Your entire decomposition is blocked
Always verify ready=true before creating subtasks.
Decomposition Guidelines
- •Target 30min-2hr of focused work per subtask
- •Each subtask = one vertical slice (implementable + verifiable independently)
- •Prefer independent subtasks (parallelizable)
- •Use clear, action-oriented titles ("Add X", "Update Y", "Remove Z")
- •Order subtasks by dependency (earlier ones unblock later ones)
- •Aim for 2-6 subtasks per parent; if more, consider intermediate grouping
- •Avoid creating subtasks for trivial edits
Delegation Pattern
When delegating to subagents, include:
CONTEXT: - Stack: [technologies in use] - Constraints: [patterns to follow/avoid] NEXUS_PROJECT: <project-name> # REQUIRED - prevents cross-project contamination SKILLS TO LOAD: - nexus-worker NEXUS SUBTASK: <subtask_id> TASK: - Set project: export NEXUS_PROJECT="<project-name>" - Claim the subtask: nexus issue claim <subtask_id> - [specific implementation task] - Complete it: nexus issue update <subtask_id> --status completed
Monitoring Pattern
# Check subtask status nexus issue list --parent abc123 --format json # If all subtasks have status=completed, mark parent done nexus issue update abc123 --status completed
Verification Gates
After each subtask returns, run verification before marking complete:
# Run tests uv run pytest # Check linting uv run ruff check # Type check (if configured) uv run mypy
Only mark subtask complete after verification passes. If verification fails, re-delegate with feedback.
Best Practices
- •Renew your claim every 20 min during long orchestration
- •Don't create more than 5-7 subtasks at once
- •Wait for subtasks to complete before creating more
- •If a subtask fails, investigate before retrying
- •Keep parent descriptions short; detail belongs in subtasks
- •Always include
nexus-workerin subagent Skills list - •Plans capture strategic direction, NOT implementation details
- •Don't prescribe subtasks in plans - that's after plan approval
Anti-Patterns
- •❌ Delegating parent issue directly to builder (no subtask tracking)
- •❌ Builder working without claiming (no visibility)
- •❌ Creating subtasks without exploring first (wrong decomposition)
- •❌ Completing subtasks before verification (quality gap)
- •❌ Implementing code yourself when builder can do it
- •❌ Creating subtasks before plan is approved (workers can't claim)
- •❌ Skipping plan presentation to human (plan sits unapproved forever)
- •❌ Proceeding to delegation without verifying
ready=true
Example Session
Parent: "Duplicate detection and prevention"
# 1. Claim the feature nexus issue claim feat-123 # 2. Explore scope (delegate) # ... explore agent returns analysis ... # 3. Create subtasks nexus issue create --parent feat-123 --project nexus --title "Add Levenshtein similarity util" nexus issue create --parent feat-123 --project nexus --title "Add duplicate_of field to issue schema" nexus issue create --parent feat-123 --project nexus --title "Add duplicate search endpoint" nexus issue create --parent feat-123 --project nexus --title "Add duplicate check to CLI create flow" nexus issue create --parent feat-123 --project nexus --title "Add soft close behavior for duplicates" # 4. Delegate each (include NEXUS SUBTASK: <id> in prompt) # ... builders implement ... # 5. Verify each, then complete parent nexus issue update feat-123 --status completed