sidequest

name	sidequest
description	Routes any job into the right lev workflow by complexity and returns runnable next steps. Use when you want one-shot autonomous SDLC from quick fix through epic.
version	1.0.0
skill_type	workflow
category	process-execution
triggers	["sidequest","side quest","just do it","autonomous task","one shot"]

Sidequest - Autonomous SDLC Router

Overview

Takes any job description and autonomously determines the right execution strategy — from a trivial one-liner to a full epic-driven SDLC with BD tracking. Returns "done" with a runnable instructions artifact.

Quick Start

/sidequest fix the login timeout bug
/sidequest add SSO support for enterprise clients
/sidequest redesign the authentication system to support multi-tenant

Architecture Context

For current lev architecture, generate on the fly: ls ~/lev/core/ | sort (20 modules: domain, poly, exec, harness, orchestration, flowmind, graph...) grep "id:" ~/lev/dna/*.dna.yaml (DNA contracts — behavioral gates)

Key primitives: ExecTransport (domain→poly DI), TmuxHarness (owned spawn), AdapterRegistry (6 adapters), A2A Dispatcher (AgentJob→JobExecutor), Route.parse('lev://module/fractal/item'), fractal config. ntm is EXTERNAL — use TmuxHarness for owned tmux spawn.

Phase 0: Context Gathering (lev get pre-step)

Before classifying, gather context with semantic search:

SESSION_DIR="./tmp/sidequest-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$SESSION_DIR"

# Extract problem domain keywords
KEYWORDS="<extracted from job description>"

# Search for prior art, related code, and relevant skills
lev get "$KEYWORDS" --indexes codebase,tasks,skills,memory > "$SESSION_DIR/00-context.md" 2>/dev/null || \
lev get "$KEYWORDS" --indexes codebase,tasks,skills,memory > "$SESSION_DIR/00-context.md"

# Check if this work already exists in BD
bd list --status=open | grep -i "$KEYWORDS" >> "$SESSION_DIR/00-context.md"

Fallback (if lev get slow/unavailable):

# Timeout after 30 seconds, proceed with reduced context
timeout 30s sh -c 'lev get "$1" --indexes codebase,tasks > "$2" 2>/dev/null || lev find "$1" --indexes codebase,tasks > "$2"' _ "$KEYWORDS" "$SESSION_DIR/00-context.md" || {
  echo "# Context gathering timed out - using bd + grep fallback" > "$SESSION_DIR/00-context.md"
  bd list --status=open >> "$SESSION_DIR/00-context.md" 2>/dev/null
  # Fallback to grep for quick file discovery
  grep -r "$KEYWORDS" --include="*.ts" --include="*.md" -l . 2>/dev/null | head -20 >> "$SESSION_DIR/00-context.md"
}

Escalation path: If classification is uncertain after context gathering, route UP one level and note "escalated due to ambiguity" in DONE.md.

Phase 1: Complexity Classification

Classify the job on 4 dimensions:

COMPLEXITY FACTORS:
├─ Scope: How many files/components affected? (1 | 2-5 | 6-15 | 15+)
├─ Clarity: How well-defined is the task? (exact | clear | fuzzy | unknown)
├─ Risk: What breaks if wrong? (nothing | recoverable | significant | critical)
└─ Sessions: Can this be done in one sitting? (yes | maybe | no | definitely not)

Classification Matrix

Scope	Clarity	Risk	Sessions	→ Level
1 file	exact	nothing	yes	TRIVIAL
2-5 files	clear	recoverable	yes	BASE
6-15 files	fuzzy	significant	maybe	DEEP
15+ files	unknown	critical	no	EPIC

Tie-breaking: When factors disagree, route UP one level. Better to over-spec than under-spec.

Phase 2: Route to Handler

TRIVIAL — Direct Execute

Criteria: 1 file, exact change, no risk, <10 LOC
Handler: Just do it. No BD, no spec artifact.

Steps:
1. Make the change
2. Run tests (if they exist)
3. Write DONE.md with what changed

BASE — Plan + Implement

Criteria: 2-5 files, clear scope, recoverable risk
Handler: Lightweight spec → implement → validate

Steps:
1. Create minimal spec (5-10 bullet points + acceptance checks)
2. Implement changes
3. Run canned validations (test, build, lint)
4. bd create + bd close (single bead for tracking)
5. Write DONE.md with changes + validation results

DEEP — Design-to-BD Flow

Criteria: 6-15 files, fuzzy scope, significant risk
Handler: design-to-bd → agentic-execution → validate

Steps:
1. Research dispatch (2-3 parallel `lev get` queries)
2. Design document (stored in $SESSION_DIR/design.md)
3. BD scaffolding (epic + tasks with dependencies)
4. Agentic execution with turn-based dispatch:
   - Turn 1: Research/scaffold parallel
   - Turn 2: Implementation parallel
   - Turn 3: Validation (mandatory)
5. bd close when all validations pass
6. Write DONE.md with epic summary + instructions

EPIC — Full SDLC

Criteria: 15+ files, unknown scope, critical risk, multi-session
Handler: thinking-parliament → design-to-bd → agentic-execution → ralph-tui

Steps:
1. Parliament deliberation (multi-modal, see thinking-parliament)
2. Design-to-BD with [A][B][C][V] workstreams
3. Agentic execution with wave-based parallelism:
   lev exec --epic=<id> --dry-run    # Preview waves
   lev exec --epic=<id>              # Execute
4. Ralph validation loop:
   - 3-round devil's advocate
   - Task-specific validations from BD descriptions
   - <promise>EPIC_COMPLETE</promise> required
5. bd sync + git push
6. Write DONE.md with full execution report

Phase 3: Multi-Model Dispatch (when applicable)

For DEEP and EPIC levels, use multi-model dispatch for research/design:

# Parallel research with different models for perspective diversity
lev exec "Research: $ASPECT_A" --model=claude-sonnet-4-20250514 --adapter=claude-agent-sdk > "$SESSION_DIR/research-a.md" &
lev exec "Research: $ASPECT_B" --model=google/gemini-3-flash-preview --adapter=ai-sdk > "$SESSION_DIR/research-b.md" &
lev exec "Research: $ASPECT_C" --model=openai/gpt-5.2-pro --adapter=ai-sdk > "$SESSION_DIR/research-c.md" &
wait

# Synthesize with opus for deep reasoning
lev exec "Synthesize these research findings into a design..." --model=opus --adapter=cli

Phase 4: Completion Artifact

Every sidequest produces $SESSION_DIR/DONE.md:

# Sidequest Complete

## Job: <original description>
## Level: <TRIVIAL|BASE|DEEP|EPIC>
## Duration: <start → end timestamps>

## What Changed
- <file>: <description of change>
- ...

## Validations Run
- [ ] Tests: <pass/fail>
- [ ] Build: <pass/fail>
- [ ] Lint: <pass/fail>
- [ ] Task-specific: <details>

## Runnable Instructions (for human follow-up)
1. <any manual steps needed>
2. <deployment notes>
3. <monitoring to watch>

## BD Tracking
- Epic: <id or "none">
- Tasks closed: 
 Tasks remaining: 

Error Handling

IF classification uncertain:
  └─→ Route UP one level (over-spec, don't under-spec)

IF execution fails mid-stream:
  └─→ Write STALLED.md with:
      - What completed
      - What failed (error details)
      - What remains
      - Suggested recovery steps
  └─→ bd update <id> --status=blocked

IF validation fails:
  └─→ Retry once with fix attempt
  └─→ If still fails: escalate to STALLED.md
  └─→ Never close a task with failing validations

Integration Points

Tool	When Used	Purpose
lev get	Phase 0	Context gathering, prior art
bd create/close	BASE+	Work tracking
lev exec	DEEP+	Multi-model dispatch
thinking-parliament	EPIC	Multi-modal deliberation
design-to-bd	DEEP+	Design → BD scaffolding
agentic-execution	DEEP+	Turn-based parallel dispatch
ralph-tui	EPIC	Autonomous completion loop

Examples

Trivial

/sidequest fix typo in README.md line 42

→ Level: TRIVIAL
→ Action: Fix typo, no tests needed
→ DONE.md: "Fixed typo: 'recieve' → 'receive' in README.md:42"

Base

/sidequest add rate limiting to the /api/login endpoint

→ Level: BASE
→ Action: Spec (middleware placement, limits) → Implement → Test
→ BD: Single bead tracking the change
→ DONE.md: Files changed, test results, deployment notes

Deep

/sidequest add WebSocket support for real-time notifications

→ Level: DEEP
→ Action: Research (3 models) → Design → BD scaffold → Implement → Validate
→ BD: Epic with 4-6 tasks + validation task
→ DONE.md: Architecture decisions, implementation summary, test coverage

Epic

/sidequest redesign the entire auth system for multi-tenant support

→ Level: EPIC
→ Action: Parliament → Design → BD [A][B][C][V] → Agentic exec → Ralph loop
→ BD: Epic with 10+ tasks across workstreams
→ DONE.md: Full execution report with migration guide

Technique Map

• Role definition - Clarifies operating scope and prevents ambiguous execution.
• Context enrichment - Captures required inputs before actions.
• Output structuring - Standardizes deliverables for consistent reuse.
• Step-by-step workflow - Reduces errors by making execution order explicit.
• Edge-case handling - Documents safe fallbacks when assumptions fail.

Technique Notes

These techniques improve reliability by making intent, inputs, outputs, and fallback paths explicit. Keep this section concise and additive so existing domain guidance remains primary.

Prompt Architect Overlay

Role Definition

You are the prompt-architect-enhanced specialist for lev-orch-sidequest, responsible for deterministic execution of this skill's guidance while preserving existing workflow and constraints.

Input Contract

• Required: clear user intent and relevant context for this skill.
• Preferred: repository/project constraints, existing artifacts, and success criteria.
• If context is missing, ask focused questions before proceeding.

Output Contract

• Provide structured, actionable outputs aligned to this skill's existing format.
• Include assumptions and next steps when appropriate.
• Preserve compatibility with existing sections and related skills.

Edge Cases & Fallbacks

• If prerequisites are missing, provide a minimal safe path and request missing inputs.
• If scope is ambiguous, narrow to the highest-confidence sub-task.
• If a requested action conflicts with existing constraints, explain and offer compliant alternatives.