Using AgentDock
Task queue
GitHub issues as the queue, ready labels and blockers.
AgentDock has no task tracker of its own. The orchestrator's queue is the project's open GitHub issues that carry the ready label, and the Queue page shows that queue the way the orchestrator sees it. Open it from Project → Queue.
GitHub stays the editor: you label, edit, close and prioritise issues there. The only write the Queue page offers is filing a new issue.
How an issue gets into the queue
An open issue is in the queue when it carries the project's ready label. The label is, in order:
- the project's Ready label override (Settings → General);
orchestrator.readyLabelfrom the project's.code-analyzer-config.json;cs:ready.
Add the label on GitHub, use /code-sentinel:issue --ready or /code-sentinel:spec in Claude Code, or click New issue on the Queue page. See Writing specs for how to write an issue the orchestrator can dispatch.
States
Every queued issue gets one state, computed with the same rules as the orchestrator's own triage. The first rule that matches wins.
| State | When | What clears it |
|---|---|---|
in_flight (IN FLIGHT) | An open pull request says Closes #n (or Fixes, Resolves), a live slot works on the issue, or the issue has cs:in-flight | The pull request merges or closes |
blocked_person (BLOCKED, person) | The issue has cs:needs-person, or its body has a Gate: line | A person answers and removes the gate |
blocked_work (BLOCKED, work) | A Depends on #m line points at an issue that is open, or was closed without a merged pull request | #m is closed by a merged pull request |
no_spec (NO SPEC) | The body has no acceptance criteria, a bug has no reproduction, or a size: XL / size: XXL issue has no ## Parallel plan | Edit the body on GitHub |
ready (READY) | None of the above | The orchestrator dispatches it |
Each row also shows the reason, what would clear it, and the priority. The list is ordered like the orchestrator orders it: priority: critical, then high, then medium, then unlabelled, then by lowest issue number.
Body conventions the queue reads
Depends on #41
## Acceptance criteria
- [ ] Exports a CSV of the filtered rows
- [ ] An empty filter exports every row
## Parallel plan
| Slot | Owns | Touches | Depends on | Lead | Model |
|---|---|---|---|---|---|
| i42-api | apps/api/src/export/** | apps/api/src/app.module.ts | none | yes | opus |- Acceptance criteria: a
## Acceptance criteriasection with at least one- [ ]item. A bug instead needs## Steps to reproduceor## Reproduction. Depends on #m: read only at the start of a line, outside code fences, and never asowner/repo#m. A dependency closed by hand, without a merged pull request, still blocks.## Parallel plan: the slot table thatcs-specwrites. AgentDock does not recompute waves; it lists the slot names, lead and model under the issue.
The orchestrator's verdict wins
The orchestrator writes its own verdict for each issue on its round board. When that round is newer than the last change to the issue, the Queue page shows the orchestrator's state and reason, and marks the source. If AgentDock's own computation disagrees, a muted note says what AgentDock computed. This keeps one brain: the orchestrator.
Held for a lead, below the list, comes only from the orchestrator's latest round. It lists slots waiting for a lead slot to merge first, and when they will dispatch.
List and Board views
Switch between List and Board in the toolbar. The board has five fixed columns, one per state. You cannot move cards: state comes from GitHub and the orchestrator, never from the UI.
Click an issue to open its sheet: the body, its blockers with links, its parallel-plan slots, its state in recent rounds, and a link to GitHub. Filter chips narrow the list by state. Refresh (operators) asks the runner to poll GitHub now.
Create an issue
Operators can click New issue. The dialog has Title, Body, Labels and a Queue for the orchestrator switch.
- The runner files the issue with its own
gh(gh issue create --repo <owner/repo>), so it is authored by the GitHub account signed in on that machine. - Queue for the orchestrator adds the ready label only when the body is complete enough to dispatch: it has acceptance criteria, and a
size: XLissue has a parallel plan. Otherwise the switch is disabled and the dialog says what is missing. - Labels are limited to labels that already exist on the repository's issues, plus
enhancementandbug. The ready label itself cannot be picked by hand, so the completeness rule cannot be skipped.
Every created issue is audited with its title, labels and whether it was queued.
How fresh the queue is
The runner's issues collector polls GET /repos/<owner>/<repo>/issues?state=open through gh, with an ETag, so an unchanged queue costs no GitHub rate limit.
| Situation | Poll interval |
|---|---|
| Default | 60 seconds |
| Your setting | queue.pollSeconds in runner.json, from 15 to 3600 |
| GitHub App installed and healthy for the project | 10 minutes, because push events trigger an immediate poll |
With the optional GitHub App, GitHub tells AgentDock when an issue, pull request or check changes and the runner polls at once. If GitHub stops reaching you, the runner falls back to 60 seconds. Nothing breaks either way.
Open pages update live: a change in the queue reaches the browser within a few seconds of the next poll.
Who can do what
| Action | Minimum role on the project |
|---|---|
| See the queue and issue sheets | viewer |
| Refresh, create an issue | operator |
A user who is not a member of the project gets a 404, as if the project did not exist.