product-flow
Claude Code plugin for spec-driven development. Enables PMs, designers, and developers to collaborate in a structured process: spec → plan → code → deploy, with Claude assisting at every step.
Quick start
1. Install the plugin
Open your terminal, type claude and press Enter. Once it loads, run:
/plugin marketplace add [email protected]:deuveme/product-flow.git
Then, in the same session, run:
/plugin install product-flow@product-flow
Close the terminal. If you had Claude Code Desktop open, close it and reopen it.
You are ready to use the plugin commands!
2. Update the plugin
Open your terminal, type claude and press Enter. Once it loads, run:
/plugin update product-flow@product-flow
Close the terminal and reopen Claude Code.
Commands:
/product-flow:start — start a new feature/product-flow:continue — advance to next step (repeatable)/product-flow:build — generate code (when plan is ready)/product-flow:submit — share code for review/product-flow:fix — fix issues found during testing or code review (TDD guaranteed)/product-flow:deploy-to-stage — publish to staging/product-flow:status — see where you are/product-flow:context — see memory usage
Workflow:
/product-flow:start → /product-flow:continue (repeat) → /product-flow:build → /product-flow:submit → /product-flow:deploy-to-stage
(DRAFT PR) (spec → plan, team feedback) (code, TDD) (exit DRAFT, review) (approved → merge)
↕ issues found?
/product-flow:fix
(TDD fix cycle)
Documentation
Features
- Spec-driven: No code without a spec. Specs are reviewed and refined before planning.
- Quality gates: Specs, plans, and code are validated before moving to the next step.
- TDD by default: Code is generated using Red-Green-Refactor cycles with ZOMBIES test ordering.
- Design challenge: Plans are challenged against 30 complexity dimensions to prevent over-engineering.
- Approval testing: Specs are written as executable fixtures before implementation.
- Test quality: Tests are validated against Kent Beck's 12 Test Desiderata properties.
- Team collaboration: Team feedback integrates back into specs and plans via PR comments.
- Visual design exploration: Collaborative design skill for exploring ambiguous features through scenarios and vertical slicing before spec creation.
- Event modeling: Decompose event-driven features into independently testable slices (STATE_CHANGE / STATE_VIEW / AUTOMATION) before planning.
- Safe migrations: Expand-contract pattern for breaking changes — rename columns, refactor APIs, or replace services with zero downtime.
- Implementation verification: Post-implement quality gate (
speckit.verify) that validates code against spec, plan, tasks, and constitution before submitting for review.
- Phantom completion detection:
speckit.verify-tasks checks that tasks marked done have real code behind them — not stubs or TODOs — using a 5-layer cascade (file existence, git diff, pattern matching, dead-code detection, semantic assessment).
- Drift reconciliation:
speckit.reconcile surgically updates spec, plan, and tasks when implementation diverges from the original design.
- ADR proposals: At submit time, the agent analyzes
research.md and decisions.md and proposes which decisions are worth promoting to project-level Architecture Decision Records. Proposals appear in the PR body under ## For Developers so the team can review them alongside the code.
- ADR consolidation: At deploy time, if the PR has proposed ADRs the agent asks the user whether to write them. If confirmed, each ADR is written to
docs/adr/NNNN-<slug>.md in standard format (Context / Decision / Consequences) and committed to main alongside the merge.
- Scope splitting:
speckit.split analyzes a spec for scope creep using scope, size, and language signals. If a split is warranted, it trims the current spec and creates a new branch with a draft PR for the extracted feature — with vertical-slice validation and expand-contract warnings when features share entities.
Requirements
jsegov
brsbl
deepeshBodh
helderberto
nikhilsitaram
hujianbest