kanban-based-development

Name: kanban-based-development
Author: antopolskiy

171stars22forks

How to install kanban-based-development?

antopolskiy/kanban-md/kanban-based-development

$npx -y skills add antopolskiy/kanban-md --skill kanban-based-development

Installs into the current project.

Summary

Autonomous, parallel-safe development workflow using kanban-md. Use when the user asks to work through tasks, do kanban-based development, or when multiple agents need to coordinate work on the same codebase. Optimized for explicit handoffs and a "defer to user" protocol when hum

Files · 1

View on GitHub

SKILL.md

1	<!-- kanban-md-skill-version: 0.31.0 -->
2
3	# Kanban-Based Development
4
5	Autonomous, parallel-safe development using `kanban-md` to coordinate work on a shared board.
6	Claims prevent duplicate work; `review` is the waiting room (handoff, user action, merge, decisions).
7
8	## Multi-Agent Environment
9
10	This board is shared. Multiple agents and humans may be working on it simultaneously. You are NOT the only one reading or modifying tasks. This means:
11
12	- Another agent may claim a task between the time you list it and try to pick it.
13	- Tasks you saw as available a moment ago may no longer be available.
14
15	The claim mechanic is the coordination primitive. It prevents two agents from working on the same task. You MUST claim a task before starting any work on it, and you MUST only pick unclaimed tasks. Violating this causes duplicate work, merge conflicts, and wasted effort.
16
17	## Non-Negotiables
18
19	- Claim before you change anything. No task edits, no code changes.
20	- One active task per agent. Keep at most one task in `in-progress` for your agent session.
21	- Never steal a live claim. If it's claimed, pick something else.
22	- Never release someone else’s claim. Only use `edit --release` for your own work (or when the user explicitly asks).
23	- Always leave a handoff. Before you park a task, write a short update in the body so someone else can continue.
24	- Refresh claims to avoid timeout. If the task might take longer than `claim_timeout`, periodically renew your claim: `kanban-md edit <ID> --claim <agent>`.
25
26	## Board Home vs Worktrees (simple rule)
27
28	- Always run `kanban-md` from board home (the canonical repo directory that owns the shared board).
29	- Always do code changes in a task worktree. Never edit code in board home.
30	- If the board is git-tracked, commit board changes on `main` as a separate commit after the task is merged and moved to `done`.
31
32	At the start of the session, determine and remember `<board-home>`:
33
34	```bash
35	cd <the canonical repo directory that owns the shared board>
36	pwd # remember this path as <board-home>
37	```
38
39	Recommended: keep two shells (or split panes) open:
40
41	- Board shell at `<board-home>` for `kanban-md` commands
42	- Worktree shell at the task worktree for code changes
43
44	Do not run multiple mutating `kanban-md` commands in parallel against the same board directory.
45
46	If you are unsure you’re using the shared board, run `kanban-md board --compact` and confirm the board name/shape is what you expect.
47
48	## Defer-to-User Boundary (exceptions)
49
50	By default, agents should take tasks all the way to `done` (worktree → commit → merge → done).
51
52	Defer to the user (leave the task in `review` with a handoff) only when you need:
53
54	- an important product/spec decision with multiple valid options and no clear winner
55	- credentials/access or external actions (push to remote, releases, deployments, ENV variables, etc.)
56	- a merge conflict that requires judgment (not just mechanical resolution)
57	- repeated test/lint failures you can’t resolve
58
59	## Agent Identity (for claims)
60
61	Each agent session must generate a unique name to identify itself for claims. At the very start of a session, run:
62
63	```bash
64	kanban-md agent-name
65	```
66
67	This produces a name like `quiet-storm` or `frost-maple`. Remember this name in your context and use it as a literal string in all claim/release commands for the rest of the session. Do not store it in a file or environment variable — those are not persistent or isolated between agents.
68
69	Example: if the generated name is `frost-maple`, use `--claim frost-maple` in every claim command.
70
71	## Default Loop (worktree → merge → done)
72
73	Use `--compact` for board/list/log output whenever available to keep output short.
74
75	Before picking work, ensure board home is on `main`:
76
77	```bash
78	cd <board-home>
79	git switch main
80	git status
81	```
82
83	### 1) Pick and claim (atomically)
84
85	From board home:
86
87	Pick only from startable columns to avoid accidentally re-picking `review` work:
88
89	```bash
90	kanban-md pick --claim <agent> --status todo --move in-progress
91	```
92
93	If `todo` is empty:
94
95	```bash
96	kanban-md pick --claim <agent> --status backlog --move in-progress
97	```
98
99	This is atomic — if another agent claims the task between your list and claim, `pick` handles it safely. No need to list/choose/claim manually.
100
101	By default, `pick` prints the picked task details (including body), so a separate `show` is not required. Use `--no-body` only when you want the one-line confirmation.
102
103	### 2) Create a worktree (default)

People who liked this also viewed

6 picks

Type

kanban-based-development

171stars22forks

View on GitHub

How to install kanban-based-development?

antopolskiy/kanban-md/kanban-based-development

$npx -y skills add antopolskiy/kanban-md --skill kanban-based-development

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- kanban-md-skill-version: 0.31.0 -->
2
3	# Kanban-Based Development
4
5	Autonomous, parallel-safe development using `kanban-md` to coordinate work on a shared board.
6	Claims prevent duplicate work; `review` is the waiting room (handoff, user action, merge, decisions).
7
8	## Multi-Agent Environment
9
10	This board is shared. Multiple agents and humans may be working on it simultaneously. You are NOT the only one reading or modifying tasks. This means:
11
12	- Another agent may claim a task between the time you list it and try to pick it.
13	- Tasks you saw as available a moment ago may no longer be available.
14
15	The claim mechanic is the coordination primitive. It prevents two agents from working on the same task. You MUST claim a task before starting any work on it, and you MUST only pick unclaimed tasks. Violating this causes duplicate work, merge conflicts, and wasted effort.
16
17	## Non-Negotiables
18
19	- Claim before you change anything. No task edits, no code changes.
20	- One active task per agent. Keep at most one task in `in-progress` for your agent session.
21	- Never steal a live claim. If it's claimed, pick something else.
22	- Never release someone else’s claim. Only use `edit --release` for your own work (or when the user explicitly asks).
23	- Always leave a handoff. Before you park a task, write a short update in the body so someone else can continue.
24	- Refresh claims to avoid timeout. If the task might take longer than `claim_timeout`, periodically renew your claim: `kanban-md edit <ID> --claim <agent>`.
25
26	## Board Home vs Worktrees (simple rule)
27
28	- Always run `kanban-md` from board home (the canonical repo directory that owns the shared board).
29	- Always do code changes in a task worktree. Never edit code in board home.
30	- If the board is git-tracked, commit board changes on `main` as a separate commit after the task is merged and moved to `done`.
31
32	At the start of the session, determine and remember `<board-home>`:
33
34	```bash
35	cd <the canonical repo directory that owns the shared board>
36	pwd # remember this path as <board-home>
37	```
38
39	Recommended: keep two shells (or split panes) open:
40
41	- Board shell at `<board-home>` for `kanban-md` commands
42	- Worktree shell at the task worktree for code changes
43
44	Do not run multiple mutating `kanban-md` commands in parallel against the same board directory.
45
46	If you are unsure you’re using the shared board, run `kanban-md board --compact` and confirm the board name/shape is what you expect.
47
48	## Defer-to-User Boundary (exceptions)
49
50	By default, agents should take tasks all the way to `done` (worktree → commit → merge → done).
51
52	Defer to the user (leave the task in `review` with a handoff) only when you need:
53
54	- an important product/spec decision with multiple valid options and no clear winner
55	- credentials/access or external actions (push to remote, releases, deployments, ENV variables, etc.)
56	- a merge conflict that requires judgment (not just mechanical resolution)
57	- repeated test/lint failures you can’t resolve
58
59	## Agent Identity (for claims)
60
61	Each agent session must generate a unique name to identify itself for claims. At the very start of a session, run:
62
63	```bash
64	kanban-md agent-name
65	```
66
67	This produces a name like `quiet-storm` or `frost-maple`. Remember this name in your context and use it as a literal string in all claim/release commands for the rest of the session. Do not store it in a file or environment variable — those are not persistent or isolated between agents.
68
69	Example: if the generated name is `frost-maple`, use `--claim frost-maple` in every claim command.
70
71	## Default Loop (worktree → merge → done)
72
73	Use `--compact` for board/list/log output whenever available to keep output short.
74
75	Before picking work, ensure board home is on `main`:
76
77	```bash
78	cd <board-home>
79	git switch main
80	git status
81	```
82
83	### 1) Pick and claim (atomically)
84
85	From board home:
86
87	Pick only from startable columns to avoid accidentally re-picking `review` work:
88
89	```bash
90	kanban-md pick --claim <agent> --status todo --move in-progress
91	```
92
93	If `todo` is empty:
94
95	```bash
96	kanban-md pick --claim <agent> --status backlog --move in-progress
97	```
98
99	This is atomic — if another agent claims the task between your list and claim, `pick` handles it safely. No need to list/choose/claim manually.
100
101	By default, `pick` prints the picked task details (including body), so a separate `show` is not required. Use `--no-body` only when you want the one-line confirmation.
102
103	### 2) Create a worktree (default)

People who liked this also viewed

6 picks

Type