The /kanon:work command turns pending product changes into review-ready pull requests.

Two ways to run it

Interactively — an engineer runs /kanon:work in their own Claude Code session, watches, and steers. This page describes that flow.
From the Kanon UI — anyone clicks Run with worker on the Changes page and a worker daemon you keep running executes the same command headlessly (--non-interactive), streaming a live trace back to the browser. Same skill, same quality bar, no terminal.

The change pipeline

Changes flow from the knowledge base to your codebase:

KB detects a gap or user requests a change
  → Spec change created (open)
    → /kanon:work picks it up (implementing)
      — run in your terminal, or queued to the worker from the UI
      → Code is written, tested, verified
        → PR opened (draft or ready)
          → Human reviews and merges
            → Change resolved

Picking up a change

# The next open change (highest priority)
/kanon:work --next

# A specific Linear ticket
/kanon:work ENG-42

# A specific change by ID
/kanon:work cm1234abc

The command shows what it's about to work on and asks for confirmation before writing any code.

Bug fixes and improvements

For bugs and improvements, the command goes straight to implementation:

Creates a branch (fix/eng-42-broken-repayment)
Reads the affected code and tests
Makes the minimal changes needed
Adds or updates tests
Runs typecheck + lint + tests
Opens a PR

Feature implementation with vertical slices

Features get a planning phase first. The plan breaks the feature into 2-6 vertical slices — each a thin, shippable increment.

Creating a plan

# Create the plan only
/kanon:work ENG-43 --plan-only

The plan is saved to .kanon/plans/{change-id}.md with:

Overview of the feature
Numbered slices, each with: goal, dependencies, file changes, tests, acceptance criteria, risks
Open questions and out-of-scope items

Executing slices

# Execute slice 1
/kanon:work ENG-43 --slice 1

# After slice 1's PR is merged, execute slice 2
/kanon:work ENG-43 --slice 2

Each slice:

Creates its own branch (feat/eng-43-slice-1)
Only touches files listed in that slice
Opens its own PR with a reference to the full plan
Updates the plan file to mark the slice as complete

Slice design principles

The planning phase follows these principles:

Vertical, not horizontal. Each slice touches all layers for one narrow capability.
First slice is the smallest thing that works. Prove the path end-to-end.
Each slice builds on the previous one. Slice 2 assumes slice 1 is merged.
Last slice removes scaffolding. Feature flags, hardcoded fallbacks, TODOs.

Quality standards

Every /kanon:work execution enforces:

Minimal changes — only what the change requires, no refactoring
Style conforming — matches the existing codebase style
Tested — every behavioral change has a test
Verified — typecheck + lint + tests all pass
Self-reviewed — diff checked for scope creep before committing
Structured PR — body includes what/why/changes/verification/acceptance criteria

Failure handling

Verification fails after 3 attempts → stops, reports what's failing, leaves the change as "implementing"
Git conflicts → tells you to resolve manually, never force-pushes
Missing gh CLI → commits and pushes, gives you the PR command to run yourself

Working on changes