kanbot 0.2.0 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,91 @@
1
+ ---
2
+
3
+ name: kanbot-guide
4
+ 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.
5
+ ---
6
+
7
+ # kanbot guide
8
+
9
+ 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.
10
+
11
+ 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.
12
+
13
+ ## Docs
14
+
15
+ | Question | Slug |
16
+ | --------------------------------------------- | ------------------- |
17
+ | How do I install and set up a repo? | `getting-started` |
18
+ | How does a card move across the board? | `workflow` |
19
+ | How do I file ideas by chatting? | `capturing-ideas` |
20
+ | My own PRs, local sessions, direct commits? | `outside-the-board` |
21
+ | Which agents are there, how do I change them? | `agents` |
22
+ | Skills and project memory? | `skills` |
23
+ | Claude or Codex? | `providers` |
24
+ | Every config field, labels, notifications | `configuration` |
25
+ | Copilot as an extra reviewer | `copilot-review` |
26
+ | Bot or user identity, merge by approving | `identity` |
27
+ | Upgrading and `.kanbot-new` files | `upgrading` |
28
+ | Every command and flag | `usage` |
29
+
30
+ ## Board flow
31
+
32
+ Ideas (you write) → Planning (agent plans, you comment) → Ready (you approve by moving the card) → In Progress (agent builds, opens a PR) → Review (two agent reviews with fixes; you comment) → Done (you merge, or approve and kanbot merges).
33
+
34
+ Agents never get a GitHub token. The daemon does every comment, push and PR. Only collaborators with write access can steer agents.
35
+
36
+ ## Guided setup
37
+
38
+ 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.
39
+
40
+ 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`.
41
+ 2. **Provider.** Ask which subscription they have, then `bunx kanbot init --provider claude|codex` in the repo root.
42
+ 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.
43
+ 4. **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.
44
+ 5. **Options.** Go through [Choose options](#choose-options). For app mode, run `kanbot app create` and have them install the app on the repo.
45
+ 6. **Commit and push** the kanbot files. Agents only see what's on the pushed base branch.
46
+ 7. **Check.** `kanbot doctor` until it passes, then `kanbot run --once --dry-run`, then `kanbot run`.
47
+ 8. **First card.** Have them write an issue, put it in Planning and read the plan. Point to `workflow`.
48
+
49
+ ## Choose options
50
+
51
+ Ask only about what matters to them. Defaults are fine for the rest. Options live in `.kanbot/config.yml`; restart the daemon after changes.
52
+
53
+ | Option | Ask | Recommend |
54
+ | ---------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
55
+ | `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. |
56
+ | `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. |
57
+ | `provider` | Claude or ChatGPT subscription? | Whichever they pay for. |
58
+ | `concurrency` | How many agents at once? | Default 3. Lower on a small machine or near usage limits. |
59
+ | `review.copilot` | Want GitHub Copilot as an extra reviewer? (costs credits) | Off unless they have a paid Copilot plan. |
60
+ | `notify.desktop`, `notify.webhook` | Where do you want to hear that a PR is ready? | Desktop. Add an ntfy.sh webhook for phone alerts. |
61
+ | `codex.networkAccess` | Do agents need to install packages? (Codex only) | Off unless installs fail. |
62
+ | `explore:N` label | Want several approaches built for some issues? | Per issue, not config. |
63
+
64
+ ### Who does what
65
+
66
+ | Action | `user` mode | `app` mode |
67
+ | ----------------------------------------- | ---------------------- | ------------ |
68
+ | Comments, PRs, labels, issue and PR edits | User, `🤖 kanbot` line | `<app>[bot]` |
69
+ | Commits, pushes, merges, board moves | User | User |
70
+
71
+ Board moves stay on the user's account: GitHub Apps can't use boards owned by a personal account.
72
+
73
+ ### App mode
74
+
75
+ - `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.
76
+ - Same app in another repo: `kanbot app link --id <id> --slug <slug>`, then add the repo to the app's installation.
77
+ - Back to user mode: `identity.mode: user`.
78
+
79
+ ### Merge on approval
80
+
81
+ 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.
82
+
83
+ 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.
84
+
85
+ ## Troubleshoot
86
+
87
+ 1. `kanbot doctor`: prints a fix for each failed check.
88
+ 2. `kanbot status`: board by column, daemon, failures, rate-limit pause.
89
+ 3. `.kanbot/logs/*.jsonl`: full agent transcripts.
90
+ 4. `needs-human` label: the issue has a comment saying why. Fix the cause, then remove the label to retry.
91
+ 5. Nothing happens: is the daemon running, are kanbot files pushed to the base branch, is the card in an active column?
@@ -13,7 +13,7 @@ Board flow:
13
13
  3. **Ready**: a human approves the plan by moving the card here.
14
14
  4. **In Progress**: an `implementer-*` agent builds the plan on a branch and commits.
15
15
  5. **Review**: `reviewer-code`, then `reviewer-spec`, then `fixer` for findings, human review comments, failing CI and merge conflicts.
16
- 6. **Done**: a human merges.
16
+ 6. **Done**: a human merges, or approves and the daemon merges.
17
17
 
18
18
  ## Golden rules
19
19