Plan Writing Elite

A practical skill for breaking down work into clear, actionable implementation plans — covering task decomposition, verification criteria, dependency identification, and concise planning that keeps teams aligned without over-documenting.

When to Use This Skill

Choose Plan Writing Elite when you need to:

• Break down a feature into implementation tasks with clear criteria
• Write plans that are specific enough for any team member to execute
• Define verification steps for each task to confirm completion
• Identify dependencies and ordering constraints
• Create plans that balance detail with brevity

Consider alternatives when:

• You need strategic product planning (use a product strategy skill)
• You need project timelines and Gantt charts (use a PM skill)
• You need architecture design (use an architecture skill)

Quick Start

Copy
# Create an implementation plan
claude "Write a task breakdown for adding Stripe subscription billing to our SaaS app. We use Next.js, Prisma, and PostgreSQL."

Copy
# Plan: Stripe Subscription Billing

## Tasks

### 1. Add Stripe SDK and environment config
- Install `stripe` and `@stripe/stripe-js` packages
- Add `STRIPE_SECRET_KEY`, `STRIPE_PUBLISHABLE_KEY`,
  `STRIPE_WEBHOOK_SECRET` to `.env`
- Create `lib/stripe.ts` with initialized Stripe client
- **Verify**: `stripe.customers.list()` returns without error

### 2. Create subscription database schema
- Add Prisma models: `Subscription`, `Price`, `Product`
- Subscription: userId, stripeSubscriptionId, status,
  currentPeriodEnd, priceId
- Run migration: `npx prisma migrate dev`
- **Verify**: Tables exist in PostgreSQL, Prisma Studio shows them

### 3. Build pricing page with Stripe Checkout
- Create `/pricing` page with plan comparison
- Add "Subscribe" button that calls `POST /api/checkout`
- API route creates Stripe Checkout session with price ID
- Redirect to Stripe Checkout
- **Verify**: Clicking Subscribe opens Stripe Checkout
  with correct plan and price

### 4. Implement Stripe webhook handler
- Create `POST /api/webhooks/stripe` endpoint
- Handle events: `checkout.session.completed`,
  `invoice.paid`, `customer.subscription.updated`,
  `customer.subscription.deleted`
- Update Subscription record on each event
- **Verify**: Complete a test purchase in Stripe test mode,
  verify Subscription record is created in DB

### 5. Add subscription status checks
- Create `getSubscription(userId)` helper
- Add middleware to protect premium routes
- Show subscription status on user dashboard
- **Verify**: Free user sees upgrade prompt,
  subscribed user accesses premium features

### 6. Build subscription management portal
- Create "Manage Subscription" button
- Generate Stripe Customer Portal session
- Handle portal return URL
- **Verify**: User can cancel, upgrade, and update
  payment method through the portal

## Dependencies
1 → 2 → 3 → 4 → 5 → 6 (sequential)
Tasks 3+4 can be partially parallel (API + webhook)

## Risks
- Webhook delivery failures: implement retry + idempotency
- Subscription status sync: webhook is source of truth, not client

Core Concepts

Task Decomposition Rules

Rule	Description	Example
Atomic	Each task produces one deliverable	"Create webhook handler"
Verifiable	Each task has a pass/fail check	"Test purchase creates DB record"
Time-Bounded	Each task takes 1-8 hours	Split if > 8 hours
Independent	Minimize dependencies between tasks	Note dependencies explicitly
Named	Task name starts with a verb	"Create", "Add", "Build"

Verification Criteria

Copy
## Writing Good Verification Steps

### ✅ Good (Observable, Specific)
"Clicking Subscribe opens Stripe Checkout with the
correct plan name and price displayed"

### ❌ Bad (Vague, Unverifiable)
"Stripe integration works correctly"

### Formula
**Verify**: [Action] produces [specific observable result]

### Examples by Type
- API: "POST /api/checkout returns 200 with session URL"
- Database: "Subscription record appears in Prisma Studio
  with status='active'"
- UI: "Pricing page shows 3 plans with monthly/annual toggle"
- Integration: "Completing test purchase in Stripe dashboard
  triggers webhook and creates DB record within 5 seconds"

Dependency Mapping

Copy
## Dependency Types

### Sequential (must be in order)
1 → 2 → 3: Schema before API before UI

### Parallel (can run simultaneously)
3 | 4: Pricing page and webhook can be built in parallel

### External (waiting on something outside your control)
5 depends on: Stripe account approval (applied, ~2 days)

### Notation
→ : strict dependency (must complete before next)
| : can run in parallel
⊕ : merge point (parallel paths converge)

Configuration

Parameter	Description	Example
granularity	Task decomposition level	"fine" / "coarse"
include_verify	Add verification criteria	true
include_deps	Map task dependencies	true
estimate	Include time estimates	true
format	Plan output format	"markdown" / "linear"

Best Practices

1. Every task must start with a verb — "Authentication" is not a task. "Implement session-based authentication" is a task. Verbs force specificity and make it clear what action to take.

2. Write verification criteria before starting implementation — If you can't define how to verify a task is done, the task isn't clear enough. Verification criteria are your test cases — define them upfront.

3. Split tasks that take longer than one day — A task that takes 3 days is actually 3-5 smaller tasks bundled together. Break it apart. Each piece should be completable in a single focused session.

4. Name dependencies explicitly, don't assume order — "Task 3 requires Task 2's database schema" is explicit. Listing tasks 1-6 and assuming sequential order is implicit and often wrong — tasks 3 and 4 might be parallel.

5. Include risks at the end, not per task — Listing risks alongside every task clutters the plan. Aggregate risks at the bottom with mitigation strategies. This keeps the task list clean and risk awareness concentrated.

Common Issues

Plans are too detailed and become specifications — A plan tells you what to build and in what order. A specification tells you exactly how to build it. Plans should be 1 page; specs can be 10 pages. If your plan has implementation code, it's a spec.

Verification criteria are vague or missing — "It works" is not a verification criterion. Every task needs a specific, observable check. If you can't verify it, you don't know when it's done, and neither does anyone reviewing your work.

Dependencies create a purely sequential plan — If every task depends on the previous one, nothing can be parallelized. Look for tasks that share a dependency but are independent of each other (building the pricing page and the webhook handler can happen simultaneously).