Field report from commissioning a project board end-to-end with an agent (private repo, 2026-07-20).
Context
An agent can build almost all of a project board through the CLI/API: create the project, add
custom fields, create and close milestones, bootstrap labels, create issues, set every field value,
link the project to a repo. In one run this week that was 13 milestones, 4 labels, 4 custom fields
and 75 backfilled issues.
What it cannot do is a small, stubborn residue:
- Project views have no create API at all — the roadmap/table/board layouts that make the board
usable are UI-only. The agent can build the whole board and still leave the human looking at a
default table.
- Auto-add workflows are UI-only, and plan-capped (1 on Free).
- Some edits are safer by hand, or need a permission the agent's token deliberately lacks.
The standard says nothing about what the agent owes the human at that boundary. So the residue gets
delivered as prose at the end of a chat session — ephemeral, unsearchable, unassignable,
invisible to anyone else working the board, and gone the moment the session is closed. The work is
reported "done" while a mandatory human step is recorded nowhere durable.
The right instinct is already in the standard, scoped to exactly one case —
session-end-checklist.md
on unmerged branches: "merge it, delete it, or open an issue that owns it. No silent
survivors." Manual residue deserves the same treatment.
This is not board-specific. The same shape appears whenever an agent commissions shared
infrastructure: CI that needs a secret or Environment only an owner can create, a DNS record, an org
policy toggle, a plan-gated feature, anything behind interactive authentication.
Proposal
A Commissioning handoff section in
agent-collaboration.md:
- One issue owns the residue. When an agent commissions shared infrastructure and any step
cannot be completed with the tools it holds, it opens — or keeps open — exactly one issue that
owns those steps, before it reports the work done. Chat is a delivery mechanism, not a record.
- It is assigned to the human who owns the resource, and sits in the review/verify column. The
agent does not close it: this is the existing closing-force rule doing its job, and it means an
incomplete commissioning is visible on the board rather than asserted complete in a transcript.
- Body uses the three-audience format already defined in this doc (Option A "tell your agent" /
Option B GUI clicks / Option C CLI + shared Verify), with each residual step as a checkbox
so partial progress is visible.
- Each step says why it is manual — one of: no API, permission/scope withheld,
plan-gated, interactive auth, deliberately human (irreversible or judgement-bearing). This
matters because the reason expires: "no API" today becomes a one-line script when the platform
ships the endpoint, and a labelled reason is re-evaluable where "do this in the UI" is not.
- It links what was commissioned — the board/pipeline/environment — and every doc the
commissioning changed, per the linking rule (see the companion issue).
And one line in
session-end-checklist.md:
Tasks
Acceptance criteria
- After an agent commissions a board, the human's remaining to-do list exists as an assigned,
checkboxed issue on that board, not in a chat transcript.
- The rule names the residue classes and requires a reason per step.
- The session-end checklist fails if residue exists only in chat.
— 🤖 Claude, on behalf of @PBNZ
Field report from commissioning a project board end-to-end with an agent (private repo, 2026-07-20).
Context
An agent can build almost all of a project board through the CLI/API: create the project, add
custom fields, create and close milestones, bootstrap labels, create issues, set every field value,
link the project to a repo. In one run this week that was 13 milestones, 4 labels, 4 custom fields
and 75 backfilled issues.
What it cannot do is a small, stubborn residue:
usable are UI-only. The agent can build the whole board and still leave the human looking at a
default table.
The standard says nothing about what the agent owes the human at that boundary. So the residue gets
delivered as prose at the end of a chat session — ephemeral, unsearchable, unassignable,
invisible to anyone else working the board, and gone the moment the session is closed. The work is
reported "done" while a mandatory human step is recorded nowhere durable.
The right instinct is already in the standard, scoped to exactly one case —
session-end-checklist.mdon unmerged branches: "merge it, delete it, or open an issue that owns it. No silent
survivors." Manual residue deserves the same treatment.
This is not board-specific. The same shape appears whenever an agent commissions shared
infrastructure: CI that needs a secret or Environment only an owner can create, a DNS record, an org
policy toggle, a plan-gated feature, anything behind interactive authentication.
Proposal
A Commissioning handoff section in
agent-collaboration.md:cannot be completed with the tools it holds, it opens — or keeps open — exactly one issue that
owns those steps, before it reports the work done. Chat is a delivery mechanism, not a record.
agent does not close it: this is the existing closing-force rule doing its job, and it means an
incomplete commissioning is visible on the board rather than asserted complete in a transcript.
Option B GUI clicks / Option C CLI + shared Verify), with each residual step as a checkbox
so partial progress is visible.
plan-gated, interactive auth, deliberately human (irreversible or judgement-bearing). This
matters because the reason expires: "no API" today becomes a one-line script when the platform
ships the endpoint, and a labelled reason is re-evaluable where "do this in the UI" is not.
commissioning changed, per the linking rule (see the companion issue).
And one line in
session-end-checklist.md:owned by an assigned, checkboxed issue.
Tasks
standard/agent-collaboration.md.standard/session-end-checklist.md.standard/org-migration-checklist.md— board rebuild is the canonicalinstance (views + auto-add are exactly this residue), and that doc already tells you to
"budget the click-through" without saying where the click-through gets written down.
cap, workflow re-verification) so the handoff issue is generated, not remembered.
Acceptance criteria
checkboxed issue on that board, not in a chat transcript.
— 🤖 Claude, on behalf of @PBNZ