devflow

Conduct a conversational Q&A to capture requirements for a feature or change, then dry-run the draft against prior accepted requirements to detect conflicts before acceptance. Use when the user mentions "new feature", "change request", "requirements", "spec this out", "what do you want", "what are we building", "let's figure out what this needs", "supersede", "replace the old requirement", or is about to start non-trivial work without a requirements doc. Produces a time-ordered, globally-unique, immutable requirement file with a machine-readable deltas block, runs structural and declarative-state conflict checks, and either accepts (folding into .devflow/state.yml) or reports conflicts with resolution paths.

Turn an accepted requirement into a commit-sized implementation plan with per-step verification, Mermaid diagrams, captured architectural decisions, and a structured scenarios.yml catalog that links each behavior to one or more native tests (unit, integration, contract, load, smoke, e2e). Use when the user asks to "plan this out", "break it down", "design this", "make a TDD plan", "step-by-step approach", or when a requirement has status=accepted but no plan.md exists yet. Produces plan.md (commit-sized steps with verification), decisions.md (ADR-lite entries keyed to DEC-xxxx), and scenarios.yml (scenario specifications with status=spec-only and empty tests lists). Every scenario starts as spec-only; tests are written in the next phase.

Execute ONE plan step at a time with a strict TDD red/green/refactor loop and SOLID discipline (SRP, OCP, DIP). Use when the user asks to "start implementing", "write the code", "work the plan", "do step N", "keep going", or when .devflow/session.yml has phase=implement-step. For each scenario the step covers, populate the scenarios.yml tests list, write failing tests in the consumer repo's native framework (vitest/jest/pytest/rspec/go test/etc.), advance status to tests-written, implement code until green, advance status to passing, refactor, and pause at pause_after=true boundaries for engineer review. Runs code early and often via temp scripts under tmp/. If reality conflicts with the plan, stops and escalates back to create-plan for a revision rather than working around it.

Orchestrate a disciplined five-phase coding workflow (gather-requirements, create-plan, implement-step, finalize-feature, review-changes) for AI coding agents. Use when the user starts a new feature, kicks off non-trivial work, asks for a "full workflow" or "end-to-end plan", mentions "dev flow" or "devflow", wants requirements-before-code, wants commit-sized steps, mentions TDD or BDD, needs to resume paused work, or is unsure which phase to enter next. Enforces requirements-as-migrations (immutable, supersede-only) and a structured scenarios.yml catalog that links each behavior to one or more native tests. Routes into the correct phase skill; does not reimplement phase behavior.

Prepare a completed feature for handoff to review. Use when all plan steps have advanced to passing, the user says "finalize", "wrap up", "clean up", "ready for review", "we're done implementing", or when .devflow/session.yml has phase=finalize-feature. Updates agent-facing docs (AGENTS.md / CLAUDE.md / README.md / CHANGELOG), empties the tracked contents of tmp/ after engineer confirmation (keeping the directory with a .keep marker so runtimes that expect it to exist still work), verifies that scripts and utilities introduced during implementation are referenced from plan.md, re-runs the full test suite with the scenarios-coverage audit, and regenerates .devflow/state.yml from log.jsonl to check for drift. Does NOT write production code and does NOT perform code review — routes to review-changes at the end for readability/security/audit passes.

Review a finalized feature for readability, maintainability, and security before it ships, and run the mechanical audits (scenarios-coverage, state-drift, traceability) that hard-block merge. Use when finalize-feature has completed, the user says "review this", "code review", "security review", "ready to merge?", "what should I check", or when .devflow/session.yml has phase=review-changes. Produces a review report with findings sorted by severity (block / warn / info), each citing exact files and lines with a suggested resolution. Does NOT silently fix findings — routes block-severity issues back to implement-step (code fixes) or create-plan (plan/scenario fixes). Covers SOLID subset, rich domain types, naming, complexity, dead code, test quality, authn/authz, input validation, injection surfaces, secrets, logging hygiene, and denial-of-service resilience.