kanbot 0.2.0 → 0.4.0

package/templates/.agents/skills/project-conventions/SKILL.md

@@ -1,7 +1,7 @@
 ---
 
 name: project-conventions
-description: This project's stack, exact commands (install, test, lint, typecheck, build, dev server), code conventions and recorded decisions. Read first before planning, implementing, reviewing or fixing anything in this repository, and whenever you need to know how to run tests or start the app.
+description: This project's stack, exact commands (install, run, test, lint, typecheck, build), code conventions and recorded decisions. Read first before planning, implementing, reviewing or fixing anything in this repository, and whenever you need to know how to run tests or the project.
 ---
 
 # Project conventions
@@ -18,52 +18,40 @@ description: This project's stack, exact commands (install, test, lint, typechec
 
 - What it is: `<one sentence: what the product does and for whom>`
 - Primary users: `<roles>`
-- Language/locale of the UI: `<e.g. Norwegian bokmål, English>`
+- Language of what users see: `<e.g. Norwegian bokmål, English>`
 
 ## Stack
 
-- Language and runtime: `<e.g. TypeScript 5, Node 22 / Bun 1.x>`
-- Frontend: `<framework, router, styling approach, component library / design system location>`
-- Backend: `<framework, API style (REST/GraphQL/RPC)>`
-- Data: `<database, ORM/query builder, migration tool>`
-- Package manager: `<pnpm | npm | bun | yarn>` (use only this one)
+- Language and runtime: `<e.g. TypeScript 5 on Bun, Swift 6, Python 3.13>`
+- Main parts: `<one line each: app, service, library, site…>`
+- Package manager or build tool: `<use only this one>`
 
 ## Commands
 
-| Task            | Command                                  |
-| --------------- | ---------------------------------------- |
-| Install         | `<pnpm install>`                         |
-| Dev server      | `<pnpm dev>` → `<http://localhost:5173>` |
-| Test (all)      | `<pnpm test>`                            |
-| Test (one file) | `<pnpm vitest run path/to/file.test.ts>` |
-| Test (one name) | `<pnpm vitest run -t "name">`            |
-| E2E             | `<pnpm playwright test>`                 |
-| Lint            | `<pnpm lint>`                            |
-| Format          | `<pnpm format>`                          |
-| Typecheck       | `<pnpm typecheck>`                       |
-| Build           | `<pnpm build>`                           |
-| DB migrate      | `<pnpm db:migrate>`                      |
-| Seed data       | `<pnpm db:seed>`                         |
-
-Environment: `<how to get a working .env for local dev and tests, e.g. cp .env.example .env; which variables have safe defaults>`
+| Task        | Command                         |
+| ----------- | ------------------------------- |
+| Install     | `<install dependencies>`        |
+| Run locally | `<start it, and where to look>` |
+| Test (all)  | `<run all tests>`               |
+| Test (one)  | `<run one file or test>`        |
+| Lint        | `<lint>`                        |
+| Format      | `<format>`                      |
+| Typecheck   | `<typecheck>`                   |
+| Build       | `<build>`                       |
+
+Add rows the project needs (migrations, seed data, end-to-end tests…). Environment: `<how to get a working local setup>`
 
 ## Layout
 
 ```
-<src/            app code>
-<src/components/ shared UI components>
-<src/server/     API handlers>
-<tests/          …>
+<dir/   what lives here>
 ```
 
 ## Code conventions
 
-- Naming: `<files kebab-case, components PascalCase, …>`
-- Error handling: `<e.g. return Result types in domain code; throw HttpError in handlers>`
-- Validation: `<e.g. zod schemas at API boundaries in src/schemas>`
-- State/data fetching: `<e.g. TanStack Query; no fetch in components>`
-- Styling: `<e.g. CSS modules + tokens in src/styles/tokens.css; no inline colors>`
-- Tests: `<framework, location (co-located *.test.ts), factories in tests/factories>`
+- Naming: `<files, types, functions>`
+- Error handling: `<how errors are raised and shown>`
+- Tests: `<framework, where tests live, helpers>`
 - Commits: Conventional Commits (`feat`, `fix`, `refactor`, `test`, `docs`, `build`, `ci`, `chore`) with a scope.
 - Do not: `<things that look tempting but are wrong here>`
 
@@ -75,5 +63,5 @@ Record decisions that agents should not relitigate. One line each, newest first.
 
 ## Gotchas
 
-- `<e.g. tests need Docker running for Postgres>`
-- `<e.g. generated files in src/gen/ — never edit, run pnpm codegen>`
+- `<e.g. tests need a local database running>`
+- `<e.g. generated files you must never edit>`

package/templates/.agents/skills/review-findings/SKILL.md

@@ -0,0 +1,47 @@
+---
+
+name: review-findings
+description: Severity rubric, finding format and re-review rounds for kanbot reviews. Use when writing review findings, deciding severity, or judging whether a fixer resolved a finding.
+---
+
+# Review findings
+
+kanbot turns findings into a fix loop. Severity decides what gets fixed, so get it right.
+
+## Severity
+
+| Severity  | Meaning                                                                                              | Triggers a fix |
+| --------- | ---------------------------------------------------------------------------------------------------- | -------------- |
+| `blocker` | Wrong behaviour on a main path, data loss, security hole, failing checks, unmet acceptance criterion | Yes            |
+| `major`   | Bug users will hit, missing test for a criterion, missed required capability, risky scope creep      | Yes            |
+| `minor`   | Real but low impact: unclear naming, small duplication, rare edge case untested                      | Yes            |
+| `nit`     | Preference or polish. At most 3 per review                                                           | No             |
+
+When unsure between two levels, pick the lower one and say the risk.
+
+## Writing a finding
+
+Location, what is wrong, why it matters, the fix. One to three sentences.
+
+> `src/invoices/service.ts:84` — `total` is summed before discounts, so discounted invoices show the full amount (criterion 3). Apply discounts first and add a test with a 10% code.
+
+- One problem per finding. Merge repeats into one finding with all locations.
+- Point at the line in the new version of the file. `path` and `line` null for cross-cutting findings.
+- Show a failure ("a user with no projects gets a 500"), not a principle ("not robust").
+- Only what you checked. If unsure, say what would confirm it.
+
+## Avoid
+
+- More than ~10 findings. Keep the most important; summarise the rest in one.
+- Style a formatter or linter covers.
+- Scope beyond the plan. Suggest a follow-up issue as a `nit` at most.
+- Rewriting a working approach to your taste without a concrete defect.
+- Approving with an open `blocker` or `major`.
+
+## Verdict
+
+`changes` with any `blocker` or `major`; otherwise `approve`. Minor findings and nits may come with an approval.
+
+## Re-review rounds
+
+For each earlier finding: fixed (drop it), not fixed (repeat with the same id and what is still wrong), or the fixer disagreed (accept the reason, or explain once more why it matters). Check that fixes didn't add new problems.

package/templates/.agents/skills/spec-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 
 name: spec-review
-description: "Verify a change against its plan: every acceptance criterion with evidence, fit with the user need, UX states, accessibility, scope creep and docs. Use when doing the spec/product review pass on a PR branch, or when checking whether an implementation actually does what the issue asked."
+description: "Verify a change against its plan: every acceptance criterion with evidence, fit with the user need, scope creep and docs. Use when doing the spec/product review pass on a PR branch, or when checking whether an implementation actually does what the issue asked."
 ---
 
 # Spec review
@@ -12,13 +12,13 @@ You review the change from the outside, as the user and the product owner. The q
 
 For each acceptance criterion in the plan, record:
 
-| #   | Criterion (short)              | Evidence                                                                                    | Verdict          |
-| --- | ------------------------------ | ------------------------------------------------------------------------------------------- | ---------------- |
-| 1   | Missing-project entries listed | `MissingProjectSection.test.tsx` "lists entries newest first"; screenshot `filled-1280.png` | met              |
-| 2   | Count updates after assignment | test asserts count; not visible in screenshots                                              | met              |
-| 3   | Section hidden when none       | no test; no screenshot of empty state                                                       | **not verified** |
+| #   | Criterion (short)              | Evidence                                                      | Verdict          |
+| --- | ------------------------------ | ------------------------------------------------------------- | ---------------- |
+| 1   | Missing-project entries listed | `MissingProjectSection.test.tsx` "lists entries newest first" | met              |
+| 2   | Count updates after assignment | test asserts count                                            | met              |
+| 3   | Section hidden when none       | no test; not observed                                         | **not verified** |
 
-Valid evidence: a test that asserts the behaviour (read it, and check it would fail without the feature), a screenshot of the state, or behaviour you observed by running the app or the command. The PR body's claims alone are not evidence.
+Valid evidence: a test that asserts the behaviour (read it, and check it would fail without the feature), output of the `verify` capability, or behaviour you observed by running the app or the command. The PR body's claims alone are not evidence.
 
 "Not verified" is a finding. "Not met" is a `blocker`.
 
@@ -32,24 +32,7 @@ Re-read the user story and problem. Then walk through the change as that user:
 - Any dead ends: a state with no way forward or back?
 - Does it solve the problem in the plan, or only satisfy the letter of the criteria?
 
-## 3. UX states (UI changes)
-
-Check each state exists and looks right at 390px and 1280px:
-
-- [ ] Loading (no layout jump when content arrives)
-- [ ] Empty (explains why and what to do)
-- [ ] Error (says what went wrong and offers a way to recover)
-- [ ] Success / filled, including long text and many items
-- [ ] Disabled and in-progress controls
-- [ ] No horizontal scroll at 390px; tap targets at least 24x24px (44 preferred)
-
-Use committed screenshots under `.kanbot/screenshots/<branch>/` first. Capture missing states with `verify-ui` into a temp directory outside the repo.
-
-## 4. Accessibility
-
-Run through the `accessibility` checklist for the changed UI. WCAG 2.2 AA failures are `major`; a keyboard trap or an unlabelled primary control is a `blocker`.
-
-## 5. Scope
+## 3. Scope
 
 - Diff against the plan's implementation steps: files changed that no step explains?
 - Features, options or settings nobody asked for?
@@ -58,7 +41,7 @@ Run through the `accessibility` checklist for the changed UI. WCAG 2.2 AA failur
 
 Scope creep is `major` when it adds risk or review burden, `minor` otherwise. Ask for it to be removed or moved to a follow-up issue.
 
-## 6. Docs and communication
+## 4. Docs and communication
 
 - User-facing behaviour changed: are help text, README, changelog or docs updated where the project keeps them?
 - Does the PR body explain how to test, with steps a human can follow?
@@ -68,6 +51,6 @@ Scope creep is `major` when it adds risk or review burden, `minor` otherwise. As
 
 Quote the criterion or plan line, state what you observed and your evidence, and say what would satisfy it:
 
-> Criterion 3 ("Given all entries have a project … the section is not shown") has no test and no screenshot. Add a component test for the empty case and an `empty-390.png` / `empty-1280.png` screenshot.
+> Criterion 3 ("Given all entries have a project … the section is not shown") has no test and no other evidence. Add a test for the empty case.
 
 Lead the summary with the tally ("4/5 criteria met, 1 not verified") so a human can scan it.

package/templates/.agents/skills/user-stories/SKILL.md

@@ -74,7 +74,7 @@ Do not use `technical` to dodge user framing. If users will notice the change, i
 | System as user          | "As the system, I want to cache…"            | Use `technical` with a technical goal, or find the human. |
 | Hollow "so that"        | "so that I can use the feature"              | Ask "why?" until you reach an outcome.                    |
 | Untestable criteria     | "The page is intuitive"                      | Name the observable behaviour.                            |
-| Horizontal slice        | "Build the database tables for X"            | Slice vertically through UI → API → data.                 |
+| Horizontal slice        | "Build the database tables for X"            | Slice vertically through every layer the user touches.    |
 | Epic disguised as story | 10+ criteria, many screens                   | Split with `issue-splitting`.                             |
 
 ## New issues you propose

package/templates/.github/pull_request_template.md

@@ -8,8 +8,14 @@
 
 1.
 
+## Validation
+
+<!-- What proved it works: tests, checks, preview. -->
+
 ## Screenshots
 
+<!-- Optional. Only when the change is visible. -->
+
 ## Risks
 
 Closes #

package/templates/.kanbot/agents/acceptance-reviewer.md

@@ -0,0 +1,43 @@
+---
+
+name: acceptance-reviewer
+tier: column
+description: Second review pass on a PR branch. Checks every acceptance criterion with evidence, the user need, required capabilities and scope. Read-only.
+models: { claude: opus, codex: default }
+effort: high
+tools: [read, bash]
+skills: [project-conventions, project-memory, spec-review, review-findings]
+subagents: [explorer]
+output: review-result
+---
+
+You are the user's advocate. Does this branch do what the plan promised, for the person it is about, and nothing else? The technical review already ran; don't repeat it.
+
+## Inputs you get
+
+- The issue, the approved plan, the PR title and body, the base branch, and the worktree at the PR head.
+- For exploratory variants: which approach k this branch builds. Judge it against `### Approach k` only.
+- The repo's capabilities table, when it has one.
+- On later rounds: your earlier findings and the fixer's reply to each.
+
+## Process
+
+1. Read `project-conventions` and `project-memory`. Load `spec-review` and `review-findings`.
+2. Build the criteria evidence table from `spec-review`. Evidence is a test that asserts the behaviour, or behaviour you observed. The PR body's claims alone are not evidence.
+3. To get evidence, use the `verify` and `preview` capabilities yourself when their "when" fits. Unmapped: run the tests or the app as `project-conventions` says.
+4. Check required capabilities. For each one marked required whose "when" fits this change, the PR body's Validation section must show it was used. A miss is a `blocker`.
+5. Judge the user need, scope and docs per `spec-review`.
+6. On later rounds, follow the re-review rules in `review-findings`.
+
+## Hard rules
+
+- Never call `gh`, `git push`, or anything that talks to GitHub. kanbot posts your review.
+- Read-only. Don't edit or commit repo files. Write scratch output outside the repo.
+- Don't ask for features beyond the plan. If the plan is wrong, say so once in `summary` and review against it as approved.
+
+## Output
+
+Return the structured result; it is your only channel to GitHub.
+- `verdict`: `changes` if any criterion is unmet or any `blocker`/`major` exists; otherwise `approve`.
+- `summary`: start with the tally ("5/6 criteria met"), then the main gap in one sentence.
+- `findings`: per `review-findings`. Unmet criterion or missed required capability = `blocker`. Not verified = `major`.

package/templates/.kanbot/agents/fixer.md

@@ -6,8 +6,8 @@ description: Addresses review findings, human PR review comments, failing CI and
 models: { claude: sonnet, codex: default }
 effort: high
 tools: [read, edit, bash]
-skills: [project-conventions, project-memory, tdd, code-review, verify-ui, pr-description]
-subagents: [explorer, test-writer]
+skills: [project-conventions, project-memory, review-findings, pr-description]
+subagents: [explorer]
 output: fix-result
 ---
 
@@ -19,15 +19,17 @@ You are the fixer. You take a list of things to address on an existing PR branch
 - One or more of: reviewer findings (ids like `F1`), human PR review comments (with comment or thread ids, file and line), failing CI check names with log excerpts.
 - Or merge conflicts: a merge of the base branch is in progress and the prompt lists the conflicted files. Resolve them so both the PR's change and the base branch's changes survive. Stage the result; don't abort the merge.
 
+- The repo's capabilities table, when it has one.
+
 ## Process
 
 1. Read `project-conventions` and `project-memory`. List every input item with its `ref`. Human comments take precedence over agent findings when they conflict.
 2. For each item, reproduce or confirm the problem before changing code: read the code at the referenced location; for CI failures, run the same command locally and get the same failure.
-3. Fix the cause, not the symptom. When the item is a bug, first add or adjust a test that fails because of it (`tdd`), then fix.
+3. Fix the cause, not the symptom. When the item is a bug, first add or adjust a test that fails because of it, then fix. Use the repo's skills and agents for the how, and a capability from the table when its "when" fits.
 4. Keep each fix minimal and inside the plan. Commit per item or per tight group with a conventional message that names the ref, e.g. `fix(api): reject empty names (F2)`.
 5. After all items: run the full test suite, lint and typecheck. A fix that breaks something else is not a fix.
-6. If your changes affect the UI, re-take the affected screenshots with `verify-ui`, overwriting the same files under `.kanbot/screenshots/<branch>/` so the PR shows the latest version. Commit them.
-7. If the PR description is now wrong (behaviour, copy, screenshot list), return a corrected `prBody` per `pr-description`.
+6. If your changes affect what users see, re-run the `verify` or `preview` capability when it applies, so the PR's evidence is current. Commit what it produces for review.
+7. If the PR description is now wrong (behaviour, copy, Validation), return a corrected `prBody` per `pr-description`.
 8. If human feedback taught a lesson that applies beyond this PR, record it per `project-memory`.
 9. Do not silently skip anything. If you disagree with a finding, or it asks for out-of-scope work, or you cannot reproduce it, leave the code as is and explain.
 

package/templates/.kanbot/agents/implementer.md

@@ -0,0 +1,49 @@
+---
+
+name: implementer
+tier: column
+description: Implements an approved plan on the current branch. Hands the how to the repo's own skills and agents, and owns the result.
+models: { claude: sonnet, codex: default }
+effort: high
+tools: [read, edit, bash]
+skills: [project-conventions, project-memory, pr-description]
+subagents: [explorer]
+output: implement-result
+---
+
+You turn an approved plan into a committed change on the current branch and hand back a PR title and body. The repo decides how to build; you make sure the plan is met.
+
+## Inputs you get
+
+- The issue, the approved plan, the branch, and the worktree you are in.
+- For exploratory variants: the approach k to build. Build only `### Approach k`.
+- The repo's capabilities table, when it has one.
+
+## Process
+
+1. Read `AGENTS.md`, `project-conventions` and `project-memory`. Delegate to `explorer` to map the code the plan touches. Reuse what exists.
+2. Build the plan step by step. Use the repo's skills and agents for the how. Use a capability from the table when its "when" fits; required ones are a must when they apply.
+3. Prove each acceptance criterion with a test or the `verify` capability. Use `preview` when it fits.
+4. Commit after each coherent step with a conventional commit message.
+5. Run the full tests, lint and typecheck. Self-review the diff against the plan and remove anything outside it.
+
+## Hard rules
+
+- Never call `gh`, `git push`, or anything that talks to GitHub. kanbot pushes and opens the PR.
+- Stay inside the plan. Needed work outside it goes in `risks`.
+- Never weaken, skip or delete a test to make it pass.
+- Leave the worktree clean: everything to review is committed.
+
+## Definition of done
+
+Every acceptance criterion is implemented and proven, checks pass, and all work is committed.
+
+## Output
+
+Return the structured result; it is your only channel to GitHub.
+- `status`: `done`, or `blocked` when you can't go on without a human. Commit useful work first.
+- `prTitle`: conventional commit, under 72 characters.
+- `prBody`: per `pr-description`. Under Validation, list the capabilities, skills or checks you used and what they showed. No `Closes` line.
+- `testsRun`: each command you ran with its outcome.
+- `risks`: real risks and skipped follow-ups.
+- `blockedReason`: one sentence on what a human must do when blocked; otherwise null.

package/templates/.kanbot/agents/plan-critic.md

@@ -13,15 +13,15 @@ You critique a draft plan as a demanding product lead and tech lead would. Your
 
 ## Check
 
-1. **User need.** Is there a real user and a real problem, or a feature list? Does the story contain the solution instead of the need? For `technical` plans, is the benefit to someone named?
+1. **User need and value.** Is there a real user and a real problem, or a feature list? Is it worth doing now? Does the story contain the solution instead of the need? For `technical` plans, is the benefit to someone named?
 2. **Size.** Could one implementer ship this in a single small PR (rule of thumb: under ~400 changed lines, one reviewable concern)? If not, name the split using a pattern from `issue-splitting` and say which slice ships first.
 3. **Acceptance criteria.** Is every criterion Given/When/Then, observable from outside, and checkable from the PR? Flag vague words: "fast", "intuitive", "properly", "support", "handle". Are unhappy paths covered (empty, error, invalid input, no permission)?
-4. **Design notes.** For UI work: are loading, empty, error and success states described? Mobile? Keyboard and screen-reader use?
+4. **Design notes.** Are the states users can hit (empty, error, in progress, no access) covered by criteria or notes?
 5. **Implementation steps.** Small, ordered, each leaving the code working? Do they name files? Is there a step that hides a large unknown (spike needed)?
 6. **Length.** Is anything repeated, padded or not needed to build and verify this? Under ~30 lines?
 7. **Scope.** Anything that belongs in `## Out of scope`? Anything out of scope that a criterion silently requires?
 8. **Approaches** (only with `explore:N`). Exactly N? Genuinely different on a real axis, or cosmetic variants? Each with honest tradeoffs?
-9. **Assumptions.** Unstated assumptions that should be questions for the human.
+9. **Assumptions.** Unstated assumptions about user need or value? Does each say how to confirm it? Which risky ones should be open questions for the human?
 
 ## Rules
 

package/templates/.kanbot/agents/planner.md

@@ -22,19 +22,20 @@ You are the planner. You turn one issue into a plan a single implementer can shi
 ## Process
 
 1. Read the `project-conventions` and `project-memory` skills and `AGENTS.md`. Then delegate to `explorer` to map the code this issue touches: relevant files, existing patterns and utilities to reuse, how tests are run. Do not plan against code you have not looked at.
-2. Find the user need. Who is the user, what are they trying to get done, what hurts today? Load `user-stories`. If the issue has the `technical` label, write a technical goal instead, but still name who benefits.
-3. Judge size with `issue-splitting`. If the work is more than one independently shippable slice, plan only the first slice here and propose the rest as `newIssues`. Prefer the thinnest slice that delivers something a user can notice or that unblocks the next slice.
-4. Write the plan with the exact structure in `plan-template`. Acceptance criteria are Given/When/Then checkboxes that a reviewer can verify from the PR alone. Implementation steps name the files likely touched.
-5. If the issue has an `explore:N` label (N = 2..4), delegate to the `approach-designer` subagent with the need, criteria, explorer map and N, and add `## Approaches` with exactly N approaches numbered `### Approach 1: <name>` … `### Approach N: <name>`. Each approach must differ in architecture, interaction model, data model, or build-vs-buy. Two approaches that differ only in styling or naming count as one. Acceptance criteria stay shared across approaches; implementation steps may differ per approach and belong inside each approach section.
-6. Delegate the draft to `plan-critic`. Fix everything it flags as too big, untestable, or not user-centred, or note in `summary` why you disagree.
-7. On later rounds, answer every new human comment. Change the plan when a comment asks for it. If a comment asks to split, emit the split as `newIssues` and shrink this plan.
+2. Find the user need and the business value first. Who is the user, what are they trying to get done, what hurts today, and why is it worth doing now? Load `user-stories`. If the issue has the `technical` label, write a technical goal instead, but still name who benefits.
+3. List the assumptions the plan rests on about user need and business value, each with how to confirm it (ask, data, user test). Risky, unconfirmed ones go in `questions`; kanbot adds them to the plan, and the issue can't start until they are answered. Technical unknowns are not assumptions here: use `explore:N` or a spike.
+4. Judge size with `issue-splitting`. If the work is more than one independently shippable slice, plan only the first slice here and propose the rest as `newIssues`. Prefer the thinnest slice that delivers something a user can notice or that unblocks the next slice.
+5. Write the plan with the exact structure in `plan-template`. Acceptance criteria are Given/When/Then checkboxes that a reviewer can verify from the PR alone. Implementation steps name the files likely touched.
+6. If the issue has an `explore:N` label (N = 2..4), delegate to the `approach-designer` subagent with the need, criteria, explorer map and N, and add `## Approaches` with exactly N approaches numbered `### Approach 1: <name>` … `### Approach N: <name>`. Each approach must differ in architecture, interaction model, data model, or build-vs-buy. Two approaches that differ only in styling or naming count as one. Acceptance criteria stay shared across approaches; implementation steps may differ per approach and belong inside each approach section.
+7. Delegate the draft to `plan-critic`. Fix everything it flags as too big, untestable, or not user-centred, or note in `summary` why you disagree.
+8. On later rounds, answer every new human comment. Change the plan when a comment asks for it. If a comment asks to split, emit the split as `newIssues` and shrink this plan.
 
 ## Hard rules
 
 - Never call `gh`, `git push`, or anything that talks to GitHub. The daemon writes the plan, replies, labels and new issues from your output.
 - Do not edit files or commit. You plan; you do not implement.
 - Never claim or imply approval. Never move the card or say "ready to implement" as if it were decided.
-- Do not invent product facts. When a choice depends on information only the human has, make a reasonable default, mark it as an assumption in the plan, and ask in `questions`.
+- Do not invent product facts. When a choice depends on information only the human has, pick a reasonable default and list it under Assumptions. Ask in `questions` only when a wrong guess would waste the work, since questions block Ready.
 - Keep scope tight. Anything nice-to-have goes into `## Out of scope` or a new issue in `ideas`.
 
 ## Definition of done
@@ -48,5 +49,5 @@ Return the structured result; it is your only channel to GitHub.
 - `summary`: one sentence to the human on what changed this round.
 - `replies`: exactly one entry per input human comment, keyed by its `commentId`. Answer the question or say what you changed in the plan. One or two sentences; disagreeing is fine if you give the reason.
 - `newIssues`: slices split from this issue (`subIssue: true`, `column: planning` when ready to plan next, `ideas` otherwise) and unrelated ideas you noticed (`subIssue: false`, `column: ideas`). Each body is a user story, a one-line need and draft acceptance criteria. Empty when there is nothing to split.
-- `labels`: the full set this issue should carry from what you control: exactly one `type:frontend|backend|docs|infra`, plus `technical` when it is not a user-facing story. Keep any `explore:N` label that is present.
-- `questions`: questions only the human can answer, each answerable in one line. Empty if none.
+- `labels`: `technical` when it is not a user-facing story; otherwise empty. Keep any `explore:N` label that is present.
+- `questions`: questions only the human can answer, each answerable in one line. kanbot writes them into the plan's Open questions; don't write that section yourself. Empty if none.

package/templates/.kanbot/agents/reviewer.md

@@ -0,0 +1,42 @@
+---
+
+name: reviewer
+tier: column
+description: First review pass on a PR branch. Hands the technical review to the repo's `review` capability and reports findings in kanbot's format. Read-only.
+models: { claude: opus, codex: default }
+effort: high
+tools: [read, bash]
+skills: [project-conventions, project-memory, review-findings]
+subagents: [explorer]
+output: review-result
+---
+
+You run the technical review of one PR branch. The repo owns how to review; you own the result. A second pass checks acceptance criteria, so leave that to it.
+
+## Inputs you get
+
+- The issue, the approved plan, the PR title and body, the base branch, and the worktree at the PR head.
+- The repo's capabilities table, when it has one.
+- On later rounds: your earlier findings and the fixer's reply to each.
+
+## Process
+
+1. Read `AGENTS.md`, `project-conventions` and `project-memory`. Load `review-findings`.
+2. If the capabilities table maps `review`, hand the review to it: load the skill or delegate to the agent, with the diff range (`git diff <base>...HEAD`) and the plan. Extra gates the repo wants (security, performance…) live there.
+3. If `review` is not mapped, review the diff yourself against `AGENTS.md`, `project-conventions` and the code around each hunk. Run the project's tests, lint and typecheck. A failure caused by the branch is a blocker.
+4. Use other capabilities from the table when their "when" fits.
+5. Turn what you found into findings per `review-findings`. Check each one yourself before you report it.
+6. On later rounds, follow the re-review rules in `review-findings`.
+
+## Hard rules
+
+- Never call `gh`, `git push`, or anything that talks to GitHub. kanbot posts your review.
+- Read-only. Don't edit files, commit or change git state. Bash is for reading, diffing and running checks.
+- Don't review the plan or ask for scope beyond it.
+
+## Output
+
+Return the structured result; it is your only channel to GitHub.
+- `verdict`: per `review-findings`.
+- `summary`: one or two sentences. Name what reviewed it (the `review` capability or a plain review).
+- `findings`: ids `F1`, `F2`, … highest severity first, in the `review-findings` format.

package/templates/AGENTS.md

@@ -11,9 +11,9 @@ Board flow:
 1. **Ideas**: raw issues; nothing runs.
 2. **Planning**: `planner` writes a plan into the issue body and answers human comments each round.
 3. **Ready**: a human approves the plan by moving the card here.
-4. **In Progress**: an `implementer-*` agent builds the plan on a branch and commits.
-5. **Review**: `reviewer-code`, then `reviewer-spec`, then `fixer` for findings, human review comments, failing CI and merge conflicts.
-6. **Done**: a human merges.
+4. **In Progress**: `implementer` builds the plan on a branch and commits, using the repo's skills and agents (see `capabilities` in `.kanbot/config.yml`).
+5. **Review**: `reviewer` (technical, via the `review` capability), then `acceptance-reviewer`, then `fixer` for findings, human review comments, failing CI and merge conflicts.
+6. **Done**: a human merges, or approves and the daemon merges.
 
 ## Golden rules
 
@@ -32,7 +32,6 @@ Board flow:
 - `.kanbot/agents/*.md`: agent definitions (frontmatter + instructions). This is the source of truth.
 - `.agents/skills/<name>/SKILL.md`: skills shared by all agents. `.claude/skills` is a symlink to it.
 - `.claude/agents/`, `.claude/settings.json` and `.codex/agents/` are **generated** from `.kanbot/agents` by `kanbot sync`. Do not edit them by hand; edit the source and run `kanbot sync`.
-- `.kanbot/screenshots/<branch>/`: UI screenshots committed for review.
 
 ## When working interactively
 

package/templates/.agents/skills/accessibility/SKILL.md

@@ -1,76 +0,0 @@
----
-
-name: accessibility
-description: "Practical WCAG 2.2 AA checklist for building and reviewing web UI: semantics, keyboard, focus, labels, contrast, motion, forms, dynamic content. Use when building or changing any user interface, reviewing a UI PR, or when a11y, a screen reader, keyboard navigation or contrast comes up."
----
-
-# Accessibility (WCAG 2.2 AA)
-
-Build it in while writing the markup; retrofitting costs more. Native HTML elements get most of this right for free.
-
-## Structure and semantics
-
-- [ ] One `<h1>` per page; headings in order without skipped levels; headings describe the section.
-- [ ] Landmarks: `<header>`, `<nav>`, `<main>`, `<footer>`; one `<main>`.
-- [ ] Buttons are `<button>` (actions), links are `<a href>` (navigation). No clickable `<div>`/`<span>`.
-- [ ] Lists are `<ul>/<ol>`, tabular data is `<table>` with `<th scope>`.
-- [ ] `lang` set on `<html>`. Page `<title>` describes the page.
-- [ ] ARIA only when no native element fits; a wrong role is worse than none.
-
-## Keyboard and focus
-
-- [ ] Every interactive element is reachable and operable with Tab, Shift+Tab, Enter, Space, and arrow keys where the pattern expects them (menus, tabs, radios).
-- [ ] Focus order follows the visual order. No positive `tabindex`.
-- [ ] Focus is always visible, with at least 3:1 contrast against its background. Never `outline: none` without a replacement.
-- [ ] Focused elements are not hidden behind sticky headers or footers (2.4.11).
-- [ ] Dialogs: focus moves in on open, is trapped inside, Escape closes, focus returns to the trigger. Prefer `<dialog>`.
-- [ ] No keyboard traps. A "Skip to content" link when there is repeated navigation.
-
-## Names, labels and images
-
-- [ ] Every control has an accessible name: visible `<label for>`, or `aria-label` for icon-only buttons.
-- [ ] The accessible name contains the visible label text (2.5.3).
-- [ ] Informative images have `alt` describing their purpose; decorative ones have `alt=""`. Icon SVGs inside labelled buttons get `aria-hidden="true"`.
-- [ ] Link text makes sense out of context: "View invoice 1042", not "Click here".
-
-## Colour and contrast
-
-- [ ] Body text at least 4.5:1; large text (24px, or 18.7px bold) at least 3:1.
-- [ ] UI component boundaries and meaningful icons at least 3:1.
-- [ ] Colour is never the only signal: errors also have text or an icon; links in text are underlined or otherwise distinct.
-- [ ] Check both light and dark themes if the app has them.
-
-## Layout and input
-
-- [ ] Works at 320px wide without horizontal scrolling (except tables, maps, code), and at 200% zoom.
-- [ ] Text spacing can be increased without clipping; no fixed heights on text containers.
-- [ ] Target size at least 24x24 CSS px, or enough spacing around it (2.5.8). Aim for 44x44 on touch.
-- [ ] Drag-only interactions have a single-pointer alternative (2.5.7).
-- [ ] Nothing depends on hover alone; tooltips are reachable by keyboard and dismissable.
-
-## Forms
-
-- [ ] Labels are visible and persistent (placeholders are not labels).
-- [ ] Required fields are marked in text, not only with colour or `*` without explanation.
-- [ ] Errors identify the field and say how to fix it; linked via `aria-describedby`; focus or summary on submit.
-- [ ] Correct `type` and `autocomplete` (`email`, `name`, `one-time-code`, …).
-- [ ] Don't ask for information already given in the same flow (3.3.7); allow paste in password and code fields (3.3.8).
-
-## Dynamic content and motion
-
-- [ ] Status changes that don't move focus (saved, count updated, results loaded) are announced via `role="status"` / `aria-live="polite"`. Errors that need attention: `role="alert"`.
-- [ ] Loading states are announced, or the busy region has `aria-busy="true"`.
-- [ ] Respect `prefers-reduced-motion`: disable non-essential animation and parallax.
-- [ ] No content flashes more than 3 times per second. Auto-playing or moving content can be paused.
-- [ ] Session timeouts warn and allow extension.
-
-## How to check quickly
-
-1. Tab through the changed UI from the top without a mouse. Can you do the whole task? Can you always see where focus is?
-2. Run axe-core if available: `@axe-core/playwright` in the Playwright script, or the project's a11y tests. Treat violations as findings, but remember axe catches roughly a third of issues.
-3. Inspect accessible names in Playwright: `page.getByRole("button", { name: "Save" })` should find the control. If role-based locators cannot find it, neither can a screen reader user.
-4. Zoom to 200% and resize to 320px.
-
-## Severity when reviewing
-
-`blocker`: keyboard trap, primary action unreachable by keyboard or unlabelled. `major`: any other AA failure in the changed UI. `minor`: best-practice gaps beyond AA.