/nexus

Nexus Agent Chain Templates Reference

Purpose: Chain modifications only — complexity/sub-type variants that differ from the default chain, dynamic addition/skip triggers, and Rally parallel escalation. Read when: You already know the task type and need a variant, or you need to adjust an in-flight chain.

Scope boundary (post-cleanup): Base chains live in routing-matrix.md — it is the single source of truth for "which agents fire for task type X", including Recipe Hints and conditional Additions. This file holds only the delta: rows whose chain differs from that default. A row that merely restated the routing-matrix default has been removed; if a task type is absent here, use routing-matrix.md unchanged. Task types unique to this file (QA, TEST, COMPARE, UX_DESIGN) have no routing-matrix row and are fully owned here.

Contents

• Chain Variants by Task Type (deltas from routing-matrix defaults)
• Forge → Builder Integration
• Dynamic Chain Adjustment Rules
• Rally Parallel Chain Variants

Chain Variants by Task Type

Each row is a deviation from the routing-matrix.md default for that task type. Read the default there first; apply the variant here when its complexity/sub-type key matches.

Rows are work-phase deltas, not full ship chains. They deliberately omit the terminal Guardian (SHIP) step that routing-matrix.md's default chains end with: Guardian still runs after the variant whenever the task type's matrix row includes it, and is simply not repeated on every row. Rows for types with no matrix row (QA, TEST, COMPARE, UX_DESIGN) and rows whose deliverable is not a code change (advisory, strategy, document packages) end where they are written — no Guardian is implied there.

Single-agent sub-type variants are not tabled — they are the Recipe Hints in routing-matrix.md. Examples: ADVISORY/{1on1,group,triage,retro,pitch} = Magi[<mode>]; FIGURE_CHANNELING/{single,panel} = Magi[advisor] / Magi[advisor].

Forge → Builder Integration

When using Forge → Builder chains, Forge MUST output:

• types.ts → Builder converts to Value Objects
• errors.ts → Builder converts to DomainError classes
• forge-insights.md → Builder uses as business rules reference

Builder then applies:

1. Clarify Phase: Parse Forge outputs, detect ambiguities
2. Design Phase: TDD (test skeleton first), domain model design
3. Build Phase: Type-safe implementation with Event Sourcing/CQRS if needed
4. Validate Phase: Performance optimization, error handling verification

Dynamic Chain Adjustment Rules

Addition Triggers

• 3 consecutive test failures → Re-decompose with Sherpa
• Security-related code changes → Add Sentinel
• Security needs runtime validation → Add Probe after Sentinel
• UI changes included → Consider Muse/Palette
• UX assumptions need validation → Add Field before Echo
• Code changes exceed 50 lines → Consider refactoring with Zen
• Type errors occur → Return to Builder to strengthen type definitions
• Database queries slow (>100ms) → Add Tuner
• New tables/schemas needed → Add Schema before Builder
• Critical user flow changes → Add Voyager for E2E coverage
• Multi-page feature implementation → Add Voyager
• Builder detects ON_AMBIGUOUS_SPEC → Escalate to user or return to Spark
• Complex distributed workflow → Builder activates Event Sourcing/Saga patterns
• High read/write ratio disparity → Builder applies CQRS pattern
• Red team assessment requested → Add Breach after Sentinel
• Detection rules needed → Add Vigil
• Problem framing stuck → Add Flux for perspective shift
• User names a real notable figure ("what would <figure> do here?", "critique this as <figure>") → Use Magi[channel/critique] for the advisory reading; invoke Magi[decide] only when a verdict is requested
• A decision panel keeps producing the same in-house viewpoints → Add Magi[advisor] before Magi[decide] to inject named-expert mental models
• Ideation has gone flat with generic ideas → Add Magi[advisor] before Flux so expert frameworks seed the brainstorm
• Figma design available → Add Frame before Artisan
• Mockup/screenshot to code → Add Pixel (faithful reproduction from image)
• Detailed design-to-code gap analysis / fidelity audit / design review requested → Add Pixel[gap-report]; chain to Canon for WCAG mapping when a11y is in scope, Judge for report quality review, Artisan for remediation
• Personal branding or portfolio → Add Compete[brand]
• Combinatorial testing needed → Add Matrix before Radar
• Feature has 3+ independent dimensions or variants → Add Matrix after Spark
• Review covers 4+ files across 2+ modules → Add Matrix before Judge
• Test coverage gaps identified → Add Matrix to define coverage matrix
• Load test targets multiple endpoints/scenarios → Add Matrix before Siege
• Prerelease covers multiple platforms/environments → Add Matrix before Sentinel
• Approach stuck or single-perspective bias detected → Add Flux for reframing
• Feature ideation yields < 2 options → Add Flux before Spark
• Architecture decision has hidden assumptions → Add Flux before Magi
• Review finds no issues but confidence is low → Add Flux for blind-spot check
• First principles analysis requested or root assumptions questioned → Add Flux at chain start, combine with Matrix for decomposition
• Optimization target unclear or premature → Add Flux before Bolt/Tuner to question "are we optimizing the right thing?"
• Migration involves 3+ technology dimensions → Add Matrix before Shift detect for migration path analysis
• Postmortem reveals recurring pattern → Add Flux after Triage for deeper root cause reframing
• API design has 3+ resource types or versioning concerns → Add Matrix before Gateway
• UX design has 3+ user segments or device types → Add Matrix before Vision
• Deployment targets multiple environments/regions → Add Matrix before Guardian
• Content needs A/B testing across segments → Add Matrix before Prose
• Marketing requires multi-dimensional analysis (3+ segments × channels × campaigns) → Add Matrix to the MARKETING chain
• Remediation of known pattern → Replace Scout with Mend
• Ecosystem health check → Add Gauge

Matrix / Flux variants are derived, not enumerated. <TYPE>|matrix = Matrix → <base chain> and <TYPE>|first-principles = Flux → <base chain> (optionally with Matrix inserted for decomposition) are generated on demand by applying the Matrix/Flux triggers above to the base chain in routing-matrix.md. They are deliberately absent from the variant table — do not re-add them as rows.

Chain Selection Disambiguation

• Landing page or marketing site → Use DESIGN/landing-page (includes Prose for content-first approach)
• Marketing consulting requested (comprehensive strategy) → Use MARKETING/full (or the default MARKETING chain in routing-matrix.md for time-boxed engagements; MARKETING/full embeds Sherpa decomposition because 10-step chains require atomic-step planning)
• Brand strategy or visual identity for a product/company → Use MARKETING/brand (Vision-led, not Compete's personal-brand Recipe)
• Personal/engineer branding (individual portfolio, career, conference visibility) → Use MARKETING/personal-brand (Compete-led, distinct from product brand)
• Persona unclear or target segment ambiguous → Use MARKETING/persona-driven (Field-first to derive persona from qualitative data)
• Customer acquisition cost rising / paid channels saturated → Use MARKETING/acquisition (KPI-first; Pulse defines target CAC/LTV before channel tuning)
• Churn or LTV decline detected → Use MARKETING/retention (includes Trace for session-level churn cause analysis)
• Strategy needs human advisor pressure-testing → Add Magi[advisor] after the initial evidence frame
• Synthetic user voice needed when no real customers exist yet → Add Echo[demand] before Saga (early-stage persona need generation)
• MARKETING vs STRATEGY routing: STRATEGY/{seo,compete,retention,metrics,ab-test} are single-tactic chains (one specialist + Builder + Radar) for engineering-side implementation. MARKETING/* are consulting chains (multi-specialist, narrative-led, often without code output). Use MARKETING when the deliverable is strategy/messaging/plan; use STRATEGY when the deliverable is code/instrumentation.
• MARKETING/content vs CREATIVE/marketing-asset: MARKETING/content includes Saga (narrative)+Pulse (measurement) for content-strategy; CREATIVE/marketing-asset is image+copy asset production only (Growth→Builder→Prose→Artisan). Use the former for content marketing plans, the latter for one-off creative deliverables.
• MARKETING/seo-geo vs STRATEGY/seo: MARKETING/seo-geo adds Prose (copy)+Radar (quality gate) for full content+technical SEO; STRATEGY/seo is the narrow 3-step engineering implementation. Default to MARKETING/seo-geo unless the task is purely meta-tag/JSON-LD code.
• App UI with "clean" or "minimal" requirement → Use DESIGN/app-ui-restrained chain
• Visual direction unclear → Add Forge with moodboard mode before Vision
• Content strategy needed → Add Prose before or after Vision
• Design chain spans 5+ agents with implementation (Muse/Forge/Artisan) → Add Sherpa after Vision/Prose direction phase to decompose into atomic steps before implementation begins

Rally Parallel Escalation Triggers

• Chain has 2+ independent implementation steps → Escalate to Rally for parallel execution
• Sherpa decomposition produces parallel_group → Delegate to Rally via SHERPA_TO_RALLY_HANDOFF
• Feature scope spans 4+ files across 2+ domains (frontend/backend/DB) → Rally with Frontend/Backend Split
• Chain includes both Artisan and Builder implementation → Rally with Frontend/Backend Split
• 3+ independent bug fixes needed → Rally with Feature Parallel
• Implementation + test + docs needed simultaneously → Rally with Code/Test/Docs Triple
• Multi-module refactoring identified → Rally with Feature Parallel after Atlas/Sherpa

Rally Non-Escalation (Keep Sequential)

• Investigation-only chains (Lens, Scout, Trail) → No Rally
• Advisory-only chains (Magi 1on1/triage/retro/pitch) → No Rally; the advisory Recipe is single-session by contract
• Single-agent chains (Quill, Scribe) → No Rally
• Changes under 10 lines total → No Rally
• High-risk security changes → Prefer sequential with checkpoints
• Each branch needs < 50 lines of code → Nexus _PARALLEL_BRANCHES sufficient

Skip Triggers

• Changes under 10 lines AND tests exist → May skip Radar
• Pure documentation changes → Skip Radar/Sentinel
• Config files only → Only relevant agent
• Sentinel-only static issues → May skip Probe
• Schema unchanged → May skip Tuner

Rally Parallel Chain Variants

When Rally is activated for parallel execution, standard chains transform into parallel variants.

See rally/reference/integration-patterns.md for detailed team composition and handoff formats.