You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: skills/ak-plan/SKILL.md
+79-21Lines changed: 79 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -141,7 +141,7 @@ Create all tasks? (y/n)
141
141
142
142
The user must confirm before any `ak create task` calls are made. If the user requests changes, adjust and re-preview.
143
143
144
-
## Phase 3: Create Board & Tasks
144
+
## Phase 3: Create Board, Workers & Tasks
145
145
146
146
Use the existing board for the project. One project = one board.
147
147
@@ -150,6 +150,32 @@ ak get board # find the project board
150
150
# Only create a new board if this is a new product with no board yet
151
151
```
152
152
153
+
Before creating tasks, choose or create the workers that will own them. Read `references/runtime-delegation.md`.
154
+
155
+
Check existing agents. For a typical project you need:
156
+
-**fullstack-developer** or backend + frontend split
157
+
158
+
Only assign work to agents whose `runtime_available` is `true`. If the best role exists only on an unavailable runtime, create a new worker with the same role, soul, skills, and handoff settings on an available runtime.
159
+
160
+
Create missing agents before task creation:
161
+
```yaml
162
+
kind: Agent
163
+
metadata:
164
+
name: <human-username>
165
+
annotations:
166
+
agent-kanban.dev/display-name: "<Human Name>"
167
+
spec:
168
+
runtime: <available-runtime>
169
+
role: "<role>"
170
+
bio: "<durable responsibility>"
171
+
skills:
172
+
- <source>@<skill>
173
+
subagents:
174
+
- <worker-agent-id>
175
+
```
176
+
177
+
The leader must generate the Agent YAML from the project context and apply it with `ak apply -f <file>`. Do not use role templates. After creation, run `ak get agent -o json` and confirm the new worker is visible and `runtime_available: true` before assigning tasks.
178
+
153
179
Create tasks with full specs. For each task:
154
180
155
181
1. **`--title`** — concise action phrase
@@ -160,14 +186,25 @@ Create tasks with full specs. For each task:
160
186
3. **`--repo <id>`** — from `ak repo list`
161
187
4. **`--priority`** — urgent/high/medium/low
162
188
5. **`--labels`** — include version label (e.g. `v1.4.0`) plus category (backend, frontend, cli, etc.)
163
-
6.**`--depends-on`** — task IDs this depends on
189
+
6. **`--assign-to <agent-id>`** — worker chosen before task creation
190
+
7. **`--depends-on`** — task IDs this depends on
164
191
165
192
Create tasks in dependency order so earlier task IDs can be referenced:
- Create one task for one reviewable outcome. Split unrelated backend, frontend, CLI, and infra work.
201
+
- Make each task independently claimable: no hidden chat context, no "continue from above" descriptions.
202
+
- Put the exact files, APIs, commands, UI states, and acceptance checks in `--description`.
203
+
- Assign every task at creation with `--assign-to`.
204
+
- Use `--depends-on` for real blockers or overlapping files. Tasks touching the same files should be sequential.
205
+
- Keep parallel tasks independent by file ownership and data model boundary.
206
+
- Use stable labels: version plus area, such as `v1.4.0,backend` or `v1.4.0,cli`.
207
+
171
208
### Task Description Quality
172
209
173
210
Agents are autonomous — the description is their only input. A good description:
@@ -195,23 +232,7 @@ POST /api/items — create item
195
232
196
233
Vague descriptions produce vague code. Be specific.
197
234
198
-
## Phase 4: Assign
199
-
200
-
Before choosing or creating workers, read `references/runtime-delegation.md`.
201
-
202
-
Tasks should already be assigned via `--assign-to` on create. If not, use `ak update task <id>` or recreate.
203
-
204
-
Check existing agents. For a typical project you need:
205
-
-**fullstack-developer** or backend + frontend split
206
-
207
-
Only assign work to agents whose `runtime_available` is `true`. If the best role exists only on an unavailable runtime, create a new worker with the same role, soul, skills, and handoff settings on an available runtime.
208
-
209
-
Create missing agents if needed:
210
-
```bash
211
-
ak create agent --template <template> --name "<Name>"
212
-
```
213
-
214
-
## Phase 5: Monitor & Merge
235
+
## Phase 4: Monitor & Merge
215
236
216
237
**Block on `ak wait board` instead of writing polling loops.** It streams tasks one at a time as they reach the filter status. Exit codes: 0 condition met, 2 task cancelled, 124 timeout.
When all tasks are done, report the final summary to the user.
314
335
336
+
## AK Command or Product Issues
337
+
338
+
If the blocker appears to be an `ak` bug, missing capability, confusing UX, or documentation gap, file an issue in the official repo after collecting a minimal reproduction:
339
+
340
+
```bash
341
+
gh issue create \
342
+
--repo saltbo/agent-kanban \
343
+
--title "ak: <short problem summary>" \
344
+
--body "$(cat <<'EOF'
345
+
## Summary
346
+
<what failed or what capability is missing>
347
+
348
+
## Command
349
+
ak <command and flags>
350
+
351
+
## Expected
352
+
<what should have happened>
353
+
354
+
## Actual
355
+
<exact error text or observed behavior>
356
+
357
+
## Context
358
+
- ak version:
359
+
- OS:
360
+
- Runtime:
361
+
- Auth type: user | machine | agent
362
+
- Board/task/repo IDs, if relevant:
363
+
364
+
## Reproduction
365
+
1. <step>
366
+
2. <step>
367
+
EOF
368
+
)"
369
+
```
370
+
371
+
Never include API keys, session tokens, private keys, `.env` contents, or private repository data. If `gh` is unavailable, open `https://github.com/saltbo/agent-kanban/issues/new` and paste the same content.
372
+
315
373
## Rules
316
374
317
375
- **Workflow completion is mandatory** — once this skill is invoked, the full lifecycle (plan → create → assign → monitor → review → merge all) MUST run to completion. If you are interrupted mid-workflow (user asks a side question, chat drifts to another topic, tool fails, etc.), handle the interruption and then **immediately resume the workflow from where you left off**. Never ask "should I continue monitoring?" or "do you want me to keep going?" — the answer is always yes. The only way to exit the workflow early is if the user explicitly says to stop, cancel, or abort.
0 commit comments