Plugin commands
The Kanon plugin runs inside Claude Code and provides eight slash commands.
/kanon:setup
Purpose: Sign in and configure the project.
What it does:
- Starts a device-authorization flow (opens a browser URL)
- Exchanges the device code for an access token
- Verifies your workspace membership
- Writes
.kanon/config.jsonwith server URL and repo slug
When to use: First time setting up a project, or after changing your Kanon account.
Arguments: none
/kanon:discover
Purpose: Analyze the codebase and propose a product taxonomy.
What it does:
- Runs 9 signal collectors over the source code: routes, navigation components, layouts, middleware/guards, schemas, i18n, GraphQL, modules, and code ownership
- Digests the signals and makes one LLM triangulation call
- Produces proposed domains and features for human review
- Optionally pushes the result to the server
Arguments:
[target-url]— a running app URL (triggers refine mode)[repo-slug]— e.g.,your-org/your-app--refine— also crawl the running app in Chrome--auto-approve— skip human review, bulk-approve all proposals
Modes:
- Code-only (default): reads the codebase directly. Fast, no running app needed.
- Code + browser refine: also crawls the running app with Claude in Chrome for visual navigation data.
- Auto-approve: after push, approves all proposals and starts scanning. For CI or trusted pipelines.
/kanon:scan
Purpose: Deep-scan a feature and generate its knowledge base guide.
What it does:
- Extracts claims (business rules) from the feature's source files
- Collects mechanical facts (tables, routes, jobs, flags, events, experiments, security)
- Synthesizes an overview and deep-dive chapters
- Composes front matter (narrative, principles, lifecycle, data model, routes, etc.)
- Persists the guide to the knowledge base
Arguments:
[domain-key] [feature-key]— scan a specific feature--all— scan all approved features--guide— generate the full guide (default: claims + facts only)--force— re-scan even if inputs haven't changed
/kanon:push
Purpose: Upload a discovery bundle to the server.
What it does:
- Locates the latest
bundle.jsonin.kanon/runs/ - Validates it against the schema
- Asks the user to confirm
- POSTs to
/api/ingest - Reports the result and links to the review UI
Arguments: none (uses the latest run)
/kanon:status
Purpose: Show the current state of the knowledge base.
What it does:
- Fetches the taxonomy (approved vs proposed counts)
- Fetches recent ingest runs
- Shows a summary table
Arguments:
[repo-slug]— optional, uses config if omitted
/kanon:work
Purpose: Pick up a pending product change and implement it as a PR.
What it does:
- Fetches the next open spec change (or a specific one by ID)
- For features: creates a vertical-slice implementation plan
- Implements the change (or one slice of the plan)
- Runs verification (typecheck, lint, tests)
- Opens a draft PR with a structured body
Arguments:
[change-id]— work on a specific change[linear-id]— e.g.,ENG-42--next— pick the highest-priority open change--slice N— execute slice N of an existing plan--plan-only— create the plan without implementing--non-interactive— no confirmations (what the worker daemon passes): unknown change types take the plan-first feature path, and the PR is a draft unless typecheck + lint + tests all passed
Change types:
- Bug (
Fix:prefix) → implements directly, no planning phase - Improvement (
Improve:) → implements directly - Feature (
Add:) → creates a vertical-slice plan first, then implements slice by slice
/kanon:worker
Purpose: Start the worker daemon — execute changes queued from the Kanon UI, so nobody has to open Claude Code per change.
What it does:
- Verifies
claude,gh, andgitare ready (fails loudly if not) - Polls your Kanon workspace for tasks queued from the UI: Run with worker on a change, Run discovery with worker and Scan all with worker on the review page
- For each task: creates a git worktree (on a server-derived branch for changes; detached for discover/scan), runs the matching skill headlessly (
/kanon:work,/kanon:discover, or/kanon:scan, all--non-interactive), streams a live activity trace to the session view, and reports the outcome (a PR, or pushed proposals)
Runs in the foreground until you Ctrl-C. One task at a time; code never leaves the machine. See The worker daemon for always-on setup and troubleshooting.
Arguments: none (serves the repo it runs in)
/kanon:setup-ci
Purpose: Wire per-test coverage from your CI pipeline.
What it does:
- Configures your CI to report test results to Kanon
- Maps passing tests to claims for trust verification
- Sets up the webhook or upload step
Arguments: depends on your CI provider