flagon-io/g1t

public

Where people and agents ship software together. The open-source git platform for the whole job: issues, agents, checks and deploys to the edge.

git agents cloudflare rust forge mcp

Commit

Web: Work's sidebar names Work once

Work's first rows sat under a Work items heading right below the mode's own Work label. Like every other mode's first rows, they are now unlabelled; Sessions keeps its heading.

G1T-Session:: ses_01m56x1naveyhs08bw0cwsh2sf

syntaqxcommitted 6h agoParentf436168Browse files

1	−	---
2	−	title: Issues became work items
3	−	description: Issues moved out of repositories into workspace-level work items. What happened to the issues, labels and milestones you had, why old links still work, and what to change in scripts and agents.
4	−	---
5	−
6	−	Issues used to belong to one repository each. They are now
7	−	[work items](/guides/work-items/), which belong to the workspace and can
8	−	link several repositories. Work, after Home and Explore in
9	−	the left rail, replaces each repository's Issues tab.
10	−
11	−	## What happened to your issues
12	−
13	−	Every issue became a work item, with everything it had: its title and
14	−	description, comments, reactions, labels, assignees, milestone, claims,
15	−	sessions, pull requests and what it was blocked by.
16	−
17	−	- It has a new number. Work items are numbered once for the whole
18	−	workspace, and each issue was given the next number, oldest first, above
19	−	every number any of the workspace's repositories had used. So an issue
20	−	number and a work item number never mean two things.
21	−	- Its repository is its origin. The work item links the repository
22	−	the issue was in as its `origin`, and keeps the old number there. Its
23	−	pull requests' repositories are linked as `touched`.
24	−	- Pull requests kept their numbers. New ones take the workspace's next
25	−	number.
26	−	- Who can see it did not change. Anyone who could read the repository
27	−	still sees the work item filed there. Members of the workspace now see
28	−	every work item in it.
29	−
30	−	## Old links still work
31	−
32	−	- `g1t.sh/<owner>/<repo>/issues/12` redirects to the work item that issue
33	−	became, at `g1t.sh/<owner>/-/work/<number>`. Issues, New issue,
34	−	Labels and Milestones under a repository redirect to Work:
35	−	the repository's issue list to the Work list filtered to it, and its
36	−	labels and milestones to the workspace's. A milestone's own old address,
37	−	`…/milestones/3`, lands on the milestones list, since milestones were
38	−	renumbered.
39	−	- A person's Issues tab is their Work items tab, at
40	−	`g1t.sh/u/<name>/items`.
41	−	- `#12` and `owner/repo#12` in descriptions, comments and commit messages
42	−	written before still link to that issue's work item.
43	−	- `Closes #12` in history still points at the right work item.
44	−	- A repository has no Work or Sessions page of its own, and
45	−	`g1t.sh/<owner>/<repo>/work` and `…/sessions` are not found. Its claims
46	−	and sessions are on Work's
47	−	[Sessions](/guides/sessions/#the-sessions-page), filtered to it:
48	−	`g1t.sh/<workspace>/-/work/sessions?repo=<name>`. A session's page is
49	−	`g1t.sh/<workspace>/-/work/sessions/<id>`, and a pull request's recorded
50	−	session is its Session tab, `…/pull/<number>/session`.
51	−
52	−	## Labels and milestones
53	−
54	−	Labels and milestones now belong to the workspace, too.
55	−
56	−	- Labels with the same name in several repositories became one label. The
57	−	one made first kept its color and description.
58	−	- Milestones were renumbered in the workspace. Each records the
59	−	repository it came from, and every work item and pull request in it
60	−	stayed in it.
61	−
62	−	## What to change
63	−
64	−	Nothing that reads links or references needs to change. What calls g1t by
65	−	name does:
66	−
67	−	\| Was \| Now \|
68	−	\| --- \| --- \|
69	−	\| `g1t issue …` \| `g1t work …`: `list`, `view`, `new`, `comment`, `edit`, `close`, `reopen` \|
70	−	\| `g1t browse --issues` \| `g1t browse --work` \|
71	−	\| `g1t work context N` \| `g1t work view N` \|
72	−	\| `g1t work list` (claims and sessions) \| `g1t work status` \|
73	−	\| `--issue N` on `g1t pr create`, `g1t session …` and `g1t work events` \| `--item N` \|
74	−	\| The MCP `issue` tool \| `work_item`, with `workspace` and `number` \|
75	−	\| `pull_request` `create` with `issue` \| `pull_request` `create` with `item` \|
76	−	\| `/repos/{owner}/{name}/issues…` \| `/workspaces/{workspace}/work…` \|
77	−	\| Repository labels and milestones routes \| `/workspaces/{workspace}/labels` and `/workspaces/{workspace}/milestones` \|
78	−	\| `issue.` events and webhooks \| `work_item.`. Webhooks you had were moved over for you. \|
79	−	\| `issue` and `other_issue` in event payloads \| `item` and `other_item` \|
80	−	\| Workflows `on: issues` and `on: issue_comment`, and `permissions: { issues: … }` \| `on: work_item`, `on: work_item_comment` and `permissions: { work: … }`. The old names still read but start and grant nothing, and the workflow's page says so. \|
81	−	\| The repository settings `has_issues` and `auto_close_issues` \| `has_work_items` and `auto_close_items` \|
82	−	\| Search `is:issue` and `type: issues` \| `is:item` and `type: items` \|
83	−	\| `issues:read`, `issues:write` scopes \| `work:read`, `work:write` \|
84	−	\| `/g1t:work-on-issue` in Claude Code \| `/g1t:work-on-item`, with the plugin 0.3.0 and the CLI 0.4.0 or later \|
85	−
86	−	There are no aliases for the old names: a script that calls one gets an
87	−	error, not a silent change. Numbers in your own data, such as a tracker
88	−	that stored `owner/repo#12`, still resolve, but a work item's own number
89	−	is the one to keep from now on.

1	−	---
2	−	title: Labels
3	−	description: Say what a work item or pull request is with colored labels, filter lists by them, and manage your workspace's labels.
4	−	---
5	−
6	−	A label says what a work item or a pull request is: a `bug`, a `question`,
7	−	`good first issue`. Labels belong to the workspace, so every repository in
8	−	it uses the same ones, each with a name, a color and a description. Work
9	−	items and pull requests carry them by name, lists show them as colored
10	−	chips, and you can filter either list by one.
11	−
12	−	## The labels a workspace starts with
13	−
14	−	A new workspace starts with these:
15	−
16	−	\| Label \| Color \| Description \|
17	−	\| --- \| --- \| --- \|
18	−	\| `bug` \| `d73a4a` \| Something isn't working \|
19	−	\| `documentation` \| `0075ca` \| Improvements or additions to documentation \|
20	−	\| `duplicate` \| `cfd3d7` \| This work item or pull request already exists \|
21	−	\| `enhancement` \| `a2eeef` \| New feature or request \|
22	−	\| `good first issue` \| `7057ff` \| Good for newcomers \|
23	−	\| `help wanted` \| `008672` \| Extra attention is needed \|
24	−	\| `invalid` \| `e4e669` \| This doesn't seem right \|
25	−	\| `question` \| `d876e3` \| Further information is requested \|
26	−	\| `wontfix` \| `ffffff` \| This will not be worked on \|
27	−	\| `dependencies` \| `0366d6` \| Updates a dependency \|
28	−	\| `security` \| `ee0701` \| A security fix or a vulnerability \|
29	−
30	−	Labels used to belong to each repository. When they moved to the
31	−	workspace, labels with the same name became one, and the one made first
32	−	kept its color and description; see
33	−	[Issues became work items](/about/issues-became-work-items/#labels-and-milestones).
34	−	To add the defaults a workspace lacks:
35	−
36	−	1. Open Work, then Labels.
37	−	2. Choose Add the default labels.
38	−
39	−	Labels the workspace has already are left as they are.
40	−
41	−	## Put labels on a work item or a pull request
42	−
43	−	1. Open the work item or pull request.
44	−	2. In the sidebar, choose the settings icon beside Labels.
45	−	3. Tick labels on and off. Type to find one by its name or description.
46	−	4. Close the menu. The labels save as it closes.
47	−
48	−	Each label put on or taken off is noted in the conversation, and is a
49	−	`work_item.labeled` or `work_item.unlabeled` event (`pull.labeled` and
50	−	`pull.unlabeled` on a pull request).
51	−
52	−	Who may do this:
53	−
54	−	- The author of a work item or a pull request, and whoever asked g1t for
55	−	one, may use the workspace's labels on it.
56	−	- Anyone with the Triage [role](/guides/access-and-roles/) or higher may
57	−	label anything, and make a label as they go: type a name the workspace
58	−	does not have, and choose Create.
59	−
60	−	A work item or a pull request carries at most 20 labels.
61	−
62	−	You can label a work item as you open it, too: tick labels on **New work
63	−	item**, or with the Write role, type new ones beside them.
64	−
65	−	## Filter by a label
66	−
67	−	On Work or Pull requests, choose Label and pick one. The
68	−	address keeps it, as `?label=bug`, so the filtered list can be shared. You
69	−	can also write it as `?q=label:bug`, with quotes around a name with
70	−	spaces: `?q=label:"good first issue"`. Clear filters shows everything
71	−	again.
72	−
73	−	## Manage the workspace's labels
74	−
75	−	Open Work, then Labels, at `g1t.sh/<workspace>/-/work/labels`. It
76	−	lists every label with its description and how many work items and pull
77	−	requests carry it; choose a count to see them. Search finds a label by its
78	−	name or description.
79	−
80	−	With the Write role in the workspace or higher you can (applying labels
81	−	needs only Triage):
82	−
83	−	\| To \| Do this \|
84	−	\| --- \| --- \|
85	−	\| Make a label \| New label: a name (lowercase, at most 50 characters), a description (at most 100), and a color. \|
86	−	\| Change one \| Edit. Renaming a label renames it on every work item and pull request that carries it, in every repository. \|
87	−	\| Delete one \| Delete. It comes off everything that carries it. This cannot be undone. \|
88	−
89	−	Names are lowercase and unique in a workspace: `Bug` and `bug` are the
90	−	same label.
91	−
92	−	## Labels and g1t
93	−
94	−	- [Dependency updates](/guides/dependency-updates/) carry `dependencies`
95	−	and their ecosystem's label (`javascript`, `rust`, `go`, `python`, …)
96	−	unless `labels` in the file says otherwise. Labels the workspace lacks
97	−	are made for them.
98	−	- [Workflows](/guides/actions/) can start on `labeled` and `unlabeled`
99	−	activity of `pull_request`.
100	−
101	−	## From the API
102	−
103	−	\| To \| REST \| MCP \|
104	−	\| --- \| --- \| --- \|
105	−	\| List labels \| `GET /workspaces/{workspace}/labels` \| `workspace` `list_labels` \|
106	−	\| Make one \| `POST /workspaces/{workspace}/labels` \| `workspace` `create_label` \|
107	−	\| Change one \| `PATCH /workspaces/{workspace}/labels/{label}` \| `workspace` `update_label` \|
108	−	\| Delete one \| `DELETE /workspaces/{workspace}/labels/{label}` \| `workspace` `delete_label` \|
109	−	\| Add the defaults \| `POST /workspaces/{workspace}/labels/defaults` \| `workspace` `add_default_labels` \|
110	−
111	−	URL-encode a label's spaces in a path: `good%20first%20issue`.
112	−
113	−	```sh
114	−	curl -X POST https://api.g1t.sh/workspaces/acme/labels \
115	−	-H "Authorization: Bearer $G1T_TOKEN" \
116	−	-H "Content-Type: application/json" \
117	−	-d '{"name": "needs design", "color": "fbca04"}'
118	−	```
119	−
120	−	`labels` on the work item routes (`POST /workspaces/{workspace}/work` and
121	−	`PATCH /workspaces/{workspace}/work/{number}`, the `work_item` tool's
122	−	`create` and `update`) and on `update_pull_request` set an item's labels,
123	−	and `label` filters `list_work_items` and `list_pull_requests`. Managing
124	−	labels needs a token with `work:write`, and listing them `work:read`.

1	−	---
2	−	title: Milestones
3	−	description: Gather work items and pull requests from across your workspace under a goal and a due date, and see how much of it is done.
4	−	---
5	−
6	−	A milestone gathers work items and pull requests under one goal, such as a
7	−	release, with an optional due date. Milestones belong to the workspace, so
8	−	one can hold work from any of its repositories. Its page shows everything
9	−	in it and how far along it is: the share of its work items and pull
10	−	requests that are closed. A merged pull request counts as closed.
11	−
12	−	## Make a milestone
13	−
14	−	You need the Triage [role](/guides/access-and-roles/) in the workspace or
15	−	higher.
16	−
17	−	1. Open Work, then Milestones.
18	−	2. Choose New milestone.
19	−	3. Give it a title, unique in the workspace, and if you like a due date
20	−	and a description. The description is Markdown.
21	−	4. Choose Create milestone.
22	−
23	−	Milestones are numbered from 1 in each workspace, apart from work items
24	−	and pull requests. The number is in its address:
25	−	`g1t.sh/<workspace>/-/work/milestones/3`.
26	−
27	−	Milestones used to belong to each repository. When they moved to the
28	−	workspace they were numbered again, and each records the repository it
29	−	came from; see
30	−	[Issues became work items](/about/issues-became-work-items/#labels-and-milestones).
31	−
32	−	## Put a work item or a pull request in one
33	−
34	−	1. Open the work item or pull request.
35	−	2. In the sidebar, choose the settings icon beside Milestone.
36	−	3. Pick a milestone, or Clear milestone to take it out.
37	−
38	−	An item is in at most one milestone. Moving it is noted in the
39	−	conversation, and is a `work_item.milestoned` or `work_item.demilestoned`
40	−	event (`pull.milestoned` and `pull.demilestoned` on a pull request). With
41	−	the Triage role you can also choose a milestone on New work item.
42	−
43	−	## Follow its progress
44	−
45	−	Milestones lists open milestones soonest due first, then those without
46	−	a due date; Closed lists the rest, most recently closed first. Each
47	−	shows its due date, how many of its items are open and closed, and a bar
48	−	of how much is done. One whose due date has passed says how late it is.
49	−
50	−	A milestone's page lists its open and closed work items and pull
51	−	requests, newest first. On Work or Pull requests, choose
52	−	Milestone to filter the list by one; the address keeps it as
53	−	`?milestone=3`.
54	−
55	−	## Change, close or delete one
56	−
57	−	With the Write role in the workspace or higher, on Milestones or a
58	−	milestone's page (putting a work item in one needs only Triage):
59	−
60	−	\| To \| Do this \|
61	−	\| --- \| --- \|
62	−	\| Change its title, due date or description \| Edit, on its page. \|
63	−	\| Close it, once it is done \| Close. Reopen opens it again. \|
64	−	\| Delete it \| Delete. What was in it stays as it is, in no milestone. This cannot be undone. \|
65	−
66	−	## From the API
67	−
68	−	\| To \| REST \| MCP \|
69	−	\| --- \| --- \| --- \|
70	−	\| List milestones \| `GET /workspaces/{workspace}/milestones`, `state` to filter \| `workspace` `list_milestones` \|
71	−	\| Get one with its items \| `GET /workspaces/{workspace}/milestones/{milestone}` \| `workspace` `get_milestone` \|
72	−	\| Make one \| `POST /workspaces/{workspace}/milestones` \| `workspace` `create_milestone` \|
73	−	\| Change one \| `PATCH /workspaces/{workspace}/milestones/{milestone}` \| `workspace` `update_milestone` \|
74	−	\| Delete one \| `DELETE /workspaces/{workspace}/milestones/{milestone}` \| `workspace` `delete_milestone` \|
75	−
76	−	A milestone has `number`, `title`, `description`, `due_on` (`YYYY-MM-DD`),
77	−	`state` (`open` or `closed`), `open_items` and `closed_items`. Send
78	−	`"due_on": ""` to clear a due date, and `"state": "closed"` to close it.
79	−
80	−	```sh
81	−	curl -X POST https://api.g1t.sh/workspaces/acme/milestones \
82	−	-H "Authorization: Bearer $G1T_TOKEN" \
83	−	-H "Content-Type: application/json" \
84	−	-d '{"title": "Launch", "due_on": "2026-10-14"}'
85	−	```
86	−
87	−	`milestone`, a milestone's number, puts an item in it when you open or
88	−	change a work item (`POST /workspaces/{workspace}/work`,
89	−	`PATCH /workspaces/{workspace}/work/{number}`) and on
90	−	`update_pull_request`; `null` or `0` takes it out. Work items and pull
91	−	requests carry `milestone` as `{"number", "title"}`, and `milestone`
92	−	filters `list_work_items` and `list_pull_requests`. Managing milestones
93	−	needs a token with `work:write`, and reading them `work:read`.
94	−
95	−	[Dependency updates](/guides/dependency-updates/) put their pull requests
96	−	in the milestone their entry's `milestone` names.

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.

1	+	---
2	+	title: Issues became work items
3	+	description: Issues moved out of repositories into workspace-level work items. What happened to the issues, labels and milestones you had, why old links still work, and what to change in scripts and agents.
4	+	---
5	+
6	+	Issues used to belong to one repository each. They are now
7	+	[work items](/guides/work-items/), which belong to the workspace and can
8	+	link several repositories. Work, after Home and Explore in
9	+	the left rail, replaces each repository's Issues tab.
10	+
11	+	## What happened to your issues
12	+
13	+	Every issue became a work item, with everything it had: its title and
14	+	description, comments, reactions, labels, assignees, milestone, claims,
15	+	sessions, pull requests and what it was blocked by.
16	+
17	+	- It has a new number. Work items are numbered once for the whole
18	+	workspace, and each issue was given the next number, oldest first, above
19	+	every number any of the workspace's repositories had used. So an issue
20	+	number and a work item number never mean two things.
21	+	- Its repository is its origin. The work item links the repository
22	+	the issue was in as its `origin`, and keeps the old number there. Its
23	+	pull requests' repositories are linked as `touched`.
24	+	- Pull requests kept their numbers. New ones take the workspace's next
25	+	number.
26	+	- Who can see it did not change. Anyone who could read the repository
27	+	still sees the work item filed there. Members of the workspace now see
28	+	every work item in it.
29	+
30	+	## Old links still work
31	+
32	+	- `g1t.sh/<owner>/<repo>/issues/12` redirects to the work item that issue
33	+	became, at `g1t.sh/<owner>/-/work/<number>`. Issues, New issue,
34	+	Labels and Milestones under a repository redirect to Work:
35	+	the repository's issue list to the Work list filtered to it, and its
36	+	labels and milestones to the workspace's. A milestone's own old address,
37	+	`…/milestones/3`, lands on the milestones list, since milestones were
38	+	renumbered.
39	+	- A person's Issues tab is their Work items tab, at
40	+	`g1t.sh/u/<name>/items`.
41	+	- `#12` and `owner/repo#12` in descriptions, comments and commit messages
42	+	written before still link to that issue's work item.
43	+	- `Closes #12` in history still points at the right work item.
44	+	- A repository has no Work or Sessions page of its own, and
45	+	`g1t.sh/<owner>/<repo>/work` and `…/sessions` are not found. Its claims
46	+	and sessions are on Work's
47	+	[Sessions](/guides/sessions/#the-sessions-page), filtered to it:
48	+	`g1t.sh/<workspace>/-/work/sessions?repo=<name>`. A session's page is
49	+	`g1t.sh/<workspace>/-/work/sessions/<id>`, and a pull request's recorded
50	+	session is its Session tab, `…/pull/<number>/session`.
51	+
52	+	## Labels and milestones
53	+
54	+	Labels and milestones now belong to the workspace, too.
55	+
56	+	- Labels with the same name in several repositories became one label. The
57	+	one made first kept its color and description.
58	+	- Milestones were renumbered in the workspace. Each records the
59	+	repository it came from, and every work item and pull request in it
60	+	stayed in it.
61	+
62	+	## What to change
63	+
64	+	Nothing that reads links or references needs to change. What calls g1t by
65	+	name does:
66	+
67	+	\| Was \| Now \|
68	+	\| --- \| --- \|
69	+	\| `g1t issue …` \| `g1t work …`: `list`, `view`, `new`, `comment`, `edit`, `close`, `reopen` \|
70	+	\| `g1t browse --issues` \| `g1t browse --work` \|
71	+	\| `g1t work context N` \| `g1t work view N` \|
72	+	\| `g1t work list` (claims and sessions) \| `g1t work status` \|
73	+	\| `--issue N` on `g1t pr create`, `g1t session …` and `g1t work events` \| `--item N` \|
74	+	\| The MCP `issue` tool \| `work_item`, with `workspace` and `number` \|
75	+	\| `pull_request` `create` with `issue` \| `pull_request` `create` with `item` \|
76	+	\| `/repos/{owner}/{name}/issues…` \| `/workspaces/{workspace}/work…` \|
77	+	\| Repository labels and milestones routes \| `/workspaces/{workspace}/labels` and `/workspaces/{workspace}/milestones` \|
78	+	\| `issue.` events and webhooks \| `work_item.`. Webhooks you had were moved over for you. \|
79	+	\| `issue` and `other_issue` in event payloads \| `item` and `other_item` \|
80	+	\| Workflows `on: issues` and `on: issue_comment`, and `permissions: { issues: … }` \| `on: work_item`, `on: work_item_comment` and `permissions: { work: … }`. The old names still read but start and grant nothing, and the workflow's page says so. \|
81	+	\| The repository settings `has_issues` and `auto_close_issues` \| `has_work_items` and `auto_close_items` \|
82	+	\| Search `is:issue` and `type: issues` \| `is:item` and `type: items` \|
83	+	\| `issues:read`, `issues:write` scopes \| `work:read`, `work:write` \|
84	+	\| `/g1t:work-on-issue` in Claude Code \| `/g1t:work-on-item`, with the plugin 0.3.0 and the CLI 0.4.0 or later \|
85	+
86	+	There are no aliases for the old names: a script that calls one gets an
87	+	error, not a silent change. Numbers in your own data, such as a tracker
88	+	that stored `owner/repo#12`, still resolve, but a work item's own number
89	+	is the one to keep from now on.

1	+	---
2	+	title: Labels
3	+	description: Say what a work item or pull request is with colored labels, filter lists by them, and manage your workspace's labels.
4	+	---
5	+
6	+	A label says what a work item or a pull request is: a `bug`, a `question`,
7	+	`good first issue`. Labels belong to the workspace, so every repository in
8	+	it uses the same ones, each with a name, a color and a description. Work
9	+	items and pull requests carry them by name, lists show them as colored
10	+	chips, and you can filter either list by one.
11	+
12	+	## The labels a workspace starts with
13	+
14	+	A new workspace starts with these:
15	+
16	+	\| Label \| Color \| Description \|
17	+	\| --- \| --- \| --- \|
18	+	\| `bug` \| `d73a4a` \| Something isn't working \|
19	+	\| `documentation` \| `0075ca` \| Improvements or additions to documentation \|
20	+	\| `duplicate` \| `cfd3d7` \| This work item or pull request already exists \|
21	+	\| `enhancement` \| `a2eeef` \| New feature or request \|
22	+	\| `good first issue` \| `7057ff` \| Good for newcomers \|
23	+	\| `help wanted` \| `008672` \| Extra attention is needed \|
24	+	\| `invalid` \| `e4e669` \| This doesn't seem right \|
25	+	\| `question` \| `d876e3` \| Further information is requested \|
26	+	\| `wontfix` \| `ffffff` \| This will not be worked on \|
27	+	\| `dependencies` \| `0366d6` \| Updates a dependency \|
28	+	\| `security` \| `ee0701` \| A security fix or a vulnerability \|
29	+
30	+	Labels used to belong to each repository. When they moved to the
31	+	workspace, labels with the same name became one, and the one made first
32	+	kept its color and description; see
33	+	[Issues became work items](/about/issues-became-work-items/#labels-and-milestones).
34	+	To add the defaults a workspace lacks:
35	+
36	+	1. Open Work, then Labels.
37	+	2. Choose Add the default labels.
38	+
39	+	Labels the workspace has already are left as they are.
40	+
41	+	## Put labels on a work item or a pull request
42	+
43	+	1. Open the work item or pull request.
44	+	2. In the sidebar, choose the settings icon beside Labels.
45	+	3. Tick labels on and off. Type to find one by its name or description.
46	+	4. Close the menu. The labels save as it closes.
47	+
48	+	Each label put on or taken off is noted in the conversation, and is a
49	+	`work_item.labeled` or `work_item.unlabeled` event (`pull.labeled` and
50	+	`pull.unlabeled` on a pull request).
51	+
52	+	Who may do this:
53	+
54	+	- The author of a work item or a pull request, and whoever asked g1t for
55	+	one, may use the workspace's labels on it.
56	+	- Anyone with the Triage [role](/guides/access-and-roles/) or higher may
57	+	label anything, and make a label as they go: type a name the workspace
58	+	does not have, and choose Create.
59	+
60	+	A work item or a pull request carries at most 20 labels.
61	+
62	+	You can label a work item as you open it, too: tick labels on **New work
63	+	item**, or with the Write role, type new ones beside them.
64	+
65	+	## Filter by a label
66	+
67	+	On Work or Pull requests, choose Label and pick one. The
68	+	address keeps it, as `?label=bug`, so the filtered list can be shared. You
69	+	can also write it as `?q=label:bug`, with quotes around a name with
70	+	spaces: `?q=label:"good first issue"`. Clear filters shows everything
71	+	again.
72	+
73	+	## Manage the workspace's labels
74	+
75	+	Open Work, then Labels, at `g1t.sh/<workspace>/-/work/labels`. It
76	+	lists every label with its description and how many work items and pull
77	+	requests carry it; choose a count to see them. Search finds a label by its
78	+	name or description.
79	+
80	+	With the Write role in the workspace or higher you can (applying labels
81	+	needs only Triage):
82	+
83	+	\| To \| Do this \|
84	+	\| --- \| --- \|
85	+	\| Make a label \| New label: a name (lowercase, at most 50 characters), a description (at most 100), and a color. \|
86	+	\| Change one \| Edit. Renaming a label renames it on every work item and pull request that carries it, in every repository. \|
87	+	\| Delete one \| Delete. It comes off everything that carries it. This cannot be undone. \|
88	+
89	+	Names are lowercase and unique in a workspace: `Bug` and `bug` are the
90	+	same label.
91	+
92	+	## Labels and g1t
93	+
94	+	- [Dependency updates](/guides/dependency-updates/) carry `dependencies`
95	+	and their ecosystem's label (`javascript`, `rust`, `go`, `python`, …)
96	+	unless `labels` in the file says otherwise. Labels the workspace lacks
97	+	are made for them.
98	+	- [Workflows](/guides/actions/) can start on `labeled` and `unlabeled`
99	+	activity of `pull_request`.
100	+
101	+	## From the API
102	+
103	+	\| To \| REST \| MCP \|
104	+	\| --- \| --- \| --- \|
105	+	\| List labels \| `GET /workspaces/{workspace}/labels` \| `workspace` `list_labels` \|
106	+	\| Make one \| `POST /workspaces/{workspace}/labels` \| `workspace` `create_label` \|
107	+	\| Change one \| `PATCH /workspaces/{workspace}/labels/{label}` \| `workspace` `update_label` \|
108	+	\| Delete one \| `DELETE /workspaces/{workspace}/labels/{label}` \| `workspace` `delete_label` \|
109	+	\| Add the defaults \| `POST /workspaces/{workspace}/labels/defaults` \| `workspace` `add_default_labels` \|
110	+
111	+	URL-encode a label's spaces in a path: `good%20first%20issue`.
112	+
113	+	```sh
114	+	curl -X POST https://api.g1t.sh/workspaces/acme/labels \
115	+	-H "Authorization: Bearer $G1T_TOKEN" \
116	+	-H "Content-Type: application/json" \
117	+	-d '{"name": "needs design", "color": "fbca04"}'
118	+	```
119	+
120	+	`labels` on the work item routes (`POST /workspaces/{workspace}/work` and
121	+	`PATCH /workspaces/{workspace}/work/{number}`, the `work_item` tool's
122	+	`create` and `update`) and on `update_pull_request` set an item's labels,
123	+	and `label` filters `list_work_items` and `list_pull_requests`. Managing
124	+	labels needs a token with `work:write`, and listing them `work:read`.

1	+	---
2	+	title: Milestones
3	+	description: Gather work items and pull requests from across your workspace under a goal and a due date, and see how much of it is done.
4	+	---
5	+
6	+	A milestone gathers work items and pull requests under one goal, such as a
7	+	release, with an optional due date. Milestones belong to the workspace, so
8	+	one can hold work from any of its repositories. Its page shows everything
9	+	in it and how far along it is: the share of its work items and pull
10	+	requests that are closed. A merged pull request counts as closed.
11	+
12	+	## Make a milestone
13	+
14	+	You need the Triage [role](/guides/access-and-roles/) in the workspace or
15	+	higher.
16	+
17	+	1. Open Work, then Milestones.
18	+	2. Choose New milestone.
19	+	3. Give it a title, unique in the workspace, and if you like a due date
20	+	and a description. The description is Markdown.
21	+	4. Choose Create milestone.
22	+
23	+	Milestones are numbered from 1 in each workspace, apart from work items
24	+	and pull requests. The number is in its address:
25	+	`g1t.sh/<workspace>/-/work/milestones/3`.
26	+
27	+	Milestones used to belong to each repository. When they moved to the
28	+	workspace they were numbered again, and each records the repository it
29	+	came from; see
30	+	[Issues became work items](/about/issues-became-work-items/#labels-and-milestones).
31	+
32	+	## Put a work item or a pull request in one
33	+
34	+	1. Open the work item or pull request.
35	+	2. In the sidebar, choose the settings icon beside Milestone.
36	+	3. Pick a milestone, or Clear milestone to take it out.
37	+
38	+	An item is in at most one milestone. Moving it is noted in the
39	+	conversation, and is a `work_item.milestoned` or `work_item.demilestoned`
40	+	event (`pull.milestoned` and `pull.demilestoned` on a pull request). With
41	+	the Triage role you can also choose a milestone on New work item.
42	+
43	+	## Follow its progress
44	+
45	+	Milestones lists open milestones soonest due first, then those without
46	+	a due date; Closed lists the rest, most recently closed first. Each
47	+	shows its due date, how many of its items are open and closed, and a bar
48	+	of how much is done. One whose due date has passed says how late it is.
49	+
50	+	A milestone's page lists its open and closed work items and pull
51	+	requests, newest first. On Work or Pull requests, choose
52	+	Milestone to filter the list by one; the address keeps it as
53	+	`?milestone=3`.
54	+
55	+	## Change, close or delete one
56	+
57	+	With the Write role in the workspace or higher, on Milestones or a
58	+	milestone's page (putting a work item in one needs only Triage):
59	+
60	+	\| To \| Do this \|
61	+	\| --- \| --- \|
62	+	\| Change its title, due date or description \| Edit, on its page. \|
63	+	\| Close it, once it is done \| Close. Reopen opens it again. \|
64	+	\| Delete it \| Delete. What was in it stays as it is, in no milestone. This cannot be undone. \|
65	+
66	+	## From the API
67	+
68	+	\| To \| REST \| MCP \|
69	+	\| --- \| --- \| --- \|
70	+	\| List milestones \| `GET /workspaces/{workspace}/milestones`, `state` to filter \| `workspace` `list_milestones` \|
71	+	\| Get one with its items \| `GET /workspaces/{workspace}/milestones/{milestone}` \| `workspace` `get_milestone` \|
72	+	\| Make one \| `POST /workspaces/{workspace}/milestones` \| `workspace` `create_milestone` \|
73	+	\| Change one \| `PATCH /workspaces/{workspace}/milestones/{milestone}` \| `workspace` `update_milestone` \|
74	+	\| Delete one \| `DELETE /workspaces/{workspace}/milestones/{milestone}` \| `workspace` `delete_milestone` \|
75	+
76	+	A milestone has `number`, `title`, `description`, `due_on` (`YYYY-MM-DD`),
77	+	`state` (`open` or `closed`), `open_items` and `closed_items`. Send
78	+	`"due_on": ""` to clear a due date, and `"state": "closed"` to close it.
79	+
80	+	```sh
81	+	curl -X POST https://api.g1t.sh/workspaces/acme/milestones \
82	+	-H "Authorization: Bearer $G1T_TOKEN" \
83	+	-H "Content-Type: application/json" \
84	+	-d '{"title": "Launch", "due_on": "2026-10-14"}'
85	+	```
86	+
87	+	`milestone`, a milestone's number, puts an item in it when you open or
88	+	change a work item (`POST /workspaces/{workspace}/work`,
89	+	`PATCH /workspaces/{workspace}/work/{number}`) and on
90	+	`update_pull_request`; `null` or `0` takes it out. Work items and pull
91	+	requests carry `milestone` as `{"number", "title"}`, and `milestone`
92	+	filters `list_work_items` and `list_pull_requests`. Managing milestones
93	+	needs a token with `work:write`, and reading them `work:read`.
94	+
95	+	[Dependency updates](/guides/dependency-updates/) put their pull requests
96	+	in the milestone their entry's `milestone` names.

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.

1418	1418
1419	1419		/**
1420	1420		* Work's sidebar, and its menu on a phone (the Work tab tapped again), in
1421		−	* two sections. Work items: the views people keep coming back to, saved
1422		−	* in the address (open, yours, closed), the board of them as they move, a
1423		−	* new one, and the workspace's labels and milestones. Sessions, the work
1424		−	* being done on them: what is going now, what just ended, your own, and
1425		−	* each kind, kept in the address as well.
	1421	+	* two sections. First, under the mode's own name as every mode's first rows
	1422	+	* are, its work items: the views people keep coming back to, saved in the
	1423	+	* address (open, yours, closed), the board of them as they move, a new one,
	1424	+	* and the workspace's labels and milestones. Then Sessions, the work being
	1425	+	* done on them: what is going now, what just ended, your own, and each
	1426	+	* kind, kept in the address as well.
1426	1427		*/
1427	1428		function WorkSidebar({ slug, username }: { slug: string; username: string }) {
1428	1429		const { pathname: path, search } = useSidebarLocation();
⋯
1438	1439		<div className="flex h-full flex-col">
1439	1440		<ModeHeader title="Work" />
1440	1441		<nav aria-label="Work" className={PANEL}>
1441		−	<NavGroup title="Work items">
	1442	+	<NavRows>
1442	1443		<SidebarLink to={list} icon={<ListTodo size={15} />} current={view({})}>
1443	1444		Open
1444	1445		</SidebarLink>
⋯
1460	1461		<SidebarLink to={workPath(slug, "milestones")} icon={<Flag size={15} />} current={at("milestones")}>
1461	1462		Milestones
1462	1463		</SidebarLink>
1463		−	</NavGroup>
	1464	+	</NavRows>
1464	1465		<Rule />
1465	1466		<NavGroup title="Sessions">
1466	1467		<SidebarLink to={sessions} icon={<Radio size={15} />} current={sessionView({})}>

flagon-io/g1t

Web: Work's sidebar names Work once

Comments