Plan directions

Directions

Generate 2-4 genuinely different architecture approaches for a task. Analyze tradeoffs. Recommend one.

Important

• $ARGUMENTS is the task description. If empty, ask the user what they want to build
• Approaches must be GENUINELY DIFFERENT strategies, not minor variations of the same idea
• Every claim must be grounded in the actual codebase — read existing code before proposing
• Reuse existing infrastructure. If Redis is already configured, prefer Redis-based solutions. If the project uses Express middleware, propose middleware-based approaches
• Be honest about tradeoffs. Every approach has real downsides — state them clearly
• Take your time exploring the codebase before generating approaches

Instructions

Step 1: Understand the task

Read $ARGUMENTS. Identify:

• What needs to be built or changed
• What constraints exist (performance, backwards compatibility, timeline)
• What "done" looks like

Step 2: Explore the codebase

Use Explore agents or direct reads to understand:

• Current architecture (framework, patterns, conventions)
• Existing infrastructure that could be reused (caches, queues, databases, middleware)
• Related implementations already in the codebase
• Test patterns and coverage

Step 3: Generate approaches

Produce 2-4 approaches. For each:

Name — Short descriptive name (e.g., "Redis sliding window", "In-process token bucket")

Description — 2-3 sentences explaining the approach

Pros:

• Concrete benefits grounded in this codebase

Cons:

• Honest downsides and risks

Dimensions:

• Complexity: low / medium / high
• New dependencies: list them or "none"
• Files touched: estimated count and which ones
• Time to ship: rough estimate
• Distributed: yes / no (if relevant)
• Migration needed: yes / no

Step 4: Recommend

Pick one approach. State why in 1-2 sentences. Reference the specific codebase context that tips the decision (e.g., "You already have Redis configured in src/lib/redis.ts, so the Redis approach adds no new infra").

Step 5: Output

Use the card-based layout below. This is the EXACT format — follow it precisely.

Rules:

• Show the top 2 approaches as full cards (the best two)
• If 3-4 approaches exist, collapse the extras into a one-line summary after the cards
• Each approach gets ONE badge on the right: pick the most useful label (e.g., fast to ship, recommended, most scalable, simplest, battle-tested)
• The recommended approach gets the recommended badge
• "for" items are pros. "against" items are cons. 3 of each, max
• The metrics row at the bottom of each card uses 4 columns: complexity, ops burden, scale ceiling, time to ship
• Use box-drawing line ─── between cards

Format:

built [N] approaches for: [task summary]
explored [list of key files/areas]. pick a direction.

───────────────────────────────────────────────────────────────

 A   [Approach Name]                              [badge]

   for                              against
   [pro 1]                          [con 1]
   [pro 2]                          [con 2]
   [pro 3]                          [con 3]

   complexity   ops burden   scale ceiling   time to ship
   [value]      [value]      [value]         [value]

───────────────────────────────────────────────────────────────

 B   [Approach Name]                         [recommended]

   for                              against
   [pro 1]                          [con 1]
   [pro 2]                          [con 2]
   [pro 3]                          [con 3]

   complexity   ops burden    scale ceiling   time to ship
   [value]      [value]       [value]         [value]

───────────────────────────────────────────────────────────────

+ [N] more: C ([brief desc]), D ([brief desc])

pick direction: [A] [B] [C] [D]   or describe what matters most

Formatting details:

• Approach letter and name: use bold for the letter
• Badge: use backtick formatting
• "for" column: regular text
• "against" column: regular text
• Metrics row: use a fixed-width layout with spaces to align columns
• Align the "for" and "against" columns — "against" starts at roughly column 35
• Keep each pro/con to one short line (< 30 chars ideally)
• The collapsed "+N more" line gives just the name and a parenthetical one-liner

Step 6: Wait for pick

End with exactly: pick direction: [A] [B] [C] [D] or describe what matters most

When the user picks a letter, begin implementation immediately. When the user describes what matters, re-rank or regenerate approaches optimized for their priority.

Error Handling

1. No arguments provided: Ask "What do you want to build? Describe the task and I'll explore approaches."
2. Task too vague: Ask for specifics — "Add rate limiting" is fine, "make it better" needs clarification.
3. Only one viable approach: Report it honestly — "I explored alternatives but [approach] is the only reasonable option because [reason]. Here's why the others don't work: [list]."
4. Codebase too large to fully explore: Focus on the areas most relevant to the task. State what you explored and what you didn't.

Examples

Example 1: Rate limiting

Input: /plan-directions add rate limiting to the auth endpoints

Output:

built 3 approaches for: rate limiting on auth endpoints
explored src/middleware/, src/lib/redis.ts, src/routes/auth.ts. pick a direction.

───────────────────────────────────────────────────────────────

 A   In-process token bucket                     `fast to ship`

   for                              against
   no new dependencies              per-process only
   works with existing Express      no shared state across instances
   sub-millisecond overhead         resets on restart

   complexity   ops burden   scale ceiling   time to ship
   low          none         single process  2-4 hours

───────────────────────────────────────────────────────────────

 B   Redis sliding window                       `recommended`

   for                              against
   shared across instances          adds ioredis dependency
   survives restarts                Redis must stay up
   battle-tested pattern            slightly more complex

   complexity   ops burden    scale ceiling   time to ship
   medium       Redis managed 100k+ users     1-2 days

───────────────────────────────────────────────────────────────

+ 1 more: C (Postgres advisory locks — heavyweight but no new infra)

pick direction: [A] [B] [C]   or describe what matters most

Example 2: Single viable option

Input: /plan-directions migrate from Jest to Vitest

Output: "Only one viable approach: incremental migration with dual config. Here's why big-bang and wrapper approaches don't work for this codebase: [reasons]." Then show a single card with the approach details.