run-feature-plan

name	run-feature-plan
description	Conducts pre-flight reconnaissance of the workspace and generates a comprehensive, full-stack implementation plan for a new feature.

Run Feature Plan Skill

Generates a rigorous, full-stack implementation plan for a new feature by first conducting live reconnaissance of the workspace, then producing a structured plan document ready for dual-model review.

Step 1: Read the Workspace-Customized Feature Plan Prompt

Read docs/prompts/feature-plan-prompt.md and use the architectural constraints and stack context it contains as the grounding context for this session.

[!NOTE] If the file contains only a placeholder/disclaimer (i.e., /generate-review-prompts has not been run yet), fall back to the default feature plan procedure below.

Step 2: Collect Feature Details from the User

Ask the user to provide the following (or read from the current conversation if already supplied):

• Feature Name: A concise, descriptive name
• Core Goal: The end goal and purpose of the feature
• Key Requirements & Business Logic: Specific behaviour, rules, and constraints
• Deprecations / Removals: Anything this feature replaces or removes
• Considerations: Known risks, dependencies, or constraints

Step 3: Execute Pre-Flight Reconnaissance (MANDATORY)

Before writing a single word of the plan, use MCP tools and terminal commands to read the current state of all files relevant to this feature. This includes:

• The relevant database schema, model definitions, and migration history
• Existing service and route files in the affected domain
• Current UI components that will be touched or replaced
• GEMINI.md for architectural constraints, coding standards, and naming conventions
• docs/project/roadmap.md and docs/project/backlog.md for alignment with planned work

[!IMPORTANT] Do not put "research" or "audit" as steps in the final plan. The discovery happens now, before the plan is written. The plan must reflect your actual current findings.

Step 4: Generate the Implementation Plan

Using the reconnaissance findings and the feature details collected in Step 2, produce a Master Implementation Plan structured as follows:

Required Sections

1. Architectural Overview — What changes across which workspaces, and how data flows end-to-end
2. Implementation Master Plan — Chronologically ordered, granular tasks grouped by domain:
   • Database Migrations (if applicable)
   • Backend Services & Routes
   • Admin UI (if applicable)
   • Client UI & Components
   • Mobile / Native App (if applicable)
3. Deployment & Infrastructure Check — Which branch, which deploy script, which pipeline. If backend changes are included, mandate a server-side smoke test (curl or equivalent) before any client or mobile testing
4. Server-Side Verification Gate — Explicit endpoint health check that must pass before UI/mobile verification begins
5. Post-Implementation Cleanup — Deprecations, documentation updates, unused dependency removal

Architectural & Vibe Coding Constraints (Non-Negotiable)

Apply these constraints from GEMINI.md and the generated prompt context:

• No God Components (files > 500 lines) — decompose into composed sub-components
• Full-stack completeness — every UI change must have its backend wiring explicitly planned
• Zero regressions — cross-check against existing functionality
• The 10-Second Rule — if a file takes > 10 seconds to explain, split it

Model Recommendations

For each phase of the plan, recommend the optimal AI model and mode from the Antigravity 2.0 orchestration matrix (as documented in GEMINI.md or the global ~/.gemini/GEMINI.md).

Step 5: Queue for Dual-Model Review

After producing the plan, instruct the user:

✅ Plan ready. Run /run-implementation-plan-review-1 to have Gemini critique this plan as Principal Architect, then /run-implementation-plan-review-2 for Claude's final pragmatism pass before execution begins.

---

Default Feature Plan Procedure

Use this procedure if docs/prompts/feature-plan-prompt.md has not yet been generated by /generate-review-prompts.

Follow Steps 2–5 above using the architectural constraints found in GEMINI.md directly, without the pre-customised workspace context.