Concise Planning Studio

A practical skill for turning user requests into minimal, actionable implementation plans — covering context scanning, constraint identification, atomic step decomposition, and single-pass planning that avoids analysis paralysis.

When to Use This Skill

Choose Concise Planning Studio when you need to:

• Break down a feature request into atomic implementation steps
• Create a focused plan without over-engineering the design phase
• Identify constraints quickly from existing code and documentation
• Produce a plan that can be executed immediately without further discussion
• Avoid spending more time planning than implementing

Consider alternatives when:

• You need architectural design decisions (use an architecture skill)
• You need project roadmaps or timelines (use a PM skill)
• You need detailed technical specifications (use a tech spec skill)

Quick Start

Copy
# Generate a concise implementation plan
claude "Plan how to add a 'forgot password' feature to our Express app. We use PostgreSQL, Resend for email, and React frontend."

Copy
# Plan: Forgot Password Feature

## Context (scanned)
- Backend: Express + PostgreSQL (Prisma ORM)
- Email: Resend SDK already configured in src/lib/email.ts
- Auth: JWT-based, existing login/register routes in src/routes/auth.ts
- Frontend: React, existing LoginForm component

## Steps

1. **Add `password_reset_tokens` table**
   - Columns: id, user_id, token (UUID), expires_at, used
   - Migration: `npx prisma migrate dev --name add_password_reset`

2. **Create `POST /auth/forgot-password` endpoint**
   - Input: email
   - Generate UUID token, store with 1-hour expiry
   - Send reset link via Resend using existing email.ts
   - Always return 200 (prevent email enumeration)

3. **Create `POST /auth/reset-password` endpoint**
   - Input: token, new_password
   - Validate token exists, not expired, not used
   - Hash password, update user, mark token used

4. **Add ForgotPasswordForm component**
   - Email input + submit button
   - Success: "If that email exists, we sent a reset link"

5. **Add ResetPasswordForm component**
   - Read token from URL params
   - New password + confirm fields
   - On success: redirect to login

## Risks
- Rate limit the forgot-password endpoint (5/hour/IP)
- Token must be single-use (prevent replay)

Core Concepts

Planning Workflow

Phase	Time Budget	Action
Context Scan	2 minutes	Read README, check stack, scan code
Constraint ID	1 minute	Identify tech, patterns, limits
Step Decomposition	3 minutes	Break into atomic steps
Risk Check	1 minute	Identify what could go wrong
Output	1 minute	Write clean, ordered plan

Step Quality Rules

Copy
## What Makes a Good Step

### ✅ Good Step
"Add `password_reset_tokens` table with columns: id, user_id,
token (UUID), expires_at (timestamp), used (boolean).
Run: npx prisma migrate dev --name add_password_reset"

Why: Specific, actionable, includes the command to run.

### ❌ Bad Step
"Set up the database for password resets"

Why: Vague, doesn't specify what table/columns, not actionable.

### Rules
1. Each step changes exactly one thing
2. Each step names specific files or commands
3. Each step can be verified (how do you know it worked?)
4. Steps are ordered by dependency, not importance
5. No step takes more than 30 minutes to implement

Constraint Detection

Copy
## What to Scan Before Planning

### Always Check
- README.md — project overview, tech stack
- package.json / requirements.txt — dependencies
- Existing code patterns — naming, structure, style

### Check If Relevant
- .env.example — required environment variables
- CI/CD config — what tests run, what's deployed
- Existing tests — testing patterns and frameworks

### Questions to Ask (maximum 1-2)
Only ask when the answer changes the plan:
- "Should resets expire after 1 hour or 24 hours?"
- "Do we need to support SSO users too?"

Do NOT ask:
- "Should I use UUID for tokens?" (yes, obviously)
- "What database should I use?" (you can see it in the code)

Configuration

Parameter	Description	Example
max_steps	Maximum number of plan steps	7
max_questions	Maximum clarifying questions to ask	2
include_risks	Add risk assessment section	true
include_commands	Include exact commands to run	true
time_budget	Minutes to spend on planning	8

Best Practices

1. Spend 10% of the time planning, 90% implementing — If the task takes 2 hours, spend 12 minutes planning. Over-planning is a procrastination trap. A good-enough plan executed immediately beats a perfect plan delivered next week.

2. Ask at most 1-2 clarifying questions — If you need more than 2 questions, you're over-thinking it. Make reasonable assumptions, document them, and let the user correct you during implementation if needed.

3. Order steps by dependency, not by importance — Database migration must happen before the API endpoint that uses the table. The frontend form must exist before you can test the flow. Dependencies dictate order; importance dictates priority if steps are independent.

4. Include the verification for each step — Every step should answer: "How do I know this worked?" For a database migration: "Run npx prisma studio and verify the table exists." For an endpoint: "Run curl -X POST localhost:3000/auth/forgot-password -d '{\"email\":\"[email protected]\"}' and verify 200 response."

5. Name specific files and functions, not abstractions — "Add the endpoint in src/routes/auth.ts" is better than "Create the forgot password API." Specific references eliminate ambiguity and speed up implementation.

Common Issues

Plans are too granular and become micro-management — A plan with 25 steps for a simple feature creates overhead. Keep plans to 5-7 steps. If a step is too large, split it into at most 2-3 sub-steps, but don't decompose every function call.

Plans don't account for existing code patterns — A plan that introduces a new pattern (e.g., different folder structure, new error handling style) when the codebase already has established patterns creates inconsistency. Always scan existing code before planning.

Plans become outdated before implementation starts — If you plan today and implement next week, the codebase may have changed. Plans should be executed immediately or within 24 hours. For longer-term work, create a high-level outline and plan the details just before implementation.