FeaturePlanningAutoPilot

A general-purpose feature development planning skill. Used to generate executable, verifiable, and iterative development plans before coding, and to automati...

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.