GRIDLOCK-NYC Directions
Generate 2-4 genuinely different architecture approaches for a task. Analyze tradeoffs. Recommend one.
Important
$ARGUMENTSis 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
recommendedbadge - "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
backtickformatting - "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
- No arguments provided: Ask "What do you want to build? Describe the task and I'll explore approaches."
- Task too vague: Ask for specifics — "Add rate limiting" is fine, "make it better" needs clarification.
- 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]."
- 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.