plan-feature

name	plan-feature
description	Create complete development plan with parallel exploration
model	opus
argument-hint	name=<feature-name>

YOU ARE EXECUTING THE /plan-feature SKILL. The user triggered this skill. Follow ALL instructions below step by step. Do NOT treat this as a freeform conversation - execute the skill workflow.

Follow CLAUDE.md rules.

Output file: docs/plan-features/{$ARGUMENTS.name}_FEATURE.md (uppercase)

Ultra Think Strategy

Ultra think before each phase transition:

• After exploration results: reflect on completeness before planning
• Before writing spec: consider architecture, edge cases, future maintainability
• After validation: ensure the plan is comprehensive and actionable

---

1. GATHER REQUIREMENTS

Ask user for:

• Detailed feature description
• Mockups/screenshots if available
• Business rules and edge cases
• Integrations with existing features

Do not proceed until requirements are clear.

---

1.5 CLARIFY DETAILS

Use AskUserQuestion to clarify before exploration:

Must clarify (if not specified)

• Error messages for user-facing failures?
• Default values for new fields?
• Validation rules?
• What triggers state changes?

UX Decisions (if not specified)

• What happens on success? (toast, redirect, refresh?)
• What happens on error?
• Confirmation dialogs needed?

Permissions (if not specified)

• Who can perform each action?
• RLS policy rules (if the DB uses RLS)?

Do not proceed until critical details are clarified.

---

2. EXPLORE (PARALLEL)

Launch focused agents in a single message (parallel execution). There is no upper limit on agent count. Spawn one agent per distinct concern, area, or file-cluster the feature actually spans, and scale up freely with its breadth. The lists below are a starting menu, not a quota.

Agent-count principle

• You decide the count from the actual scope. Assess how many distinct concerns / areas / file-clusters the feature really spans on this codebase, and launch one focused agent for each. Do not anchor to a fixed number or to file counts.
• No ceiling, real floor. Use at least 2 agents per domain in scope (1 only for a genuinely trivial single-file change). Above that floor there is no maximum.
• One distinct focus per agent. Split by concern so two agents never run the same search.
• No batching. Launch them all in one message.

Backend Agents (≥2 when backend in scope, one per distinct concern, no maximum)

1. Domain & data flow - explore-codebase: "Find entities, repository interfaces, value objects, and DTOs related to [feature] in backend/internal/domain/ and backend/internal/application/dto/"
2. Usecases & business logic - explore-codebase: "Find usecases related to [feature] in backend/internal/application/usecases/. Read their Execute methods, dependencies, and error handling"
3. Handlers & routing - explore-codebase: "Find HTTP handlers and routes related to [feature] in backend/internal/presentation/. Check middleware, validation, response patterns"
4. Infrastructure & services - explore-codebase: "Find repo implementations, external service adapters, and config related to [feature] in backend/internal/infrastructure/"
5. Similar patterns - explore-codebase: "Find the most similar existing feature to [feature] in backend/. I need to replicate its patterns"

Frontend Agents (≥2 when frontend in scope, one per distinct concern, no maximum)

1. Components & UI - explore-codebase: "Find components related to [feature] in frontend/src/components/. Check props, state, Shadcn UI usage"
2. Hooks & state - explore-codebase: "Find hooks, React Query calls, and state management related to [feature] in frontend/src/hooks/ and frontend/src/lib/"
3. Pages & routing - explore-codebase: "Find pages and layouts related to [feature] in frontend/src/app/. Check route structure, data fetching, i18n"
4. Types & API layer - explore-codebase: "Find TypeScript types, API client functions related to [feature] in frontend/src/types/ and frontend/src/lib/"
5. Similar patterns - explore-codebase: "Find the most similar existing feature to [feature] in frontend/src/. I need to replicate its patterns"

The supporting agents below fan out the SAME way: one agent per distinct concern, no maximum.

Database Agents (≥1 when DB in scope, one per distinct concern, no maximum)

1. Schema & relationships - explore-db: "dev - Map tables and foreign keys related to [feature]: columns, types, FK relationships"
2. Constraints & policies - explore-db: "dev - Inspect constraints and RLS policies (if used) on tables related to [feature]"

Documentation Agents (≥1 when external docs needed, one per library/feature, no maximum)

1. [library A] - explore-docs: "[library A] [specific feature] documentation"

Web-research Agents (≥1 when external research needed, one per topic, no maximum)

1. [topic A] - websearch: "[topic A] best practices 2025 2026"

---

2.5 POST-EXPLORATION CHECK

After agents return, verify coverage across all dimensions:

1. Full code path traced? Can I trace handler -> usecase -> repository -> DB (backend) and page -> hook -> API -> component (frontend)? If gaps -> launch targeted explore-codebase
2. Similar patterns identified? Do I have a reference implementation to follow? If not -> launch explore-codebase
3. Data model complete? Tables, columns, relationships, policies known? If not -> launch additional parallel explore-db agents
4. Library docs sufficient? If not -> launch additional parallel explore-docs agents

Do NOT proceed with incomplete context.

---

3. VALIDATE ARCHITECTURE

Display architecture plan:

## Architecture Plan - [Feature Name]

### Database
- Tables to create: [list with columns]
- Tables to modify: [changes]
- Policies needed (if the DB uses RLS)

### Backend (Go Clean Architecture)
- Entities: [list]
- Usecases: [list with descriptions]
- Handlers: [endpoints]
- Code to reuse: [from exploration]

### Frontend (Next.js)
- Types, Components, Hooks, Pages
- Code to reuse: [from exploration]

### Libraries / Best Practices
- [from exploration]

Ask with AskUserQuestion: "Validate this architecture?"

• "Validate"
• "Modify"

---

4. WRITE SPEC FILE

After validation, write complete spec to docs/plan-features/{$ARGUMENTS.name}_FEATURE.md.

Use the template structure from templates/feature-spec-template.md.

Structure:

1. Overview (objective, summary, tech stack)
2. Context and Motivation
3. Functional Specifications (detailed behavior, rules, edge cases)
4. Technical Architecture (existing files to modify, new files to create)
5. Configuration (app.yaml for thresholds, limits, feature flags - NO hardcoded values)
6. Database (migrations, columns, policies)
7. Backend Implementation (phases: Domain -> Infrastructure -> Application -> Presentation)
8. Frontend Implementation (phases: Types/API -> Hooks -> Components -> Pages)
9. Execution Plan (checkboxes for each task)
10. Important Notes (compatibility, performance, security)

Backend Phase Rules

• Order: Domain -> Infrastructure -> Application -> Presentation
• Max 5 items per phase - split if more
• Separate CRUD usecases from business logic usecases
• Each phase must compile independently

---

5. DELIVER

• Confirm file created
• Summarize the phases
• Indicate next steps:
  • /dev spec=docs/plan-features/[name]_FEATURE.md phase=1
  • /dev spec=docs/plan-features/[name]_FEATURE.md phase=8
  • Or run the whole spec end-to-end: /dev-all spec=docs/plan-features/[name]_FEATURE.md

---

Rules

• EXPLORE FIRST - parallel exploration before the plan
• CONTEXT IS KEY - spec must be detailed enough for a new session
• VALIDATE - user validation before writing spec
• CHECKBOXES - execution plan with checkboxes to track progress