| 1 | --- |
| 2 | title: Work items |
| 3 | description: Track any work, a feature, a bug or a chore, as a work item of your workspace. Link it to the repositories it starts in and lands in, number it once for the whole workspace, close it when every repository has landed, and work on it from the site, the CLI, MCP and the API. |
| 4 | --- |
| 5 | |
| 6 | A work item is anything your team means to do: a feature, a bug, a chore. |
| 7 | It belongs to the workspace, not to one repository, so work that spans a |
| 8 | service, its client and its docs is one item, with one number, one |
| 9 | conversation and one place that says what is done. |
| 10 | |
| 11 | **Work** is in the left rail, after **Home** and **Explore**, at |
| 12 | `g1t.sh/<workspace>/-/work`. A work item's page is |
| 13 | `g1t.sh/<workspace>/-/work/<number>`. Work has two sections. **Work |
| 14 | items**: the [list](#the-work-list), the [Board](#the-board), **New work |
| 15 | item**, **Labels** and **Milestones**. **Sessions**: the sessions working |
| 16 | on them, at `g1t.sh/<workspace>/-/work/sessions` (see |
| 17 | [the Sessions page](/guides/sessions/#the-sessions-page)). |
| 18 | |
| 19 | Work items used to be issues, one repository's each. [Issues became work |
| 20 | items](/about/issues-became-work-items/) says what changed for the ones you |
| 21 | had. |
| 22 | |
| 23 | ## What a work item has |
| 24 | |
| 25 | - a **title** and a **description** in Markdown. Whoever works on it, |
| 26 | person or agent, works from this text. Say what done means in plain |
| 27 | words, under a `## Definition of done` heading if you like: it is |
| 28 | context for whoever works on it and its reviewers, not something a merge |
| 29 | waits on; |
| 30 | - its **repositories**, each with a role (see below); |
| 31 | - **labels** and a **milestone**, both the workspace's; |
| 32 | - **comments**, **reactions** and **assignees**; |
| 33 | - what it is **blocked by**: other work items that must land first; |
| 34 | - a **state**: open or closed. A closed work item records why: |
| 35 | `completed` or `not_planned`. |
| 36 | |
| 37 | ## One number for the workspace |
| 38 | |
| 39 | Work items and pull requests share one sequence of numbers per workspace, |
| 40 | so `#12` names exactly one thing in it. Pull requests still live in their |
| 41 | repository, at `g1t.sh/<owner>/<repo>/pull/<number>`, but a new one takes |
| 42 | the workspace's next number. Pull requests opened before work items keep |
| 43 | the numbers they had. |
| 44 | |
| 45 | Wherever Markdown shows, in a description, a comment, a commit message or |
| 46 | chat, a reference links to what it names: |
| 47 | |
| 48 | | You write | It names | |
| 49 | | --- | --- | |
| 50 | | `#12`, in a repository | That repository's pull request #12, else the work item that was its issue #12, else the workspace's work item #12, else pull request #12 in another of the workspace's repositories | |
| 51 | | `#12`, outside a repository | The workspace's work item #12, else its pull request #12 | |
| 52 | | `owner/name#12` | `#12` as it reads in repository `owner/name` | |
| 53 | | `workspace#12` | Work item or pull request #12 of another workspace | |
| 54 | |
| 55 | So old references keep working: `#12` written about an issue before work |
| 56 | items, `owner/repo#12`, and `Closes #12` in a commit, all reach the work |
| 57 | item that issue became. |
| 58 | |
| 59 | ## Repositories and their roles |
| 60 | |
| 61 | A work item links any number of the workspace's repositories, each in one |
| 62 | role: |
| 63 | |
| 64 | | Role | Means | |
| 65 | | --- | --- | |
| 66 | | `origin` | The repository it was filed in. A work item opened from a repository has one; one opened on **Work** itself has none. | |
| 67 | | `target` | A repository the work is meant to land in. | |
| 68 | | `touched` | A repository where a pull request or commit for it landed or is in progress. g1t adds these itself, when a pull request is opened for the work item or a commit names it. | |
| 69 | |
| 70 | A work item's page lists its repositories with their roles, each with its |
| 71 | pull requests for the item and whether it has **landed**. Under them, |
| 72 | **Suggested** names repositories it may also need, each with why: work |
| 73 | items like it landed there before, its CODEOWNERS cover what the item |
| 74 | talks about, or sessions on the item touched it. Choose **Add as target** |
| 75 | to link one. |
| 76 | |
| 77 | With the Triage role or higher, choose **Link a repository** to add one |
| 78 | in a role, and the cross beside a repository to unlink it. Each is noted in |
| 79 | the conversation, and is a `work_item.linked` or `work_item.unlinked` |
| 80 | event. |
| 81 | |
| 82 | ## Closing a work item |
| 83 | |
| 84 | A pull request that merges into its repository's default branch, or a |
| 85 | commit pushed there, marks **its repository** as landed on every work item |
| 86 | it names after a closing keyword (`Closes #12`, `Fixes #12`, |
| 87 | `Resolves #12`; see [Closing work items](/guides/pull-requests/#closing-work-items)). |
| 88 | The work item records it as a **resolution**: the repository, and the pull |
| 89 | request or commit that landed it. |
| 90 | |
| 91 | The work item closes as `completed`: |
| 92 | |
| 93 | - when it has no target, at the first resolution; |
| 94 | - when it has targets, once every target has landed. |
| 95 | |
| 96 | Until then it stays open, and its page says which targets are still |
| 97 | missing. A pull request that does only part of a repository's share says |
| 98 | `Part of #12` instead (or `Refs #12`): it links the pull request to the |
| 99 | work item, and the repository as touched, without landing anything. |
| 100 | |
| 101 | A work item in another workspace is never closed by your repositories: |
| 102 | `Closes other-workspace#3` does nothing. |
| 103 | |
| 104 | You can also close a work item yourself, as `completed` or `not_planned`, |
| 105 | and reopen it. Reopening clears its resolutions. |
| 106 | |
| 107 | ## Labels and milestones |
| 108 | |
| 109 | Labels and milestones belong to the workspace, and every work item and |
| 110 | pull request in it uses the same ones. See [labels](/guides/labels/) and |
| 111 | [milestones](/guides/milestones/). Both are under **Work**: |
| 112 | **Labels** at `g1t.sh/<workspace>/-/work/labels` and **Milestones** at |
| 113 | `g1t.sh/<workspace>/-/work/milestones`. |
| 114 | |
| 115 | ## Who sees a work item |
| 116 | |
| 117 | - The workspace's members see every work item. |
| 118 | - Anyone who can read a work item's origin repository sees it. Work items |
| 119 | filed in a public repository are public, and anyone who can take part in |
| 120 | a public repository can file one there. |
| 121 | - A work item with no origin is seen only by members. |
| 122 | |
| 123 | What you can do with one follows your [role](/guides/access-and-roles/): |
| 124 | the higher of your role in the workspace and your role in its origin |
| 125 | repository. Triage labels, assigns and links repositories; the author and |
| 126 | whoever asked for it can edit it. |
| 127 | |
| 128 | ## The Work list |
| 129 | |
| 130 | **Work** lists the workspace's work items, open first, newest first. |
| 131 | Filter it by state, label, milestone, assignee, repository and role (for |
| 132 | example the items a repository is a target of). The address keeps the |
| 133 | filters, so a filtered list can be shared. The work items of one |
| 134 | repository are the list filtered to it: |
| 135 | `g1t.sh/<workspace>/-/work?repo=<name>`. |
| 136 | |
| 137 | Above the list, **Cooking now** is a strip of the sessions live in the |
| 138 | workspace right now; it links to Work's |
| 139 | [Sessions](/guides/sessions/#the-sessions-page), which has them all. |
| 140 | |
| 141 | Work's sidebar has two sections. **Work items**: **Open**, **Assigned to |
| 142 | you** and **Closed**, then **Board**, **New work item**, **Labels** and |
| 143 | **Milestones**. **Sessions**: **Live now**, **Recent** and **Yours**, then |
| 144 | each kind of session. On a phone, the bar along the bottom is **Home**, |
| 145 | **Work**, **Chat**, **Notifications** and **More**, with **Work** there |
| 146 | for every member, Code access or not. Tapping **Work** again opens its |
| 147 | menu, the same two sections. **More** starts with **Explore**, then |
| 148 | **Code**. |
| 149 | |
| 150 | ## The Board |
| 151 | |
| 152 | **Board**, at `g1t.sh/<workspace>/-/work/board`, is the backlog as it |
| 153 | moves. Its columns come from what is true of each work item, so there is |
| 154 | nothing to drag: |
| 155 | |
| 156 | | Column | Holds the work items | |
| 157 | | --- | --- | |
| 158 | | **Backlog** | Open, with nobody on it. | |
| 159 | | **In progress** | Claimed or assigned, with a live session on it, or with a draft pull request. | |
| 160 | | **In review** | With an open pull request. | |
| 161 | | **Landing** | Landed in some of its target repositories, still missing in others. | |
| 162 | | **Done** | Closed in the last 14 days. | |
| 163 | |
| 164 | A work item goes in the first column that holds for it, in the order |
| 165 | **Done**, **Landing**, **In review**, **In progress**, **Backlog**. Each |
| 166 | card links to its work item and shows who, or which session, is on it. |
| 167 | Filter it by repository with `?repo=<name>`. On a phone the Board shows |
| 168 | one column at a time, with a switcher for the column. |
| 169 | |
| 170 | ## Open a work item |
| 171 | |
| 172 | On **Work**, choose **New work item**. Give it a title and a description, |
| 173 | and pick the repositories it should land in, as targets: none, one or |
| 174 | several. Opened from the list filtered to a repository, that repository |
| 175 | is its origin. |
| 176 | |
| 177 | From the CLI, `g1t work new` opens one in the current repository's |
| 178 | workspace, with the repository as its origin: |
| 179 | |
| 180 | ```sh |
| 181 | g1t work new --title "Sign-in times out on slow networks" --body "…" |
| 182 | g1t work new --title "Rename the flag" --target acme/api --target acme/docs |
| 183 | ``` |
| 184 | |
| 185 | `--target` names a repository it should land in; repeat it for more. |
| 186 | `--workspace`, outside a repository of that workspace, opens one with no |
| 187 | repository as its origin. |
| 188 | |
| 189 | ## Work on one |
| 190 | |
| 191 | Claims, hand-offs, dependencies and sessions are how people and coding |
| 192 | agents work on a work item at once without getting in each other's way; |
| 193 | see [sessions, claims and dependencies](/guides/sessions/). A session is |
| 194 | recorded in the repository it is checked out in, and the work item it |
| 195 | works on is the workspace's. A work item's page lists the sessions on |
| 196 | it; Work's **Sessions** lists every session in the workspace. |
| 197 | |
| 198 | To open a pull request for a work item, use `g1t pr create --item 12`, or |
| 199 | the `pull_request` tool's `create` with `item: 12`. The pull request's |
| 200 | repository becomes touched on the work item, and the pull request lands it |
| 201 | there when it merges. |
| 202 | |
| 203 | ## The CLI |
| 204 | |
| 205 | `g1t work` works on the current repository's workspace, or the one in |
| 206 | `--workspace` (or the `G1T_WORKSPACE` environment variable). `-R` (or |
| 207 | `--repo`) `owner/name` names a repository instead of the current one: |
| 208 | it filters `g1t work list`, and is the repository `g1t work link` and |
| 209 | `g1t work unlink` act on. Every command takes `--json`. |
| 210 | |
| 211 | | Command | Does | |
| 212 | | --- | --- | |
| 213 | | `g1t work list` | Lists open work items. `-R`, `--state`, `--label`, `--milestone`, `--assignee` and `--author` narrow it; with `-R`, `--role` keeps those linked to the repository in one role. | |
| 214 | | `g1t work view N` | Shows the work item with everything about its work: its repositories and what landed, claims, sessions, pull requests, what blocks it, decisions. | |
| 215 | | `g1t work new` | Opens a work item; `--target` for each repository it should land in. `--attach FILE` adds an image to its description: uploaded to the repository it is filed from, or, filed in the workspace alone, to the work item once it is open. | |
| 216 | | `g1t work comment N` | Comments on it. `--attach FILE` uploads an image to the work item and adds it to the comment. | |
| 217 | | `g1t work edit N` | Changes its title, description, labels, assignees or milestone. | |
| 218 | | `g1t work close N` | Closes it, as completed, or `--reason not_planned`. `--commit SHA` names a commit on the default branch that did it, which lands it there. | |
| 219 | | `g1t work reopen N` | Opens it again. | |
| 220 | | `g1t work link N` | Links a repository in a role: `--role target` (the default) or `touched`, the current repository or `-R owner/name`. | |
| 221 | | `g1t work unlink N` | Unlinks a repository, never its origin. | |
| 222 | | `g1t work claim N` | Says you are working on it. With `--title` instead of a number, opens a work item and claims it. | |
| 223 | | `g1t work release N` | Lets go of your claim. | |
| 224 | | `g1t work handoff N` | Hands it to someone else, or to anyone, with a note. | |
| 225 | | `g1t work status` | The repository's active claims and sessions. | |
| 226 | | `g1t work block N --by M` | Says it waits on work item M; `g1t work unblock N --by M` takes that back. | |
| 227 | | `g1t work events` | The repository's events; `--follow` keeps printing them, `--item N` for one work item. | |
| 228 | | `g1t work dispatch N` | Starts work on it in a session on your own Claude, or prints the Claude Code command for it. | |
| 229 | |
| 230 | [CLI commands](/reference/cli/#g1t-work) lists every flag. |
| 231 | |
| 232 | ## MCP and the API |
| 233 | |
| 234 | The MCP server's `work_item` tool takes an `action`: `list`, `get`, |
| 235 | `create`, `update`, `close`, `reopen`, `links`, `link`, `unlink`, the |
| 236 | label actions, `comment`, `react`, `attach`, `decisions`, `resolve`, `claim`, |
| 237 | `release`, `handoff`, `work` and `import`, among others. A workspace's |
| 238 | labels and milestones are on the `workspace` tool, and a repository's |
| 239 | work list is the `repository` tool's `work`. It takes |
| 240 | `workspace` and `number`; `repo` is optional, as the origin of a new work |
| 241 | item, a filter, or to find the workspace. See [MCP tools](/reference/mcp/). |
| 242 | |
| 243 | The REST API has the same under `/workspaces/{workspace}/work`: |
| 244 | |
| 245 | | To | REST | |
| 246 | | --- | --- | |
| 247 | | List work items | `GET /workspaces/{workspace}/work` | |
| 248 | | Open one | `POST /workspaces/{workspace}/work` | |
| 249 | | Get one | `GET /workspaces/{workspace}/work/{number}` | |
| 250 | | Change one | `PATCH /workspaces/{workspace}/work/{number}` | |
| 251 | | Close or reopen it | `POST /workspaces/{workspace}/work/{number}/close`, `…/reopen` | |
| 252 | | Its repositories | `GET /workspaces/{workspace}/work/{number}/links` | |
| 253 | | Link or unlink a repository | `POST` or `DELETE /workspaces/{workspace}/work/{number}/links` | |
| 254 | | Its labels | `GET`, `POST`, `PUT` or `DELETE /workspaces/{workspace}/work/{number}/labels` | |
| 255 | | Comment | `POST /workspaces/{workspace}/work/{number}/comments`; `PATCH` or `DELETE /workspaces/{workspace}/work/comments/{id}` | |
| 256 | | React | `POST /workspaces/{workspace}/work/{number}/reactions` | |
| 257 | | Upload an image for it | [`POST /workspaces/{workspace}/work/{number}/attachments`](/reference/api/work-items/upload-work-item-attachment/), with `work:write`; anyone who may comment on it may | |
| 258 | | Its decisions, with its pull requests' | `GET /workspaces/{workspace}/work/{number}/decisions` | |
| 259 | | Watch it | `GET`, `PUT` or `DELETE /workspaces/{workspace}/work/{number}/subscription` | |
| 260 | | Its work context | `GET /workspaces/{workspace}/work/{number}/work` | |
| 261 | | Claim, release, hand off | `POST /workspaces/{workspace}/work/{number}/claim`, `…/release`, `…/handoff` | |
| 262 | | A repository's work items | `GET /repos/{owner}/{name}/work` | |
| 263 | | What `#N` names | `GET /repos/{owner}/{name}/refs/{number}`, or `GET /workspaces/{workspace}/refs/{number}` | |
| 264 | | The workspace's labels and milestones | `/workspaces/{workspace}/labels`, `/workspaces/{workspace}/milestones` | |
| 265 | |
| 266 | ```sh |
| 267 | curl -X POST https://api.g1t.sh/workspaces/acme/work \ |
| 268 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 269 | -H "Content-Type: application/json" \ |
| 270 | -d '{"title": "Sign-in times out", "repo": "acme/web", "targets": ["acme/web", "acme/api"]}' |
| 271 | ``` |
| 272 | |
| 273 | A work item has `workspace`, `number`, `title`, `body`, `state`, `reason`, |
| 274 | `labels`, `milestone`, `assignees`, `blocked_by`, `repos` (each with |
| 275 | `path`, `role`, `landed` and, for one that was an issue, its |
| 276 | `legacy_number`) and `resolutions` (each with `repo` and the `pull` or |
| 277 | `commit` that landed it). Changing work items needs a token with |
| 278 | `work:write`. |
| 279 | |
| 280 | Every change is an event, `work_item.opened`, `work_item.closed` and so |
| 281 | on, sent to [webhooks](/guides/webhooks/): a repository's webhooks for the |
| 282 | work items linked to it, a workspace's for all of them. |