deskwork
What an agent noticed, tracked as real work
An agent that spots a problem mid-task usually mentions it once and moves on. deskwork files it as a GitHub issue, keeps the dependency edges between issues honest, and writes a roadmap into the repository - with the date, the issue count it was built from and one line of reasoning per call, so the ordering can be argued with rather than trusted.
Install deskwork
Add the DBHQ marketplace, once
/plugin marketplace add dbhq-uk/marketplaceInstall the skill
/plugin install deskwork@dbhq
Both commands work in Claude Code and in Codex. The marketplace is a public repository you can read first: dbhq-uk/marketplace (external site)
What it is good at
Filing a finding where it will be seen again
capture turns something an agent noticed into a tracked issue with its context attached, instead of a sentence in a transcript nobody will read twice. A body that leaves a required section unfilled is refused, and if the issue looks like one already open or closed in the last 30 days, it files nothing and shows the candidates instead.
Keeping GitHub's issue identifiers apart
One issue carries an issue number, a REST database id and a GraphQL node id, and none of them is interchangeable. The REST dependencies API wants the database id, and handed a number it links a different issue in a different repository while still reporting success - so deskwork never calls it. Edges are written by issue number through the GitHub CLI, every write is read back, and an edge that landed wrong is named with the command that removes it.
Recording why the order is the order
The roadmap carries the date, the issue count behind it and a line of reasoning per call. An order that puts a closed, blocked or unreviewed issue next is refused whole, by name. It is built to be disagreed with, which a generated list of numbers cannot be.
Leaving the reasoning to the agent and the decision to you
review writes nothing: it prints the graph, the agent proposes what should block what, and you approve or reject each proposal. One verb per answer records it, with its reason, in a comment on the issue, so a rejected edge is not proposed again. Nothing here computes a priority and presents it as a fact.
What it does not do
It does not close issues
There is no close verb anywhere in it, and the one module that talks to GitHub refuses a close, delete or transfer before the call is made. A pull request may carry Closes #N and GitHub closes the issue on merge, after a human has reviewed - so the constraint holds itself rather than depending on restraint.
It does not touch pull requests
It neither merges nor proposes a merge order - buildwork proposes one, and a human merges. It pushes nothing either: roadmap commits one file locally and leaves the push to you, which matters most where merging to the default branch is what deploys.
It does not infer a dependency edge
An edge exists because it was proposed and accepted, and the reasoning is recorded beside it. Nothing is derived from titles, labels or timing.
It does not hold a credential
An authenticated GitHub CLI is the credential. It stores no token and keeps no settings directory of its own, so there is nothing of its own to leak.
It has not yet had a supervised run on a real repository
Every mode is tested end to end against a fake GitHub CLI that keeps a small GitHub in a file, and none has yet been run against a real repository and Projects v2 board. A first deployment should start with init on a test repository, with a human watching.
Read it before you install it
Every line is public and MIT licensed. The README is the long version of this page, including the parts that are still rough.