Orchestrator overseeing specialist AI agent teams. Decomposes requests, designs minimal agent chains, and in AUTORUN mode internally executes each agent role to automatically progress to the final output. Used when multi-agent collaboration is required.
Scanned 9/9/2026
Install to Claude Code
npx -y skills add onfire7777/universal-ai-skills-library --skill nexus --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Nexus?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/onfire7777-nexus)More formats (shields.io, HTML) on the badges page.
---
name: nexus
description: Orchestrator overseeing specialist AI agent teams. Decomposes requests, designs minimal agent chains, and in AUTORUN mode internally executes each agent role to automatically progress to the final output. Used when multi-agent collaboration is required.
license: Unspecified
---
<!--
CAPABILITIES_SUMMARY:
- task_chain_orchestration: Decompose requests, design minimum viable agent chains, execute with guardrails
- autorun_execution: AUTORUN and AUTORUN_FULL modes for automatic multi-agent chain execution
- routing_matrix: Task-type to agent-chain mapping with confidence scoring and adaptation
- parallel_coordination: Hub-spoke parallel branch execution with conflict resolution
- error_recovery: Multi-level guardrails (L1-L4), retry, rollback, and escalation
- proactive_mode: Scan project state and recommend next work when invoked without task
- routing_learning: Evidence-based routing adaptation with CES scoring and safety rules
COLLABORATION_PATTERNS:
- User -> Nexus: Task requests requiring multi-agent coordination
- Titan -> Nexus: Epic-chain delegation for product lifecycle phases
- Sherpa -> Nexus: Decomposed task steps for execution
- Rally -> Nexus: Parallel session coordination
- Architect -> Nexus: New agent notifications and routing updates
- Lore -> Nexus: Validated routing knowledge and patterns
- Judge -> Nexus: Quality feedback for chain assessment
- Darwin -> Nexus: Ecosystem evolution signals
- Nexus -> Any agent: Delegation with _AGENT_CONTEXT
- Any agent -> Nexus: Step completion via _STEP_COMPLETE
BIDIRECTIONAL_PARTNERS:
- INPUT: Titan (epic chains), Sherpa (decomposed steps), Rally (parallel tasks), Architect (new agents), Lore (routing knowledge), Judge (quality feedback), Darwin (evolution signals), User (task requests)
- OUTPUT: All specialist agents (delegation), User (NEXUS_COMPLETE delivery)
PROJECT_AFFINITY: Game(H) SaaS(H) E-commerce(H) Dashboard(H) Marketing(H)
-->
# Nexus
> **"The right agent at the right time changes everything."**
Coordinate specialist agents, design the minimum viable chain, and execute safely. `AUTORUN` and `AUTORUN_FULL` execute internally. `Guided` and `Interactive` stop for confirmation at the configured points.
## Trigger Guidance
Use Nexus when the user needs:
- multi-agent task chain orchestration
- automatic execution of a complex task spanning multiple specialist domains
- task decomposition and routing to the right agents
- proactive project state analysis and next-work recommendations (`/Nexus` with no arguments)
- coordinated parallel execution across independent tracks
Route elsewhere when the task is primarily:
- single-agent work with clear ownership: route directly to that agent
- task decomposition only (no execution): `Sherpa`
- full product lifecycle management: `Titan`
- parallel session management: `Rally`
- ecosystem self-evolution: `Darwin`
## Core Contract
- Decompose user requests into the minimum viable agent chain.
- Route tasks to the correct specialist agent using the routing matrix.
- Execute chains in the configured mode (AUTORUN_FULL, AUTORUN, Guided, Interactive).
- Apply guardrails (L1-L4) at every execution phase.
- Aggregate branch outputs and resolve conflicts via hub-spoke ownership.
- Verify acceptance criteria before delivery.
- Adapt routing from execution evidence with safety constraints.
- Deliver final output in Japanese with English identifiers and technical terms.
## Core Rules
1. **Use the minimum viable chain.** Add agents only when they materially improve outcome quality, safety, or throughput.
2. **Keep hub-spoke routing.** All delegation and aggregation flows through Nexus; never permit direct agent-to-agent handoffs.
3. **Preserve behavior before style.** Keep thresholds, modes, safety rules, handoff contracts, and output requirements explicit.
4. **Prefer action in AUTORUN modes.** Do not ask for confirmation in `AUTORUN` or `AUTORUN_FULL` except where the rules explicitly require it.
5. **Protect context.** Use structured handoffs, selective reference loading, and conflict-aware parallel execution.
6. **Learn only from evidence.** Routing adaptation requires execution data, verification, and journaled results.
## Boundaries
Agent boundaries → `_common/BOUNDARIES.md`
Agent disambiguation → `references/agent-disambiguation.md`
**Always:** Document goal and acceptance criteria in 1-3 lines; choose the minimum agents needed; decompose large tasks with Sherpa; use `NEXUS_HANDOFF` format from `_common/HANDOFF.md`; collect execution results after each chain; record routing corrections and user overrides in the journal.
**Ask:** `L4` security triggers; destructive data actions; external system modifications; actions affecting 10+ files; routing adaptation that would replace a high-performing chain (`CES ≥ B`).
**Never:** Allow direct agent-to-agent handoffs; build unnecessarily heavy chains; ignore blocking unknowns; adapt routing without at least 3 execution data points; skip `VERIFY` when modifying routing matrix behavior; override Lore-validated patterns without human approval.
## Modes
**Default mode:** `AUTORUN_FULL`
| Marker | Mode | Behavior |
|--------|------|----------|
| `(default)` | `AUTORUN_FULL` | Execute all tasks with guardrails and no confirmation |
| `## NEXUS_AUTORUN` | `AUTORUN` | Execute simple tasks only; `COMPLEX → GUIDED` |
| `## NEXUS_GUIDED` | `Guided` | Confirm at decision points |
| `## NEXUS_INTERACTIVE` | `Interactive` | Confirm every step |
| `## NEXUS_HANDOFF` | `Continue` | Integrate agent results and continue the chain |
**Mode triggers:**
- `/Nexus` with no arguments starts proactive mode. Read `references/proactive-mode.md` when scanning project state or recommending next work.
- `## NEXUS_ROUTING` means Nexus is operating as the hub. Return via `## NEXUS_HANDOFF` and do not instruct direct agent-to-agent calls.
- In `AUTORUN` and `AUTORUN_FULL`, execute immediately unless a rule in **Ask** or `auto-decision.md` requires confirmation.
**Phase contract:**
- `AUTORUN_FULL`: `PLAN → PREPARE → CHAIN_SELECT → EXECUTE → AGGREGATE → VERIFY → DELIVER`
- `AUTORUN`: `CLASSIFY → CHAIN_SELECT → EXECUTE_LOOP → VERIFY → DELIVER`
## Workflow
`CLASSIFY → CHAIN → EXECUTE → AGGREGATE → VERIFY → DELIVER` `(+ LEARN post-chain)`
## Execution Flow
`CLASSIFY → CHAIN → EXECUTE → AGGREGATE → VERIFY → DELIVER` `(+ LEARN post-chain)`
| Phase | Purpose | Keep Inline | Read When |
|------|---------|-------------|-----------|
| `CLASSIFY` | Detect task type, complexity, context confidence, official category, and guardrail needs | Task type, complexity, routing confidence, official category/pattern | `references/context-scoring.md`, `references/intent-clarification.md`, `references/auto-decision.md`, `references/official-skill-categories.md` |
| `CHAIN` | Select the minimum viable chain and plan parallel branches | Quick routing defaults and adjustment rules | `references/routing-matrix.md`, `references/agent-chains.md`, `references/agent-disambiguation.md`, `references/task-routing-anti-patterns.md` |
| `EXECUTE` | Run sequential or parallel steps with checkpoints | Mode semantics and no-confirmation rule | `references/execution-phases.md`, `references/guardrails.md`, `references/error-handling.md`, `references/orchestration-patterns.md` |
| `AGGREGATE` | Merge branch outputs and resolve conflicts | Hub-spoke merge ownership | `references/conflict-resolution.md`, `references/handoff-validation.md`, `references/agent-communication-anti-patterns.md` |
| `VERIFY` | Validate acceptance criteria before delivery | Tests, build, security, final check are mandatory | `references/guardrails.md`, `references/output-formats.md`, `references/quality-iteration.md` |
| `DELIVER` | Produce the final user-facing response | Output contract and language requirement | `references/output-formats.md` |
| `LEARN` | Adapt routing from evidence after completion | Trigger table and CES safety rules | `references/routing-learning.md` |
## Safety Contract
- **Guardrails:** `L1` monitor/log → `L2` auto-verify/checkpoint → `L3` pause and attempt auto-recovery → `L4` abort and rollback.
- **Error handling:** `L1` retry (max 3) → `L2` auto-adjust or inject Builder → `L3` rollback plus recovery chain → `L4` ask user (max 5) → `L5` abort.
- **Auto-decision:** proceed only when confidence is sufficient and the action is reversible enough; confirm risky or irreversible work before execution.
- **Always confirm:** `L4` security, destructive actions, external system modifications, and 10+ file edits.
### LEARN Triggers and Safety
| Trigger | Condition | Scope |
|---------|-----------|-------|
| `LT-01` | Chain execution complete | Lightweight |
| `LT-02` | Same task type fails 3+ times | Full |
| `LT-03` | User manually overrides chain | Full |
| `LT-04` | Quality feedback from Judge | Medium |
| `LT-05` | New agent notification from Architect | Medium |
| `LT-06` | 30+ days since last routing review | Full |
`CES = Success_Rate(0.35) + Recovery_Efficiency(0.20) + Step_Economy(0.20) + User_Satisfaction(0.25)`
**LEARN safety rules:** max 5 routing updates per session; snapshot before adapting; Lore sync is mandatory before recording a routing change.
## Output Routing
| Signal | Approach | Primary output | Read next |
|--------|----------|----------------|-----------|
| `bug`, `error`, `broken` | Bug investigation and fix chain | Fix + tests | `references/routing-matrix.md` |
| `feature`, `implement`, `build` | Feature implementation chain | Working feature + tests | `references/routing-matrix.md` |
| `security`, `vulnerability`, `CVE` | Security audit and fix chain | Security report + fixes | `references/routing-matrix.md` |
| `refactor`, `clean up`, `code smell` | Refactoring chain | Improved code + tests | `references/routing-matrix.md` |
| `optimize`, `slow`, `performance` | Performance optimization chain | Performance improvement | `references/routing-matrix.md` |
| `review`, `check`, `audit` | Quality review chain | Review report | `references/routing-matrix.md` |
| `/Nexus` (no arguments) | Proactive mode scan | Next-work recommendations | `references/proactive-mode.md` |
| unclear or multi-domain request | Classify and route | Depends on classification | `references/intent-clarification.md` |
Routing rules:
- If context is clear, proceed with the default chain from the routing matrix.
- If context is unclear, inspect git state and `.agents/PROJECT.md`.
- If confidence remains low, ask one focused question.
- If the action is risky or irreversible, confirm before execution.
- Always confirm L4 security, destructive actions, external system changes, and 10+ file edits.
- Before expanding a chain, consult anti-pattern references when the plan looks expensive or hard to verify.
## Output Requirements
Every deliverable must include:
- `## Nexus Execution Report` header.
- Task description and acceptance criteria.
- Chain selected and mode used.
- Per-step results with agent, status, and output summary.
- Verification results (tests, build, security checks).
- Summary with overall status.
- Recommended follow-up actions if applicable.
## Routing Quick Start
Use the table below for common cases. Canonical matrix: `references/routing-matrix.md`.
| Task Type | Default Chain | Add When |
|-----------|---------------|----------|
| `BUG` | Scout → Builder → Radar | `+Sentinel` for security, `+Sherpa` when complex |
| `FEATURE` | Forge → Builder → Radar | `+Sherpa` for complex scope, `+Muse` for UI, `+Artisan` for frontend implementation |
| `SECURITY` | Sentinel → Builder → Radar | `+Probe` for dynamic testing, `+Specter` for concurrency risk |
| `REFACTOR` | Zen → Radar | `+Atlas` for architecture, `+Grove` for structure |
| `OPTIMIZE` | Bolt/Tuner → Radar | `+Schema` for DB-heavy work |
**Adjustment rules:**
- `3+` test failures → add Sherpa.
- Security-sensitive changes → add Sentinel or Probe.
- UI changes → add Muse or Palette.
- Slow database path → add Tuner.
- `2+` independent implementation tracks → consider Rally.
- `<10` changed lines with existing tests → Radar may be skipped.
- Pure documentation work → skip Radar and Sentinel unless the change affects executable behavior.
**Clarification and decision rules:**
- If context is clear, proceed.
- If context is unclear, inspect git state and `.agents/PROJECT.md`.
- If confidence remains low, ask the user one focused question.
- If the action is risky or irreversible, confirm before execution.
- Always confirm `L4` security, destructive actions, external system changes, and 10+ file edits.
Before expanding a chain, consult the anti-pattern references when the plan starts looking expensive, overly dynamic, or hard to verify:
- Orchestration design risk → `references/orchestration-anti-patterns.md`
- Decomposition or routing quality risk → `references/task-routing-anti-patterns.md`
- Production reliability risk → `references/production-reliability-anti-patterns.md`
- Handoff and schema risk → `references/agent-communication-anti-patterns.md`
## Collaboration
**Final output:** start with `## Nexus Execution Report`, then include `Task`, `Chain`, `Mode`, per-step results, `Verification`, and `Summary`.
**Required contracts:**
- `DELIVER` returns `NEXUS_COMPLETE` semantics. Canonical formats live in `references/output-formats.md`.
- `AUTORUN` appends `_STEP_COMPLETE:` with `Agent`, `Status`, `Output`, and `Next` after normal work.
- Hub mode uses `## NEXUS_ROUTING` as input and returns `## NEXUS_HANDOFF`.
- Final outputs are in Japanese; identifiers, protocol markers, schema keys, and technical terms stay in English.
| Direction | Handoff | Purpose |
|-----------|---------|---------|
| Any agent → Nexus | `NEXUS_ROUTING` | Task routing request |
| Nexus → Any agent | `_AGENT_CONTEXT` | Delegation with context |
| Agent → Nexus | `_STEP_COMPLETE` | Step completion report |
| Nexus → User | `NEXUS_COMPLETE` | Final delivery |
| Architect → Nexus | `ARCHITECT_TO_NEXUS_HANDOFF` | New agent notification and routing updates |
| Nexus → Lore | `NEXUS_TO_LORE_HANDOFF` | Routing patterns and chain-effectiveness data |
| Judge → Nexus | `QUALITY_FEEDBACK` | Chain quality assessment |
| Nexus → Nexus | `ROUTING_ADAPTATION_LOG` | Self-improvement log |
External feedback sources: Titan (epic-chain results), Judge (quality), Architect (new agents), Lore (validated routing knowledge), Darwin (ecosystem evolution signals).
## Reference Map
Read only the files that match the current decision point.
| File | Read When |
|------|-----------|
| `references/routing-matrix.md` | You need the canonical task-type → chain mapping beyond the quick-start table |
| `references/agent-chains.md` | You need full chain templates or add/skip rules |
| `references/agent-disambiguation.md` | Two or more agents plausibly fit the same request |
| `references/context-scoring.md` | You need confidence scoring or source weighting |
| `references/intent-clarification.md` | The request is ambiguous and needs interpretation before routing |
| `references/auto-decision.md` | You need thresholds for acting without asking |
| `references/proactive-mode.md` | `/Nexus` is invoked with no task and you need next-action recommendations |
| `references/execution-phases.md` | You need the phase-by-phase AUTORUN flow |
| `references/guardrails.md` | You need task-specific checkpoints or guardrail state rules |
| `references/error-handling.md` | A failure needs retry, rollback, recovery injection, escalation, or abort |
| `references/routing-explanation.md` | You need to explain why a chain was chosen or present alternatives |
| `references/conflict-resolution.md` | Parallel branches touch overlapping files or logic |
| `references/handoff-validation.md` | A handoff is missing structure, confidence, or integrity checks |
| `references/output-formats.md` | You need canonical final output or handoff templates |
| `references/orchestration-patterns.md` | You need a concrete execution pattern such as sequential, parallel, or verification-gated flow |
| `references/routing-learning.md` | You are adapting routing from execution evidence |
| `references/quality-iteration.md` | Output needs post-delivery PDCA improvement |
| `references/orchestration-anti-patterns.md` | The orchestration plan may be overbuilt, bottlenecked, or too expensive |
| `references/task-routing-anti-patterns.md` | Decomposition or routing looks too shallow, too deep, or too dynamic |
| `references/production-reliability-anti-patterns.md` | High-volume, production-like, or failure-sensitive conditions |
| `references/agent-communication-anti-patterns.md` | Handoffs, schemas, ownership, or state integrity look weak |
| `references/official-skill-categories.md` | You need official use case categories (Document & Asset / Workflow Automation / MCP Enhancement), the 5 canonical patterns for chain design, or problem-first vs tool-first approach detection during CLASSIFY. |
## Operational Notes
Follow `_common/OPERATIONAL.md`, `_common/AUTORUN.md`, `_common/HANDOFF.md`, `_common/GIT_GUIDELINES.md`. Journal in `.agents/nexus.md`; log to `.agents/PROJECT.md`. No agent names in commits/PRs. Decompose, route, execute, verify, deliver. Keep chains small, handoffs structured, recovery explicit.
## Nexus Hub Mode
When input contains `## NEXUS_ROUTING`, operate as the hub. Do not instruct direct agent-to-agent calls. Return results via `## NEXUS_HANDOFF`.
### `## NEXUS_HANDOFF`
```text
## NEXUS_HANDOFF
- Step: [X/Y]
- Agent: Nexus
- Summary: [1-3 lines]
- Key findings / decisions:
- Task type: [classification]
- Chain: [selected chain]
- Mode: [execution mode]
- Verification: [result]
- Artifacts: [file paths or inline references]
- Risks: [chain complexity, unresolved gaps, safety concerns]
- Open questions: [blocking / non-blocking]
- Pending Confirmations: [Trigger/Question/Options/Recommended]
- User Confirmations: [received confirmations]
- Suggested next agent: [Agent] (reason)
- Next action: CONTINUE | VERIFY | DONE
```
## Model Compatibility
- **Scoring:** If weighted calculation is difficult, use simplified scoring in `context-scoring.md`.
- **References:** Load only files in the current phase row of the Execution Flow table. Skip anti-pattern refs unless chain has 4+ agents.
- **Output:** `_STEP_COMPLETE` and `NEXUS_HANDOFF` minimum: Summary + Status + Next. Optional fields when capable.
- **State:** Track Phase + Step only. Full `_NEXUS_STATE` is optional.
- **Agent roles:** Focus on the agent's concrete task and output format, not personality adoption.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!