Independent, report-only code quality review — use for 'review the code', 'code review', 'check code quality', or when an implementation (a diff, changed files, or uncommitted work, whether from TDD or written ad hoc) is complete and quality needs assessment before proceeding. Runs a sequential 5-layer analysis — data structures, special case elimination, complexity, breaking changes & behavioral conflicts, and practicality — plus a security-surface pass and a read-only intent-fit check, producing a severity-graded report without modifying any code. Does not execute acceptance criteria to verify spec conformance (that's verifying-and-adapting) and does not apply fixes (that's code-improving).
Run the entire Praxis craft workflow end-to-end as one guided flow that orchestrates every specialist stage in sequence (clarify → slice → design → TDD → review → improve → verify). Manual mode (default) checkpoints at the spec, design, and ship gates; --autopilot runs end-to-end without prompting, creating multiple commits across stages and modifying production code and tests, stopping only on its hard-stop conditions — including a mandatory human ship gate before Done that even autopilot never auto-confirms. Use when the user wants the whole pipeline (e.g. mentions Praxis craft, `/praxis:craft`, `$craft`, or "take this from idea to shipped") — not for a single stage, which should go to that stage's own skill.
Applies the fixes from a code-reviewing report — auto-fixing critical, high, and medium severity findings, leaving low-severity items for the user to decide, never modifying test files, and keeping every existing test green. Consumes a severity-graded review report (canonically from code-reviewing) and commits each fix; it does not hunt for new issues or add features. Use after code-reviewing produces a report, when the user says 'apply the review findings', 'fix the review comments', 'auto-fix these review issues', or 'address the code review'.
Implements a story through the Red → Green → Refactor cycle — use to 'start TDD', 'implement this story', 'write the tests', 'let's code this', or 'next slice', once a Story-Level Behavioral Spec with acceptance criteria exists (if none exist, route to clarifying-intent first). Converts each acceptance criterion into a failing test, writes the minimum code to pass, refactors to let design emerge, and commits each cycle directly to the repository (one commit per criterion). If no architecture was provided and the design path is non-obvious, it stops with a needs-design signal rather than improvising a design. Optionally consumes a design sketch; handles the feedback loop back to clarifying-intent when implementation reveals spec gaps.
Maps a Story-Level Behavioral Spec to a lightweight design sketch — locate the affected files, match existing patterns, check the choice against modern (2026) idiom for the stack at the project's scale, and propose one implementation direction, just enough to write the first failing test. Use before TDD when the path is non-obvious, or to answer "where do I start?", "which files do I change?", "how should I implement this?", "is this the idiomatic / best-practice approach for our stack?", "what architecture fits our scale?", or to map a spec to code. Consistency-first — it flags modern-practice divergences for the caller, never redesigns silently. After clarifying-intent or slicing-stories.
Clarifies a request before implementation by working through two phases — product space (who needs this, why, what success looks like) then system space (where it lands in any existing code, what behavior must not break, what observable signals confirm it works). Produces a Feature Brief (feature-sized input) or Story-Level Behavioral Spec (story-sized input) ready for slicing or implementation. Use whenever a request is vague or underspecified, when scoping new work, when adding features to existing code, before any non-trivial planning or coding, or when a user says "I have a rough idea", "help me scope this", "what should we build", or "spec this out".
Splits a Feature Brief into an ordered slice map of thin, vertical story slices — each capturing scope and build order, while deferring detailed acceptance criteria to downstream clarifying-intent. Use after clarifying-intent produces a Feature Brief, when a feature is too large for one story. Triggers on 'split this into stories', 'split this into slices', 'slice this feature', 'sequence these stories', 'what's the build order', 'create a slice map', or when a Feature Brief needs to be broken into deliverable increments.
Closes the loop after implementation by checking it holistically against the Story-Level Behavioral Spec — executing each acceptance criterion's observable behavior and citing the evidence, reconciling spec-vs-reality divergences, capturing emerged design knowledge, and recommending the next slice, rework, or done. Use after implementation is complete — canonically after driving-tdd and any review/improve pass — to confirm the build conforms to what was specified. Triggers on 'does this match the spec', 'check against the spec', 'close out this story against the spec', 'did we build what was specified', or 'close out this story'.