Any Percent

Any%

Explore different approaches in parallel - no restrictions, fastest path to comparing real implementations. Each variant uses hosted LLM for code generation.

Announce: "I'm using speed-run:any% for parallel exploration via hosted LLM."

Core principle: When unsure of the best architecture, implement multiple approaches fast via hosted LLM and let real code + tests determine the winner.

When to Use

• Unsure which architectural approach is best
• Want to compare 2-5 different designs quickly
• "Try both approaches", "explore both", "not sure which way"
• Want token-efficient parallel exploration

Workflow Overview

Directory Structure

docs/plans/<feature>/
  design.md                  # Shared context
  speed-run/
    any-percent/
      variant-<slug>/
        plan.md              # Implementation plan for this variant
      result.md              # Final report

.worktrees/
  speed-run-variant-<slug>/  # Variant worktree

Phase 1: Quick Context

Gather just enough to generate approaches (1-2 questions max):

• What are you building?
• Any hard constraints? (language, framework, infrastructure)

Do NOT brainstorm extensively. The point of any% is to explore fast, not deliberate slowly.

Phase 2: Generate Approaches

Identify the primary architectural axis (biggest impact decision):

• Storage engine (SQL vs NoSQL vs file-based)
• Framework (Express vs Fastify vs Hono)
• Architecture pattern (monolith vs microservices vs serverless)
• State management approach
• Auth strategy

Generate 2-5 approaches along that axis:

Based on the requirements, here are 3 approaches to explore:

1. variant-sqlite: SQLite storage with query builder
   → Pros: Simple, embedded, zero config
   → Cons: Single writer, no replication

2. variant-postgres: PostgreSQL with ORM
   → Pros: Scalable, ACID, rich queries
   → Cons: External dependency, more setup

3. variant-redis: Redis with persistence
   → Pros: Fast, built-in pub/sub
   → Cons: Memory-bound, limited queries

All will be implemented via hosted LLM and tested.
Spawning 3 parallel variants now.

Variant limits: Max 5-6. Don't do full combinatorial explosion:

1. Identify the primary axis
2. Create variants along that axis
3. Fill secondary slots with natural pairings

Phase 3: Plan + Implement (Parallel)

Setup worktrees:

.worktrees/speed-run-variant-sqlite/
.worktrees/speed-run-variant-postgres/
.worktrees/speed-run-variant-redis/

Branches:
<feature>/speed-run/variant-sqlite
<feature>/speed-run/variant-postgres
<feature>/speed-run/variant-redis

CRITICAL: Dispatch ALL variants in a SINGLE message

<single message>
  Task(variant-sqlite, run_in_background: true)
  Task(variant-postgres, run_in_background: true)
  Task(variant-redis, run_in_background: true)
</single message>

Variant agent prompt:

You are implementing the [VARIANT-SLUG] variant in a speed-run any% exploration.
Other variants are being implemented in parallel with different approaches.

**Your working directory:** /path/to/.worktrees/speed-run-variant-<slug>
**Design context:** docs/plans/<feature>/design.md
**Your plan location:** docs/plans/<feature>/speed-run/any-percent/variant-<slug>/plan.md

**Your approach:** [APPROACH DESCRIPTION]
  - [Key architectural decisions for this variant]
  - [Technology choices specific to this variant]

**Your workflow:**
1. Create implementation plan for YOUR approach
   - Save to plan location above
   - Focus on what makes this approach unique
2. For each implementation task, use hosted LLM for first-pass code generation:
   - Write a contract prompt (DATA CONTRACT + API CONTRACT + ALGORITHM + RULES)
   - Call: mcp__speed-run__generate_and_write_files
   - Run tests
   - Fix failures with Claude Edit tool (surgical 1-4 line fixes)
   - Re-test until passing
3. Follow TDD
4. Use verification before claiming done

**Code generation rules:**
- Use mcp__speed-run__generate_and_write_files for algorithmic code
- Use Claude direct ONLY for surgical fixes and multi-file coordination
- Write contract prompts with exact data models, routes, and algorithm steps

**Report when done:**
- Plan created: yes/no
- All tasks completed: yes/no
- Test results (output)
- Files changed count
- Hosted LLM calls made
- Fix cycles needed
- What makes this variant's approach unique
- Any issues encountered

Phase 4: Evaluate

Step 1: Gate check - All tests pass

Step 2: Run same scenario tests against all variants

Use scenario-testing skill. Same scenarios, different implementations.

Step 3: Fresh-eyes on survivors

Fresh-eyes review of variant-sqlite (N files)...
Fresh-eyes review of variant-postgres (N files)...

Step 4: Invoke Judge Skill

CRITICAL: Invoke speed-run:judge now.

The judge skill contains the full scoring framework with checklists. Invoking it fresh ensures the scoring format is followed exactly.

Invoke: speed-run:judge

Context to provide:
- Variants to judge: variant-sqlite, variant-postgres, variant-redis
- Worktree locations: .worktrees/speed-run-variant-<slug>/
- Test results from each variant
- Scenario test results
- Fresh-eyes findings
- Speed-run metrics: hosted LLM calls, fix cycles, generation time per variant

The judge skill will:

1. Fill out the complete scoring worksheet for each variant
2. Fill out the Speed-Run Metrics table
3. Build the scorecard with integer scores (1-5, no half points)
4. Check hard gates (Fitness Δ≥2, any score=1)
5. Announce winner with rationale (including token efficiency)

Do not summarize or abbreviate the scoring. The judge skill output should be the full worksheet.

Any%-specific context: In any%, variants explore different architectural approaches, so Fitness differences are expected and valid. A Fitness gap here reflects different design trade-offs, not deviation from a shared design. Weight Craft and Spark higher when approaches are fundamentally different.

Phase 5: Completion

Winner: Use finish-branch

Losers: Cleanup

git worktree remove .worktrees/speed-run-variant-sqlite
git worktree remove .worktrees/speed-run-variant-redis
git branch -D <feature>/speed-run/variant-sqlite
git branch -D <feature>/speed-run/variant-redis

Write result.md:

# Any% Results: <feature>

## Approaches Explored
| Variant | Approach | Tests | Scenarios | Fresh-Eyes | LLM Calls | Result |
|---------|----------|-------|-----------|------------|-----------|--------|
| variant-sqlite | Embedded SQL | 18/18 | 5/5 | 0 issues | 3 | WINNER |
| variant-postgres | External DB + ORM | 20/20 | 5/5 | 1 minor | 4 | eliminated |
| variant-redis | In-memory + persist | 16/16 | 4/5 | 2 issues | 5 | eliminated |

## Winner Selection
Reason: Simplest architecture, zero external dependencies, all scenarios pass

## Token Savings
Estimated savings vs Claude direct: ~60% on code generation

Save to: docs/plans/<feature>/speed-run/any-percent/result.md

Skill Dependencies

Common Mistakes

Too many variants

• Problem: Combinatorial explosion, wasted compute
• Fix: Cap at 5-6, pick primary axis only

Extensive brainstorming before exploring

• Problem: Defeats the purpose of any% (fast exploration)
• Fix: 1-2 questions max, then generate and go

Using Claude direct for all code generation

• Problem: No token savings, defeats speed-run purpose
• Fix: Variants MUST use hosted LLM for first-pass generation

Dispatching variants in separate messages

• Problem: Serial instead of parallel
• Fix: ALL Task tools in a SINGLE message

Skipping scenario tests

• Problem: Can't compare variants fairly
• Fix: Same scenarios against all variants

Forgetting cleanup

• Problem: Orphaned worktrees
• Fix: Always cleanup losers, write result.md