/plan-feature — Feature Planning

Create a detailed implementation plan for a new feature, producing a structured spec that can be handed off to /dev.

Process

1. Requirements gathering

• •Clarify the feature request with the user
• •Identify acceptance criteria
• •Determine scope boundaries (what's in, what's out)

2. Codebase analysis

• •Explore the current codebase to understand existing patterns
• •Identify files and modules that will be affected
• •Check for existing utilities or components that can be reused
• •Look for similar features already implemented

3. Technical design

• •Choose the implementation approach
• •Define the data model changes (if any)
• •Plan the API surface (routes, server actions, etc.)
• •Design the UI components (if applicable)
• •Identify third-party integrations needed

SaaS-specific design considerations

Subscription gating:

• •Which subscription tier(s) can access this feature? (free / pro / enterprise)
• •Is this a hard gate (blocked) or soft gate (limited usage)?
• •Where is the subscription check enforced? (middleware, server action, component)
• •What does the upgrade prompt look like?

Multi-tenancy:

• •Is this feature user-scoped or organization-scoped?
• •RLS implications: what policies are needed?
• •Does the data model need org_id foreign keys?
• •How does this interact with existing org member roles?

Billing impact:

• •Does this feature change metered usage?
• •Are new Stripe products/prices needed?
• •Does the pricing page need updating?
• •Any proration or plan change implications?

Auth requirements:

• •Does this feature require authentication?
• •What role/permission level is needed?
• •Are there public (unauthenticated) views?
• •OAuth or email verification requirements?

4. Implementation plan

Produce a phased plan with this structure:

## Feature: [name]

### Overview
Brief description of what this feature does.

### Phase 1: [Foundation — DB & Types]
- [ ] Task 1 — file(s) affected, what changes
- [ ] Task 2 — ...

### Phase 2: [Core logic — Server Actions & API]
- [ ] Task 3 — ...
- [ ] Task 4 — ...

### Phase 3: [UI / Integration]
- [ ] Task 5 — ...

### Phase 4: [Polish / Edge cases]
- [ ] Task 6 — ...

### SaaS Feature Checklist
- [ ] RLS policies cover all CRUD operations
- [ ] Subscription tier gating implemented
- [ ] Audit logging for important actions
- [ ] Error states (auth, permission, subscription, network)
- [ ] Loading states (skeleton/spinner)
- [ ] Mobile responsive
- [ ] Empty states with helpful guidance
- [ ] Rate limiting (if applicable)

### Risks & open questions
- ...

Rules

• •Do NOT write code during planning — this is a planning-only skill
• •Be specific about files and changes, not vague
• •Consider error handling, loading states, and edge cases
• •Flag decisions that need user input
• •Keep the plan realistic and achievable
• •Always address subscription gating and multi-tenancy for new features