kanbot 0.2.0 → 0.4.0

package/src/providers/claude.ts

@@ -8,6 +8,7 @@ import {
 	CLAUDE_DENY,
 	claudeTools,
 } from "../agents/sync.ts";
+import { mcpConfigPath } from "./mcp.ts";
 import {
 	looksRateLimited,
 	type Provider,
@@ -25,45 +26,54 @@ type ResultEvent = {
 	api_error_status?: number | null;
 };
 
+/** CLI args for a headless run. */
+export function claudeArgs(input: RunInput, agentsFile: string): string[] {
+	const { agent } = input;
+	const cmd = [
+		"claude",
+		"-p",
+		"--agents",
+		agentsFile,
+		"--agent",
+		agent.name,
+		"--output-format",
+		"stream-json",
+		"--verbose",
+		"--json-schema",
+		JSON.stringify(input.schema),
+		"--permission-mode",
+		"acceptEdits",
+		"--allowedTools",
+		...headlessTools(agent),
+		"--disallowedTools",
+		...CLAUDE_DENY,
+		"--no-session-persistence",
+		// Isolate from the user's own setup: no user-level plugins, skills or
+		// MCP servers, so workers only see the repo's agents and skills.
+		"--setting-sources",
+		"project,local",
+		"--strict-mcp-config",
+		"--settings",
+		JSON.stringify(CLAUDE_ATTRIBUTION),
+	];
+	// The repo's committed MCP servers only.
+	const mcp = mcpConfigPath(input.cwd);
+	if (mcp) cmd.push("--mcp-config", mcp);
+	if (agent.models.claude) cmd.push("--model", agent.models.claude);
+	if (agent.effort) cmd.push("--effort", agent.effort);
+	return cmd;
+}
+
 /** Claude Code headless (`claude -p`), using the logged-in subscription. */
 export const claude: Provider = {
 	name: "claude",
 	async run(input: RunInput): Promise<RunResult> {
-		const { agent } = input;
 		// Pass agent definitions explicitly so runs don't depend on what is
 		// committed in the worktree's .claude/agents.
 		const tmp = await mkdtemp(join(tmpdir(), "kanbot-claude-"));
 		const agentsFile = join(tmp, "agents.json");
 		await Bun.write(agentsFile, JSON.stringify(claudeAgentsJson(input.agents)));
-		const cmd = [
-			"claude",
-			"-p",
-			"--agents",
-			agentsFile,
-			"--agent",
-			agent.name,
-			"--output-format",
-			"stream-json",
-			"--verbose",
-			"--json-schema",
-			JSON.stringify(input.schema),
-			"--permission-mode",
-			"acceptEdits",
-			"--allowedTools",
-			...headlessTools(agent),
-			"--disallowedTools",
-			...CLAUDE_DENY,
-			"--no-session-persistence",
-			// Isolate from the user's own setup: no user-level plugins, skills or
-			// MCP servers, so workers only see the repo's agents and skills.
-			"--setting-sources",
-			"project,local",
-			"--strict-mcp-config",
-			"--settings",
-			JSON.stringify(CLAUDE_ATTRIBUTION),
-		];
-		if (agent.models.claude) cmd.push("--model", agent.models.claude);
-		if (agent.effort) cmd.push("--effort", agent.effort);
+		const cmd = claudeArgs(input, agentsFile);
 
 		const res = await spawnWorker(cmd, {
 			cwd: input.cwd,

package/src/providers/codex.ts

@@ -1,8 +1,10 @@
 import { mkdtemp, rm } from "node:fs/promises";
 import { tmpdir } from "node:os";
 import { join } from "node:path";
+import type { AgentDef } from "../agents/load.ts";
 import { agentInstructions } from "../agents/sync.ts";
 import { git } from "../daemon/git.ts";
+import { codexMcpArgs, type McpServer, readMcpServers } from "./mcp.ts";
 import {
 	looksRateLimited,
 	type Provider,
@@ -11,6 +13,58 @@ import {
 	spawnWorker,
 } from "./types.ts";
 
+/** CLI args for a headless run. */
+export function codexArgs(o: {
+	agent: AgentDef;
+	cwd: string;
+	gitDir: string;
+	schemaFile: string;
+	lastFile: string;
+	networkAccess: boolean;
+	mcpServers: Record<string, McpServer>;
+}): string[] {
+	const { agent } = o;
+	const sandbox =
+		agent.tools.includes("edit") || agent.tools.includes("bash")
+			? "workspace-write"
+			: "read-only";
+	const cmd = [
+		"codex",
+		"exec",
+		"--json",
+		"--ephemeral",
+		// Isolate from the user's own setup: no user-level plugins or MCP
+		// servers. Auth still comes from CODEX_HOME.
+		"--ignore-user-config",
+		"--sandbox",
+		sandbox,
+		"--cd",
+		o.cwd,
+		"--add-dir",
+		o.gitDir,
+		"--output-schema",
+		o.schemaFile,
+		"--output-last-message",
+		o.lastFile,
+		"-c",
+		`developer_instructions=${JSON.stringify(agentInstructions(agent))}`,
+		// The repo's committed MCP servers only.
+		...codexMcpArgs(o.mcpServers),
+	];
+	if (o.networkAccess)
+		cmd.push("-c", "sandbox_workspace_write.network_access=true");
+	if (agent.models.codex && agent.models.codex !== "default")
+		cmd.push("--model", agent.models.codex);
+	if (agent.effort) {
+		cmd.push(
+			"-c",
+			`model_reasoning_effort="${agent.effort === "max" ? "xhigh" : agent.effort}"`,
+		);
+	}
+	cmd.push("-");
+	return cmd;
+}
+
 /** Codex CLI headless (`codex exec`), using the logged-in ChatGPT plan. */
 export function codex({ networkAccess }: { networkAccess: boolean }): Provider {
 	return {
@@ -29,39 +83,15 @@ export function codex({ networkAccess }: { networkAccess: boolean }): Provider {
 					"--path-format=absolute",
 					"--git-common-dir",
 				);
-				const sandbox =
-					agent.tools.includes("edit") || agent.tools.includes("bash")
-						? "workspace-write"
-						: "read-only";
-				const cmd = [
-					"codex",
-					"exec",
-					"--json",
-					"--ephemeral",
-					"--sandbox",
-					sandbox,
-					"--cd",
-					input.cwd,
-					"--add-dir",
+				const cmd = codexArgs({
+					agent,
+					cwd: input.cwd,
 					gitDir,
-					"--output-schema",
 					schemaFile,
-					"--output-last-message",
 					lastFile,
-					"-c",
-					`developer_instructions=${JSON.stringify(agentInstructions(agent))}`,
-				];
-				if (networkAccess)
-					cmd.push("-c", "sandbox_workspace_write.network_access=true");
-				if (agent.models.codex && agent.models.codex !== "default")
-					cmd.push("--model", agent.models.codex);
-				if (agent.effort) {
-					cmd.push(
-						"-c",
-						`model_reasoning_effort="${agent.effort === "max" ? "xhigh" : agent.effort}"`,
-					);
-				}
-				cmd.push("-");
+					networkAccess,
+					mcpServers: await readMcpServers(input.cwd),
+				});
 
 				const res = await spawnWorker(cmd, {
 					cwd: input.cwd,

package/src/providers/mcp.ts

@@ -0,0 +1,71 @@
+import { existsSync } from "node:fs";
+import { join } from "node:path";
+
+/*
+ * Workers get the repo's committed MCP servers, never the user's own.
+ * `.mcp.json` (Claude's format) is the one source for both providers.
+ */
+
+export type McpServer = {
+	type?: string;
+	command?: string;
+	args?: string[];
+	env?: Record<string, string>;
+	url?: string;
+	headers?: Record<string, string>;
+};
+
+export function mcpConfigPath(dir: string): string | null {
+	const path = join(dir, ".mcp.json");
+	return existsSync(path) ? path : null;
+}
+
+/** Servers in `<dir>/.mcp.json`. Empty when missing or unreadable. */
+export async function readMcpServers(
+	dir: string,
+): Promise<Record<string, McpServer>> {
+	const path = mcpConfigPath(dir);
+	if (!path) return {};
+	try {
+		const json = (await Bun.file(path).json()) as {
+			mcpServers?: Record<string, McpServer>;
+		};
+		return json.mcpServers ?? {};
+	} catch {
+		return {};
+	}
+}
+
+/** Codex runs stdio and streamable HTTP servers. Others (e.g. sse) are left out. */
+export function codexSupports(s: McpServer): boolean {
+	if (s.type === "sse") return false;
+	return Boolean(s.command || s.url);
+}
+
+const str = (s: string) => JSON.stringify(s);
+const table = (o: Record<string, string>) =>
+	`{${Object.entries(o)
+		.map(([k, v]) => `${str(k)}=${str(v)}`)
+		.join(",")}}`;
+
+/** `-c mcp_servers=…` for codex, as an inline TOML table. Empty when none. */
+export function codexMcpArgs(servers: Record<string, McpServer>): string[] {
+	const entries = Object.entries(servers)
+		.filter(([, s]) => codexSupports(s))
+		.map(([name, s]) => {
+			const fields = s.command
+				? [
+						`command=${str(s.command)}`,
+						s.args?.length ? `args=[${s.args.map(str).join(",")}]` : "",
+						s.env && Object.keys(s.env).length ? `env=${table(s.env)}` : "",
+					]
+				: [
+						`url=${str(s.url as string)}`,
+						s.headers && Object.keys(s.headers).length
+							? `http_headers=${table(s.headers)}`
+							: "",
+					];
+			return `${str(name)}={${fields.filter(Boolean).join(",")}}`;
+		});
+	return entries.length ? ["-c", `mcp_servers={${entries.join(",")}}`] : [];
+}

package/src/schemas/results.ts

@@ -35,7 +35,7 @@ export const PlanResult = z.strictObject({
 		.describe("Issues to create, e.g. when the human asks to split work."),
 	labels: z
 		.array(z.string())
-		.describe("Labels the issue should have, e.g. type:frontend or technical."),
+		.describe("Labels the issue should have, e.g. technical."),
 	questions: z
 		.array(z.string())
 		.describe(
@@ -55,9 +55,6 @@ export const ImplementResult = z.strictObject({
 	testsRun: z
 		.array(z.string())
 		.describe("One line each: command and result, e.g. `bun test`: 5 pass."),
-	screenshots: z
-		.array(z.string())
-		.describe("Repo-relative paths of screenshots committed for review."),
 	risks: z
 		.array(z.string())
 		.describe("Real risks only, one line each. Empty when none."),
@@ -98,7 +95,7 @@ export const FixResult = z.strictObject({
 		.string()
 		.nullable()
 		.describe(
-			"Full updated PR description when your changes made the current one wrong (behaviour, copy, screenshots); null otherwise.",
+			"Full updated PR description when your changes made the current one wrong (behaviour, copy, validation); null otherwise.",
 		),
 });
 export type FixResult = z.infer<typeof FixResult>;

package/src/templates.ts

@@ -24,6 +24,7 @@ export type FileClass = "kanbot" | "user" | "shared";
 const CLASSES: [prefix: string, FileClass][] = [
 	[".github/workflows/kanbot-", "kanbot"],
 	[".agents/skills/kanbot-admin/", "kanbot"],
+	[".agents/skills/kanbot-guide/", "kanbot"],
 	[".agents/skills/kanbot-idea/", "kanbot"],
 	["AGENTS.md", "user"],
 	["CLAUDE.md", "user"],

package/templates/.agents/skills/approach-designer/SKILL.md

@@ -17,7 +17,7 @@ Pick the axis where the decision matters most for this problem, then spread appr
 | Interaction model | Search box · faceted filters · timeline browsing                            |
 | Where logic lives | Client-side filtering of loaded data · server query endpoint · search index |
 | Data model        | Denormalised read model · query on existing tables · materialised view      |
-| Build vs. reuse   | Custom component · existing design-system table · third-party library       |
+| Build vs. reuse   | Build it · reuse what the project has · third-party library                 |
 | Timing            | Synchronous · background job with notification · precomputed nightly        |
 | Scope of change   | Minimal tweak to the current screen · new dedicated screen                  |
 

package/templates/.agents/skills/kanbot-admin/SKILL.md

@@ -1,12 +1,12 @@
 ---
 
 name: kanbot-admin
-description: Maintain this repo's kanbot setup with a human. Use to add or edit kanbot agents, skills or project memory, change `.kanbot/config.yml`, run `kanbot upgrade` or merge `.kanbot-new` files. Not for board jobs.
+description: Change this repo's kanbot setup with a human. Use to add or edit kanbot agents, skills or project memory, map capabilities, give workers MCP servers, change `.kanbot/config.yml`, switch identity mode, turn on merge on approval, run `kanbot upgrade` or merge `.kanbot-new` files. Not for board jobs. For setup walkthroughs and explaining options, use kanbot-guide.
 ---
 
 # kanbot admin
 
-You are helping a human maintain kanbot, the board-driven agent team in this repo. Board agents (planner, implementers, reviewers, fixer) never use this skill.
+You are helping a human maintain kanbot, the board-driven agent team in this repo. Board agents (planner, implementer, reviewers, fixer) never use this skill. To explain options or set kanbot up from scratch, use `kanbot-guide`.
 
 ## Map
 
@@ -14,27 +14,58 @@ You are helping a human maintain kanbot, the board-driven agent team in this rep
 | -------------------------- | -------------------------------------- | ------------------------------- |
 | `.kanbot/agents/<name>.md` | Agent definitions, the source of truth | Yes, then `kanbot sync`         |
 | `.agents/skills/<name>/`   | Skills shared by all agents            | Yes                             |
-| `.kanbot/config.yml`       | Daemon config; schema next to it       | Yes                             |
+| `.kanbot/config.yml`       | Daemon config; schema next to it       | Yes, then restart the daemon    |
+| `.mcp.json`                | MCP servers workers get                | Yes, then commit                |
 | `.kanbot/manifest.json`    | Template hashes from the last upgrade  | Never by hand                   |
 | `.claude/`, `.codex/`      | Generated by `kanbot sync`             | Never; edit the source and sync |
+| `~/.kanbot/apps/<id>.pem`  | Private key of the kanbot GitHub App   | Never commit                    |
 
-`kanbot <command> --help` lists every flag. Agent frontmatter fields and output schemas: read an existing agent in `.kanbot/agents/` and copy its shape.
+`kanbot <command> --help` lists every flag. `.kanbot/config.schema.json` describes every config field. Docs: https://kanbot.mib.im.
 
 ## Recipes
 
-Finish every recipe with `kanbot sync` when agents changed, then `kanbot doctor`, then show the human the diff. The human commits and pushes; worktrees are made from the pushed base branch, so agents see nothing until then.
+Finish every recipe with `kanbot sync` when agents changed, then `kanbot doctor`, then show the human the diff. The human commits and pushes; worktrees are made from the pushed base branch, so agents see nothing until then. Restart the daemon after config changes.
+
+### Switch to app mode
+
+1. `kanbot app create`. The human clicks **Create GitHub App** on GitHub, then installs it on the repo.
+2. Already have an app from another repo? `kanbot app link --id <id> --slug <slug>`, add the repo to its installation, and copy `~/.kanbot/apps/<id>.pem` if on another machine.
+3. `kanbot doctor` checks the app, its key and the install.
+
+Back to user mode: set `identity.mode: user`.
+
+### Turn on merge on approval
+
+1. Set `merge.onApproval: true` and pick `merge.method` (`squash`, `merge` or `rebase`).
+2. Recommend app mode, so they can approve their own kanbot PRs.
+3. Warn: never enable the branch rule "Require approval of the most recent reviewable push". It blocks their own approval.
+
+### Map a capability
+
+kanbot's agents run the process; the repo's own skills and agents do the work on code. Capabilities tell them which to use.
+
+1. Make sure the skill is in `.agents/skills/<name>/` or the agent in `.kanbot/agents/`. A `.claude/agents` or `.codex/agents` agent works on one provider only.
+2. Add it under `capabilities` in config: `review: code-review`, or `{ use, when, required }` when it only applies sometimes or a miss should block acceptance review.
+3. Reserved names: `verify` (prove acceptance criteria), `review` (technical review, pass 1), `preview` (something a human can try). Any other name is the human's.
+4. `kanbot doctor` lists what's mapped, flags a missing `use`, and names reserved needs not yet mapped.
+
+Don't add implementers or `type:*` labels. `implementers` in config is deprecated: replace it with capabilities and remove it.
+
+### Give workers an MCP server
+
+Add it to `.mcp.json` (Claude's format) and commit. Workers get only these servers, never the human's own. Codex can't run `sse` servers; `kanbot doctor` lists what workers get.
 
 ### Add or change an agent
 
 1. Copy the closest existing agent. `name` must match the filename.
 2. Column agents (`tier: column`) need an `output` schema; subagents (`tier: sub`) are reached through a column agent's `subagents`.
-3. A new implementer also needs an entry under `implementers` in config and a matching `type:<x>` label on GitHub. Tell the human to create the label.
+3. To have board agents use it, map it as a capability (above).
 4. The body says _how_ to work. The daemon's prompt carries the task.
 
 ### Add a skill
 
 1. Create `.agents/skills/<name>/SKILL.md` with `name` (matches the folder) and a `description` that says what it covers and when it applies.
-2. Add the name to `skills` in each agent that should load it.
+2. For work on code, map it as a capability. For kanbot's own process, add the name to `skills` in each agent that should load it. `kanbot doctor` fails on skills that don't exist.
 
 ### Add a memory
 
@@ -45,6 +76,7 @@ When the human says "remember that …" or corrects something agents keep gettin
 1. Run `bunx kanbot@latest upgrade --dry-run` and summarise it for the human.
 2. Run `bunx kanbot@latest upgrade`.
 3. Merge every `.kanbot-new` file (below).
+4. Files kanbot no longer ships stay in place. If the repo had kanbot's old craft skills (`verify-ui`, `code-review`, `tdd`…) and no `capabilities`, upgrade maps them. Show the human the new `capabilities` block. Old `implementer-*` and `reviewer-*` agents are unused once the new ones exist; the human may delete them.
 
 ### Merge `.kanbot-new` files
 

package/templates/.agents/skills/kanbot-guide/SKILL.md

@@ -0,0 +1,110 @@
+---
+
+name: kanbot-guide
+description: Explain kanbot and guide a human through it. Use when someone asks what kanbot is, how to set it up in a repo, which config options to pick (provider, bot or user identity, merge on approval, Copilot, notifications), how the board flow works, where something is documented, or why something isn't working. Works before kanbot is installed in the repo. For changing agents, skills or upgrading, use kanbot-admin.
+---
+
+# kanbot guide
+
+You are helping a human understand and set up kanbot: a daemon that runs a team of Claude Code or Codex agents from a GitHub Project board. They write and prioritize issues; agents plan, build, review and fix; they approve plans and merge.
+
+Explain in plain words. Ask before choosing for them; give a recommendation with one line of why. Docs live at https://kanbot.mib.im/<slug>. Link the page instead of repeating it.
+
+## Docs
+
+| Question                                      | Slug                |
+| --------------------------------------------- | ------------------- |
+| How do I install and set up a repo?           | `getting-started`   |
+| How does a card move across the board?        | `workflow`          |
+| How do I file ideas by chatting?              | `capturing-ideas`   |
+| My own PRs, local sessions, direct commits?   | `outside-the-board` |
+| Which agents are there, how do I change them? | `agents`            |
+| Skills and project memory?                    | `skills`            |
+| Claude or Codex?                              | `providers`         |
+| Every config field, labels, notifications     | `configuration`     |
+| Using our own skills and agents for the work  | `capabilities`      |
+| Copilot as an extra reviewer                  | `copilot-review`    |
+| Bot or user identity, merge by approving      | `identity`          |
+| Upgrading and `.kanbot-new` files             | `upgrading`         |
+| Every command and flag                        | `usage`             |
+
+## Board flow
+
+Ideas (you write) → Planning (agent plans, you comment) → Ready (you approve by moving the card) → In Progress (agent builds, opens a PR) → Review (technical, then acceptance review, with fixes; you comment) → Done (you merge, or approve and kanbot merges).
+
+kanbot runs the process; the repo's own skills and agents do the work on code, through capabilities. Plans list assumptions about user need; open questions keep a card from starting in Ready.
+
+Agents never get a GitHub token. The daemon does every comment, push and PR. Only collaborators with write access can steer agents. Workers see only what's committed, including MCP servers in `.mcp.json`; never the user's own plugins or servers.
+
+## Guided setup
+
+Go step by step. Run each command, check its output, then go on. If `.kanbot/config.yml` exists, run `kanbot doctor` first and skip what passes.
+
+1. **Requirements.** Bun 1.3+, `gh` logged in, `claude` or `codex` logged in with a subscription (not an API key). Run `gh auth refresh -s project`.
+2. **Provider.** Ask which subscription they have, then `bunx kanbot init --provider claude|codex` in the repo root.
+3. **Conventions.** Fill in `.agents/skills/project-conventions/SKILL.md` with them: stack, commands to test, lint and typecheck. Adjust `.github/workflows/ci.yml` to run the same. Every agent reads this first.
+4. **Capabilities.** kanbot runs the process; the repo's own skills and agents do the work. Ask which skills they have for proving acceptance criteria (`verify`), technical review (`review`) and something a human can try (`preview`), and map them under `capabilities` in `.kanbot/config.yml`. See [Capabilities](#capabilities).
+5. **Board.** `kanbot board create`, or `kanbot board link --owner <login> --number <n>` for an existing project. Have them enable the four built-in project workflows it prints; they can't be set through the API.
+6. **Options.** Go through [Choose options](#choose-options). For app mode, run `kanbot app create` and have them install the app on the repo.
+7. **Commit and push** the kanbot files. Agents only see what's on the pushed base branch.
+8. **Check.** `kanbot doctor` until it passes, then `kanbot run --once --dry-run`, then `kanbot run`.
+9. **First card.** Have them write an issue, put it in Planning and read the plan. Point to `workflow`.
+
+## Capabilities
+
+```yaml
+capabilities:
+  verify: { use: e2e-tests, when: Changes users see }
+  preview: { use: deploy-preview, required: true }
+  review: code-review # bare name: no when, not required
+```
+
+- `use`: a skill in `.agents/skills` or an agent in `.kanbot/agents`. `when`: when it applies. `required: true`: a miss blocks acceptance review.
+- Any other name is theirs (`benchmark`, `security`…). Unmapped needs are left to the agent.
+- Suggest, don't install: no `verify` → a skill that runs the app or end-to-end tests; no `preview` → a preview deploy or test build; no `review` → a review skill with their checklist. `kanbot doctor` names what's not mapped.
+
+## Choose options
+
+Ask only about what matters to them. Defaults are fine for the rest. Options live in `.kanbot/config.yml`; restart the daemon after changes.
+
+| Option                             | Ask                                                       | Recommend                                                                                                                       |
+| ---------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| `identity.mode` (`user` \| `app`)  | Should kanbot talk as you, or as its own bot?             | `app`: clear who said what, GitHub notifies you, and you can approve its PRs. `user` for zero setup. Commits are yours in both. |
+| `merge.onApproval`, `merge.method` | Merge by approving the PR, or press merge yourself?       | `true` with `app` mode. In `user` mode only another collaborator can approve.                                                   |
+| `provider`                         | Claude or ChatGPT subscription?                           | Whichever they pay for.                                                                                                         |
+| `concurrency`                      | How many agents at once?                                  | Default 3. Lower on a small machine or near usage limits.                                                                       |
+| `review.copilot`                   | Want GitHub Copilot as an extra reviewer? (costs credits) | Off unless they have a paid Copilot plan.                                                                                       |
+| `notify.desktop`, `notify.webhook` | Where do you want to hear that a PR is ready?             | Desktop. Add an ntfy.sh webhook for phone alerts.                                                                               |
+| `codex.networkAccess`              | Do agents need to install packages? (Codex only)          | Off unless installs fail.                                                                                                       |
+| `explore:N` label                  | Want several approaches built for some issues?            | Per issue, not config.                                                                                                          |
+
+### Who does what
+
+| Action                                    | `user` mode            | `app` mode   |
+| ----------------------------------------- | ---------------------- | ------------ |
+| Comments, PRs, labels, issue and PR edits | User, `🤖 kanbot` line | `<app>[bot]` |
+| Commits, pushes, merges, board moves      | User                   | User         |
+
+Board moves stay on the user's account: GitHub Apps can't use boards owned by a personal account.
+
+### App mode
+
+- `kanbot app create` opens GitHub; they click **Create GitHub App**, then install it on the repo. The key goes in `~/.kanbot/apps/<id>.pem`; never commit it.
+- Same app in another repo: `kanbot app link --id <id> --slug <slug>`, then add the repo to the app's installation.
+- Back to user mode: `identity.mode: user`.
+
+### Merge on approval
+
+kanbot merges, as the user, only `kanbot/*` PRs that are agent-reviewed, approved on the latest commit by a collaborator, with no open change request, passing checks, no conflicts and no `needs-human`. A push after approval needs a new approval.
+
+Warn: never enable the branch rule "Require approval of the most recent reviewable push". The user's account pushes kanbot's commits, so it blocks their own approval.
+
+## Troubleshoot
+
+1. `kanbot doctor`: prints a fix for each failed check.
+2. `kanbot status`: board by column, daemon, failures, rate-limit pause.
+3. `.kanbot/logs/*.jsonl`: full agent transcripts.
+4. `needs-human` label: the issue has a comment saying why. Fix the cause, then remove the label to retry.
+5. Nothing happens: is the daemon running, are kanbot files pushed to the base branch, is the card in an active column?
+6. Card stays in Ready: the plan has open questions. kanbot commented on the issue. Answer them in Planning, or remove them from the plan.
+7. Agent didn't use a skill: is it mapped under `capabilities`, does its `when` fit, and is it committed?

package/templates/.agents/skills/kanbot-idea/SKILL.md

@@ -45,7 +45,7 @@ Match the repo's issue template, so the issue reads like one filed through GitHu
 <notes, or _None._>
 ```
 
-Title: the outcome in under 70 characters. Technical issues get the `technical` label. Leave `type:*` labels to the planner.
+Title: the outcome in under 70 characters. Technical issues get the `technical` label.
 
 Show the title and body. File it only after the human says yes.
 

package/templates/.agents/skills/plan-template/SKILL.md

@@ -20,13 +20,18 @@ Need: <one or two sentences: what hurts today and how we'll know it worked.>
 - [ ] Given <context>, when <action>, then <observable result>.
 <!-- 2-6 items. Cover the happy path plus the edge cases that matter. -->
 
+## Assumptions
+
+- <What the plan assumes about the user's need or the business value.> Confirm: <ask, data, or a user test>.
+<!-- 1-4 items. Risky, unconfirmed ones also go in `questions`. -->
+
 ## Out of scope
 
 - <Only what a reader would otherwise expect. Omit the section if nothing.>
 
 ## Design notes
 
-<UI: placement, key copy, states that differ from the obvious. Non-UI: API or data shape. 1-4 lines. Omit if nothing beyond the criteria.>
+<Decisions the criteria don't settle: what users see or call, key copy, data shape. 1-4 lines. Omit if nothing beyond the criteria.>
 
 ## Implementation steps
 
@@ -39,12 +44,14 @@ Need: <one or two sentences: what hurts today and how we'll know it worked.>
 
 ## Open questions
 
-- <Only what blocks the human's approval, with the default you assume. Omit if none.>
+<!-- Don't write this section. kanbot fills it from your `questions` output. Open questions keep the issue out of Ready. -->
 ```
 
 ## Rules
 
 - Required: User story (or Technical goal), Acceptance criteria, Implementation steps. Omit other sections when empty; don't write "None."
+- Assumptions are about user need and business value, not code. Technical unknowns go in `explore:N` or a spike.
+- Ask a question (`questions` output) only if building on a wrong guess would waste the work. kanbot won't start while any are open.
 - One line per bullet. No prose paragraphs, no repeating the issue text.
 - Acceptance criteria are shared by all approaches. Approach-specific steps go inside each `### Approach k`.
 - File paths come from reading the code, not guesses. Mark new files "(new)".
@@ -65,6 +72,11 @@ Need: entries without a project silently drop off invoices; users find out when
 - [ ] Given every entry has a project, when I open the month view, then the list is hidden.
 - [ ] Given loading fails, when I open the month view, then the list shows "Couldn't load entries" and "Try again".
 
+## Assumptions
+
+- Users fix missing projects before invoicing, not after. Confirm: ask two users how they invoice.
+- Most months have under 20 such entries. Confirm: query last quarter's data.
+
 ## Out of scope
 
 - Bulk-assigning projects (new issue).
@@ -78,8 +90,4 @@ List sits above the calendar, collapsed to 5 rows with "Show all (n)". Reuse `Pr
 1. Add `missingProject` filter to `GET /entries`, with tests. Files: `api/entries/routes.ts`
 2. Add `MissingProjectSection` with its states and tests. Files: `web/entries/MissingProjectSection.tsx` (new)
 3. Mount it in the month view and refresh after assignment. Files: `web/month/MonthView.tsx`
-
-## Open questions
-
-- Include earlier months? Default: current month only.
 ```

package/templates/.agents/skills/pr-description/SKILL.md

@@ -27,8 +27,12 @@ Conventional commit, imperative, under 72 characters, naming the user-visible ef
 
 ## Screenshots
 
-![<state, width>](.kanbot/screenshots/<branch>/<name>.png)
-<!-- UI changes only; 1-3 images that show the change. -->
+![<state>](repo-relative path to a committed image)
+<!-- Optional. Only when the change is visible; 1-3 images. -->
+
+## Validation
+
+- <What you used to prove it works (tests, skills, preview) and what it showed. 1-3 bullets.>
 
 ## Notes for reviewer
 
@@ -40,5 +44,5 @@ Conventional commit, imperative, under 72 characters, naming the user-visible ef
 - One line per bullet. No "Why" section; the issue has it.
 - Describe what the code does now, not how you got there.
 - Anything you could not verify goes in `risks`, not the body.
-- Screenshot paths must match the `screenshots` output field.
+- Omit Screenshots when there is nothing to show.
 - Aim for under 20 lines.