# Plan Directions > Generate 2-4 concrete architecture approaches for a given task, with tradeoff analysis and a recommendation. Use when user says 'directions', 'what are my options', 'compare approaches', 'how should I build this', 'architecture options', 'design options', or 'explore approaches'. Do NOT use for code review (use code-review for that). Do NOT use for investigating bugs (use postmortem for that). - Skill: `gridlock-nyc/plan-directions` (Agent Skill) - Install (CLI): `npx skillmds@latest add gridlock-nyc/plan-directions` - Raw SKILL.md: https://api.skillmd.com/api/skills/gridlock-nyc/plan-directions/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: GRIDLOCK-NYC (https://skillmd.com/u/gridlock-nyc) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gridlock-nyc/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.