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
+42-3Lines changed: 42 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ The leader chooses its own username and optional full name.
37
37
## Input
38
38
39
39
Parse the user's input:
40
-
-**Name** — version (e.g. "v1.4.0") or product name (e.g. "my-api")
40
+
-**Name** — version (e.g. "v1.4") or product name (e.g. "my-api"). If the user provides a patch version such as `v1.4.0`, normalize task labels to `v1.4`.
41
41
-**Goals** — what to achieve (if not provided, ask)
42
42
43
43
## Phase 0: Detect Mode
@@ -142,6 +142,44 @@ Create all tasks? (y/n)
142
142
143
143
The user must confirm before any `ak create task` calls are made. If the user requests changes, adjust and re-preview.
144
144
145
+
### Label Best Practices
146
+
147
+
Labels are board-level taxonomy, not free-form notes. Before task creation, define the small label set this plan will use and show it in the preview. Prefer reusing existing board labels and adding only labels that will remain useful for future filtering.
148
+
149
+
Recommended label categories:
150
+
151
+
-**Version** — usually one version label per versioned task, formatted `vX.Y` (for example `v1.4`, `v2.0`). Prefer avoiding patch versions (`v1.4.0`) or suffixes (`v1.4-final`, `v1.4-test`) unless the board already has a specific reason to track that granularity.
152
+
-**Area** — one or two stable implementation areas: `backend`, `frontend`, `cli`, `api`, `database`, `infra`, `docs`, `ui`, `security`, `test`.
153
+
-**Type** — optional, only when it materially helps filtering: `feature`, `bug`, `refactor`.
154
+
155
+
Prefer keeping temporary process state, tools, providers, experiments, and implementation trivia in the task description instead of labels. Labels such as `done`, `setup:lefthook`, `prompt-fix-test`, `smoke-test`, `cost-test`, `codex`, `github`, `cloudflare`, `tanstack-query`, or file/library names usually become noisy unless the board already uses that exact label intentionally.
156
+
157
+
When labels overlap, choose the stable category:
158
+
159
+
- Use `infra`, not `infrastructure`.
160
+
- Use `bug`, not `bugfix`.
161
+
- Use `database`, not `db`.
162
+
- Use `frontend` for UI implementation unless the task is specifically design polish, then add `ui`.
163
+
164
+
Task labels must already exist on the board. Check existing labels first; if a needed label does not exist, create it with color and description, then use it on tasks:
- Assign every task at creation with `--assign-to`.
212
250
- Use `--depends-on` for real blockers or overlapping context. Tasks touching the same files, data model, or API contract should be sequential or merged.
213
251
- Keep parallel tasks independent by feature/module boundary and data model boundary.
214
-
- Use stable labels: version plus area, such as `v1.4.0,backend` or `v1.4.0,cli`.
252
+
- Use stable labels: version plus area, such as `v1.4,backend` or `v1.4,cli`.
253
+
- Keep the board label set small and reusable. If a label would be used by only one task and is not a version label, put that detail in the task description instead.
0 commit comments