FeaturePlanningAutoPilot

A general-purpose feature development planning skill. Used to generate executable, verifiable, and iterative development plans before coding, and to automatically capture lessons learned after each conversation.

This Skill standardizes the "analyze first → plan next → implement last" approach. It applies to frontend, backend, full-stack, API integration, SQL migrations, and mobile page refactoring tasks.

1) When to Use

Activate this Skill when the user expresses any of the following intentions:

• "Analyze before writing code"
• "Give me a plan first" / "Break it into steps" / "Execute in phases"
• "Ensure correctness and feasibility"
• "Create a reusable implementation blueprint"

2) Expected Outputs

Every planning session must produce the following four deliverables:

1. Scope Definition: Clearly state what is and is not included in this task.
2. Execution Plan: 3–9 verifiable steps in clear sequence.
3. Risks & Rollback: Key risk points and a minimal rollback strategy.
4. Acceptance Checklist: Actionable verification items (APIs, pages, logs, builds, tests).

3) Standard Workflow (Must Follow in Order)

Phase A – Quick Clarification

• Restate the goal in 1–2 sentences
• Confirm constraints: tech stack, directory, whether API/DB changes are allowed, timeline
• If information is missing: ask at most 1–3 key questions; default when possible

Phase B – Context Scan

Complete at minimum the following checks before producing a plan:

• Location of relevant pages / APIs / services
• Data sources and state transitions (e.g., Pending Delivery → Pending Inbound → Completed)
• Existing similar implementations (prefer reuse)
• List of files likely to be affected

Phase C – Plan Drafting

Plan requirements:

• 3–9 steps, each with a concise 3–7 word action title
• Every step must be verifiable (has a "definition of done")
• Only 1 step may be in-progress at a time
• State prerequisites for external dependencies or database changes

Phase D – Implementation & Validation

• Execute the plan step by step; update status after each step
• Perform at least one local validation per phase
• Before finishing, run a minimum viable acceptance check (build / key path click-through / API response)

Phase E – Lessons Captured (Auto-Iterate)

At the end of the conversation, append three categories of experience to evolution.json:

• preferences: User's preferred output style or delivery format
• fixes: Issues encountered this session and how they were resolved
• custom_prompts: Strong prompts that can be reused directly next time

Also sync the learnings back into the "Experience Enhancements" section of SKILL.md.

4) Plan Template (Ready to Reuse)

## Feature Development Plan (AutoPilot)

### 0. Goal & Scope
- Goal:
- Included in this task:
- Excluded from this task:
- Prerequisites:

### 1. Execution Steps
1. [ ] Review current state and dependencies
   - Definition of done: Relevant files and data flow located
2. [ ] Design minimal-change solution
   - Definition of done: Modification points and impact surface confirmed
3. [ ] Implement core changes
   - Definition of done: Core path code complete
4. [ ] Handle edge cases and errors
   - Definition of done: Empty state / failure state / permission state all functional
5. [ ] Verify and regression test
   - Definition of done: Key paths pass, results are reproducible

### 2. Risks & Rollback
- Risk:
- Monitoring signal:
- Rollback method:

### 3. Acceptance Criteria
- [ ] Feature behavior matches requirements
- [ ] No new build errors introduced
- [ ] Key UI / API paths verified

5) High-Quality Plan Rules (Hard Constraints)

• No "hollow steps" (e.g., "implement feature")
• Never omit "data source" or "state transitions"
• No unrelated large-scale changes (only minimal changes relevant to the task)
• Never skip validation (at least one local check + one result check)
• Never overstate conclusions (explicitly say so when something cannot be verified)

6) Common Task Mappings

A. Mobile Page Optimization

Must include:

• Visual layer (spacing, overflow, readability, tap target size)
• Interaction layer (default state, disabled state, loading state, empty state)
• Data layer (API fields consistent with rendered output)

B. List / Stats Consistency

Must include:

• Confirm same source API
• Confirm same filtering criteria
• Verify homepage numbers match detail list

C. State-Driven Workflows (e.g., Inbound)

Must include:

• Define initial state
• Define conditions that trigger state transitions
• Intercept and prompt for invalid states

7) Auto-Iteration Protocol

Trigger an experience update for this Skill when any of the following conditions are met:

• User explicitly responds with "this is great" or "this isn't working"
• A build error occurs and is resolved
• A deviation between the plan and the actual implementation is corrected

Update Structure

evolution.json follows this structure:

{
  "last_updated": "ISO_DATETIME",
  "preferences": [],
  "fixes": [],
  "custom_prompts": ""
}

Principles for Writing Learnings

• Preferences → write abstract rules (reusable across projects)
• Fixes → write "trigger condition + resolution approach"
• Prompts → write instructions that can be pasted directly

8) Recommended Trigger Commands

• /plan-auto — Generate a standard execution plan
• /plan-auto deep — Output a full plan including risks and rollback
• /plan-auto mobile — Focus on mobile page and interaction refactoring
• /plan-auto evolve — Automatically capture learnings at the end of the session

9) Experience Enhancements (Synced from evolution.json)

This section is auto-updated by the iteration process to prevent experience loss.

User-Learned Best Practices & Constraints

• Plan conclusions must align with the current implementation scope; avoid overreaching beyond applicable scenarios.
• Before presenting an implementation plan, cross-check existing code and database state to ensure the plan is logically sound and actionable.
• Before outputting a plan, clearly define the applicable scope and state transition conditions, and state all necessary prerequisites.