Start a debug session - load the CANONIFY.md index, route the error you paste (text, screenshot, or a log-file reference) to the canon for that area so Claude debugs with the right context, then after the fix suggest capturing the footgun via /canonify:update-canon or /canonify:create-canon. Run when the user types /canonify:debug, or says "help me debug this error", "I'm getting this exception", "here's an error log / stack trace", "why is this failing".
Seed new canons in THIS repo from a list of existing canons in another project - using the source canons as the structural template, then re-indexing this repo's code so every citation and the verified SHA are correct here. It is create-canon driven by a source list, not a file copy. Run when the user types /canonify:import-canon, or says "import the canons from project A", "replicate the composite canons here", "bring in the canons from <path/repo>", "seed this repo's canons from <project>", "copy canons from <project> and re-verify".
Health-check the canon - verify every canon's references still exist and are registered, flag canons whose referenced source files have changed since they were last verified (git-derived staleness), and best-effort check whether the installed Canonify plugin is behind its GitHub source. Reports a worklist; does not auto-fix. Run when the user types /canonify:doctor, or says "check the canon", "are the docs stale", "audit the canons", "canonify health check", "lint the canon", "is canonify up to date".
Audit the current diff against the canonical patterns in CANONIFY.md and the docs it points to. Run when the user types /canonify:commit or asks to check before committing/pushing/deploying/shipping, verify the changes, or perform similar pre-commit verification. Mirrors the plan-time CANON routing - same selector, opposite direction.
Capture a mid-coding discovery into an EXISTING canon - describe the update and Canonify routes to the right canon, checks whether it's already covered (and whether a revision is needed) or adds it in house-style, then keeps registration + the verified SHA honest. Run when the user types /canonify:update-canon, or says "add this to the canon", "the FormBuilder canon is missing/wrong about X", "I discovered Y, capture it", "update the Z canon", "this should be in the canon", "revise the canon for X".
Load the canonical patterns relevant to the task being planned, by routing through CANONIFY.md. Run when the user types /canonify:build or signals plan-time intent - phrases like "let's plan this", "I want to add X", "what's the right pattern for Y", "starting work on Z". Bookend partner to /canonify:commit. Routing logic is identical to commit-time, but pointed at the task description instead of the diff.
Author a new "canon" - one canonical-pattern doc (a .md) - for a file, service, or design element, then register it in CANONIFY.md + the category INDEX. The command name teaches the vocabulary: each pattern doc is a "canon." Run when the user types /canonify:create-canon, or says "create a canon for X", "document this file/service", "I need to document X", "write a canon for the Y service", "add a doc for this design element".
One-time onboarding wizard that sets Canonify up in a fresh repo - a short survey (scan-and-seed? scheduled doctor?), then write CANONIFY.md + the docs/ skeleton and optionally bulk-seed canons by scanning the codebase. Run when the user types /canonify:kickoff, or says "set up Canonify", "kick off Canonify", "onboard this repo", "initialize the canon", "start canonify here".