Deliver Feature

Convert a feature idea into tracked project artifacts and code through a gated workflow. Keep the PRD and plan in the project, let the user revise each artifact in chat, and only advance when the user explicitly approves the next phase.

Artifact Rules

• Treat the current working directory as the project root unless the user specifies another root.
• Store each feature under plans/NNNN. feature name/.
• Save the PRD to plans/NNNN. feature name/prd.md.
• Save the implementation plan to plans/NNNN. feature name/plan.md.
• Compute NNNN as the next unused 4-digit sequence.
• Build feature name from a short human-readable feature title. Keep spaces, but remove path-unsafe characters.
• Reuse an existing feature folder when the user is continuing that feature instead of starting a new one.
• Never overwrite another feature's PRD or plan.

Phase Gates

Run phases in this order:

1. Create PRD
2. Create a plan from PRD
3. Implement a plan
4. Review changes
5. Fix review issues

Use these exact advancement labels:

• Create a plan
• Implement a plan

If the client supports suggested replies or buttons, offer those exact labels. Otherwise, ask the user to send those exact messages.

For PRD and plan phases, stop after drafting or updating the artifact and wait for user approval. For review and fix phases, continue automatically until the review is clean or a real blocker requires user input.

Step 1: Create PRD

• Ask only for the missing information needed to draft a useful PRD: problem, target users, desired outcome, constraints, non-goals, acceptance criteria, and rollout concerns when relevant.
• Once enough context exists, create or choose the feature folder under plans/.
• Invoke $write-a-prd with the user request and save the result to prd.md in that feature folder.
• Show the PRD location and a concise summary after drafting.
• When the user asks for PRD edits, update prd.md directly and remain in this phase.
• Do not begin planning until the user approves with Create a plan.

Step 2: Create Plan From PRD

• Invoke $prd-to-plan with a reference to the approved prd.md.
• Save the result to plan.md in the same feature folder.
• Keep the plan implementation-oriented and grounded in the current repository.
• Show the plan location and a concise summary after drafting.
• When the user asks for plan edits, update plan.md directly and remain in this phase.
• Do not begin implementation until the user approves with Implement a plan.

Step 3: Implement Plan

• Read the approved plan.md.
• Execute the implementation phase with the message implement and the plan reference.
• Keep scope aligned with the plan unless the user explicitly expands it.
• Preserve unrelated user changes.
• When implementation is complete, move directly to review.

Step 4: Review Changes

• Invoke $code-review with the message uncommited changes.
• Review the working tree changes produced by this workflow.
• If the repository already contained unrelated uncommitted changes before implementation, avoid treating unrelated findings as blockers for this workflow.
• If review finds no material issues, end the workflow and report that the implementation is ready.
• If review finds issues, carry the findings into Step 5 immediately.

Step 5: Fix Review Issues

• Execute the fix phase with the message fix this issues and include the review findings.
• Address higher-severity issues first.
• Preserve the feature scope while fixing defects introduced during implementation.
• After fixes are complete, return to Step 4.
• Stop the loop only when $code-review reports no material findings or when progress is blocked by a missing product or technical decision that requires the user.

Interaction Rules

• Keep the current phase explicit in responses.
• Confirm the feature folder path after creating it.
• Summarize artifact changes briefly after each PRD or plan revision.
• Keep chat responses concise; the detailed content belongs in prd.md and plan.md.
• If the user tries to skip ahead, create the missing prerequisite artifact first unless the user explicitly asks to bypass the workflow.
• If $write-a-prd, $prd-to-plan, or $code-review are unavailable, state that clearly and fall back to performing the equivalent work manually.