A quality harness for Claude Code. Routes any prompt into spec → plan → implement → adversarial audit → living docs, and holds the turn open until the work actually holds up: no TODOs, no deferred scope, no unverified test claims.
What an auditor is allowed to assert, and what it must cite. Preloaded into every praxis review auditor through the skills frontmatter field, so the rule exists once. Use whenever you are reviewing, auditing, or verifying a change and about to state a verdict: it defines the difference between a finding and a guess…
Select and apply the software-engineering best-practices and guidelines relevant to the task at hand (and, in auto-pilot, resolve design decisions autonomously by picking the best-practice that fits. Use during planning, implementation, review, or any time an approach/design decision is being made: choosing an…
Prepare any repository for top-tier Claude Code use. Runs automatically as the first step of any session that does real work in a repo praxis has not set up, and on demand via /praxis:bootstrap. Use on a brand-new repo, an existing repo with no Claude Code setup, or an existing repo that already has a CLAUDE.md…
Detect and close capability gaps just-in-time. Use whenever a task would benefit from a tool, MCP server, skill, or plugin you don't currently have, for example the work needs database access, browser control, an issue tracker, or a repeated specialised workflow. Always search for an existing capability (already…
Keep the CLAUDE.md hierarchy (root and nested files) current and regression-free. Use when a convention, command, dependency, or architectural pattern changes; when the user runs /praxis:docs; when you notice CLAUDE.md contradicts the actual code; or after adding a subsystem that deserves its own nested CLAUDE.md.…
Professional code craftsmanship standards, especially how to write comments the right way. Use whenever writing or editing code, when adding comments or docstrings, during code review, or when the user asks for clean, production-quality, well-documented code. Covers comment discipline (explain why not what)…
Keep the project's /docs tree, CHANGELOG.md, the technical-debt register (docs/DEBT.md), and Architecture Decision Records (docs/adr/) alive and accurate. Use for EVERY change that adds, modifies, or removes behaviour, an API, a config, an architectural decision, or a workflow: read the relevant docs first, then…
Design and build user-facing front-ends to professional standard, any niche: marketing sites, landing/lead pages, storefronts/e-commerce, SaaS product UI, CRM/CMS, admin panels, dashboards. Use WHENEVER a change adds or alters user-facing surface, whatever the request called it: "build a site for…", "make a landing…
Deliver a finished change through Git and GitHub to professional standards, and cut releases. Use when the work is complete and audited and it should be committed, pushed, turned into a pull request, or released, or when the user runs /praxis:ship. Covers Conventional Commits, branch naming, PR authoring, SemVer…
Restructure a vague or terse request into an explicit, actionable engineering spec before any work begins. Use at the start of any implementation task, whenever a prompt is ambiguous, underspecified, or high-level (e.g. "fix this", "make it better", "integrate X"), or when the user asks you to turn an idea into a…
Run praxis's full quality review on a code change. Use this whenever you finish a non-trivial edit, before declaring work done, when the Stop gate reports an unreviewed change, or when the user asks for a review, audit, or quality check. Dispatches the vertical auditors (adversarial, regression, duplication…
Audit, reverse-audit, and fix an ENTIRE existing codebase, not a diff. Use when the user asks to scan, audit, review, health-check, or harden a whole repo or directory ("audit this project", "find everything wrong", "scan the codebase"), or runs /praxis:audit repo. Shards the repo into a deterministic coverage ledger…
What 'the change' means in a review, and how an auditor establishes it: the branch's commits since its base as well as what is still uncommitted, never the working tree alone. Preloaded into every praxis review auditor through the skills frontmatter field, so the rule exists once. Use whenever you are about to audit…
Prove a change works by running the product, not only its tests. Use whenever a change touches a user-facing surface (a page, a screen, a route, a CLI command, a job) and whenever the unit suite passing would not actually tell you the thing works: after implementing a feature, before recording the quality report, when…
The end-to-end workflow for any implementation or change request. Use this WHENEVER the user asks to fix, add, implement, integrate, refactor, update, migrate, optimize, or otherwise change the code-base, even from a one-line prompt like "fix this" or "integrate X". It restructures the request into a spec…