sidequest

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sidequest - Autonomous SDLC Router

Sidequest - 自主SDLC路由器

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.
接收任何任务描述,自主确定合适的执行策略——从简单的单行修改到带有BD跟踪的完整史诗级SDLC流程。返回包含可运行指令工件的“完成”状态。

Quick Start

快速开始

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

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

阶段0:上下文收集(
lev get
前置步骤)

Before classifying, gather context with semantic search:
bash
SESSION_DIR="./tmp/sidequest-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$SESSION_DIR"
分类前,通过语义搜索收集上下文:
bash
SESSION_DIR="./tmp/sidequest-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$SESSION_DIR"

Extract problem domain keywords

提取问题领域关键词

KEYWORDS="<extracted from job description>"
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"
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中存在

bd list --status=open | grep -i "$KEYWORDS" >> "$SESSION_DIR/00-context.md"

**Fallback (if `lev get` slow/unavailable):**
```bash
bd list --status=open | grep -i "$KEYWORDS" >> "$SESSION_DIR/00-context.md"

**备选方案(若`lev get`缓慢/不可用):**
```bash

Timeout after 30 seconds, proceed with reduced context

30秒后超时,使用简化上下文继续

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.
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 "# 上下文收集超时 - 使用bd + grep备选方案" > "$SESSION_DIR/00-context.md" bd list --status=open >> "$SESSION_DIR/00-context.md" 2>/dev/null

备选方案:使用grep快速查找文件

grep -r "$KEYWORDS" --include=".ts" --include=".md" -l . 2>/dev/null | head -20 >> "$SESSION_DIR/00-context.md" }

**升级路径:** 如果上下文收集后分类仍不确定,则升级一级,并在DONE.md中注明“因歧义升级”。

Phase 1: Complexity Classification

阶段1:复杂度分类

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)
从4个维度对任务进行分类:
复杂度因素:
├─ 范围:影响多少文件/组件?(1 | 2-5 | 6-15 | 15+)
├─ 清晰度:任务定义有多明确?(精确 | 清晰 | 模糊 | 未知)
├─ 风险:出错会导致什么问题?(无影响 | 可恢复 | 重大 | 关键)
└─ 时长:能否一次完成?(是 | 可能 | 否 | 绝对不行)

Classification Matrix

分类矩阵

ScopeClarityRiskSessions→ Level
1 fileexactnothingyesTRIVIAL
2-5 filesclearrecoverableyesBASE
6-15 filesfuzzysignificantmaybeDEEP
15+ filesunknowncriticalnoEPIC
Tie-breaking: When factors disagree, route UP one level. Better to over-spec than under-spec.
范围清晰度风险时长→ 级别
1个文件精确无影响TRIVIAL(微小)
2-5个文件清晰可恢复BASE(基础)
6-15个文件模糊重大可能DEEP(深度)
15+个文件未知关键EPIC(史诗)
平局处理: 当因素不一致时,升级一级。宁可选高规格也不要低规格。

Phase 2: Route to Handler

阶段2:路由到处理程序

TRIVIAL — Direct Execute

TRIVIAL — 直接执行

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
标准:1个文件,精确修改,无风险,<10行代码
处理程序:直接执行。无需BD,无需规格工件。

步骤:
1. 进行修改
2. 运行测试(如果存在)
3. 编写DONE.md记录修改内容

BASE — Plan + Implement

BASE — 规划+实现

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
标准:2-5个文件,范围清晰,风险可恢复
处理程序:轻量级规格 → 实现 → 验证

步骤:
1. 创建最小规格(5-10个要点+验收检查)
2. 实现修改
3. 运行标准化验证(测试、构建、代码检查)
4. bd create + bd close(单个条目跟踪)
5. 编写DONE.md记录修改内容+验证结果

DEEP — Design-to-BD Flow

DEEP — 设计到BD流程

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
标准:6-15个文件,范围模糊,风险重大
处理程序:设计转BD → Agent执行 → 验证

步骤:
1. 研究调度(2-3个并行`lev get`查询)
2. 设计文档(存储在$SESSION_DIR/design.md)
3. BD框架搭建(史诗任务+带依赖的子任务)
4. 基于轮次调度的Agent执行:
   - 轮次1:并行研究/搭建框架
   - 轮次2:并行实现
   - 轮次3:验证(必填)
5. 所有验证通过后执行bd close
6. 编写DONE.md记录史诗任务摘要+指令

EPIC — Full SDLC

EPIC — 完整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
标准:15+个文件,范围未知,风险关键,需多轮次
处理程序:思维议会 → 设计转BD → Agent执行 → ralph-tui

步骤:
1. 议会审议(多模态,参考thinking-parliament)
2. 带[A][B][C][V]工作流的设计转BD
3. 基于波浪式并行的Agent执行:
   lev exec --epic=<id> --dry-run    # 预览波浪式任务
   lev exec --epic=<id>              # 执行任务
4. Ralph验证循环:
   - 3轮魔鬼辩护式验证
   - 基于BD描述的任务特定验证
   - 需包含<promise>EPIC_COMPLETE</promise>
5. bd sync + git push
6. 编写DONE.md记录完整执行报告

Phase 3: Multi-Model Dispatch (when applicable)

阶段3:多模型调度(适用时)

For DEEP and EPIC levels, use multi-model dispatch for research/design:
bash
undefined
对于DEEP和EPIC级别,使用多模型调度进行研究/设计:
bash
undefined

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

使用opus模型综合研究结果生成设计

lev exec "Synthesize these research findings into a design..." --model=opus --adapter=cli
undefined
lev exec "Synthesize these research findings into a design..." --model=opus --adapter=cli
undefined

Phase 4: Completion Artifact

阶段4:完成工件

Every sidequest produces
$SESSION_DIR/DONE.md
:
markdown
undefined
每个sidequest都会生成
$SESSION_DIR/DONE.md
markdown
undefined

Sidequest Complete

Sidequest完成

Job: <original description>

任务:<原描述>

Level: <TRIVIAL|BASE|DEEP|EPIC>

级别:<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>
  1. <所需的手动步骤>
  2. <部署说明>
  3. <需监控的内容>

BD Tracking

BD跟踪

  • Epic: <id or "none">
  • Tasks closed: <list>
  • Tasks remaining: <list or "none">
undefined
  • 史诗任务:<ID或“无”>
  • 已关闭任务:<列表>
  • 剩余任务:<列表或“无”>
undefined

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
若分类不确定:
  └─→ 升级一级(宁可选高规格也不要低规格)

若执行中途失败:
  └─→ 编写STALLED.md,包含:
      - 已完成内容
      - 失败内容(错误详情)
      - 剩余内容
      - 建议的恢复步骤
  └─→ bd update <id> --status=blocked

若验证失败:
  └─→ 重试一次并尝试修复
  └─→ 若仍失败:升级到STALLED.md
  └─→ 绝不要关闭验证失败的任务

Integration Points

集成点

ToolWhen UsedPurpose
lev get
Phase 0Context gathering, prior art
bd create/close
BASE+Work tracking
lev exec
DEEP+Multi-model dispatch
thinking-parliament
EPICMulti-modal deliberation
design-to-bd
DEEP+Design → BD scaffolding
agentic-execution
DEEP+Turn-based parallel dispatch
ralph-tui
EPICAutonomous completion loop
工具使用时机用途
lev get
阶段0上下文收集、既有方案查询
bd create/close
BASE及以上工作跟踪
lev exec
DEEP及以上多模型调度
thinking-parliament
EPIC多模态审议
design-to-bd
DEEP及以上设计→BD框架搭建
agentic-execution
DEEP及以上轮次并行调度
ralph-tui
EPIC自主完成循环

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"
/sidequest fix typo in README.md line 42

→ 级别:TRIVIAL
→ 操作:修复拼写错误,无需测试
→ DONE.md:"修复拼写错误:README.md第42行的'recieve'改为'receive'"

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
/sidequest add rate limiting to the /api/login endpoint

→ 级别:BASE
→ 操作:规格定义(中间件位置、限制规则)→ 实现 → 测试
→ BD:单个条目跟踪该修改
→ DONE.md:修改的文件、测试结果、部署说明

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
/sidequest add WebSocket support for real-time notifications

→ 级别:DEEP
→ 操作:研究(3个模型)→ 设计 → BD框架 → 实现 → 验证
→ BD:包含4-6个任务+验证任务的史诗任务
→ DONE.md:架构决策、实现摘要、测试覆盖率

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
/sidequest redesign the entire auth system for multi-tenant support

→ 级别:EPIC
→ 操作:议会审议 → 设计 → BD [A][B][C][V]工作流 → Agent执行 → Ralph循环
→ BD:包含10+个跨工作流任务的史诗任务
→ DONE.md:完整执行报告+迁移指南

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.
  • 角色定义 - 明确操作范围,避免执行歧义。
  • 上下文增强 - 行动前捕获所需输入。
  • 输出结构化 - 标准化交付物,确保一致性复用。
  • 分步工作流 - 明确执行顺序,减少错误。
  • 边缘情况处理 - 记录假设不成立时的安全 fallback 方案。

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.
这些技术通过明确意图、输入、输出和 fallback 路径提高可靠性。保持本部分简洁且补充性,确保现有领域指导仍为核心。

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.
你是增强版prompt-architect,负责lev-orch-sidequest的确定性执行,同时保留现有工作流和约束。

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

边缘情况与Fallback

  • 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.
  • 若先决条件缺失,提供最小安全路径并请求缺失输入。
  • 若范围模糊,缩小到最高置信度的子任务。
  • 若请求的操作与现有约束冲突,解释并提供合规替代方案。