AgentSkillsCN

nexus-orchestrator

统筹 Nexus 项目:规划史诗级功能或特性,将其拆解为子任务,并委派给各执行人员。适用于“Nexus”“编排”“拆分”“创建工单”“子任务”“委派工作”等场景,专为任务编排代理而设计。

SKILL.md
--- frontmatter
name: nexus-orchestrator
description: "Coordinate nexus work: plan epics/features, decompose into subtasks, delegate to workers. Use on 'nexus', 'orchestrate', 'decompose', 'create tickets', 'subtasks', 'delegate work'. Load for task-orchestrator agent."

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

bash
# 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:

  1. Suggest adding export NEXUS_PROJECT="<project>" to .envrc
  2. Ask user for confirmation: "Should I add export NEXUS_PROJECT=\"<suggested>\" to .envrc?"
  3. If confirmed, append to .envrc

If no .envrc exists:

  1. Ask user which project to use (show available projects)
  2. Suggest creating .envrc with the project setting

If .envrc already has NEXUS_PROJECT:

  1. Use it as-is, don't modify

Example Prompt to User

I found these nexus projects: nexus, aiesdp-pipeline

This repo is named nexus which matches a project. Should I:

  1. Add export NEXUS_PROJECT="nexus" to .envrc?
  2. Use a different project?

Runtime Export

Once determined, always export before any nexus commands:

bash
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:

text
NEXUS_PROJECT: <project-name>

The worker will use this directly without needing to discover it.

Server Check

bash
nexus status || echo "Server not running on port 7001"

CLI-Only Operations

All nexus operations MUST use the nexus CLI:

bash
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

LevelCreated ByClaimed BySkill Used
Epic/FeaturePlanner/UserTask-Orchestratornexus-orchestrator
SubtaskTask-OrchestratorBuilder/Tester/Reviewernexus-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

bash
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

CommandPurpose
nexus next --claimClaim 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 completedComplete parent when done
nexus statusSee all your active claims
nexus plan template <type>Get plan template
nexus plan show <id>View plan details
nexus plan list --not-readyFind plans awaiting approval
nexus plan edit <id>Modify plan based on feedback
nexus plan update <id> --readyApprove 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

TypeApprovalUse Case
featureHuman requiredNew capability
researchAuto-approvedDiscovery, investigation
bugfixAuto-approvedFixing broken behavior
refactorAuto-approvedRestructuring without behavior change
testingAuto-approvedAdding/improving test coverage

Workflow Steps

code
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

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

bash
# 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:

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

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

bash
# 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:

  1. You create subtasks
  2. You delegate to workers
  3. Workers try to claim and get ValueError
  4. 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:

text
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

bash
# 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:

bash
# 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-worker in 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"

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