# Deliver Feature

> Guide a staged feature-delivery workflow from idea to PRD, PRD to implementation plan, plan to code, and code to a review/fix loop. Use when the user wants a structured feature workflow with explicit approvals, stored `plans/NNNN. feature name/` artifacts, `$write-a-prd` for PRD drafting, `$prd-to-plan` for planning, `implement` for execution, and `$code-review` over uncommitted changes followed by fixes until the review is clean.

- Skill: `mishankov/deliver-feature` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add mishankov/deliver-feature`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mishankov/deliver-feature/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: mishankov (https://skillmd.com/u/mishankov)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mishankov/deliver-feature

---


# 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.