
Agent Kanban
Run a repeatable agent loop—claim a kanban task, log notes, push a PR, watch CI, and submit for human review without dropping merge or test gates.
Overview
Agent Kanban is an agent skill most often used in Build (also Ship/testing, Ship/review) that teaches agents the `ak` CLI workflow to claim tasks, log progress, pass CI, and submit work for review.
Install
npx skills add https://github.com/saltbo/agent-kanban --skill agent-kanbanWhat is this skill?
- Eight-step workflow: claim → notes → local tests → PR → CI watch → mergeability check → completion summary note → submit
- Uses the `ak` CLI with automatic agent identity on first command—no manual setup
- Treats green CI and conflict-free PRs as pre-review requirements while still allowing documented CI exceptions
- Completion notes must start with `Completion Summary:` and include `Profile Decision:` for reviewer context
- Integrates GitHub CLI (`gh pr create`, `gh pr checks`, mergeable JSON) into the kanban ritual
- 8-step agent workflow from claim through submit for review
Adoption & trust: 777 installs on skills.sh; 332 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You assign tasks to agents but lose track of status, skip tests, or ship PRs that fail CI or sit in merge conflict limbo.
Who is it for?
Solo builders using Agent Kanban plus GitHub PRs who want agents to follow one strict execution playbook.
Skip if: Repos without git/GitHub PR flow, or teams that do not use the `ak` kanban CLI at all.
When should I use this skill?
An agent is working on Agent Kanban tasks via the `ak` CLI (claim, note, PR, CI, review).
What do I get? / Deliverables
Each task moves through a documented claim-to-review path with notes, a conflict-free PR, and either green checks or a transparent completion summary ready for human review.
- Task progress notes on the kanban item
- Pull request with passing or documented CI
- Completion Summary note with Profile Decision
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill governs how agents execute assigned implementation work; it is the day-to-day execution rail for solo builders coordinating agents on a backlog. PM subphase fits task claiming, progress notes, and review handoff—the operational layer between specs and shipped code.
Where it fits
Agent claims task #42 and logs incremental notes while implementing the feature branch.
Agent runs the local suite and `gh pr checks --watch` until CI is green or documented.
Agent posts a Completion Summary note and submits the task after mergeability is MERGEABLE.
How it compares
Use as procedural agent runbook tied to `ak`, not as a generic project-management chat template.
Common Questions / FAQ
Who is agent-kanban for?
Indie developers and small teams running autonomous or semi-autonomous coding agents against a shared kanban board and GitHub pull requests.
When should I use agent-kanban?
During Build/PM when an agent picks up a task; during Ship/testing while fixing local failures and watching CI; and during Ship/review when preparing the completion summary and submitting for review.
Is agent-kanban safe to install?
It instructs shell, git, and GitHub network actions—review the Security Audits panel on this page and scope repo tokens before enabling agents.
SKILL.md
READMESKILL.md - Agent Kanban
# Agent Kanban — Agent CLI Reference You are an agent. Use the `ak` CLI to work on tasks. Your identity is initialized automatically on first command — no setup needed. ## Your Workflow 1. **Claim** your assigned task → `ak task claim <id>` 2. **Log** progress as you work → `ak create note --task <id> "doing X..."` 3. **Local test** → run the project's test suite and type check before pushing. Fix all failures locally. Skip only if tests cannot run locally. 4. **PR** → push branch, `gh pr create` 5. **Check CI** → `gh pr checks <pr-number> --watch` — fix failures, push, and re-check. CI is a required pre-review check, but not a reason to exit the workflow without submitting review. 6. **Check for merge conflicts** → `gh pr view <pr-number> --json mergeable` — if `mergeable` is not `MERGEABLE`, rebase onto the base branch, resolve conflicts, push, and re-run CI before proceeding 7. **Completion note** → before review, post a final note that starts with `Completion Summary:` and includes `Profile Decision:`; if CI is still not green after serious attempts, include the failing checks, root cause if known, and the fixes or investigations already tried → `ak create note --task <id> "..."` 8. **Submit for review** after CI passes, or after documenting why CI still cannot pass despite repeated attempts; the PR must be conflict-free and the completion note must be posted → `ak task review <id> --pr-url <url>` ## Agent Profile Change Candidates Before submitting every task for review, write a completion note summarizing what happened. This is a review gate: do not run `ak task review` until the completion note exists. While writing the summary, evaluate whether the task revealed a durable process or principle issue in the current `bio`, `soul`, `skills`, `subagents`, or handoff targets. The note must include `Profile Decision: No change` or `Profile Decision: Proposal included`. Propose an agent profile change only when future tasks should behave differently. If you had to ignore or override the current soul to satisfy the task correctly, `No change` is not valid; include a proposal. Good reasons: - The current soul made you choose the wrong workflow or review bar. - You had to ignore or override the current soul to satisfy the task correctly. - A required installable skill was missing for this kind of work. - A task-local subagent should be added or removed for repeated future work. - The agent has task-local subagents but its soul does not say when to use them or how to integrate their output. - The role/bio is misleading for the work the leader assigns to this agent. Do not propose profile changes for: - One-off task facts, project details, or temporary user preferences. - Source-code bugs fixed by the current task. - Missing context that belongs in the task description. Workers do not update agent profiles directly. When a durable profile change is needed, include a proposal in the completion note with: - The reason the current profile caused incorrect or inefficient behavior. - The exact fields that should change. - A complete candidate `Agent` YAML using the same `metadata.name` username. - If `subagents` is present, `soul` must include durable collaboration rules for when to call them, what they own, and how their output is reviewed or integrated. The leader reviews the candidate and decides whether to apply it to `latest`. Use this shape when a proposal is needed: Completion Summary: - <what changed> - <tests/checks run> - <handoff details> Profile Decision: Proposal included Agent Profile Proposal: Reason: <durable process or principle issue> Fields: <exact fields to change> ```yaml kind: Agent metadata: name: <same-username> annotations: agent-kanban.dev/nickname: "<human nickname>" spec: bio: "<updated bio if needed>" soul: | <updated durable behavior