@omnicoreos/planka-mcp 0.2.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.
- package/CHANGELOG.md +86 -0
- package/CONTRIBUTING.md +37 -0
- package/CREDITS.md +39 -0
- package/LICENSE +22 -0
- package/README.es.md +213 -0
- package/README.md +213 -0
- package/dist/client.d.ts +96 -0
- package/dist/client.d.ts.map +1 -0
- package/dist/client.js +281 -0
- package/dist/client.js.map +1 -0
- package/dist/errors.d.ts +85 -0
- package/dist/errors.d.ts.map +1 -0
- package/dist/errors.js +226 -0
- package/dist/errors.js.map +1 -0
- package/dist/identity.generated.d.ts +3 -0
- package/dist/identity.generated.d.ts.map +1 -0
- package/dist/identity.generated.js +4 -0
- package/dist/identity.generated.js.map +1 -0
- package/dist/index.d.ts +3 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +93 -0
- package/dist/index.js.map +1 -0
- package/dist/operations/attachments.d.ts +34 -0
- package/dist/operations/attachments.d.ts.map +1 -0
- package/dist/operations/attachments.js +89 -0
- package/dist/operations/attachments.js.map +1 -0
- package/dist/operations/board-id.d.ts +9 -0
- package/dist/operations/board-id.d.ts.map +1 -0
- package/dist/operations/board-id.js +86 -0
- package/dist/operations/board-id.js.map +1 -0
- package/dist/operations/boards.d.ts +143 -0
- package/dist/operations/boards.d.ts.map +1 -0
- package/dist/operations/boards.js +391 -0
- package/dist/operations/boards.js.map +1 -0
- package/dist/operations/cards.d.ts +36 -0
- package/dist/operations/cards.d.ts.map +1 -0
- package/dist/operations/cards.js +81 -0
- package/dist/operations/cards.js.map +1 -0
- package/dist/operations/comments.d.ts +28 -0
- package/dist/operations/comments.d.ts.map +1 -0
- package/dist/operations/comments.js +53 -0
- package/dist/operations/comments.js.map +1 -0
- package/dist/operations/labels.d.ts +60 -0
- package/dist/operations/labels.d.ts.map +1 -0
- package/dist/operations/labels.js +146 -0
- package/dist/operations/labels.js.map +1 -0
- package/dist/operations/lists.d.ts +15 -0
- package/dist/operations/lists.d.ts.map +1 -0
- package/dist/operations/lists.js +40 -0
- package/dist/operations/lists.js.map +1 -0
- package/dist/operations/projects.d.ts +24 -0
- package/dist/operations/projects.d.ts.map +1 -0
- package/dist/operations/projects.js +61 -0
- package/dist/operations/projects.js.map +1 -0
- package/dist/operations/tasks.d.ts +30 -0
- package/dist/operations/tasks.d.ts.map +1 -0
- package/dist/operations/tasks.js +111 -0
- package/dist/operations/tasks.js.map +1 -0
- package/dist/schemas/entities.d.ts +389 -0
- package/dist/schemas/entities.d.ts.map +1 -0
- package/dist/schemas/entities.js +202 -0
- package/dist/schemas/entities.js.map +1 -0
- package/dist/schemas/requests.d.ts +539 -0
- package/dist/schemas/requests.d.ts.map +1 -0
- package/dist/schemas/requests.js +187 -0
- package/dist/schemas/requests.js.map +1 -0
- package/dist/schemas/responses.d.ts +2626 -0
- package/dist/schemas/responses.d.ts.map +1 -0
- package/dist/schemas/responses.js +75 -0
- package/dist/schemas/responses.js.map +1 -0
- package/dist/tools/attachments.d.ts +270 -0
- package/dist/tools/attachments.d.ts.map +1 -0
- package/dist/tools/attachments.js +247 -0
- package/dist/tools/attachments.js.map +1 -0
- package/dist/tools/cards.d.ts +401 -0
- package/dist/tools/cards.d.ts.map +1 -0
- package/dist/tools/cards.js +368 -0
- package/dist/tools/cards.js.map +1 -0
- package/dist/tools/comments.d.ts +217 -0
- package/dist/tools/comments.d.ts.map +1 -0
- package/dist/tools/comments.js +208 -0
- package/dist/tools/comments.js.map +1 -0
- package/dist/tools/index.d.ts +1293 -0
- package/dist/tools/index.d.ts.map +1 -0
- package/dist/tools/index.js +62 -0
- package/dist/tools/index.js.map +1 -0
- package/dist/tools/labels.d.ts +214 -0
- package/dist/tools/labels.d.ts.map +1 -0
- package/dist/tools/labels.js +302 -0
- package/dist/tools/labels.js.map +1 -0
- package/dist/tools/lists.d.ts +117 -0
- package/dist/tools/lists.d.ts.map +1 -0
- package/dist/tools/lists.js +178 -0
- package/dist/tools/lists.js.map +1 -0
- package/dist/tools/navigation.d.ts +106 -0
- package/dist/tools/navigation.d.ts.map +1 -0
- package/dist/tools/navigation.js +151 -0
- package/dist/tools/navigation.js.map +1 -0
- package/dist/tools/queries.d.ts +380 -0
- package/dist/tools/queries.d.ts.map +1 -0
- package/dist/tools/queries.js +256 -0
- package/dist/tools/queries.js.map +1 -0
- package/dist/tools/tasks.d.ts +223 -0
- package/dist/tools/tasks.d.ts.map +1 -0
- package/dist/tools/tasks.js +169 -0
- package/dist/tools/tasks.js.map +1 -0
- package/docs/planka-2x-gotchas.md +192 -0
- package/docs/tools.md +659 -0
- package/docs/troubleshooting.md +138 -0
- package/package.json +71 -0
- package/project.identity.json +7 -0
- package/scripts/bootstrap-board.mjs +160 -0
- package/scripts/lib/planka-api.mjs +244 -0
- package/scripts/lib/workflow-template.mjs +26 -0
- package/scripts/setup.mjs +236 -0
- package/scripts/setup.sh +48 -0
- package/scripts/sync-identity.mjs +57 -0
- package/server.json +43 -0
- package/tests/smoke/planka-smoke.mjs +920 -0
- package/workflow/README.md +232 -0
- package/workflow/board-template.md +115 -0
- package/workflow/skills/planka-close-card/SKILL.md +81 -0
- package/workflow/skills/planka-orchestrator/SKILL.md +126 -0
- package/workflow/worktrees/README.md +104 -0
- package/workflow/worktrees/wt.conf.example +24 -0
- package/workflow/worktrees/wt.sh +345 -0
|
@@ -0,0 +1,232 @@
|
|
|
1
|
+
# A board that survives the session
|
|
2
|
+
|
|
3
|
+
This is an optional working method built around the MCP server in this repository.
|
|
4
|
+
You do not need it to use the 24 Planka tools.
|
|
5
|
+
|
|
6
|
+
## The problem it solves
|
|
7
|
+
|
|
8
|
+
A fresh agent session does not know why a task exists, what was already tried, or
|
|
9
|
+
which decision unblocked it. That state usually lives in one person's head. The
|
|
10
|
+
result is repeated investigation, stale branches, and a human who has to reconstruct
|
|
11
|
+
every workstream on demand.
|
|
12
|
+
|
|
13
|
+
This proposal moves that state into a Planka board. The board is not a backlog that
|
|
14
|
+
the human must maintain. It is the durable handoff between conversations, agents,
|
|
15
|
+
branches, and worktrees.
|
|
16
|
+
|
|
17
|
+
Adopt it in layers:
|
|
18
|
+
|
|
19
|
+
1. Use only the MCP server.
|
|
20
|
+
2. Add the board states and card format.
|
|
21
|
+
3. Add parallel worktrees with a director and one worker per card.
|
|
22
|
+
|
|
23
|
+
Stop at the layer that helps. The method is a starting point, not a doctrine.
|
|
24
|
+
|
|
25
|
+
## Core rules
|
|
26
|
+
|
|
27
|
+
1. **The conversation is the input.** The human explains a bug or feature. The
|
|
28
|
+
agent writes the card. The board mirrors work; it is not a form the human fills.
|
|
29
|
+
2. **Columns describe verifiable repository state.** A card in `In worktree` has a
|
|
30
|
+
real branch and worktree. A card in `Merged` is in the base branch and verified.
|
|
31
|
+
3. **Read every comment before touching a card.** The description says how the task
|
|
32
|
+
started. Comments say what is true now. The newest human decision wins.
|
|
33
|
+
4. **One writer per worktree.** In parallel mode, the worker assigned to a card is
|
|
34
|
+
the only agent that edits its branch. The director coordinates and audits.
|
|
35
|
+
5. **Evidence travels with the card.** Checks, manual verification, remaining risk,
|
|
36
|
+
and the commit or branch are recorded before a session ends.
|
|
37
|
+
|
|
38
|
+
## Board states
|
|
39
|
+
|
|
40
|
+
The bootstrap script creates these lists:
|
|
41
|
+
|
|
42
|
+
| List | Verifiable meaning | Owner of the transition |
|
|
43
|
+
|---|---|---|
|
|
44
|
+
| `Pending` | Described, but no branch or worktree exists | Director |
|
|
45
|
+
| `Needs your decision` | One concrete product or risk choice blocks work | Director puts it here; human unlocks it |
|
|
46
|
+
| `In worktree` | The metadata points to a live branch and worktree | Director |
|
|
47
|
+
| `Test it` | Pre-merge human judgment is genuinely required | Director after worker evidence |
|
|
48
|
+
| `Review in main` | Merged, but the final proof only exists on the integrated branch or environment | Director; human confirms |
|
|
49
|
+
| `Merged` | In the base branch, closure recorded, and required verification complete | Director |
|
|
50
|
+
|
|
51
|
+
Do not use columns as moods such as “almost done.” If repository state and board
|
|
52
|
+
state disagree, fix the board immediately.
|
|
53
|
+
|
|
54
|
+
## Human handshakes
|
|
55
|
+
|
|
56
|
+
### `decided`
|
|
57
|
+
|
|
58
|
+
For a card in `Needs your decision`, the human:
|
|
59
|
+
|
|
60
|
+
1. leaves a comment containing the decision;
|
|
61
|
+
2. applies the `decided` label.
|
|
62
|
+
|
|
63
|
+
The agent does not infer the decision from the label alone. It reads all comments,
|
|
64
|
+
treats the newest human decision as binding, rewrites the description so the chosen
|
|
65
|
+
scope is self-contained, and then moves the card to `Pending` or `In worktree`.
|
|
66
|
+
|
|
67
|
+
Only a human applies `decided`. Keep the label as durable provenance.
|
|
68
|
+
|
|
69
|
+
### `tested-ok`
|
|
70
|
+
|
|
71
|
+
For a card in `Review in main`, the human applies `tested-ok` after checking the
|
|
72
|
+
integrated behavior. The director then moves it to `Merged`. If the check fails, the
|
|
73
|
+
human comments with the observed behavior and the director creates or reopens a fix.
|
|
74
|
+
|
|
75
|
+
Only a human applies `tested-ok`.
|
|
76
|
+
|
|
77
|
+
## Card anatomy
|
|
78
|
+
|
|
79
|
+
Use the copyable template in [board-template.md](board-template.md). A useful card
|
|
80
|
+
answers five questions in ordinary language:
|
|
81
|
+
|
|
82
|
+
- What is happening?
|
|
83
|
+
- How can someone see or reproduce it?
|
|
84
|
+
- Where does it live?
|
|
85
|
+
- What proves it is done?
|
|
86
|
+
- What could this change break?
|
|
87
|
+
|
|
88
|
+
At the bottom, a machine-readable comment links the card to Git:
|
|
89
|
+
|
|
90
|
+
```html
|
|
91
|
+
<!-- agent-work
|
|
92
|
+
branch: agent/fix-export-timeout
|
|
93
|
+
worktree: .worktrees/fix-export-timeout
|
|
94
|
+
port: 4173
|
|
95
|
+
plan: docs/plans/fix-export-timeout.md
|
|
96
|
+
-->
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
Omit fields that do not apply. The card remains the source of truth for the
|
|
100
|
+
card-to-branch-to-worktree relationship.
|
|
101
|
+
|
|
102
|
+
## Labels are instructions
|
|
103
|
+
|
|
104
|
+
The template uses a deliberately small behavior vocabulary:
|
|
105
|
+
|
|
106
|
+
| Label | Agent behavior |
|
|
107
|
+
|---|---|
|
|
108
|
+
| `needs-decision` | Stop implementation and ask one concrete question |
|
|
109
|
+
| `decided` | Read the human decision in comments and prioritize the card |
|
|
110
|
+
| `tested-ok` | Human confirmed the post-merge check |
|
|
111
|
+
| `fast-track` | Small, low-risk change; use the repository's short verification path |
|
|
112
|
+
| `standard` | Normal planning, implementation, and verification path |
|
|
113
|
+
| `serial` | Run alone because it touches shared or irreversible state |
|
|
114
|
+
| `zone:*` | Mutual-exclusion key for parallel work |
|
|
115
|
+
|
|
116
|
+
Two cards with the same `zone:*` label never run in parallel. Tune zones to your
|
|
117
|
+
repository boundaries. The starter set is only an example.
|
|
118
|
+
|
|
119
|
+
Use `serial` for migrations, shared test fixtures, global infrastructure, or any
|
|
120
|
+
verification that mutates one shared environment.
|
|
121
|
+
|
|
122
|
+
## Director and workers
|
|
123
|
+
|
|
124
|
+
Parallel mode separates coordination from editing.
|
|
125
|
+
|
|
126
|
+
### Director
|
|
127
|
+
|
|
128
|
+
The director:
|
|
129
|
+
|
|
130
|
+
- reads the complete board and every candidate card's comments;
|
|
131
|
+
- chooses eligible cards, respecting `serial` and `zone:*` exclusions;
|
|
132
|
+
- creates branches and worktrees;
|
|
133
|
+
- writes the card metadata;
|
|
134
|
+
- gives each worker one bounded brief;
|
|
135
|
+
- audits evidence and decides the next board state;
|
|
136
|
+
- serializes merges and cleans worktrees.
|
|
137
|
+
|
|
138
|
+
In this contract, the director does not edit repository files. This keeps ownership
|
|
139
|
+
clear and makes a worker's evidence first-hand rather than reconstructed.
|
|
140
|
+
|
|
141
|
+
### Worker
|
|
142
|
+
|
|
143
|
+
One worker owns one card and one worktree. It:
|
|
144
|
+
|
|
145
|
+
- edits only that worktree;
|
|
146
|
+
- follows the repository's own instructions;
|
|
147
|
+
- runs the relevant checks;
|
|
148
|
+
- performs the acceptance steps from the card;
|
|
149
|
+
- captures visual evidence when the change is visual;
|
|
150
|
+
- commits its work;
|
|
151
|
+
- writes progress and closure only on its assigned card.
|
|
152
|
+
|
|
153
|
+
A worker does not select other cards, move unrelated cards, merge the base branch,
|
|
154
|
+
or invent human approval.
|
|
155
|
+
|
|
156
|
+
### Worker brief
|
|
157
|
+
|
|
158
|
+
A director should provide:
|
|
159
|
+
|
|
160
|
+
```text
|
|
161
|
+
Mission: one concrete outcome
|
|
162
|
+
Card: title, current description, and every relevant comment
|
|
163
|
+
Worktree: absolute path and branch
|
|
164
|
+
Acceptance: exact observable proof
|
|
165
|
+
Required checks: repository-specific commands
|
|
166
|
+
Do not: scope boundaries and external side effects
|
|
167
|
+
Output: commit, checks, manual proof, risks, and closing comment
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
If a worker needs correction, continue the same worker session when the runtime
|
|
171
|
+
supports it. Replacing it loses the context the board/worktree contract is trying to
|
|
172
|
+
preserve.
|
|
173
|
+
|
|
174
|
+
## Automatic progress and vetoes
|
|
175
|
+
|
|
176
|
+
Verified work may merge without another ceremony when all required evidence is
|
|
177
|
+
present and the repository allows it. Keep explicit vetoes for work where automated
|
|
178
|
+
confidence is not enough:
|
|
179
|
+
|
|
180
|
+
- access control, visibility, or security boundaries;
|
|
181
|
+
- destructive migrations or shared production-like data;
|
|
182
|
+
- money, billing, or irreversible external side effects;
|
|
183
|
+
- infrastructure that competes with a human's active environment;
|
|
184
|
+
- physical hardware or third-party approval that the worker cannot exercise.
|
|
185
|
+
|
|
186
|
+
A veto does not mean “never.” It means stop at `Test it` or `Review in main` with an
|
|
187
|
+
exact question or check. “Please test” without saying what remains uncertain is not
|
|
188
|
+
evidence.
|
|
189
|
+
|
|
190
|
+
## Closure evidence
|
|
191
|
+
|
|
192
|
+
The worker leaves a comment like this before handing the card back:
|
|
193
|
+
|
|
194
|
+
```markdown
|
|
195
|
+
✅ Ready for review
|
|
196
|
+
|
|
197
|
+
**Changed:** <one user-visible sentence>
|
|
198
|
+
|
|
199
|
+
**Where to check:** <URL, command, or exact path>
|
|
200
|
+
|
|
201
|
+
**Prove it:** <one concrete acceptance step>
|
|
202
|
+
|
|
203
|
+
**Risk:** <real nearby behavior that could regress>
|
|
204
|
+
|
|
205
|
+
**Verified:** <checks and manual evidence, with honest omissions>
|
|
206
|
+
|
|
207
|
+
**Commit:** <commit SHA>
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
The director audits the claim against the branch, checks, and attachments. It does
|
|
211
|
+
not silently upgrade “not tested” into “passed.”
|
|
212
|
+
|
|
213
|
+
## A safe cycle
|
|
214
|
+
|
|
215
|
+
1. Read the board and comments.
|
|
216
|
+
2. Prefer `decided` cards whose zones are free.
|
|
217
|
+
3. Apply `serial` and zone exclusions.
|
|
218
|
+
4. Create one worktree per selected card and update metadata.
|
|
219
|
+
5. Dispatch one worker per worktree.
|
|
220
|
+
6. Workers implement, verify, commit, and comment.
|
|
221
|
+
7. Director audits and chooses `Test it`, `Review in main`, or merge.
|
|
222
|
+
8. Merge one worktree at a time.
|
|
223
|
+
9. Confirm the board, base tree, and worktree inventory agree.
|
|
224
|
+
|
|
225
|
+
The optional [worktree helper](worktrees/README.md) automates the Git mechanics. It
|
|
226
|
+
does not decide whether a card is safe to run or merge.
|
|
227
|
+
|
|
228
|
+
## Start small
|
|
229
|
+
|
|
230
|
+
For a first trial, use one board and one card. Ask the agent to create a card from a
|
|
231
|
+
conversation, read it back, implement in one branch, and leave the closure comment.
|
|
232
|
+
Add parallelism only after that loop feels boring and reliable.
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
# Board template
|
|
2
|
+
|
|
3
|
+
Create the optional workflow on an empty board:
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
export PLANKA_BASE_URL="https://planka.example.com"
|
|
7
|
+
export PLANKA_AGENT_EMAIL="agent@example.com"
|
|
8
|
+
export PLANKA_AGENT_PASSWORD="<YOUR_PASSWORD>"
|
|
9
|
+
|
|
10
|
+
node scripts/bootstrap-board.mjs --board-id "<BOARD_ID>"
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
Or create the board inside a project and then bootstrap it:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
node scripts/bootstrap-board.mjs \
|
|
17
|
+
--project-id "<PROJECT_ID>" \
|
|
18
|
+
--board-name "Agent Work"
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
The command is idempotent. It fills missing template lists and labels. It refuses to
|
|
22
|
+
alter an unrelated populated board unless you pass `--force` deliberately.
|
|
23
|
+
|
|
24
|
+
## Lists
|
|
25
|
+
|
|
26
|
+
| Order | Name | Repository invariant |
|
|
27
|
+
|---:|---|---|
|
|
28
|
+
| 1 | `Pending` | No branch or worktree exists |
|
|
29
|
+
| 2 | `Needs your decision` | A human answer is required |
|
|
30
|
+
| 3 | `In worktree` | Branch and worktree exist |
|
|
31
|
+
| 4 | `Test it` | Human proof is required before merge |
|
|
32
|
+
| 5 | `Review in main` | Merged; final integrated proof is pending |
|
|
33
|
+
| 6 | `Merged` | Integrated and verified |
|
|
34
|
+
|
|
35
|
+
`Merged` is created as a Planka `closed` list. The others are `active` lists.
|
|
36
|
+
|
|
37
|
+
## Labels
|
|
38
|
+
|
|
39
|
+
| Label | Meaning |
|
|
40
|
+
|---|---|
|
|
41
|
+
| `needs-decision` | Implementation is blocked on one human choice |
|
|
42
|
+
| `decided` | Human decision is in the comments |
|
|
43
|
+
| `tested-ok` | Human approved the integrated result |
|
|
44
|
+
| `fast-track` | Repository-defined lightweight path |
|
|
45
|
+
| `standard` | Normal verification path |
|
|
46
|
+
| `serial` | Never run beside another worktree |
|
|
47
|
+
| `zone:frontend` | Frontend ownership boundary |
|
|
48
|
+
| `zone:backend` | Backend ownership boundary |
|
|
49
|
+
| `zone:data` | Data/schema boundary |
|
|
50
|
+
| `zone:infra` | Infrastructure/global-state boundary |
|
|
51
|
+
| `zone:shared-ui` | Shared design-system boundary |
|
|
52
|
+
|
|
53
|
+
Rename or add zones to match your repository. The important contract is that two
|
|
54
|
+
cards with the same zone do not run concurrently.
|
|
55
|
+
|
|
56
|
+
## Card description
|
|
57
|
+
|
|
58
|
+
```markdown
|
|
59
|
+
## What is happening
|
|
60
|
+
One or two sentences from the user's point of view.
|
|
61
|
+
|
|
62
|
+
## How to see it
|
|
63
|
+
Exact reproduction steps or the place to inspect.
|
|
64
|
+
|
|
65
|
+
## Where it lives
|
|
66
|
+
- path/to/likely-file.ts
|
|
67
|
+
- path/to/related-test.ts
|
|
68
|
+
|
|
69
|
+
## Done means
|
|
70
|
+
Observable acceptance criteria.
|
|
71
|
+
|
|
72
|
+
## Risk
|
|
73
|
+
Nearby behavior or data that could regress.
|
|
74
|
+
|
|
75
|
+
<!-- agent-work
|
|
76
|
+
branch: agent/short-slug
|
|
77
|
+
worktree: .worktrees/short-slug
|
|
78
|
+
port:
|
|
79
|
+
plan:
|
|
80
|
+
-->
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
The description captures current scope. Comments preserve decisions, attempts,
|
|
84
|
+
evidence, and handoffs over time.
|
|
85
|
+
|
|
86
|
+
## Decision request
|
|
87
|
+
|
|
88
|
+
Ask one question, not a questionnaire:
|
|
89
|
+
|
|
90
|
+
```markdown
|
|
91
|
+
🚧 Decision needed
|
|
92
|
+
|
|
93
|
+
Should an archived item remain visible to administrators, or disappear for every
|
|
94
|
+
role? This changes the access boundary, so implementation is paused.
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
The human replies in a comment and applies `decided`.
|
|
98
|
+
|
|
99
|
+
## Closing comment
|
|
100
|
+
|
|
101
|
+
```markdown
|
|
102
|
+
✅ Ready for review
|
|
103
|
+
|
|
104
|
+
**Changed:** Export now reports a useful timeout instead of hanging.
|
|
105
|
+
|
|
106
|
+
**Where to check:** Settings → Exports → Start export
|
|
107
|
+
|
|
108
|
+
**Prove it:** Start an export against the slow test fixture and confirm it stops with the timeout message.
|
|
109
|
+
|
|
110
|
+
**Risk:** Normal exports and retry behavior share the same request path.
|
|
111
|
+
|
|
112
|
+
**Verified:** unit tests ✅ · typecheck ✅ · manual slow-fixture check ✅
|
|
113
|
+
|
|
114
|
+
**Commit:** abc1234
|
|
115
|
+
```
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: planka-close-card
|
|
3
|
+
description: This skill should be used when the user asks to "close this Planka card", "ship this card", "finish the card", "record the card handoff", or confirms "tested ok" for a workflow card. It verifies evidence, records a durable closing comment, and performs only the merge or board transition owned by the current role.
|
|
4
|
+
version: 0.1.0
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Close a Planka workflow card
|
|
8
|
+
|
|
9
|
+
Closure is evidence plus a truthful state transition. Do not move a card merely
|
|
10
|
+
because implementation stopped.
|
|
11
|
+
|
|
12
|
+
## Read first
|
|
13
|
+
|
|
14
|
+
1. Read the card description and every comment.
|
|
15
|
+
2. Read the repository's contribution and verification instructions.
|
|
16
|
+
3. Resolve the `<!-- agent-work -->` branch and worktree against real Git state.
|
|
17
|
+
4. Determine your role:
|
|
18
|
+
- worker: edits, verifies, commits, and writes the handoff;
|
|
19
|
+
- director: audits, merges, cleans, and changes board state;
|
|
20
|
+
- human confirmation handler: records `tested-ok` and completes the final move.
|
|
21
|
+
|
|
22
|
+
Do not perform another role's transition unless the user explicitly assigned both
|
|
23
|
+
roles and the repository allows it.
|
|
24
|
+
|
|
25
|
+
## Worker closure
|
|
26
|
+
|
|
27
|
+
The worker must:
|
|
28
|
+
|
|
29
|
+
1. Run the relevant repository checks.
|
|
30
|
+
2. Execute the card's observable acceptance step.
|
|
31
|
+
3. Capture visual evidence when the change is visual.
|
|
32
|
+
4. Record any skipped or impossible proof explicitly.
|
|
33
|
+
5. Commit all intended files and confirm the worktree is clean.
|
|
34
|
+
6. Leave this comment on the assigned card:
|
|
35
|
+
|
|
36
|
+
```markdown
|
|
37
|
+
✅ Ready for review
|
|
38
|
+
|
|
39
|
+
**Changed:** <one user-visible sentence>
|
|
40
|
+
|
|
41
|
+
**Where to check:** <URL, command, or exact path>
|
|
42
|
+
|
|
43
|
+
**Prove it:** <one concrete acceptance step>
|
|
44
|
+
|
|
45
|
+
**Risk:** <real nearby behavior that could regress>
|
|
46
|
+
|
|
47
|
+
**Verified:** <checks and manual evidence, with honest omissions>
|
|
48
|
+
|
|
49
|
+
**Commit:** <commit SHA>
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
The worker does not merge, delete the worktree, or move unrelated cards.
|
|
53
|
+
|
|
54
|
+
## Director closure
|
|
55
|
+
|
|
56
|
+
The director verifies:
|
|
57
|
+
|
|
58
|
+
- commit and important diff match the card;
|
|
59
|
+
- required checks are green;
|
|
60
|
+
- acceptance evidence is first-hand and specific;
|
|
61
|
+
- risk and omissions are explicit;
|
|
62
|
+
- worker and base trees are clean;
|
|
63
|
+
- no veto requires human judgment.
|
|
64
|
+
|
|
65
|
+
Then choose exactly one destination:
|
|
66
|
+
|
|
67
|
+
- merge and `Merged` when verification is complete;
|
|
68
|
+
- `Test it` when human judgment is needed before merge;
|
|
69
|
+
- merge and `Review in main` when only integrated proof remains;
|
|
70
|
+
- stay `In worktree` with a concrete red result when implementation is incomplete.
|
|
71
|
+
|
|
72
|
+
Use the supported merge helper. Never bypass its clean-tree, conflict, or verification
|
|
73
|
+
guards. After merge, confirm the branch/worktree cleanup and board state agree.
|
|
74
|
+
|
|
75
|
+
## Human confirmation
|
|
76
|
+
|
|
77
|
+
For a card in `Review in main`, an explicit human confirmation or human-applied
|
|
78
|
+
`tested-ok` is authorization to move it to `Merged`. If the human reports a failure,
|
|
79
|
+
comment with the observation and open or restore a fix card instead.
|
|
80
|
+
|
|
81
|
+
Never apply `tested-ok` or `decided` on behalf of the human.
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: planka-orchestrator
|
|
3
|
+
description: This skill should be used when the user asks to "orchestrate the Planka board", "run cards in parallel", "act as the director", "dispatch workers from Planka", or "continue the board workflow". It coordinates cards, comments, worktrees, worker ownership, evidence, and safe merges without editing repository files in the director role.
|
|
4
|
+
version: 0.1.0
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Planka workflow orchestrator
|
|
8
|
+
|
|
9
|
+
Use this skill only for the optional workflow documented in `workflow/README.md`.
|
|
10
|
+
The Planka MCP server must be connected and the repository must define its own build,
|
|
11
|
+
test, review, and merge rules.
|
|
12
|
+
|
|
13
|
+
## Role boundary
|
|
14
|
+
|
|
15
|
+
You are the director. Do not edit repository files. Workers are the only writers:
|
|
16
|
+
one worker, one card, one branch, one worktree.
|
|
17
|
+
|
|
18
|
+
The director may:
|
|
19
|
+
|
|
20
|
+
- read the repository and board;
|
|
21
|
+
- create and update cards;
|
|
22
|
+
- create worktrees with the repository's supported helper;
|
|
23
|
+
- dispatch or continue workers;
|
|
24
|
+
- audit diffs, commits, checks, comments, and attachments;
|
|
25
|
+
- merge through the repository's supported path;
|
|
26
|
+
- clean completed worktrees.
|
|
27
|
+
|
|
28
|
+
## Preflight
|
|
29
|
+
|
|
30
|
+
1. Read the repository's agent instructions and workflow documentation.
|
|
31
|
+
2. Check the base tree and current worktrees without changing them.
|
|
32
|
+
3. Read the full board.
|
|
33
|
+
4. For every candidate card, read the description and all comments in order.
|
|
34
|
+
5. Confirm the card has acceptance criteria and one behavior label.
|
|
35
|
+
6. Resolve `serial` and `zone:*` exclusions before creating anything.
|
|
36
|
+
|
|
37
|
+
Never trust a suspicious zero-comment result blindly. If the card's state implies a
|
|
38
|
+
decision or prior work, use `planka_get_comments` and report an MCP/API mismatch.
|
|
39
|
+
|
|
40
|
+
## Selection
|
|
41
|
+
|
|
42
|
+
Choose cards in this order:
|
|
43
|
+
|
|
44
|
+
1. Cards in `Needs your decision` with a human-applied `decided` label.
|
|
45
|
+
2. Eligible `Pending` cards whose zones are free.
|
|
46
|
+
3. At most the concurrency limit supported by the repository and machine.
|
|
47
|
+
|
|
48
|
+
Do not select:
|
|
49
|
+
|
|
50
|
+
- a card whose required decision is absent or ambiguous;
|
|
51
|
+
- two cards with the same `zone:*` label;
|
|
52
|
+
- any second card beside a `serial` card;
|
|
53
|
+
- work requiring credentials, hardware, external approval, or irreversible changes
|
|
54
|
+
that the worker cannot verify safely.
|
|
55
|
+
|
|
56
|
+
For a `decided` card, read the newest human decision, treat it as binding, and update
|
|
57
|
+
the description so the chosen scope can be understood without reconstructing the
|
|
58
|
+
comment thread. Never apply `decided` or `tested-ok` yourself.
|
|
59
|
+
|
|
60
|
+
## Dispatch
|
|
61
|
+
|
|
62
|
+
For each selected card:
|
|
63
|
+
|
|
64
|
+
1. Create the branch and worktree using the repository helper.
|
|
65
|
+
2. Update the card's `<!-- agent-work -->` metadata.
|
|
66
|
+
3. Move the card to `In worktree` only after the Git state exists.
|
|
67
|
+
4. Dispatch one worker from inside that worktree.
|
|
68
|
+
|
|
69
|
+
The worker brief must contain:
|
|
70
|
+
|
|
71
|
+
- exact mission and acceptance criteria;
|
|
72
|
+
- the complete current card context, including decisions;
|
|
73
|
+
- allowed repository scope and explicit exclusions;
|
|
74
|
+
- worktree path and branch;
|
|
75
|
+
- required checks and manual verification;
|
|
76
|
+
- required closing comment and commit evidence.
|
|
77
|
+
|
|
78
|
+
Workers may use their own bounded subagents, but only one worker session owns writes
|
|
79
|
+
to the worktree. If correction is needed, continue the same session when possible.
|
|
80
|
+
|
|
81
|
+
## Audit
|
|
82
|
+
|
|
83
|
+
Audit, do not recreate, the worker's evidence:
|
|
84
|
+
|
|
85
|
+
- inspect the commit and important diff;
|
|
86
|
+
- confirm required checks actually ran and passed;
|
|
87
|
+
- confirm the acceptance step matches the card;
|
|
88
|
+
- inspect visual evidence when the behavior is visual;
|
|
89
|
+
- confirm the closing comment states omissions and remaining risk honestly;
|
|
90
|
+
- confirm the worker changed only its assigned scope.
|
|
91
|
+
|
|
92
|
+
If evidence is incomplete, leave a concrete comment and continue the same worker with
|
|
93
|
+
one targeted request. Do not mark a theory as a verified result.
|
|
94
|
+
|
|
95
|
+
## Destination
|
|
96
|
+
|
|
97
|
+
- Merge when repository checks and acceptance evidence are complete and no veto
|
|
98
|
+
applies.
|
|
99
|
+
- Use `Test it` when a human must judge something before merge. State exactly what
|
|
100
|
+
to inspect and why the worker could not settle it.
|
|
101
|
+
- Merge to `Review in main` when all pre-merge evidence exists but the final proof
|
|
102
|
+
only exists in the integrated environment. State the exact post-merge check.
|
|
103
|
+
- Use `Needs your decision` for product, access, cost, or irreversible choices. Ask
|
|
104
|
+
one concise question.
|
|
105
|
+
|
|
106
|
+
Security/access boundaries, destructive data operations, billing, shared
|
|
107
|
+
infrastructure, physical hardware, and third-party approvals are human gates unless
|
|
108
|
+
the repository explicitly defines a safe automated proof.
|
|
109
|
+
|
|
110
|
+
## Merge and close
|
|
111
|
+
|
|
112
|
+
Merge one worktree at a time through the repository's supported helper. Before merge:
|
|
113
|
+
|
|
114
|
+
- worker tree clean;
|
|
115
|
+
- worker commits exist;
|
|
116
|
+
- base tree clean;
|
|
117
|
+
- required checks and acceptance evidence recorded;
|
|
118
|
+
- card metadata matches the actual branch and worktree.
|
|
119
|
+
|
|
120
|
+
After merge, remove the worktree through the helper and make the board match reality.
|
|
121
|
+
Move directly to `Merged` only when all required verification is complete. A card in
|
|
122
|
+
`Review in main` moves to `Merged` only after a human applies `tested-ok` or gives an
|
|
123
|
+
equivalent explicit confirmation.
|
|
124
|
+
|
|
125
|
+
End with a compact report: cards selected, cards merged, cards waiting for a human,
|
|
126
|
+
checks, worktrees still alive, and any board/repository mismatch.
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Optional worktree helper
|
|
2
|
+
|
|
3
|
+
`wt.sh` is a conservative example for running one agent worker per Git worktree.
|
|
4
|
+
It manages Git mechanics; it does not choose cards or decide that a merge is safe.
|
|
5
|
+
|
|
6
|
+
The script has no built-in port range, package manager, dev command, environment
|
|
7
|
+
copy, or dependency install. Configure only what your repository needs.
|
|
8
|
+
|
|
9
|
+
## Install
|
|
10
|
+
|
|
11
|
+
From your repository root:
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
mkdir -p scripts
|
|
15
|
+
cp workflow/worktrees/wt.sh scripts/wt.sh
|
|
16
|
+
chmod +x scripts/wt.sh
|
|
17
|
+
cp workflow/worktrees/wt.conf.example .agent-worktrees.conf
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
Review `.agent-worktrees.conf` before use. Commit the script and config if they are
|
|
21
|
+
part of your team's contract. Add `.worktrees/` to `.gitignore`.
|
|
22
|
+
|
|
23
|
+
## Commands
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
scripts/wt.sh new fix-export-timeout
|
|
27
|
+
scripts/wt.sh up fix-export-timeout
|
|
28
|
+
scripts/wt.sh list
|
|
29
|
+
scripts/wt.sh doctor
|
|
30
|
+
scripts/wt.sh merge fix-export-timeout
|
|
31
|
+
scripts/wt.sh kill fix-export-timeout
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
`merge` performs a local `--no-ff` merge and never pushes.
|
|
35
|
+
|
|
36
|
+
## Development command discovery
|
|
37
|
+
|
|
38
|
+
If `WT_DEV_COMMAND` is empty, the helper looks for a `dev` script in
|
|
39
|
+
`package.json` and chooses a command from the repository lockfile:
|
|
40
|
+
|
|
41
|
+
| Lockfile | Command |
|
|
42
|
+
|---|---|
|
|
43
|
+
| `package-lock.json` | `npm run dev` |
|
|
44
|
+
| `pnpm-lock.yaml` | `pnpm run dev` |
|
|
45
|
+
| `yarn.lock` | `yarn dev` |
|
|
46
|
+
| `bun.lock` or `bun.lockb` | `bun run dev` |
|
|
47
|
+
|
|
48
|
+
Set an explicit command for non-Node repositories or unusual scripts:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
WT_DEV_COMMAND='make dev'
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
If the command needs a port, set `WT_PORT_START` and use `{port}` or read the `PORT`
|
|
55
|
+
environment variable:
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
WT_PORT_START=4100
|
|
59
|
+
WT_MAX_WORKTREES=4
|
|
60
|
+
WT_DEV_COMMAND='npm run dev -- --port {port}'
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
The numbers are examples in the config, not behavior compiled into the script.
|
|
64
|
+
|
|
65
|
+
## Environment safety
|
|
66
|
+
|
|
67
|
+
The helper does not copy `.env`. Parallel processes can duplicate queue consumers,
|
|
68
|
+
scheduled jobs, webhooks, billing calls, or production writes.
|
|
69
|
+
|
|
70
|
+
If a worktree needs environment values, create a reviewed safe template and opt in:
|
|
71
|
+
|
|
72
|
+
```bash
|
|
73
|
+
WT_ENV_TEMPLATE=.env.worktree
|
|
74
|
+
WT_ENV_TARGET=.env
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
Do not point `WT_ENV_TEMPLATE` at a production credential file. Disable background
|
|
78
|
+
workers and external side effects in the template itself.
|
|
79
|
+
|
|
80
|
+
## Dependency setup
|
|
81
|
+
|
|
82
|
+
Set `WT_INSTALL_COMMAND` when each worktree needs its own dependencies:
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
WT_INSTALL_COMMAND='npm ci'
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Leave it empty when your repository has another supported strategy. The helper does
|
|
89
|
+
not symlink dependency directories because that is not safe for every package manager.
|
|
90
|
+
|
|
91
|
+
## Safety model
|
|
92
|
+
|
|
93
|
+
- Slugs accept only lowercase letters, numbers, and hyphens.
|
|
94
|
+
- The base tree and worker tree must be clean before merge.
|
|
95
|
+
- A worker must contain commits not yet in the base branch.
|
|
96
|
+
- A configured development port must be free before start and stopped before merge.
|
|
97
|
+
- Merges are serialized with an atomic directory lock that works on macOS and Linux.
|
|
98
|
+
- Conflicts are resolved in the worker branch, never half-applied in the base tree.
|
|
99
|
+
- `kill` preserves unmerged work unless `--force` is explicit.
|
|
100
|
+
- No command pushes.
|
|
101
|
+
|
|
102
|
+
`doctor` reports files modified by more than one live worktree. This is an early
|
|
103
|
+
warning, not a conflict resolver. The board's `zone:*` rule should prevent most of
|
|
104
|
+
these overlaps before Git sees them.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Copy this file to .agent-worktrees.conf in your repository root.
|
|
2
|
+
|
|
3
|
+
# Defaults to the remote default branch, then main/master, then the current branch.
|
|
4
|
+
WT_BASE_BRANCH=
|
|
5
|
+
|
|
6
|
+
# Defaults shown here are paths/names, not environment-specific ports.
|
|
7
|
+
WT_ROOT=.worktrees
|
|
8
|
+
WT_BRANCH_PREFIX=agent/
|
|
9
|
+
WT_MAX_WORKTREES=4
|
|
10
|
+
|
|
11
|
+
# Leave empty to run without assigned ports. If set, each worktree receives the
|
|
12
|
+
# first free port starting here and `up` exports PORT. Use {port} in the command
|
|
13
|
+
# when your dev CLI needs an explicit argument.
|
|
14
|
+
WT_PORT_START=
|
|
15
|
+
|
|
16
|
+
# Leave empty to discover package.json#scripts.dev and the package manager lockfile.
|
|
17
|
+
WT_DEV_COMMAND=
|
|
18
|
+
|
|
19
|
+
# Optional command run once inside a newly created worktree.
|
|
20
|
+
WT_INSTALL_COMMAND=
|
|
21
|
+
|
|
22
|
+
# Environment copying is opt-in. Point only at a reviewed, worktree-safe template.
|
|
23
|
+
WT_ENV_TEMPLATE=
|
|
24
|
+
WT_ENV_TARGET=.env
|