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

Docs: Work has a section of its own

Work gets its own sidebar group and tab, right after Get started, as it has its own place in the app's rail. Its pages, under work/: Work itself (the rail, Work's sidebar, the Work list and Cooking now, the phone and the phone app), work items, the Board, closing work items, labels, milestones, Sessions, session titles, claims and dependencies, working with agents, and how issues became work items. guides/work-items, guides/labels, guides/milestones and about/issues-became-work-items move there whole; the Work parts of guides/sessions move there too, and it keeps recording sessions from a harness, under Coding agents. The detail of closing work items moves from pull requests to its own page. Every old address redirects, and so does a link to a part of a page that moved on its own: scripts/moved.mjs sends #heading links on from the redirect, or from the page still there. Every link in the docs, the API's descriptions, agents.md and the landing page names the new pages. Corrected against the code: work context fields (suggested_targets, each repository's required_checks and pulls), suggested targets' signals (no CODEOWNERS), auto_close_items, reopening clearing where it landed, who may file and change a work item, the phone app's Items | Board | Sessions, and a session's timeout of 30 minutes in start_session's description. The MCP reference no longer names work_item create's checks field, which the API dropped.

G1T-Session:: ses_01m56x1naveyhs08bw0cwsh2sf

syntaqxcommitted 6h agoParent2dc493cBrowse files

t

apps
- api/src
- docs
  - scripts
  - src
    - content/docs
      - architecture
      - concepts
      - guides
      - reference
      - work
    - data
- web
  - app/components
  - public
crates/g1t/src
scripts

j/k next and previous file, v mark viewed

3	3		import { defineConfig } from 'astro/config';
4	4
5	5		import { generateApiReference } from './scripts/api-reference.mjs';
	6	+	import { movedParts, pages } from './scripts/moved.mjs';
6	7
7	8		// A page per REST operation, written from the OpenAPI document.
8	9		const apiGroups = generateApiReference();
9	10
	11	+	// Pages that moved, so links already shared still arrive. A key with a
	12	+	// #heading is a part of a page that moved on its own (scripts/moved.mjs).
	13	+	const moved = {
	14	+	'/guides/inbox/': '/guides/notifications/',
	15	+	'/guides/mirroring/': '/guides/github/',
	16	+	'/guides/today/': '/guides/home/',
	17	+	// g1t no longer runs agents of its own: coding agents connect to it.
	18	+	'/guides/g1t-agents/': '/guides/bring-your-own-agent/',
	19	+	'/guides/working-with-g1t/': '/guides/bring-your-own-agent/',
	20	+	'/guides/agents/': '/guides/bring-your-own-agent/',
	21	+	'/guides/agent-abilities/': '/guides/bring-your-own-agent/',
	22	+	'/guides/agent-access/': '/guides/bring-your-own-agent/',
	23	+	'/guides/agent-memory/': '/guides/bring-your-own-agent/',
	24	+	'/guides/agent-routines/': '/guides/bring-your-own-agent/',
	25	+	'/guides/agent-sessions/': '/guides/why-blame/',
	26	+	'/guides/agent-skills/': '/guides/bring-your-own-agent/',
	27	+	'/guides/agent-budgets/': '/guides/usage-and-billing/',
	28	+	'/guides/agents-and-memory/': '/guides/bring-your-own-agent/',
	29	+	'/guides/talking-to-agents/': '/guides/bring-your-own-agent/',
	30	+	'/guides/chat-app/': '/guides/chat/',
	31	+	'/guides/customize/': '/guides/bring-your-own-agent/',
	32	+	'/guides/marketplace/': '/guides/bring-your-own-agent/',
	33	+	'/guides/models/': '/guides/ai/',
	34	+	'/guides/ai-gateway/': '/guides/ai/',
	35	+	'/guides/context-hub/': '/guides/bring-your-own-agent/',
	36	+	// Project and workspace memory is gone: harnesses keep their own.
	37	+	'/guides/memory/': '/guides/bring-your-own-agent/',
	38	+	'/guides/spend/': '/guides/usage-and-billing/',
	39	+	'/guides/outcomes/': '/work/milestones/',
	40	+	// Issues became workspace work items: their operations moved with them.
	41	+	'/reference/api/issues/list-issues/': '/reference/api/work-items/list-work-items/',
	42	+	'/reference/api/issues/create-issue/': '/reference/api/work-items/open-work-item/',
	43	+	'/reference/api/issues/get-issue/': '/reference/api/work-items/get-work-item/',
	44	+	'/reference/api/issues/update-issue/': '/reference/api/work-items/update-work-item/',
	45	+	'/reference/api/issues/close-issue/': '/reference/api/work-items/close-work-item/',
	46	+	'/reference/api/issues/reopen-issue/': '/reference/api/work-items/reopen-work-item/',
	47	+	'/reference/api/integrations/import-issue/': '/reference/api/work-items/import-work-items/',
	48	+	'/reference/api/issues/list-issue-labels/': '/reference/api/work-items/list-work-item-labels/',
	49	+	'/reference/api/issues/add-issue-labels/': '/reference/api/work-items/add-work-item-labels/',
	50	+	'/reference/api/issues/set-issue-labels/': '/reference/api/work-items/set-work-item-labels/',
	51	+	'/reference/api/issues/remove-issue-labels/': '/reference/api/work-items/remove-work-item-labels/',
	52	+	'/reference/api/issues/remove-issue-label/': '/reference/api/work-items/remove-work-item-label/',
	53	+	'/reference/api/issues/add-comment/': '/reference/api/work-items/add-work-item-comment/',
	54	+	'/reference/api/issues/edit-comment/': '/reference/api/work-items/edit-work-item-comment/',
	55	+	'/reference/api/issues/delete-comment/': '/reference/api/work-items/delete-work-item-comment/',
	56	+	'/reference/api/issues/react/': '/reference/api/work-items/react-to-work-item/',
	57	+	'/reference/api/issues/upload-attachment/': '/reference/api/work-items/upload-attachment/',
	58	+	'/reference/api/decisions-and-why/list-issue-decisions/': '/reference/api/work-items/list-work-item-decisions/',
	59	+	'/reference/api/claims-and-work/get-work/': '/reference/api/work-items/get-work/',
	60	+	'/reference/api/claims-and-work/claim-issue/': '/reference/api/work-items/claim-work-item/',
	61	+	'/reference/api/claims-and-work/claim-new-issue/': '/reference/api/work-items/claim-new-work-item/',
	62	+	'/reference/api/claims-and-work/list-claims/': '/reference/api/work-items/list-claims/',
	63	+	'/reference/api/claims-and-work/release-claim/': '/reference/api/work-items/release-claim/',
	64	+	'/reference/api/claims-and-work/hand-off-issue/': '/reference/api/work-items/hand-off-work-item/',
	65	+	'/reference/api/notifications/get-issue-subscription/': '/reference/api/notifications/get-work-item-subscription/',
	66	+	'/reference/api/notifications/set-issue-subscription/': '/reference/api/notifications/set-work-item-subscription/',
	67	+	'/reference/api/notifications/delete-issue-subscription/': '/reference/api/notifications/delete-work-item-subscription/',
	68	+	// Work has a section of its own, as it has in the app.
	69	+	'/guides/work-items/': '/work/work-items/',
	70	+	'/guides/work-items/#open-a-work-item': '/work/work-items/#file-a-work-item',
	71	+	'/guides/work-items/#the-work-list': '/work/#the-work-list',
	72	+	'/guides/work-items/#the-board': '/work/board/',
	73	+	'/guides/work-items/#closing-a-work-item': '/work/closing/',
	74	+	'/guides/work-items/#labels-and-milestones': '/work/labels/',
	75	+	'/guides/work-items/#work-on-one': '/work/agents/',
	76	+	'/guides/work-items/#the-cli': '/work/agents/#the-cli',
	77	+	'/guides/work-items/#mcp-and-the-api': '/work/agents/#mcp-and-the-api',
	78	+	'/guides/labels/': '/work/labels/',
	79	+	'/guides/milestones/': '/work/milestones/',
	80	+	'/about/issues-became-work-items/': '/work/from-issues/',
	81	+	// Sessions' pages, titles and claims moved to Work; recording a
	82	+	// session from a harness stayed.
	83	+	'/guides/sessions/#sessions': '/guides/sessions/#record-a-session',
	84	+	'/guides/sessions/#the-sessions-page': '/work/sessions/',
	85	+	'/guides/sessions/#on-the-site': '/work/sessions/#sessions-elsewhere-on-the-site',
	86	+	'/guides/sessions/#session-titles': '/work/session-titles/',
	87	+	'/guides/sessions/#picking-up-a-work-item': '/work/agents/#pick-up-a-work-item',
	88	+	'/guides/sessions/#what-a-session-worked-on': '/work/sessions/#what-a-session-records',
	89	+	'/guides/sessions/#claims': '/work/claims-and-dependencies/#claims',
	90	+	'/guides/sessions/#dependencies': '/work/claims-and-dependencies/#dependencies',
	91	+	'/guides/sessions/#overlaps': '/work/claims-and-dependencies/#overlaps',
	92	+	'/guides/sessions/#events': '/work/claims-and-dependencies/#events',
	93	+	'/guides/sessions/#who-sees-what': '/work/sessions/#who-sees-what',
	94	+	'/guides/sessions/#who-may-do-what': '/work/claims-and-dependencies/#who-may-do-what',
	95	+	'/guides/sessions/#pending-coordination-updates': '/work/claims-and-dependencies/#coordination-updates',
	96	+	};
	97	+
10	98		export default defineConfig({
11	99		site: 'https://docs.g1t.sh',
12		−	// Pages that moved, so links already shared still arrive.
13		−	redirects: {
14		−	'/guides/inbox/': '/guides/notifications/',
15		−	'/guides/mirroring/': '/guides/github/',
16		−	'/guides/today/': '/guides/home/',
17		−	// g1t no longer runs agents of its own: coding agents connect to it.
18		−	'/guides/g1t-agents/': '/guides/bring-your-own-agent/',
19		−	'/guides/working-with-g1t/': '/guides/bring-your-own-agent/',
20		−	'/guides/agents/': '/guides/bring-your-own-agent/',
21		−	'/guides/agent-abilities/': '/guides/bring-your-own-agent/',
22		−	'/guides/agent-access/': '/guides/bring-your-own-agent/',
23		−	'/guides/agent-memory/': '/guides/bring-your-own-agent/',
24		−	'/guides/agent-routines/': '/guides/bring-your-own-agent/',
25		−	'/guides/agent-sessions/': '/guides/why-blame/',
26		−	'/guides/agent-skills/': '/guides/bring-your-own-agent/',
27		−	'/guides/agent-budgets/': '/guides/usage-and-billing/',
28		−	'/guides/agents-and-memory/': '/guides/bring-your-own-agent/',
29		−	'/guides/talking-to-agents/': '/guides/bring-your-own-agent/',
30		−	'/guides/chat-app/': '/guides/chat/',
31		−	'/guides/customize/': '/guides/bring-your-own-agent/',
32		−	'/guides/marketplace/': '/guides/bring-your-own-agent/',
33		−	'/guides/models/': '/guides/ai/',
34		−	'/guides/ai-gateway/': '/guides/ai/',
35		−	'/guides/context-hub/': '/guides/bring-your-own-agent/',
36		−	// Project and workspace memory is gone: harnesses keep their own.
37		−	'/guides/memory/': '/guides/bring-your-own-agent/',
38		−	'/guides/spend/': '/guides/usage-and-billing/',
39		−	'/guides/outcomes/': '/guides/milestones/',
40		−	// Issues became workspace work items: their operations moved with them.
41		−	'/reference/api/issues/list-issues/': '/reference/api/work-items/list-work-items/',
42		−	'/reference/api/issues/create-issue/': '/reference/api/work-items/open-work-item/',
43		−	'/reference/api/issues/get-issue/': '/reference/api/work-items/get-work-item/',
44		−	'/reference/api/issues/update-issue/': '/reference/api/work-items/update-work-item/',
45		−	'/reference/api/issues/close-issue/': '/reference/api/work-items/close-work-item/',
46		−	'/reference/api/issues/reopen-issue/': '/reference/api/work-items/reopen-work-item/',
47		−	'/reference/api/integrations/import-issue/': '/reference/api/work-items/import-work-items/',
48		−	'/reference/api/issues/list-issue-labels/': '/reference/api/work-items/list-work-item-labels/',
49		−	'/reference/api/issues/add-issue-labels/': '/reference/api/work-items/add-work-item-labels/',
50		−	'/reference/api/issues/set-issue-labels/': '/reference/api/work-items/set-work-item-labels/',
51		−	'/reference/api/issues/remove-issue-labels/': '/reference/api/work-items/remove-work-item-labels/',
52		−	'/reference/api/issues/remove-issue-label/': '/reference/api/work-items/remove-work-item-label/',
53		−	'/reference/api/issues/add-comment/': '/reference/api/work-items/add-work-item-comment/',
54		−	'/reference/api/issues/edit-comment/': '/reference/api/work-items/edit-work-item-comment/',
55		−	'/reference/api/issues/delete-comment/': '/reference/api/work-items/delete-work-item-comment/',
56		−	'/reference/api/issues/react/': '/reference/api/work-items/react-to-work-item/',
57		−	'/reference/api/issues/upload-attachment/': '/reference/api/work-items/upload-attachment/',
58		−	'/reference/api/decisions-and-why/list-issue-decisions/': '/reference/api/work-items/list-work-item-decisions/',
59		−	'/reference/api/claims-and-work/get-work/': '/reference/api/work-items/get-work/',
60		−	'/reference/api/claims-and-work/claim-issue/': '/reference/api/work-items/claim-work-item/',
61		−	'/reference/api/claims-and-work/claim-new-issue/': '/reference/api/work-items/claim-new-work-item/',
62		−	'/reference/api/claims-and-work/list-claims/': '/reference/api/work-items/list-claims/',
63		−	'/reference/api/claims-and-work/release-claim/': '/reference/api/work-items/release-claim/',
64		−	'/reference/api/claims-and-work/hand-off-issue/': '/reference/api/work-items/hand-off-work-item/',
65		−	'/reference/api/notifications/get-issue-subscription/': '/reference/api/notifications/get-work-item-subscription/',
66		−	'/reference/api/notifications/set-issue-subscription/': '/reference/api/notifications/set-work-item-subscription/',
67		−	'/reference/api/notifications/delete-issue-subscription/': '/reference/api/notifications/delete-work-item-subscription/',
68		−	},
	100	+	redirects: pages(moved),
69	101		integrations: [
	102	+	movedParts(moved),
70	103		starlight({
71	104		title: 'g1t docs',
72	105		description: 'Guides and reference for g1t, the code platform for your team and its coding agents.',
⋯
132	165		{ label: 'How g1t works', slug: 'concepts/overview' },
133	166		{ label: 'The g1t CLI', slug: 'guides/cli' },
134	167		{ label: 'Home', slug: 'guides/home' },
135		−	{ label: 'Work items', slug: 'guides/work-items' },
136	168		{ label: 'Ask g1t', slug: 'guides/ask' },
137	169		{ label: 'AI providers', slug: 'guides/ai' },
138	170		{ label: 'Notifications', slug: 'guides/notifications' },
⋯
143	175		],
144	176		},
145	177		{
	178	+	label: 'Work',
	179	+	items: [
	180	+	{ label: 'Work', slug: 'work' },
	181	+	{ label: 'Work items', slug: 'work/work-items' },
	182	+	{ label: 'The Board', slug: 'work/board' },
	183	+	{ label: 'Closing work items', slug: 'work/closing' },
	184	+	{ label: 'Labels', slug: 'work/labels' },
	185	+	{ label: 'Milestones', slug: 'work/milestones' },
	186	+	{ label: 'Sessions', slug: 'work/sessions' },
	187	+	{ label: 'Session titles', slug: 'work/session-titles' },
	188	+	{ label: 'Claims and dependencies', slug: 'work/claims-and-dependencies' },
	189	+	{ label: 'Working with agents', slug: 'work/agents' },
	190	+	{ label: 'Issues became work items', slug: 'work/from-issues' },
	191	+	],
	192	+	},
	193	+	{
146	194		label: 'Chat',
147	195		items: [
148	196		{ label: 'Chat', slug: 'guides/chat' },
⋯
187	235		{ label: 'Connect a coding agent', slug: 'guides/bring-your-own-agent' },
188	236		{ label: 'Build and ship an app with an agent', slug: 'guides/build-and-ship' },
189	237		{ label: 'Claude Code plugin', slug: 'guides/claude-code-plugin' },
190		−	{ label: 'Sessions, claims and dependencies', slug: 'guides/sessions' },
	238	+	{ label: 'Recording sessions', slug: 'guides/sessions' },
191	239		{ label: 'Sessions and why-blame', slug: 'guides/why-blame' },
192	240		],
193	241		},
⋯
207	255		{ label: 'Pull requests and checks', slug: 'guides/pull-requests' },
208	256		{ label: 'Checks', slug: 'guides/checks' },
209	257		{ label: 'Pull requests into other branches', slug: 'guides/base-branches' },
210		−	{ label: 'Labels', slug: 'guides/labels' },
211		−	{ label: 'Milestones', slug: 'guides/milestones' },
212	258		{ label: 'The merge queue', slug: 'guides/merge-queue' },
213	259		{ label: 'Rules', slug: 'guides/rules' },
214	260		{ label: 'CODEOWNERS', slug: 'guides/codeowners' },
⋯
277	323		label: 'About',
278	324		items: [
279	325		{ label: "What g1t can't do yet", slug: 'about/limitations' },
280		−	{ label: 'Issues became work items', slug: 'about/issues-became-work-items' },
281	326		{ label: 'An open letter to Cloudflare', slug: 'about/open-letter-to-cloudflare' },
282	327		],
283	328		},

1	+	// @ts-check
2	+	/**
3	+	* Pages that moved, and parts of pages that moved on their own.
4	+	*
5	+	* astro.config.mjs lists them as `'/old/': '/new/'`, and a part of a page
6	+	* as `'/old/#heading': '/new/#heading'`. Astro's redirects take the pages.
7	+	* A redirect never sees a link's #fragment, so the parts are this
8	+	* integration's: once the site is built, it puts a short script at the top
9	+	* of each old address's page (the redirect, or the page itself when it is
10	+	* still there) that sends a link to a moved part on to where it went. On a
11	+	* redirect, a link to any other part keeps its #fragment, since the parts
12	+	* of a moved page keep their names.
13	+	*/
14	+	import { readFile, writeFile } from 'node:fs/promises';
15	+	// readFile throws for an old address with no page, so a moved part never
16	+	// names a page the build does not make.
17	+	import { fileURLToPath } from 'node:url';
18	+
19	+	/** @param {Record<string, string>} moved */
20	+	export function pages(moved) {
21	+	return Object.fromEntries(Object.entries(moved).filter(([from]) => !from.includes('#')));
22	+	}
23	+
24	+	/** @param {Record<string, string>} moved @returns {import('astro').AstroIntegration} */
25	+	export function movedParts(moved) {
26	+	return {
27	+	name: 'g1t-moved-parts',
28	+	hooks: {
29	+	'astro:build:done': async ({ dir, logger }) => {
30	+	/** @type {Map<string, Record<string, string>>} */
31	+	const parts = new Map();
32	+	for (const [from, to] of Object.entries(moved)) {
33	+	const [page, part] = from.split('#');
34	+	if (!part) continue;
35	+	parts.set(page, { ...parts.get(page), [part]: to });
36	+	}
37	+	for (const [page, map] of parts) {
38	+	const file = fileURLToPath(new URL(`.${page}index.html`, dir));
39	+	const html = await readFile(file, 'utf8');
40	+	const whole = moved[page] ?? '';
41	+	const script =
42	+	`<script>(function(){var p=${JSON.stringify(map)},w=${JSON.stringify(whole)},h=location.hash,` +
43	+	`t=p[decodeURIComponent(h.slice(1))]\|\|(w&&w+h);if(t)location.replace(t)})()</script>`;
44	+	// First in the page, before a redirect's own refresh. Astro's
45	+	// redirect pages have no <head> tag, Starlight's pages do.
46	+	const at = /<head[^>]*>/i.exec(html) ?? /<!doctype html>/i.exec(html);
47	+	const end = at ? at.index + at[0].length : 0;
48	+	await writeFile(file, html.slice(0, end) + script + html.slice(end));
49	+	}
50	+	logger.info(`${parts.size} pages send links to their moved parts on`);
51	+	},
52	+	},
53	+	};
54	+	}

29	29
30	30		\| On GitHub \| On g1t \|
31	31		\| --- \| --- \|
32		−	\| `on:` `push` (branches, tags, paths), `pull_request`, `pull_request_target`, `work_item`, `work_item_comment`, `pull_request_review`, `schedule`, `workflow_dispatch`, `workflow_run`, `merge_group`, `create`, `delete`, `repository_dispatch`, `release`, `deployment`, `deployment_status` \| The same, from g1t's own pushes, pull requests, [work items](/guides/work-items/) linked to the repository, comments, [releases](#releases), [deployments](#deployments) and [merge queue](/guides/merge-queue/). `work_item` and `work_item_comment` are g1t's own, in place of GitHub's `issues` and `issue_comment`, with `github.event.work_item` in place of `github.event.issue`; `work_item_comment` runs for comments on pull requests too, with `github.event.work_item.pull_request` set. A workflow on `issues` or `issue_comment` still reads, but starts nothing, and its page says to write `work_item` or `work_item_comment`. `create` starts on each new branch or tag, at its commit; `delete` on each branch or tag a push deletes, on the default branch's latest commit, with `github.event.ref` and `github.event.ref_type` naming what went. As on GitHub, neither takes `branches` or `tags` filters: a workflow on them runs for every branch and tag. `repository_dispatch` starts on [a dispatch event](#repository-dispatch). \|
	32	+	\| `on:` `push` (branches, tags, paths), `pull_request`, `pull_request_target`, `work_item`, `work_item_comment`, `pull_request_review`, `schedule`, `workflow_dispatch`, `workflow_run`, `merge_group`, `create`, `delete`, `repository_dispatch`, `release`, `deployment`, `deployment_status` \| The same, from g1t's own pushes, pull requests, [work items](/work/work-items/) linked to the repository, comments, [releases](#releases), [deployments](#deployments) and [merge queue](/guides/merge-queue/). `work_item` and `work_item_comment` are g1t's own, in place of GitHub's `issues` and `issue_comment`, with `github.event.work_item` in place of `github.event.issue`; `work_item_comment` runs for comments on pull requests too, with `github.event.work_item.pull_request` set. A workflow on `issues` or `issue_comment` still reads, but starts nothing, and its page says to write `work_item` or `work_item_comment`. `create` starts on each new branch or tag, at its commit; `delete` on each branch or tag a push deletes, on the default branch's latest commit, with `github.event.ref` and `github.event.ref_type` naming what went. As on GitHub, neither takes `branches` or `tags` filters: a workflow on them runs for every branch and tag. `repository_dispatch` starts on [a dispatch event](#repository-dispatch). \|
33	33		\| `jobs`, `needs`, `if`, `outputs`, `env`, `defaults`, `timeout-minutes`, `continue-on-error` \| The same. \|
34	34		\| `timeout-minutes` and `continue-on-error` on a step \| The same, for `run:` and `uses:` steps alike. A `uses:` step's action is stopped at its limit, with every process it started; a step inside a composite action stops at its own limit or the `uses:` step's, whichever comes first. A step stopped this way fails, unless `continue-on-error` lets the job go on. \|
35	35		\| `strategy.matrix` with `include` and `exclude`, `fail-fast`, `max-parallel`, a matrix from `fromJSON(needs.…)` \| The same. \|

93	93		titles, and what subagents were asked and reported; g1t does it again as
94	94		it records. Your prompts show only to you; the workspace's members see the
95	95		rest, and anyone else who can read the repository sees only that the
96		−	session runs ([Who sees what](/guides/sessions/#who-sees-what)).
	96	+	session runs ([Who sees what](/work/sessions/#who-sees-what)).
97	97
98	98		\| When \| The hook runs \| What g1t receives \|
99	99		\| --- \| --- \| --- \|
⋯
185	185		name the whole job: g1t keeps that title, unless the session goes on to
186	186		other work items or pull requests, when it is named again as it ends.
187	187		Rename a session on its page to pin your own title: g1t and Claude never
188		−	replace it. See [Session titles](/guides/sessions/#session-titles).
	188	+	replace it. See [Session titles](/work/session-titles/).
189	189		2. It shows to the team. The project's overview lists it in **Live
190	190		now under its pull request, else its branch, else under No branch
191	191		yet**, with who it is for, Claude Code, its state, when it was last
192	192		heard from and its branch; the workspace's
193		−	[Sessions](/guides/sessions/#the-sessions-page) lists it with the rest.
	193	+	[Sessions](/work/sessions/) lists it with the rest.
194	194		3. It gets a work item when it becomes a change others should know
195	195		about: a branch to push, a pull request. Claude is told to look for a
196	196		work item first (`g1t work list`) and claim it with `g1t work claim N`,
⋯
289	289		out of date, and said the same way.
290	290
291	291		A CLI older than 0.3.3 records sessions but cannot acknowledge
292		−	[coordination updates](/guides/sessions/#pending-coordination-updates). The hooks then show
	292	+	[coordination updates](/work/claims-and-dependencies/#coordination-updates). The hooks then show
293	293		pending updates only when they change, not before every prompt, and ask
294	294		Claude to tell you once to update the CLI.
295	295
⋯
317	317
318	318		A recorded session can be read on its own page, linked from the work item, the
319	319		pull request's Session tab and the workspace's
320		−	[Sessions](/guides/sessions/#the-sessions-page): who ran
	320	+	[Sessions](/work/sessions/): who ran
321	321		it, its subagents as a tree, the skills used, what it touched, and the
322	322		work items and pull requests it worked on.
323	323

252	252		g1t work reopen 12
253	253		```
254	254
255		−	[Work items](/guides/work-items/) belong to the workspace, and `g1t work`
	255	+	[Work items](/work/work-items/) belong to the workspace, and `g1t work`
256	256		works on the current repository's workspace, or the one in `--workspace`
257	257		(or `G1T_WORKSPACE`). `-R` filters `g1t work list` to the work items
258	258		linked to that repository, and names the repository `g1t work link` and
⋯
465	465		\| `g1t session updates [ID]` \| What other sessions did that concerns this one (claims, overlaps, dependency changes, decisions, merge queue results), oldest first, up to 100. Reading never clears them. It first says which files the working copy changed, so overlapping edits are noticed (`G1T_TOUCH=0` turns that off). \|
466	466		\| `g1t session acknowledge ID... --note TEXT` \| Records your decision about those updates (what changes in your plan, or why nothing does) and clears exactly the IDs given, for this session only; `--session` names another of yours. Saying the same again does nothing. \|
467	467		\| `g1t session end` \| Ends it, with an optional `--reason` and `--result` (what it reported; `-` reads it from stdin), and forgets it. Its subagents still going end with it. \|
468		−	\| `g1t session list` \| The repository's sessions; `--state active`, `--item`, `--pull` (any session tied to it), `--path` (those that touched a file, or a folder ending in `/`), `--subagents` to list subagents under the sessions that started them. `--workspace` (this repository's workspace) or `--workspace SLUG` lists the sessions of every repository of a workspace instead, narrowed by `--harness`, `--person`, `--in NAME` (a repository of it), `--state`, `--item` and `--subagents`; see [the Sessions page](/guides/sessions/#the-sessions-page). \|
	468	+	\| `g1t session list` \| The repository's sessions; `--state active`, `--item`, `--pull` (any session tied to it), `--path` (those that touched a file, or a folder ending in `/`), `--subagents` to list subagents under the sessions that started them. `--workspace` (this repository's workspace) or `--workspace SLUG` lists the sessions of every repository of a workspace instead, narrowed by `--harness`, `--person`, `--in NAME` (a repository of it), `--state`, `--item` and `--subagents`; see [the Sessions page](/work/sessions/). \|
469	469		\| `g1t session view [ID]` \| A session and what it recorded, its subagents and their results, the work items and pull requests it worked on, and the skills used; the current one without an id. \|
470	470
471	471		The id is kept in `.git/g1t/session`, in the working copy's own git

5	5
6	6		The phone app is meant to be g1t on Android and iOS, with its own
7	7		screens for what you do away from a desk: triaging and discussing
8		−	[work items](/guides/work-items/) in Work, talking with your team in
	8	+	[work items](/work/work-items/) in Work, talking with your team in
9	9		Chat, with notifications on your phone, and reviewing pull requests in
10	10		Code. Everything else opens on the site, in your phone's browser.
11	11
⋯
63	63
64	64		## Work
65	65
66		−	Work on the phone is the site's [Work](/guides/work-items/), laid out for
67		−	one hand. A switch at its top, Items \| Board, chooses between the
68		−	list and the Board.
	66	+	Work on the phone is the site's [Work](/work/), laid out for one hand. A
	67	+	switch at its top, Items \| Board \| Sessions, chooses between the list,
	68	+	the Board and [Sessions](#sessions).
69	69
70		−	- The list shows the workspace's open work items, newest first: each
71		−	with its number, title, state, labels and the repositories it is linked
72		−	to, which fold into "+2" past the first few. Pull down to read it
73		−	again; it loads more as you near its end.
	70	+	- The list shows the workspace's work items, newest first, with
	71	+	Open, Closed and All under the switch: each with its number,
	72	+	title, state, labels and the repositories it is linked to, which fold
	73	+	into "+2" past the first few. Pull down to read it again; it loads more
	74	+	as you near its end.
74	75		- Filters are in a sheet: tap the filter button in the header, a
75	76		filter's chip above the list, or Work in the bar again. Choose the
76	77		state, Assigned to me, a label, a milestone, a repository and its role.
⋯
84	85		done, or as not planned), reopens it, links a repository as a target,
85	86		copies its link, or opens it on the site. Tap a repository to open it or
86	87		unlink it.
87		−	- New work item (the + on Work) takes a title, a description,
	88	+	- New work item (+ New on Work) takes a title, a description,
88	89		labels and the repositories it should land in; none is fine. Opened from
89		−	a repository's Work, that repository is its origin.
90		−	- The Board is the site's [Board](/guides/work-items/#the-board):
	90	+	the list filtered to a repository, that repository is its origin, and
	91	+	starts as a target too.
	92	+	- The Board is the site's [Board](/work/board/):
91	93		Backlog, In progress, In review, Landing and Done,
92		−	each card a work item with who or which session is on it. Tap a card to
93		−	open the work item.
	94	+	one under another, with a chip for each to show one alone. Each card is
	95	+	a work item with who or which session is on it. Tap a card to open the
	96	+	work item.
94	97
95	98		## Sessions
96	99
97		−	Sessions is the site's [Sessions](/guides/sessions/#the-sessions-page),
	100	+	Sessions is the site's [Sessions](/work/sessions/),
98	101		a section of Work: the sessions at work across the workspace. Choose
99	102		Sessions at the top of Work, beside Items and Board.
100	103
101	104		- Everything, Live and Recent at the top choose what it
102	105		lists. Pull down to read it again.
103		−	- Filters are in a sheet: Started by me, and a repository.
	106	+	- Filters are in a sheet: Started by me, and a repository. Tap
	107	+	Work in the bar again to open it.
104	108		- A session shows its facts (who, harness, repository, branch, state,
105	109		when it was last heard from), what it is working on (its work item and
106	110		pull request), its subagents as a tree, the files it touched, and its

37	37		\| --- \| --- \| --- \|
38	38		\| Overview \| `g1t.sh/<workspace>/<project>` \| What it is and its links; production wherever it is deployed, or for a library its packages; what is in progress, active branches, the latest commits, and its About. See [the overview](#the-overview). \|
39	39		\| Code \| `…/code` \| The repository's files, commits and branches. \|
40		−	\| Work \| `g1t.sh/<workspace>/-/work?repo=<name>` \| The workspace's [work items](/guides/work-items/) linked to the repository. \|
	40	+	\| Work \| `g1t.sh/<workspace>/-/work?repo=<name>` \| The workspace's [work items](/work/work-items/) linked to the repository. \|
41	41		\| Pull requests, Merge queue \| `…/pulls` and so on \| As they always were. A pull request's Session tab is at `…/pull/<number>/session`. \|
42		−	\| Sessions \| `g1t.sh/<workspace>/-/work/sessions?repo=<name>` \| The workspace's [sessions](/guides/sessions/#the-sessions-page) in the repository. \|
	42	+	\| Sessions \| `g1t.sh/<workspace>/-/work/sessions?repo=<name>` \| The workspace's [sessions](/work/sessions/) in the repository. \|
43	43		\| Actions \| `…/actions` \| [GitHub Actions workflows](/guides/actions/). \|
44	44		\| Deployments \| `…/deployments` \| What is up now and every build. \|
45	45		\| Settings \| `…/settings` \| See below. \|
⋯
73	73		\| Facts \| Under production: its latest release (or, where the card does not already say it, production's state), how often checks pass, and either how many changes pass on the first try and what is open, or, for people with a role when [Observability](/guides/observability/) has data, requests and the error rate over the last day with how many errors are open. \|
74	74		\| Code \| One line to the repository: its name, default branch and when it was last pushed to, linking to Code. \|
75	75		\| Needs you \| For someone signed in: what is waiting on them, such as a failed production build or a pull request to merge or review. \|
76		−	\| Live now \| The people and coding agents working on it: each work item with its [claims and sessions](/guides/sessions/), the harness each came from and who it acts for, and sessions on no work item yet. Work's [Sessions](/guides/sessions/#the-sessions-page), filtered to the repository (`g1t.sh/<workspace>/-/work/sessions?repo=<name>`), has everything. With nobody working, people with a role see how to [connect a coding agent](/guides/bring-your-own-agent/). \|
	76	+	\| Live now \| The people and coding agents working on it: each work item with its [claims and sessions](/work/claims-and-dependencies/), the harness each came from and who it acts for, and sessions on no work item yet. Work's [Sessions](/work/sessions/), filtered to the repository (`g1t.sh/<workspace>/-/work/sessions?repo=<name>`), has everything. With nobody working, people with a role see how to [connect a coding agent](/guides/bring-your-own-agent/). \|
77	77		\| Previews \| For people with a role: the pull requests' previews that are up. \|
78	78		\| Deployments \| Each environment's latest deployment and when. \|
79	79		\| Observability \| For people with a role, when there is data: the last day's requests, an hour a bar, latency, and the newest open errors. \|

529	529
530	530		When a pull request merges into the default branch, it lands its
531	531		repository on the work item it was made for, and on every work item its
532		−	title or description names after a closing keyword: `close`, `closes`,
533		−	`closed`, `fix`, `fixes`, `fixed`, `resolve`, `resolves` or `resolved`, in
534		−	any case, with or without a colon:
535		−
536		−	```text
537		−	Fixes #12. Resolves: #14, closes acme/api#15
538		−	```
539		−
540		−	Landing marks the pull request's repository as landed on the work item and
541		−	records a resolution: the repository and the pull request. The work item
542		−	closes as completed when it has no target repositories, or once every
543		−	target has landed; until then it stays open, and its page says which
544		−	targets are missing. See [work items](/guides/work-items/#closing-a-work-item).
545		−
546		−	`Part of #12` (also `Part of acme/api#12`, or `Refs #12`) links the pull
547		−	request to the work item, and its repository as touched, without landing
548		−	anything: use it for a pull request that does only part of a repository's
549		−	share.
	532	+	title or description names after a closing keyword (`Closes #12`,
	533	+	`Fixes #12`, `Resolves #12`, and their other forms). A work item closes
	534	+	once every repository it targets has landed, or at the first landing when
	535	+	it has no target. `Part of #12` (or `Refs #12`) links the pull request
	536	+	without landing anything. Commits pushed to the default branch land work
	537	+	items the same way.
550	538
551		−	`#12` and `owner/name#12` name work items of the repository's own
552		−	workspace, whichever of its repositories they are written in. A work item
553		−	of another workspace is never closed. The pull request's `closes` lists
554		−	the work items it will land on, in the order named, and `parts` the ones it
555		−	is part of. Merging into any other branch lands nothing. A repository can
556		−	turn this off with `auto_close_items`; its pull requests then land nothing
557		−	when they merge.
558		−
559		−	Commit messages land work items the same way. When a push to the default
560		−	branch brings in a commit whose message names a work item after a closing
561		−	keyword, the commit's repository lands on it. This applies to commits
562		−	pushed directly, merged in a clone, or landed by a pull request, and up to
563		−	250 commits per push are read. The work item's timeline says who pushed
564		−	it and landed this in that commit, its page shows the commit beside
565		−	the repository, and the commit's page lists the work items it landed on.
566		−	The resolution records the commit as `commit` and who pushed it as
567		−	`pushed_by`, and `work_item.closed`, when it closes, carries the commit as
568		−	`commit`; reopening a work item clears its resolutions. A push that makes
569		−	a new branch reads none of its commits, since they were pushed before,
570		−	except a repository's first push, which makes its default branch:
571		−	`Closes #1` in the first version of a new repository lands on #1. Commits
572		−	pushed to other branches land nothing until they reach the default branch,
573		−	and `auto_close_items` turns this off as well.
574		−
575		−	A commit that is already on the default branch can land a work item later,
576		−	say one pushed before the work item was open or while `auto_close_items`
577		−	was off: [`close_work_item`](/reference/api/work-items/close-work-item/)
578		−	with `repo` and `commit` (its full hash), `g1t work close 12 --commit
579		−	<hash>` in the repository, or the `work_item` tool's `close` with `repo`
580		−	and `commit`. The commit's message must name the work item after a closing
581		−	keyword. Its repository then lands in that commit, the way a push of it
582		−	would have, by whoever did it. A commit that is not on the default branch,
583		−	or whose message does not name the work item, is refused, and so is a work
584		−	item that is already closed.
585		−
586		−	A work item's timeline links whatever landed it: landed this in a
587		−	commit links the commit, landed this by merging #14 links the pull
588		−	request, and when it was done in a [session](/guides/sessions/) the line
589		−	ends via session, linking that session. That session is the one the
590		−	closing commit names in a `G1t-Session: ses_…` trailer, or, for a work item
591		−	closed with a token (from an agent, the CLI or the MCP server), the
592		−	closer's own session on the work item that is still going.
593		−	`work_item.closed` carries it as `session`. A work item closed on the site
594		−	says only who closed it.
	539	+	The pull request's `closes` lists the work items it will land on, in the
	540	+	order named, and `parts` the ones it is part of. Merging into any other
	541	+	branch lands nothing, and a repository can turn this off with
	542	+	`auto_close_items`. [Closing work items](/work/closing/) has the whole of
	543	+	it: the keywords, landing target by target, commits, closing by hand or
	544	+	with a commit, and reopening.
595	545
596	546		Wherever a commit's message shows, `#12` links to that work item or pull
597	547		request, with its title and state when you hover over it. Old issue

1	1		---
2		−	title: Sessions, claims and dependencies
3		−	description: How agents and people see who is working on what, in a repository and across the workspace on Sessions, with sessions of their own harnesses, advisory claims on work items, what a work item is blocked by, and the one call that loads a work item's whole context.
	2	+	title: Recording sessions
	3	+	description: How a harness records its sessions on g1t, with the API, MCP or the CLI. Start, heartbeat, record and end a session, record subagents, work before there is a work item, and have g1t start sessions on your Anthropic account.
4	4		---
5		−
6		−	When several agents and people work on one repository at once, each needs
7		−	to know what the others are doing. g1t keeps that around the
8		−	[work item](/guides/work-items/), which is the unit of work: its
9		−	description says what is wanted and what done means, its pull requests are
10		−	the proposals, and around it g1t records:
11	5
12		−	- Sessions: one run of your own harness (a Claude Code session, a
13		−	Codex run) on the repository, attached to the work item and pull request
14		−	it works on. A session is recorded in the repository it is checked out
15		−	in; its work item is the workspace's.
16		−	- Claims: an advisory, expiring "I'm working on #12". Never a lock.
17		−	- Dependencies: the work items that have to land before this one.
18		−
19		−	Until there is a work item, the session is the unit: work that starts from
20		−	a question or a quick request is recorded as a session, named by g1t from
21		−	what it does ([Session titles](#session-titles)), and shows to the team on its branch or pull request. It opens or
22		−	claims a work item only when it becomes a change others should know about;
23		−	see [Work with no work item yet](#work-with-no-work-item-yet).
24		−
25		−	Nothing here waits on a harness. A harness that crashes, loses its
26		−	network or sends the same thing twice does no harm: sessions and claims
27		−	that go quiet are read as idle, ended or expired the next time anyone
28		−	looks, and starting a session or recording an entry again is a no-op.
29		−	What git and g1t record (commits, pull requests, checks, merges) is the
30		−	truth; sessions are the account of how it got there.
31		−
32		−	## The Sessions page
33		−
34		−	Sessions is a section of [Work](/guides/work-items/), at
35		−	`g1t.sh/<workspace>/-/work/sessions`: sessions are the work being done on
36		−	work items, so they live with them. Work's sidebar has it under its
37		−	Sessions heading, after the work items: Live now, Recent,
38		−	Yours, then each kind (People's harnesses, Started on g1t,
39		−	g1t's agent and Recorded on pull requests). It shows what is
40		−	cooking across the workspace: the sessions in every one of its
41		−	repositories you can read, as they happen, without reloading.
42		−
43		−	- Live now: the active and idle sessions, the most recently heard
44		−	from first. Each card shows the session's title, who it acts for, its
45		−	harness, its repository and branch, the work item and pull request it
46		−	is on, when it was last heard from, how many subagents it has, and
47		−	whether it is live or idle. A session with no title is named by what
48		−	its first prompt was for, else Session on its branch, else
49		−	Untitled session. A title that is only a tag, such as
50		−	`<pasted_content id="5c50">`, counts as no title.
51		−	- Merge queue: each repository's merge queue that has something
52		−	waiting, as on its [Merge queue](/guides/merge-queue/#the-merge-queue-page)
53		−	page.
54		−	- Just landed: the pull requests merged lately, across the
55		−	repositories, each with a link to the session behind it.
56		−	- What happened: the latest coordination events across the
57		−	repositories: claims, sessions starting and ending, overlaps, and what
58		−	the merge queue found when it combined changes.
59		−	- Recent: the sessions that ended lately.
60		−
61		−	With nothing going on, choose your client in the
62		−	[connection instructions](/guides/bring-your-own-agent/), or run
63		−	`g1t work claim <number>` from any harness.
64		−
65		−	Narrow it by repository (`?repo=web`), person (`?person=<username>`),
66		−	harness (`?harness=codex`), kind (`?kind=hosted`) and state. The address
67		−	keeps the filters, so a filtered view can be shared. A repository's
68		−	sessions are Sessions filtered to it,
69		−	`g1t.sh/<workspace>/-/work/sessions?repo=<name>`: a repository has no
70		−	Sessions page of its own.
71		−
72		−	Every kind of session is listed in this one place:
73		−
74		−	\| Kind \| Is \|
75		−	\| --- \| --- \|
76		−	\| `harness` \| A run of someone's own harness (Claude Code, Codex, Cursor, Copilot or another), with its [subagents](#subagents) under it. \|
77		−	\| `hosted` \| A session started on g1t, from a work item or the web, on the workspace's Anthropic provider: harness `claude_managed_agents`. See [Start a session on your Anthropic account](#start-a-session-on-your-anthropic-account). \|
78		−	\| `agent` \| g1t's own agent at work on a pull request. Only the workspace's members see these. \|
79		−	\| `recorded` \| A session recorded on a pull request with no session of its own. It opens on the pull request's Session tab, `g1t.sh/<owner>/<repo>/pull/<number>/session`. \|
	6	+	A [session](/work/sessions/) is one run of your harness on a repository:
	7	+	a Claude Code session, a Codex run. This page is for whoever wires a
	8	+	harness up to g1t: how a session is started, kept alive, recorded and
	9	+	ended, and how its subagents are recorded. The
	10	+	[Claude Code plugin](/guides/claude-code-plugin/) does all of it for
	11	+	Claude Code; other harnesses call the same API.
80	12
81		−	A session's page is `g1t.sh/<workspace>/-/work/sessions/<id>` (the
82		−	`ses_…` id), opened from Sessions or from anywhere the session is listed:
83		−	who ran it, in which harness and on which model, how long it has run, its
84		−	repository, the work items and pull requests it and its subagents worked
85		−	on (each says how it was tied), its subagents as a tree you open one at a
86		−	time (each with its kind, the task it was given, what it touched and what
87		−	it reported), the skills used, what was touched (files, commits, branches,
88		−	pull requests), and everything it recorded, as it records it: its prompt
89		−	folded, its messages formatted as they were written, and the tool calls
90		−	between them a line each (a command as code, a file by its path, a g1t
91		−	tool by what it did, such as work item · claim), more than three in a
92		−	row folded into one line that opens to them; a long command and what a
93		−	tool gave back open under its line. A subagent's own page links back to
94		−	the session that started it.
	13	+	What sessions are for, and how the team sees them, is under Work:
	14	+	[Sessions](/work/sessions/), [session titles](/work/session-titles/), and
	15	+	[claims and dependencies](/work/claims-and-dependencies/), which keep
	16	+	sessions out of each other's way.
95	17
96		−	The same list is in the API, MCP and the CLI:
97		−	[`GET /workspaces/{workspace}/sessions`](/reference/api/sessions/list-workspace-sessions/)
98		−	by `state` (`live`, `recent` or `ended`), `kind` (`harness`, `hosted`,
99		−	`agent` or `recorded`), `harness`, `person`, `repo`, `item`, `subagents`
100		−	and `limit`, which returns the `sessions`, each repository's `queue`, what
101		−	`landed` and the `repos` it covers;
102		−	[`GET /workspaces/{workspace}/sessions/{id}`](/reference/api/sessions/get-workspace-session/)
103		−	for one session, with its `repo`. Over MCP, the `session` tool's `list`
104		−	takes `workspace` instead of `repo`, and `get` takes `workspace` and `id`.
105		−	From the CLI:
	18	+	## Record a session
106	19
107		−	```sh
108		−	g1t session list --workspace # this repository's workspace
109		−	g1t session list --workspace acme --in web # one repository of it
110		−	g1t session list --workspace --harness codex --state active
111		−	```
	20	+	Start a session when the harness starts, keep it alive while it works, and
	21	+	end it when it stops.
112	22
113		−	`--workspace` takes a slug, or none for the current repository's
114		−	workspace; `--harness`, `--person`, `--in NAME` (a repository of it),
115		−	`--state` (active or idle: what is going now; ended), `--item` and `--subagents` narrow it.
116		−
117		−	## On the site
118		−
119		−	Besides Sessions, sessions and claims show where the work is, as it
120		−	happens, without reloading.
121		−
122		−	- A work item's Work panel, at the top of its sidebar: its claims
123		−	(who, from which harness, since when and when each lapses; ones
124		−	released, expired or handed off lately are shown dimmed), the sessions on
125		−	it with their state and when each was last heard from, what
126		−	it is blocked by and where each of those stands, and the work items it
127		−	blocks. Its author and anyone with the Triage role change what it is
128		−	blocked by with Edit. Under its pull requests, the work item shows
129		−	the latest combination that failed in the merge queue, and its
130		−	[decision records](/guides/why-blame/#decision-records), each marked
131		−	Claimed, Tested or Approved.
132		−	- A work item's and a pull request's sessions: every session tied to
133		−	it in any way, in any of the workspace's repositories, with its
134		−	subagents under it. A pull request's Session tab,
135		−	`g1t.sh/<owner>/<repo>/pull/<number>/session`, is what was recorded on
136		−	it.
137		−	- A project's overview: Live now, the people and coding agents
138		−	working on that repository, grouped by work item, then by pull request
139		−	or branch. See [the overview](/guides/projects/#the-overview).
140		−	- Start a session on a work item, for members of a workspace with an
141		−	Anthropic AI provider: see
142		−	[Start a session on your Anthropic account](#start-a-session-on-your-anthropic-account).
143		−
144		−	## Session titles
145		−
146		−	A session's title names the whole of its work, and settles instead of
147		−	following each turn. Each title says where it came from (`title_source`)
148		−	and when it settled (`title_settled_at`):
149		−
150		−	\| Source \| What it is \|
151		−	\| --- \| --- \|
152		−	\| `prompt` \| Provisional: what its first prompt asked for (its first line or sentence, without pasted text, image placeholders, code or markdown). Shown muted. \|
153		−	\| `item`, `pull`, `summary` \| Settled by g1t from the session's record. \|
154		−	\| `agent` \| Its harness or agent named it (`title` on start or update, `g1t session attach --title`). \|
155		−	\| `person` \| Someone renamed it on its page: pinned. Neither g1t nor the agent replaces it. Let g1t name it unpins it. \|
156		−
157		−	g1t settles a provisional title once there is enough to go on: the session
158		−	claims or is attached to a work item, opens or pushes a pull request,
159		−	records three prompts, or has run for 30 minutes. It names it again only
160		−	when what the session works on changes (another work item or pull
161		−	request, or many more prompts), at most every 20 minutes and only when the
162		−	new title says something else, and a last time when the session ends,
163		−	from everything it did. An agent's own title is kept, unless the session
164		−	went on to other work items or pull requests after it was named, when it
165		−	is named again as it ends.
166		−
167		−	With an [AI provider](/guides/ai/) chosen for Ask, the provider names the
168		−	session in a few words, on its fast model, from a short digest of the
169		−	record: its work items and pull requests, its prompts (as recorded, with
170		−	credentials taken out), its subagents' tasks, where it changed files, its
171		−	commits and what it reported. A session is asked about at most five times,
172		−	and one whose work is a single work item or pull request takes that title
173		−	without asking. Without a provider, or when it fails, the title is the
174		−	work item's, else the pull request's, else what the session's most telling
175		−	prompt asks for, without greetings and preambles ("This project used
176		−	to…", "I think", "So"). A subagent goes by its task and is not titled.
177		−
178		−	## Picking up a work item
179		−
180		−	Before working on a work item, load its whole context in one call:
181		−	`work_item` with `"action": "work"` over MCP, `g1t work view 12`, or
182		−	[`GET /workspaces/{workspace}/work/{number}/work`](/reference/api/work-items/get-work/):
183		−
184		−	```sh
185		−	curl https://api.g1t.sh/workspaces/acme/work/12/work \
186		−	-H "Authorization: Bearer $G1T_TOKEN"
187		−	```
188		−
189		−	\| Field \| What it holds \|
190		−	\| --- \| --- \|
191		−	\| `item` \| The work item, with its body and its repositories: each with its role and whether it has landed. \|
192		−	\| `missing` \| Its targets that have not landed yet. \|
193		−	\| `suggested` \| Repositories of the workspace it may also need, each with `why`. \|
194		−	\| `definition_of_done` \| The items under its Definition of done heading. \|
195		−	\| `required_checks` \| The checks every pull request into the default branch must pass. \|
196		−	\| `claims` \| Who says they are working on it now. \|
197		−	\| `sessions` \| Sessions on it or its pull requests, or tied to it any other way, subagents included, active ones first. Each says how many `subagents` it started. \|
198		−	\| `pulls` \| Its pull requests, in every repository it links. Those still open or draft carry their `required_checks` as they stand on the head, `mergeable`, the other pull requests they `overlap`, and their place in the merge `queue`. \|
199		−	\| `blocked_by` \| Each work item it waits on, with that work item's claims and pull requests. \|
200		−	\| `blocks` \| The work items waiting on it. \|
201		−	\| `decisions` \| [Decision records](/guides/why-blame/#decision-records) on it and its pull requests, newest first. \|
202		−	\| `last_integration_failure` \| The latest `integration_failure` decision among them, if any: the combination that failed in the merge queue, the check, the `suspects` and, when it failed on `main` alone, the pull requests that `landed` on `main` since it branched. \|
203		−	\| `recent` \| Its latest 20 coordination events, newest first. \|
204		−
205		−	Then claim it, and start (or attach) your session.
206		−
207		−	## Sessions
208		−
209		−	A session is one run of your harness on a repository. Start one when the
210		−	harness starts, keep it alive while it works, and end it when it stops.
211		−
212		−	1. Start it with `session` `start`, or
	23	+	1. Start it with `session` `start`, `g1t session start`, or
213	24		[`POST /repos/{owner}/{name}/sessions`](/reference/api/sessions/start-session/),
214		−	naming the `harness` (`claude_code`, `claude_managed_agents`, `codex`,
215		−	`cursor`, `copilot` or `other`) and the harness's own id for the session as
	25	+	naming the `harness` (`claude_code`, `codex`, `cursor`, `copilot` or
	26	+	`other`) and the harness's own id for the session as
216	27		`harness_session_id`. Starting again with the same id returns the
217	28		session already started, so a hook can call it every time without
218	29		checking first. Give `item` (the work item's number in the
219	30		repository's workspace), `pull` and `branch` when you know them, and a
220	31		`title` only if you can name the whole job in a few words (up to 200
221		−	characters): otherwise g1t names it (see [Session titles](#session-titles)).
222		−	2. Heartbeat with `session` `update`, or
	32	+	characters): otherwise g1t names it (see
	33	+	[session titles](/work/session-titles/)).
	34	+	2. Heartbeat with `session` `update`, `g1t session heartbeat`, or
223	35		[`PATCH /repos/{owner}/{name}/sessions/{id}`](/reference/api/sessions/update-session/)
224	36		with an empty body. The same call attaches the session to a work item
225		−	or pull request, records the `head_commit` it pushed, or names it
226		−	(`title`; a title a person pinned stays).
	37	+	or pull request (`g1t session attach --item 12`), records the
	38	+	`head_commit` it pushed, or names it (`title`; a title a person pinned
	39	+	stays). A heartbeat also renews the session's claims.
227	40		3. Record what happens with `session` `record`, or
228	41		[`POST /repos/{owner}/{name}/sessions/{id}/entries`](/reference/api/sessions/record-session-entries/):
229	42		prompts, reasoning, tool calls, notes and the skills it used (`skill`,
230	43		the skill's name only), up to 200 a request, and in `touched` what it
231		−	touched (see [What a session worked on](#what-a-session-worked-on)).
	44	+	touched (see [what a session records](/work/sessions/#what-a-session-records)).
232	45		Give each entry a `key`, and recording it again does nothing.
233		−	4. End it with `session` `end`, or
	46	+	4. End it with `session` `end`, `g1t session end`, or
234	47		[`POST /repos/{owner}/{name}/sessions/{id}/end`](/reference/api/sessions/end-session/),
235	48		with its `result` when it has one: what it reported when it finished.
236	49
⋯
241	54		-d '{"harness": "claude_code", "harness_session_id": "5b0c1f9e-3d2a-4e8b-9f61-0c7d2a9e4b13", "item": 12}'
242	55		```
243	56
244		−	A session's `state` is worked out from when it was last heard from. Every
245		−	update and every batch of entries counts as a heartbeat:
246		−
247		−	\| State \| Means \|
248		−	\| --- \| --- \|
249		−	\| `active` \| Heard from in the last 15 minutes. \|
250		−	\| `idle` \| Not heard from for 15 minutes. It may still come back. \|
251		−	\| `ended` \| Ended with `end_session`, or not heard from for 30 minutes (`end_reason` `timed_out`). A heartbeat brings a timed-out session back; an ended one stays ended. \|
252		−
253		−	A session its harness left behind, killed or never told to end, can be
254		−	ended by hand: End session in its menu under Live now (on the
255		−	project's overview and on Sessions), or on its page. Whoever runs a
256		−	session can end it, and so can anyone with write access to the
257		−	repository; nobody else sees the action. It ends with `end_reason`
258		−	`ended by hand by @name`, its subagents still going end with it, and its
259		−	claims stay until they are released or expire. Ending by hand is a
260		−	soft close: like a session that timed out, it comes back the moment
261		−	its harness is heard from again (an update, a recorded entry or a
262		−	start), so a harness that was in fact still running picks up where it
263		−	was. Through the API,
264		−	`end_session` on someone else's session does the same, without their
265		−	`reason` or `result`. A session g1t runs on the workspace's Anthropic
266		−	account is stopped from its page instead.
	57	+	Every update and every batch of entries counts as a heartbeat. A session
	58	+	not heard from for 15 minutes is idle, and after 30 minutes it ends as
	59	+	timed out, until a heartbeat brings it back; see
	60	+	[states](/work/sessions/#states). A session g1t runs on the workspace's
	61	+	Anthropic account is recorded as harness `claude_managed_agents`.
267	62
268	63		Entries of a session attached to a pull request show in that pull
269	64		request's [session](/guides/why-blame/#sessions), beside what was recorded
⋯
272	67		does. A session never records tool output unless you send it as a
273	68		`tool_result` entry. What looks like a credential is taken out of
274	69		everything a session records, and only the workspace's members see inside
275		−	a session: see [Who sees what](#who-sees-what).
	70	+	a session: see [who sees what](/work/sessions/#who-sees-what).
276	71
277		−	List a repository's sessions with `session` `list`, or
278		−	[`GET /repos/{owner}/{name}/sessions`](/reference/api/sessions/list-sessions/)
279		−	by `state`, `item` or `pull` (any session tied to it), or `path` (those
280		−	that touched a file, or any under a folder ending in `/`); subagents are
281		−	listed too with `subagents=true`. A session in the list with no `title`
282		−	carries `first_prompt`: the first 300 characters of the first prompt it
283		−	recorded. Read one with its entries, subagents, links, skills and what it
284		−	touched with `session` `get`. For the sessions of every repository of a
285		−	workspace, see [The Sessions page](#the-sessions-page).
	72	+	Updating, recording in and ending a session needs the token that started
	73	+	it; starting one needs a confirmed email address and a role that may file
	74	+	work items. With an access token, sessions need `pull_requests:write`.
	75	+	See [who may do what](/work/claims-and-dependencies/#who-may-do-what).
286	76
287	77		## Work with no work item yet
288	78
⋯
291	81		session is the record of that work, and the team sees it in Live now,
292	82		on Sessions and on the project's overview, while it goes:
293	83
294		−	1. It says what it is for. Give it a `title` when you start it, or
295		−	later with `session` `update`. The
296		−	[Claude Code plugin](/guides/claude-code-plugin/#work-with-no-work-item-yet)
297		−	titles each session from its first prompt that says what it is for,
298		−	from the words you typed: pasted text and image placeholders are left
299		−	out, and a slash command or a prompt that is only a paste leaves the
300		−	title to the next prompt. It never replaces a title the session
301		−	already has.
	84	+	1. It says what it is for. g1t names it from what it does, first
	85	+	from its first prompt, then from its whole record (see
	86	+	[session titles](/work/session-titles/)). Give it a `title` yourself,
	87	+	when you start it or later with `session` `update`, only if you can
	88	+	name the whole job.
302	89		2. It shows where it works. Attach its `branch` and, once there is
303	90		one, its `pull`: the project's Live now groups sessions on no work
304	91		item by pull request, then by branch.
⋯
306	93		should know about: a branch to push, a pull request. Look for one first
307	94		(`work_item` `list`, `work_item` `list_claims`); if one covers the work,
308	95		claim it. Otherwise open one and claim it in one step with `work_item`
309		−	`claim` and a `title` instead of a `number` (see [Claims](#claims)),
	96	+	`claim` and a `title` instead of a `number` (see [claims](/work/claims-and-dependencies/#claims)),
310	97		which attaches the session to it.
311	98
312	99		## Subagents
⋯
337	124		same file, each is told with `overlap.detected`. The
338	125		[Claude Code plugin](/guides/claude-code-plugin/#subagents) does all of
339	126		this for Claude Code's subagents.
340		−
341		−	## What a session worked on
342		−
343		−	A session says what it touched in `touched`, each kept once:
344		−
345		−	\| `kind` \| `value` \|
346		−	\| --- \| --- \|
347		−	\| `file` \| A file it wrote, from the repository's root. \|
348		−	\| `commit` \| A commit it made. \|
349		−	\| `branch` \| A branch it made or pushed. \|
350		−	\| `pull` \| A pull request it opened, by number. \|
351		−	\| `item` \| A work item it named or claimed, by its number in the workspace. \|
352	127
353		−	From these and the rest of what it records, g1t ties the session to the
354		−	work items and pull requests it worked on, each in as many ways as it was
355		−	(`via` in the session's `links`):
356		−
357		−	\| `via` \| When \|
358		−	\| --- \| --- \|
359		−	\| `attached` \| It said it is on it, starting or updating. \|
360		−	\| `claim` \| It claimed the work item. \|
361		−	\| `opened` \| It opened the pull request. \|
362		−	\| `branch` \| It pushed the pull request's branch, also when the pull request is opened later. \|
363		−	\| `commit` \| It made the pull request's head commit. \|
364		−	\| `trailer` \| A commit pushed to the pull request's branch names it in a `G1t-Session: ses_…` trailer. \|
365		−	\| `ref` \| Its prompt, its task, its result or a subagent's names it as `#12`. \|
366		−
367		−	A session's links cover its subagents too, and the work item and pull
368		−	request pages list every session tied to them with its subagents. Put the
369		−	trailer on the commits a session makes (`git commit --trailer "G1t-Session:
370		−	$G1T_SESSION"`) and they lead back to it. A work item a session closes, or
371		−	a repository it lands on one, says so on its timeline, via session and
372		−	a link to it: closed with the session's token while it works on the work
373		−	item, or by a commit naming it in that trailer (see
374		−	[Closing work items](/guides/pull-requests/#closing-work-items)).
375		−
376		−	When a file a session touched was touched by another active session as
377		−	well (outside its own parents and subagents), g1t sends `overlap.detected`
378		−	to both, naming each other and the files: once per pair, and again when
379		−	they touch another file in common, naming the new files.
380		−
381	128		## Start a session on your Anthropic account
382	129
383	130		g1t runs no model. Work on a work item happens in your own harness, with
⋯
503	250		`@g1t rebase` and the other
504	251		[comment commands](/guides/dependency-updates/#comment-commands) still do what
505	252		they say.
506		−
507		−	## Claims
508		−
509		−	A claim says you are working on a work item. It is advisory: anyone may
510		−	claim a work item someone else has, and is told about them, so two agents
511		−	can decide between themselves rather than collide. Nothing is refused
512		−	because of a claim. A claim is the workspace's, whichever repository the
513		−	session that holds it is checked out in, so sessions in different
514		−	repositories see each other's claims on the same work item.
515		−
516		−	- Claim an open work item with `work_item` `claim` (with
517		−	`session_id`, so that two of your sessions, such as sibling subagents,
518		−	hold claims of their own and each is told of the other's),
519		−	`g1t work claim 12`, or
520		−	[`POST /workspaces/{workspace}/work/{number}/claim`](/reference/api/work-items/claim-work-item/).
521		−	The answer has your `claim`, the `others` already on the work item, and
522		−	`blocked_by`: each work item this one waits on, with its claims and pull
523		−	requests.
524		−	- Open a work item and claim it in one step, for work that has no
525		−	work item yet: `work_item` `claim` with `title` (and `body`) and no
526		−	`number`, `g1t work claim --title "…"`, or
527		−	[`POST /workspaces/{workspace}/claims`](/reference/api/work-items/claim-new-work-item/).
528		−	The work item is opened (a `work_item.opened` event), with the
529		−	session's repository as its origin when you give `repo`, then claimed,
530		−	and the session named by `session_id` is attached to it. The answer
531		−	also has `item`, the work item opened. The session is checked first: a
532		−	claim that would be refused for it opens nothing.
533		−	- Renew it by claiming again, or give the `session_id` of your session
534		−	when you claim, and that session's heartbeats renew it.
535		−	- Release it with `work_item` `release`, `g1t work release 12`, or
536		−	[`POST /workspaces/{workspace}/work/{number}/release`](/reference/api/work-items/release-claim/),
537		−	with an optional `reason`.
538		−	- Hand it off with `work_item` `handoff`, `g1t work handoff 12`, or
539		−	[`POST /workspaces/{workspace}/work/{number}/handoff`](/reference/api/work-items/hand-off-work-item/),
540		−	with a `note` on where the work stands, for `to` (a username) or anyone.
541		−	When whoever it was for claims the work item, their `work.claimed` event
542		−	names the hand-off in `took_over`.
543		−
544		−	```sh
545		−	curl -X POST https://api.g1t.sh/workspaces/acme/work/12/claim \
546		−	-H "Authorization: Bearer $G1T_TOKEN" \
547		−	-H "Content-Type: application/json" \
548		−	-d '{"session_id": "ses_01m4b2c3d4e5f6g7h8j9k0m1n2", "note": "Taking the argument parsing first."}'
549		−
550		−	curl -X POST https://api.g1t.sh/workspaces/acme/claims \
551		−	-H "Authorization: Bearer $G1T_TOKEN" \
552		−	-H "Content-Type: application/json" \
553		−	-d '{"session_id": "ses_01m4b2c3d4e5f6g7h8j9k0m1n2", "repo": "acme/web", "title": "Preview builds time out on large repositories"}'
554		−	```
555		−
556		−	\| \| \|
557		−	\| --- \| --- \|
558		−	\| How long a claim lasts \| `ttl_minutes`: 30 unless you say, at most 240. \|
559		−	\| Opening its work item \| `title` (and `body`) instead of `number`. Giving both is refused with `422`. \|
560		−	\| When it ends \| Released, handed off, its work item closed, or not renewed in time (`expired`). \|
561		−	\| States \| `active`, `released`, `expired`, `handed_off`. \|
562		−
563		−	See who is on what with `work_item` `list_claims`, `g1t work status`, or
564		−	[`GET /repos/{owner}/{name}/claims`](/reference/api/work-items/list-claims/):
565		−	active claims unless `state` says otherwise, and `item` for one work
566		−	item's.
567		−
568		−	## Dependencies
569		−
570		−	A work item's `blocked_by` lists the work items of the same workspace that
571		−	have to land before it. Set it with `work_item` `update`, or
572		−	[`PATCH /workspaces/{workspace}/work/{number}`](/reference/api/work-items/update-work-item/),
573		−	which replaces the whole list:
574		−
575		−	```sh
576		−	curl -X PATCH https://api.g1t.sh/workspaces/acme/work/12 \
577		−	-H "Authorization: Bearer $G1T_TOKEN" \
578		−	-H "Content-Type: application/json" \
579		−	-d '{"blocked_by": [9, 10]}'
580		−	```
581		−
582		−	A list is refused with `422` when a number is not a work item of the
583		−	workspace, names the work item itself, or would make a cycle (the answer
584		−	shows the cycle, such as `#12 → #9 → #12`). Up to 50 work items. Changing
585		−	it notes the change in the work item's conversation and needs what
586		−	editing the work item does: being its author, or the Triage role.
587		−
588		−	g1t says when a dependency moves, as a `dependency.changed` event on the
589		−	blocked work item: when its list changes, and when one of its blockers
590		−	closes or has a pull request merged into the default branch. `remaining`
591		−	lists the blockers still open; when it is empty, the work item is
592		−	unblocked.
593		−
594		−	## Overlaps
595		−
596		−	Opening a pull request, and each push to it, works out which files it
597		−	changes. When it starts changing files another open or draft pull request
598		−	changes, g1t sends `overlap.detected` once for each of the two, naming the
599		−	other and the files. A pair is announced once, and again only after it stopped
600		−	overlapping. `get_work` and `pull_request` `get` show current overlaps
601		−	whenever you look.
602		−
603		−	Sessions overlap too, before there is a pull request: when a session says
604		−	it touched a file that another active session touched (see
605		−	[What a session worked on](#what-a-session-worked-on)), each gets
606		−	`overlap.detected` with `session_id`, `other_session_id`, `other_actor`
607		−	and `files`, once per pair, and again with the new `files` when another
608		−	file in common joins.
609		−
610		−	## Events
611		−
612		−	Coordination is published as events, which [webhooks](/guides/webhooks/)
613		−	deliver and the repository's timeline lists. Each carries `number` (the
614		−	work item or pull request it is about) and `item` (the work item's number
615		−	in the workspace) where there is one.
616		−
617		−	\| Event \| When \|
618		−	\| --- \| --- \|
619		−	\| `session.started` \| A session (or a subagent) starts, or one that ended starts again. Not on a repeated start. \|
620		−	\| `session.ended` \| A session ends, or times out after 30 minutes without a heartbeat. \|
621		−	\| `session.progressed` \| A session recorded more: at most every 5 seconds for each, with `session_id` (and `root_id` for a subagent), never what it recorded. Pages showing the session follow it with this. \|
622		−	\| `work.claimed` \| Someone claims a work item. `others` lists the claims already on it; `took_over` names a hand-off it takes. \|
623		−	\| `work.released` \| A claim is released, or its work item closed (`reason` `item_closed`). \|
624		−	\| `work.claim_expired` \| A claim was not renewed in time. \|
625		−	\| `work.handoff_requested` \| Someone hands a work item off: `from`, `to` (absent for anyone) and `note`. \|
626		−	\| `dependency.changed` \| A work item's `blocked_by` changed (`added`, `removed`), or a blocker closed or had its pull request merged (`cleared`). `remaining` lists the blockers still open. \|
627		−	\| `overlap.detected` \| A pull request started changing files another open one changes: `pull`, `other_pull`, `files`, `item` and `other_item`. Or a session touched files another active session touched: `session_id`, `other_session_id`, `other_actor`, `files`. \|
628		−
629		−	A session or claim that went quiet is announced as ended or expired when
630		−	the repository's sessions or claims are next read or changed, not at the
631		−	minute it lapsed.
632		−
633		−	## Who sees what
634		−
635		−	A session records someone's own work as it happens, so g1t shows it by who
636		−	is looking, on the site, the API, MCP and the CLI alike.
637		−
638		−	\| Who \| Sees \|
639		−	\| --- \| --- \|
640		−	\| Whoever ran it \| All of it: its prompts, tool calls, what it touched and reported, its pending updates. \|
641		−	\| A member of the repository's workspace \| What it did: its title, tool calls, messages, notes, skills, what it touched, its subagents' tasks, prompts and reports, its pending updates. Not the prompts someone else typed, nor a tool's output (`tool_result`): those entries show as kept back. A title shows without swearing. \|
642		−	\| Anyone else who may read the repository \| That it runs: who runs it, in which harness, since when, its state and the work items and pull requests it is tied to. Nothing it recorded, touched, was asked or reported, nor its title, branch or model. On a pull request's session, only g1t's own notes. \|
643		−
644		−	Before anything is kept, g1t takes out what looks like a credential
645		−	(`[redacted]`): every token format [secret protection](/guides/security/secret-protection/)
646		−	knows, any key or token by its issuer's prefix, `NAME_TOKEN=value`,
647		−	`password: value` and the like, `--token`/`--password` flags, `Bearer` and
648		−	`Authorization` headers, a URL's user and password and its signed query
649		−	parameters, JWTs, private keys, and long random-looking strings. What was
650		−	recorded before this is hidden the same way as it is read. The
651		−	[Claude Code plugin](/guides/claude-code-plugin/) does the same before
652		−	anything leaves your machine. It is a safety net, not a vault: keep
653		−	secrets out of prompts and command lines.
654		−
655		−	## Who may do what
656		−
657		−	\| To \| You need \|
658		−	\| --- \| --- \|
659		−	\| Read sessions and claims \| To be able to read the repository. Public repositories need no token. What a session shows depends on who you are: see [Who sees what](#who-sees-what). \|
660		−	\| Read a workspace's Sessions \| It lists the sessions of the workspace's repositories you can read; g1t's own agent's sessions only for members. \|
661		−	\| Read a work item's context \| To be able to see the work item: see [Who sees a work item](/guides/work-items/#who-sees-a-work-item). \|
662		−	\| Start a session, claim a work item, open one by claiming it \| A confirmed email address and a role that may open work items; the repository must not be archived. \|
663		−	\| Update, record in or end a session \| To be the person whose token started it. \|
664		−	\| Release a claim or hand it off \| To be the person who made it. \|
665		−	\| Set `blocked_by` \| To be the work item's author, or the Triage role. \|
666		−	\| Start a session on the workspace's Anthropic account \| To be a member of the workspace and able to open work items in the repository. The hand-off needs only to see the work item. \|
667		−
668		−	With an access token, sessions (and `start_agent_session`) need
669		−	`pull_requests:read` or `pull_requests:write`, and claims and `get_work`
670		−	need `work:read` or `work:write`, as
671		−	[scopes](/guides/authentication/#scopes) say.
672		−
673		−	## Pending coordination updates
674		−
675		−	These commands work with Codex, Claude, or another harness using the same
676		−	session API. There is no provider-specific acknowledgement protocol:
677		−
678		−	```sh
679		−	g1t session updates --json
680		−	g1t session acknowledge upd_ID --note "My scope is separate; no plan change"
681		−	```
682		−
683		−	They use `G1T_SESSION` (or the working copy's remembered session).
684		−	`session updates`, `session acknowledge` and `session heartbeat` first say
685		−	which files the working copy has changed (from `git status`), as
686		−	`session touch --file` would, so overlapping edits are noticed whichever
687		−	harness makes them; `G1T_TOUCH=0` turns that off. To avoid
688		−	shared-checkout ambiguity, `updates SESSION_ID` and `acknowledge --session
689		−	SESSION_ID` select a session explicitly. The acknowledgement command records
690		−	a decision note before clearing updates, with an idempotency key for retries.
691		−	The raw API below also works with older CLI installations.
692		−
693		−	`g1t api get_session -f id=SESSION_ID` returns up to 100 pending `updates`,
694		−	oldest first, separately from transcript entries (give `after=4294967295` to
695		−	leave the entries out). Updates are claims, releases, hand-offs and expiries,
696		−	overlaps, dependency changes, decisions, integration results, and sessions
697		−	starting and ending.
698		−
699		−	An active session receives the updates that concern it:
700		−
701		−	\| The session is \| It receives \|
702		−	\| --- \| --- \|
703		−	\| Attached to a work item or pull request, or tied to one (a claim, its branch, a `#N` it named) \| Updates about that work item or pull request: its claims, decisions, overlaps, dependency changes and integration results, and those that name it, such as an integration failure listing it as a suspect or a work item newly blocked by it \|
704		−	\| Not on anything yet \| Every update, so it can find who else is working and on what \|
705		−	\| Either \| Updates about nothing in particular, such as a session starting without a work item; and an overlap between its own files and another session's, which goes only to the two sessions \|
706		−
707		−	A session does not receive its own start or end, or the claims it made,
708		−	released or handed off. It does hear when its claim expires. New sessions
709		−	should still load the work item's context: an inbox is not a replay of what happened
710		−	before the session started.
711		−
712		−	Reading does not clear an update. After considering it and recording any
713		−	change of plan, the session owner acknowledges exact IDs:
714		−
715		−	```sh
716		−	g1t api record_session_entries -f id=SESSION_ID -f 'acknowledge[]=UPDATE_ID'
717		−	```
718		−
719		−	Repeat the field for multiple IDs, at most 100 per request, then read again
720		−	for the next page. Acknowledgement is idempotent and scoped to that session.
721		−	It means considered, not resolved. The response's `acknowledged` says how
722		−	many of the IDs name updates of that session, so a mistyped ID or one from
723		−	another session shows up as a shortfall (the CLI warns). The session page
724		−	shows pending updates.
725		−
726		−	Claude Code hooks retrieve updates in the background, at most once per ten
727		−	seconds when a successful cached response exists, and at once after an
728		−	acknowledgement. Every prompt shows what is pending; before a tool, pending
729		−	updates are shown when they change and again every two minutes. Delivery
730		−	repeats until acknowledged. Other
731		−	harnesses, including managed sessions, should poll between work steps using
732		−	the coordination skill. Neither a disconnected harness nor an idle session
733		−	is interrupted in real time.
734		−
735		−	An update is written in the same transaction as the change it announces: a
736		−	claim, release, hand-off, expiry, session start or end, overlap, decision or
737		−	change to what a work item is blocked by is never kept without its
738		−	updates, and updates never announce a change that was not made. Each
739		−	update's ID is derived from its change, so a retried request, or two
740		−	requests making the same change at once, delivers it once. The one
741		−	exception is the notice that a work item's blocker closed or merged, which
742		−	follows the close or merge: it is written right after, once per close or
743		−	merge. Updates are still a summary: re-read current work item and pull
744		−	request state before consequential actions.
745		−
746		−	Acknowledged updates are kept as receipts for 30 days. Pending updates stay
747		−	until acknowledged, including those of a session that ended, so whoever
748		−	takes over its work can see what it never considered.

12	12
13	13		\| \| Sent the events of \| Managed by \| Where \|
14	14		\| --- \| --- \| --- \| --- \|
15		−	\| A repository's \| That repository, and the [work items](/guides/work-items/) linked to it \| People with the Admin [role](/guides/access-and-roles/) on it \| The project's Settings → Webhooks \|
	15	+	\| A repository's \| That repository, and the [work items](/work/work-items/) linked to it \| People with the Admin [role](/guides/access-and-roles/) on it \| The project's Settings → Webhooks \|
16	16		\| A workspace's \| Every repository in the workspace, all its work items, the workspace's own [packages](/guides/packages/), and its [teams](/guides/teams/) \| Owners \| The workspace's Settings → Webhooks \|
17	17
18	18		Seeing a repository's webhooks, and their deliveries, needs Admin too: the
⋯
91	91		\| `workspace.member_joined` \| A person became a member of the [workspace](/guides/workspaces/#when-someone-joins). Sent to the workspace's webhooks. `data.workspace_id`, `data.workspace` (its slug), `data.user_id`, `data.username`, `data.role` (`owner` or `member`) and `data.how`: `invitation` (they accepted an invitation), `joined` (they used an invite code that names the workspace) or `created` (they made the workspace and are its first owner). \|
92	92		\| `repo.archived`, `repo.unarchived` \| It was made read-only, or writable again. \|
93	93		\| `repo.deleted`, `repo.restored`, `repo.purged` \| It was deleted, restored within its 30 days, or removed for good. \|
94		−	\| `work_item.labeled`, `work_item.unlabeled`, `pull.labeled`, `pull.unlabeled` \| A [label](/guides/labels/) was put on a work item or a pull request, or taken off: one event for each label. `data.number` and `data.label` (`name` and `color`). \|
95		−	\| `work_item.milestoned`, `work_item.demilestoned`, `pull.milestoned`, `pull.demilestoned` \| A work item or a pull request was put in a [milestone](/guides/milestones/), or taken out of one. `data.milestone` (`number` and `title`). Moving it from one to another is both. \|
	94	+	\| `work_item.labeled`, `work_item.unlabeled`, `pull.labeled`, `pull.unlabeled` \| A [label](/work/labels/) was put on a work item or a pull request, or taken off: one event for each label. `data.number` and `data.label` (`name` and `color`). \|
	95	+	\| `work_item.milestoned`, `work_item.demilestoned`, `pull.milestoned`, `pull.demilestoned` \| A work item or a pull request was put in a [milestone](/work/milestones/), or taken out of one. `data.milestone` (`number` and `title`). Moving it from one to another is both. \|
96	96		\| `pull.base_changed` \| The branch a pull request merges into changed. `data.base` names it. See [pull requests into other branches](/guides/base-branches/). \|
97		−	\| `work_item.opened`, `work_item.updated`, `work_item.assigned`, `work_item.closed`, `work_item.reopened` \| A [work item](/guides/work-items/) changed. `data.workspace`, `data.number`, `data.item_id`, `data.repo_ids` and `data.author` (`id` and `username`); on close, `data.reason`, `data.resolution` when a landing closed it (the `repo` and the `pull` request or default-branch `commit` that landed it), and `data.session` when it was closed in a session; on assignment, `data.assignees` and the newly assigned `data.added`. \|
	97	+	\| `work_item.opened`, `work_item.updated`, `work_item.assigned`, `work_item.closed`, `work_item.reopened` \| A [work item](/work/work-items/) changed. `data.workspace`, `data.number`, `data.item_id`, `data.repo_ids` and `data.author` (`id` and `username`); on close, `data.reason`, `data.resolution` when a landing closed it (the `repo` and the `pull` request or default-branch `commit` that landed it), and `data.session` when it was closed in a session; on assignment, `data.assignees` and the newly assigned `data.added`. \|
98	98		\| `work_item.linked`, `work_item.unlinked` \| A repository was linked to a work item in a role, or unlinked. `data.workspace`, `data.number`, `data.item_id`, `data.repo_ids`, `data.repo` (`owner/name`) and `data.role`. \|
99	99		\| `work_item.landed` \| A pull request or a default-branch commit landed a work item in one of its repositories. `data.resolution` (the `repo`, and the `pull` or `commit`) and `data.missing`, the targets it has still to land in. When nothing is left, `work_item.closed` follows. \|
100	100		\| `comment.created` \| A comment or review on a work item or pull request. \|
⋯
129	129		\| `integration.passed` \| A pull request's combined state passed in the merge queue: `pull` and `combination`. \|
130	130		\| `decision.recorded` \| A [decision record](/guides/why-blame/#decision-records) was kept on a work item or pull request: `decision`, with `number` and `item`. \|
131	131		\| `session.appended` \| A pull request's [session](/guides/why-blame/#sessions) grew: a coding agent recorded entries with `record_session`, a session on it recorded some, or g1t noted a merge queue failure. Busy: choose it only if you need it. \|
132		−	\| `session.started`, `session.ended` \| A [session](/guides/sessions/#sessions) of someone's harness started (not on a repeated start), or ended or timed out. `data.session`, and `data.number` (its pull request, else its work item) and `data.item`. \|
133		−	\| `work.claimed`, `work.released`, `work.claim_expired`, `work.handoff_requested` \| A [claim](/guides/sessions/#claims) on a work item was made, released, expired or handed off. `data.number` and `data.item` (the work item), `data.claim`; on `work.claimed`, `data.others` (the other active claims) and `data.took_over`; on `work.released`, `data.reason`; on a hand-off, `data.from`, `data.to` and `data.note`. \|
134		−	\| `dependency.changed` \| What a work item is [blocked by](/guides/sessions/#dependencies) changed, or a blocker closed or had its pull request merged. `data.number` (the blocked work item), `data.blocked_by`, `data.added`, `data.removed`, `data.cleared`, `data.remaining` (blockers still open) and `data.merged_pull`. \|
135		−	\| `overlap.detected` \| A push made a pull request [change files another open one changes](/guides/sessions/#overlaps). Sent once for each of the two: `data.pull`, `data.other_pull`, `data.files`, `data.item` and `data.other_item`. \|
	132	+	\| `session.started`, `session.ended` \| A [session](/guides/sessions/#record-a-session) of someone's harness started (not on a repeated start), or ended or timed out. `data.session`, and `data.number` (its pull request, else its work item) and `data.item`. \|
	133	+	\| `work.claimed`, `work.released`, `work.claim_expired`, `work.handoff_requested` \| A [claim](/work/claims-and-dependencies/#claims) on a work item was made, released, expired or handed off. `data.number` and `data.item` (the work item), `data.claim`; on `work.claimed`, `data.others` (the other active claims) and `data.took_over`; on `work.released`, `data.reason`; on a hand-off, `data.from`, `data.to` and `data.note`. \|
	134	+	\| `dependency.changed` \| What a work item is [blocked by](/work/claims-and-dependencies/#dependencies) changed, or a blocker closed or had its pull request merged. `data.number` (the blocked work item), `data.blocked_by`, `data.added`, `data.removed`, `data.cleared`, `data.remaining` (blockers still open) and `data.merged_pull`. \|
	135	+	\| `overlap.detected` \| A push made a pull request [change files another open one changes](/work/claims-and-dependencies/#overlaps). Sent once for each of the two: `data.pull`, `data.other_pull`, `data.files`, `data.item` and `data.other_item`. \|
136	136
137	137		[Managing a repository](/guides/managing-repositories/) says what each of
138	138		the `repo.` and `branch.` changes does.

75	75		\| Feature \| What it does \| Status \|
76	76		\| --- \| --- \| --- \|
77	77		\| [Repositories](/guides/managing-repositories/) and [git](/guides/git/) \| Public and private repositories over HTTPS. Pushing to a repository that does not exist creates it, private. \| <Status is="live" /> \|
78		−	\| [Work items](/guides/work-items/) and [pull requests](/guides/pull-requests/) \| Work items for the whole workspace, linked to the repositories they land in; pull requests, line comments, reviews, merge methods and auto-merge. \| <Status is="live" /> \|
	78	+	\| [Work items](/work/work-items/) and [pull requests](/guides/pull-requests/) \| Work items for the whole workspace, linked to the repositories they land in; pull requests, line comments, reviews, merge methods and auto-merge. \| <Status is="live" /> \|
79	79		\| [Checks](/guides/checks/), [rules](/guides/rules/) and the [merge queue](/guides/merge-queue/) \| Required checks, protected branches, code owners, and changes tested together before they land. \| <Status is="live" /> \|
80	80		\| [Workflows](/guides/actions/) \| Workflows from `.g1t/workflows`, most unchanged, on g1t's runners or [your own](/guides/self-hosted-runners/). \| <Status is="live" /> \|
81	81		\| [Forks](/guides/forking-repositories/) \| Fork a repository into your workspace, keep it in sync, and propose changes back. \| <Status is="live" /> \|
⋯
96	96		\| [Connect an AI client](/guides/bring-your-own-agent/) \| Coding agents and MCP chat apps sign in and work on g1t as you, with the access you give them. \| <Status is="live" /> \|
97	97		\| [The Claude Code plugin](/guides/claude-code-plugin/) \| Records every Claude Code session in a g1t repository, gives Claude the work item's context, and adds g1t's MCP server, skills and commands. \| <Status is="live" /> \|
98	98		\| [The g1t CLI](/guides/cli/) \| Work items, pull requests, checks, runs, workflows, secrets and logs from a terminal, a script or an agent's shell. \| <Status is="live" /> \|
99		−	\| [Sessions and claims](/guides/sessions/) \| Who is working on what, right now: each agent's session, the work item it claimed, and the files it shares with others. \| <Status is="live" /> \|
	99	+	\| [Sessions and claims](/work/sessions/) \| Who is working on what, right now: each agent's session, the work item it claimed, and the files it shares with others. \| <Status is="live" /> \|
100	100		\| [Assign g1t](/guides/sessions/#assign-g1t-or-ask-it-in-the-thread) \| Assign a work item to `g1t`, or mention `@g1t` in a thread, to start a session on the workspace's own Anthropic account. \| <Status is="live" /> \|
101	101		\| [Why-blame](/guides/why-blame/) \| Any line traced to its commit, pull request, work item, and the agent's own account of why it changed. \| <Status is="live" /> \|
102	102
⋯
181	181		<LinkCard
182	182		title="Labels and milestones"
183	183		description="Say what work items and pull requests are with the workspace's colored labels, and gather them under milestones with due dates."
184		−	href="/guides/labels/"
	184	+	href="/work/labels/"
185	185		/>
186	186		<LinkCard
187	187		title="Pull requests into other branches"

176	176		requests in a repository, at `/repos/{owner}/{name}/pulls/{number}`. The
177	177		two share one sequence of numbers per workspace, so a new number names
178	178		exactly one of them in it. Pull requests opened before work items keep the
179		−	numbers they had. See [work items](/guides/work-items/).
	179	+	numbers they had. See [work items](/work/work-items/).
180	180
181	181		## Errors
182	182
⋯
272	272		\| [Code scanning](/reference/api/code-scanning/list-code-scanning-alerts/) \| SARIF uploads, and the alerts and analyses they make. See [code scanning](/guides/security/code-scanning/). \|
273	273		\| [Supply chain](/reference/api/supply-chain/list-vulnerability-alerts/) \| Vulnerability alerts, the dependency graph, its SPDX SBOM, and comparing dependencies. See [supply chain](/guides/security/supply-chain/). \|
274	274		\| [Security settings](/reference/api/security-settings/get-security-settings/) \| When pull request checks fail, dependency review's policy, delegated bypass, validity checks and a workspace's overview. \|
275		−	\| [Work items](/reference/api/work-items/list-work-items/) \| What should change, in a workspace: the repositories each links, labels and comments, claims and hand-offs. See [work items](/guides/work-items/). \|
276		−	\| [Labels and milestones](/reference/api/labels-and-milestones/list-labels/) \| A workspace's labels and milestones, shared by its work items and pull requests. See [labels](/guides/labels/) and [milestones](/guides/milestones/). \|
	275	+	\| [Work items](/reference/api/work-items/list-work-items/) \| What should change, in a workspace: the repositories each links, labels and comments, claims and hand-offs. See [work items](/work/work-items/). \|
	276	+	\| [Labels and milestones](/reference/api/labels-and-milestones/list-labels/) \| A workspace's labels and milestones, shared by its work items and pull requests. See [labels](/work/labels/) and [milestones](/work/milestones/). \|
277	277		\| [Pull requests](/reference/api/pull-requests/list-pull-requests/) \| Proposed changes: reviews, merging and the merge queue. \|
278	278		\| [Sessions](/reference/api/sessions/read-session/) \| The record of how a pull request was made, written by the coding agent that made it. See [sessions and why-blame](/guides/why-blame/). \|
279	279		\| [Actions](/reference/api/actions/list-workflows/) \| Workflows, their runs and their logs. \|

192	192		tool and its action: the tables below give each, and each page of the
193	193		[API reference](/reference/api/) names the tool and action for its
194	194		operation. `get_issue` went with issues: use `work_item` with
195		−	`"action": "get"` (see [issues became work items](/about/issues-became-work-items/)).
	195	+	`"action": "get"` (see [issues became work items](/work/from-issues/)).
196	196
197	197		\| Earlier name \| Now \|
198	198		\| --- \| --- \|
⋯
333	333
334	334		## `work_item`
335	335
336		−	[Work items](/guides/work-items/): what should change, a feature, a bug or
	336	+	[Work items](/work/work-items/): what should change, a feature, a bug or
337	337		a chore. A work item belongs to a workspace and links the repositories it
338	338		starts in and lands in. Each action takes `workspace` and the item's
339	339		`number`; `repo` is optional: the origin of a new work item, a filter, or
340	340		in place of `workspace`, which is then the repository's. Before working on
341	341		one, `work` gives everything about it, and `claim` says you are on it; see
342		−	[sessions, claims and dependencies](/guides/sessions/). Work items and pull
	342	+	[claims and dependencies](/work/claims-and-dependencies/). Work items and pull
343	343		requests share numbers in a workspace; a pull request's comments, labels
344	344		and reactions are on the [`pull_request`](#pull_request) tool. `resolve`
345	345		says which of the two a `#N` names. `attach` uploads an image, such as a
⋯
350	350		\| --- \| --- \| --- \| --- \|
351	351		\| [`list`](/reference/api/work-items/list-work-items/) \| Work items, newest first, by `state`, `label`, `milestone` (its number), `assignee`, and `repo` (the items linked to it, in any role). \| `workspace` or `repo` \| `work:read` \|
352	352		\| [`get`](/reference/api/work-items/get-work-item/) \| A work item: description (which may say what done means, under Definition of done), labels, comments, its `repos` with their roles and whether each `landed`, its `resolutions`, and every pull request made for it. \| `workspace`, `number` \| `work:read` \|
353		−	\| [`create`](/reference/api/work-items/open-work-item/) \| Open a work item, with `body`, `labels`, `milestone`, `repo` (its origin) and `targets` (the repositories it should land in). A label the workspace lacks is created for someone with the Write role. `checks` is deprecated: its commands are added to the body under Definition of done, and the result carries a `deprecation` note. \| `workspace` or `repo`, `title` \| `work:write` \|
	353	+	\| [`create`](/reference/api/work-items/open-work-item/) \| Open a work item, with `body`, `labels`, `milestone`, `repo` (its origin) and `targets` (the repositories it should land in). A label the workspace lacks is created for someone with the Write role. Say what done means in `body`, under a Definition of done heading. \| `workspace` or `repo`, `title` \| `work:write` \|
354	354		\| [`update`](/reference/api/work-items/update-work-item/) \| Change its title, body, labels, milestone, assignees or `blocked_by` (the work items that must land first). Labels, assignees and `blocked_by` each replace the whole set; `milestone` `null` or `0` takes it out of its milestone. A `blocked_by` that names the work item itself, something not a work item of the workspace, or makes a cycle is refused. \| `workspace`, `number` \| `work:write` \|
355	355		\| [`links`](/reference/api/work-items/list-work-item-links/) \| The repositories it is linked to: its origin, then its targets, then those it touched, each with its `role`, its `legacy_number` (the issue number it had in its origin) and whether it `landed`; `missing` lists the targets it has not landed in yet. \| `workspace`, `number` \| `work:read` \|
356	356		\| [`link`](/reference/api/work-items/link-work-item/) \| Link a repository of the workspace in a `role`: `target` (the default) or `touched`; linking one already linked changes its role. An origin cannot be given. Triage role. \| `workspace`, `number`, `repo` \| `work:write` \|
⋯
369	369		\| [`attach`](/reference/api/work-items/upload-work-item-attachment/) \| Upload an image to show in its description or in a comment on it, kept by the work item, so one filed with no repository takes images too: `data` base64-encoded, `name` its file name. PNG, JPEG, GIF or WebP of at most 10 MB, by its bytes (`413` `too_large`, `415` `unsupported_type` otherwise). Returns `id`, `url`, `content_type`, `size` and `markdown` (`![name](url)`) to paste into a `body`. The file travels in the tool call, so keep it small (a few hundred KB); `g1t work comment --attach FILE` sends one from disk. Anyone who may comment on it may. \| `workspace`, `number`, `name`, `data` \| `work:write` \|
370	370		\| [`import`](/reference/api/work-items/import-work-items/) \| Open a work item from a Jira, Linear or Sentry item, linked to it. \| `workspace`, `reference` \| `work:write` \|
371	371		\| [`resolve`](/reference/api/work-items/resolve-ref/) \| What `#number` names where it is written: in `repo`, a pull request of it, then a work item filed there under that old issue number, then the workspace's work item, then a pull request of another of its repositories; in a `workspace` alone ([`GET /workspaces/{workspace}/refs/{number}`](/reference/api/work-items/resolve-ref-for-workspace/)), its work item, else its pull request. Answers `kind` `work_item`, `pull` or `none`. \| `workspace` or `repo`, `number` \| `work:read` \|
372		−	\| [`work`](/reference/api/work-items/get-work/) \| Everything to pick a work item up: its definition of done and required checks, its repositories with what landed where and which targets are still missing, suggested targets (each with `why`), active claims, sessions, pull requests (checks, mergeability, overlaps, queue place), what it is blocked by and blocks, decisions, and its recent coordination events. \| `workspace`, `number` \| `work:read` \|
	372	+	\| [`work`](/reference/api/work-items/get-work/) \| Everything to pick a work item up: its definition of done, each repository with its required checks, its repositories with what landed where and which targets are still missing, suggested targets (each with `why`), active claims, sessions, pull requests (checks, mergeability, overlaps, queue place), what it is blocked by and blocks, decisions, and its recent coordination events. \| `workspace`, `number` \| `work:read` \|
373	373		\| [`claim`](/reference/api/work-items/claim-work-item/) \| Say you are working on an open work item: advisory and expiring (`ttl_minutes`, 30 unless you say, at most 240), never a lock. Returns `others` already on it and what it is `blocked_by`. Claiming again, or a heartbeat of its `session_id`, renews it. With `title` (and `body`) instead of `number`, it [opens the work item first](/reference/api/work-items/claim-new-work-item/), claims it, attaches the `session_id` session to it, and returns it as `item`. \| `workspace`, and `number` or `title` \| `work:write` \|
374	374		\| [`release`](/reference/api/work-items/release-claim/) \| Give up your claim, with an optional `reason`. \| `workspace`, `number` \| `work:write` \|
375	375		\| [`handoff`](/reference/api/work-items/hand-off-work-item/) \| End your claim as handed off, `to` someone or anyone, with a `note` on where the work stands. \| `workspace`, `number`, `note` \| `work:write` \|
⋯
425	425
426	426		Your harness's session on a repository, so others see who is working on
427	427		what. Start one per run of your harness, heartbeat it, record what it does,
428		−	and end it. See [sessions](/guides/sessions/#sessions).
	428	+	and end it. See [sessions](/guides/sessions/#record-a-session).
429	429
430	430		\| Action \| What it does \| Required \| Scope \|
431	431		\| --- \| --- \| --- \| --- \|
⋯
434	434		\| [`record`](/reference/api/sessions/record-session-entries/) \| Record up to 200 `entries`, each with `kind` and `text` (`skill` for a skill used, by name), `tool` for tools, and a `key` that makes recording it again a no-op; and `touched`, what it touched (`file`, `commit`, `branch`, `pull`, `item`), which ties it to pull requests and work items and tells sessions on the same files of each other. \| `repo`, `id` \| `pull_requests:write` \|
435	435		\| [`end`](/reference/api/sessions/end-session/) \| End it, with an optional `reason` and `result` (what it reported). Its subagents still going end with it. \| `repo`, `id` \| `pull_requests:write` \|
436	436		\| [`get`](/reference/api/sessions/get-session/) \| A session and its entries (`after` pages through them), its subagents (`children`), what they touched, the work items and pull requests they worked on (`links`) and the skills used. With [`workspace`](/reference/api/sessions/get-workspace-session/) and `id` instead of `repo`, a session of any of the workspace's repositories, with its `repo`. \| `repo` or `workspace`, `id` \| `pull_requests:read` \|
437		−	\| [`list`](/reference/api/sessions/list-sessions/) \| A repository's sessions, most recently heard from first, by `state` (`active`, `idle`, `ended`), `item` or `pull` (any session tied to it), or `path` (a file touched); `subagents` lists each tree whole. With [`workspace`](/reference/api/sessions/list-workspace-sessions/) instead of `repo`, the sessions of every repository of the workspace you can read, as [Sessions](/guides/sessions/#the-sessions-page) shows them: by `state` (`live`, `recent`, `ended`), `kind` (`harness`, `hosted`, `agent`, `recorded`), `harness`, `person`, `repo`, `item`, `subagents` and `limit`, with each repository's merge `queue`, what `landed` and the `repos` covered. \| `repo` or `workspace` \| `pull_requests:read` \|
	437	+	\| [`list`](/reference/api/sessions/list-sessions/) \| A repository's sessions, most recently heard from first, by `state` (`active`, `idle`, `ended`), `item` or `pull` (any session tied to it), or `path` (a file touched); `subagents` lists each tree whole. With [`workspace`](/reference/api/sessions/list-workspace-sessions/) instead of `repo`, the sessions of every repository of the workspace you can read, as [Sessions](/work/sessions/) shows them: by `state` (`live`, `recent`, `ended`), `kind` (`harness`, `hosted`, `agent`, `recorded`), `harness`, `person`, `repo`, `item`, `subagents` and `limit`, with each repository's merge `queue`, what `landed` and the `repos` covered. \| `repo` or `workspace` \| `pull_requests:read` \|
438	438		\| [`dispatch`](/reference/api/sessions/start-agent-session/) \| Start work on an `item` (or a new work item from `title` and `body`) in a session on the person's own Claude: a Claude Managed Agents session on the workspace's Anthropic account, recorded here, or with `handoff` a Claude Code command line to run. `mode` is `plan`, `implement` or `review`; `instruction` adds to it. \| `repo` \| `pull_requests:write` \|
439	439
440	440		## `workflow`
⋯
711	711		invite members,
712	712		manage its members and owners,
713	713		connect [integrations](/guides/integrations/), manage the
714		−	[labels](/guides/labels/) and [milestones](/guides/milestones/) its work
	714	+	[labels](/work/labels/) and [milestones](/work/milestones/) its work
715	715		items and pull requests share, read and
716	716		change its [projects](/guides/projects/) (what each is, where it runs, its
717	717		links), and keep your own

1	+	---
2	+	title: Working with agents
3	+	description: How coding agents, and people at a terminal, work on work items. Load a work item's whole context in one call, claim it, open a pull request for it, and use g1t work, the work_item MCP tool and the REST API. What the Claude Code plugin and the work-on-item skill do.
4	+	---
5	+
6	+	Coding agents work on work items the way people do, through the same
7	+	calls: the [g1t CLI](/guides/cli/), the [MCP server](/reference/mcp/) and
8	+	the [REST API](/reference/api/). g1t runs no model: work happens in your
9	+	own harness, with your own agent, and g1t ties it back to the work item.
10	+	To connect one, see [connect a coding agent](/guides/bring-your-own-agent/).
11	+
12	+	## How an agent works on a work item
13	+
14	+	1. Load its context: `g1t work view 12`, or the `work_item` tool's
15	+	`work`. One call has everything: what done means, where it should land
16	+	and where it has, who is on it, its pull requests and what blocks it.
17	+	See [pick up a work item](#pick-up-a-work-item).
18	+	2. Claim it: `g1t work claim 12 --note "…"`, or `work_item` `claim`.
19	+	The answer says who else is on it. See
20	+	[claims](/work/claims-and-dependencies/#claims).
21	+	3. Open a pull request for it in the repository the change is for:
22	+	`g1t pr create --item 12`, or `pull_request` `create` with `item`. See
23	+	[open a pull request for it](#open-a-pull-request-for-it).
24	+	4. Push commits with the session's trailer,
25	+	`git commit --trailer "G1t-Session: $G1T_SESSION"`, and watch the
26	+	checks: `g1t pr checks --watch`.
27	+	5. Mark it ready with a summary: `g1t pr ready`, or `pull_request`
28	+	`ready`. When it merges, it [lands the work item](/work/closing/) in
29	+	that repository.
30	+	6. Hand it off if it stops before the work is done:
31	+	`g1t work handoff 12 --note "…"`.
32	+
33	+	All along, its [session](/work/sessions/) records what it does, and its
34	+	[coordination updates](/work/claims-and-dependencies/#coordination-updates)
35	+	say what changed around it.
36	+
37	+	## Pick up a work item
38	+
39	+	A work item's work context is everything about it in one call:
40	+	`g1t work view 12`, `work_item` with `"action": "work"` over MCP, or
41	+	[`GET /workspaces/{workspace}/work/{number}/work`](/reference/api/work-items/get-work/):
42	+
43	+	```sh
44	+	curl https://api.g1t.sh/workspaces/acme/work/12/work \
45	+	-H "Authorization: Bearer $G1T_TOKEN"
46	+	```
47	+
48	+	\| Field \| What it holds \|
49	+	\| --- \| --- \|
50	+	\| `item` \| The work item, with its description. \|
51	+	\| `definition_of_done` \| The items under its Definition of done heading. \|
52	+	\| `repos` \| Its repositories, each with its `role`, whether it has `landed`, its old issue number (`legacy_number`), the `required_checks` its default branch requires, and its `pulls` for the work item. Those still open or draft carry their checks as they stand on the head, `mergeable`, the other pull requests they `overlaps` with, and their place in the merge `queue`. \|
53	+	\| `missing` \| Its targets that have not landed yet. \|
54	+	\| `suggested_targets` \| Up to five repositories of the workspace it may also need, each with `path` and `why`. See [suggested targets](/work/work-items/#suggested-targets). \|
55	+	\| `claims` \| Who says they are working on it now. \|
56	+	\| `sessions` \| Sessions on it or its pull requests, or tied to it any other way, subagents included, those still going first; up to 50. Each says how many `subagents` it started. \|
57	+	\| `blocked_by` \| Each work item it waits on, with that work item's claims and pull requests. \|
58	+	\| `blocks` \| The work items waiting on it. \|
59	+	\| `decisions` \| [Decision records](/guides/why-blame/#decision-records) on it and its pull requests, newest first; up to 20. \|
60	+	\| `last_integration_failure` \| The latest `integration_failure` decision among them, if any: the combination that failed in the merge queue, the check, the `suspects` and, when it failed on `main` alone, the pull requests that `landed` on `main` since it branched. \|
61	+	\| `recent` \| Its latest 20 coordination events, newest first. \|
62	+
63	+	`g1t work view 12` prints the same: its description and definition of
64	+	done, its repositories with their pull requests, checks and overlaps,
65	+	Still to land in, Suggested targets (with the
66	+	`g1t work link 12 --repo owner/name` that adds one), its claims, sessions,
67	+	what blocks it and what it blocks, the last integration failure, its
68	+	decisions and what happened lately. A target the work needs that is not
69	+	linked yet is worth linking before starting:
70	+
71	+	```sh
72	+	g1t work link 12 --role target --repo acme/docs
73	+	```
74	+
75	+	## Open a pull request for it
76	+
77	+	`g1t pr create --item 12`, or `pull_request` `create` with `item: 12`,
78	+	opens a pull request for the work item in the repository it runs in:
79	+
80	+	- Without a branch, g1t makes a
81	+	[working copy](/concepts/forks/#working-copies-for-pull-requests) for
82	+	it and opens a draft. The answer has the pull request and the git
83	+	remote of its working copy, to clone and push to.
84	+	- With a `branch` already pushed, it opens the pull request from it.
85	+
86	+	Its title is the work item's unless you give one. The work item notes
87	+	opened acme/web#14 for this, and the repository is linked as
88	+	`touched` unless it is already a target. When the pull request merges
89	+	into the default branch, it lands the work item there; see
90	+	[closing work items](/work/closing/).
91	+
92	+	```json
93	+	{ "name": "pull_request", "arguments": { "action": "create", "repo": "acme/web", "item": 12 } }
94	+	```
95	+
96	+	## Work with no work item yet
97	+
98	+	Most of what an agent is asked starts without a work item, and a question,
99	+	a look around or a quick fix never needs one. The session is recorded
100	+	anyway, and shows on [Sessions](/work/sessions/) and the project's
101	+	Live now. When the work becomes a change others should know about (a
102	+	branch to push, a pull request), the agent looks for its work item
103	+	(`g1t work list`, `work_item` `list` or `list_claims`), and claims it. If
104	+	there is none, it files one and claims it in one step:
105	+
106	+	```sh
107	+	g1t work claim --title "Preview builds time out on large repositories"
108	+	```
109	+
110	+	See [work with no work item yet](/guides/sessions/#work-with-no-work-item-yet).
111	+
112	+	## The CLI
113	+
114	+	`g1t work` works on the current repository's workspace, or the one in
115	+	`--workspace` (or the `G1T_WORKSPACE` environment variable). `-R` (or
116	+	`--repo`) `owner/name` names a repository instead of the current one: it
117	+	filters `g1t work list`, and is the repository `g1t work link` and
118	+	`g1t work unlink` act on. Every command takes `--json`.
119	+
120	+	\| Command \| Does \|
121	+	\| --- \| --- \|
122	+	\| `g1t work list` \| Lists open work items. `-R`, `--state` (`open`, `closed` or `all`), `--label`, `--milestone`, `--assignee` and `--author` narrow it; with `-R`, `--role` keeps those linked to the repository in one role. \|
123	+	\| `g1t work view N` \| Shows its [work context](#pick-up-a-work-item). `--comments` adds its comments, `--web` opens it in the browser. \|
124	+	\| `g1t work new` \| Files a work item; `--target` for each repository it should land in, `--label`, `--assignee`, `--milestone`. `--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. \|
125	+	\| `g1t work comment N` \| Comments on it. `--attach FILE` uploads an image to the work item and adds it to the comment. \|
126	+	\| `g1t work edit N` \| Changes its title, description, labels, assignees or milestone. \|
127	+	\| `g1t work close N` \| Closes it, as completed, or `--reason not_planned`; `--comment` says why. `--commit SHA` names a commit on the default branch that did it, which lands it there. See [closing work items](/work/closing/). \|
128	+	\| `g1t work reopen N` \| Opens it again. \|
129	+	\| `g1t work link N` \| Links a repository in a role: `--role target` (the default) or `touched`, the current repository or `-R owner/name`. \|
130	+	\| `g1t work unlink N` \| Unlinks a repository, never its origin. \|
131	+	\| `g1t work claim N` \| Says you are working on it, with `--note` and `--ttl`. With `--title` instead of a number, files a work item and claims it. \|
132	+	\| `g1t work release N` \| Lets go of your claim. \|
133	+	\| `g1t work handoff N` \| Hands it to someone else (`--to`), or to anyone, with a `--note`. \|
134	+	\| `g1t work status` \| The repository's active claims and sessions. \|
135	+	\| `g1t work block N --by M` \| Says it waits on work item M; `g1t work unblock N --by M` takes that back. \|
136	+	\| `g1t work events` \| The repository's events; `--follow` keeps printing them, `--item N` for one work item. \|
137	+	\| `g1t work dispatch N` \| Starts work on it in a session on your own Claude, or prints the Claude Code command for it. See [start a session on your Anthropic account](/guides/sessions/#start-a-session-on-your-anthropic-account). \|
138	+
139	+	[CLI commands](/reference/cli/#g1t-work) lists every flag.
140	+
141	+	## MCP and the API
142	+
143	+	The MCP server's `work_item` tool takes an `action`: `list`, `get`,
144	+	`create`, `update`, `close`, `reopen`, `links`, `link`, `unlink`,
145	+	`labels`, `add_labels`, `set_labels`, `remove_labels`, `comment`,
146	+	`edit_comment`, `delete_comment`, `react`, `attach`, `decisions`,
147	+	`resolve` (what `#N` names), `import`, `work`, `claim`, `release`,
148	+	`handoff` and `list_claims`. It takes `workspace` and `number`; `repo` is
149	+	optional, as the origin of a new work item, a filter, or to find the
150	+	workspace. A workspace's labels and milestones are on the `workspace`
151	+	tool, and a repository's work items are the `repository` tool's `work`.
152	+	See [MCP tools](/reference/mcp/#work_item).
153	+
154	+	The REST API has the same under `/workspaces/{workspace}/work`:
155	+
156	+	\| To \| REST \|
157	+	\| --- \| --- \|
158	+	\| List work items \| `GET /workspaces/{workspace}/work` \|
159	+	\| File one \| `POST /workspaces/{workspace}/work` \|
160	+	\| Get one \| `GET /workspaces/{workspace}/work/{number}` \|
161	+	\| Change one \| `PATCH /workspaces/{workspace}/work/{number}` \|
162	+	\| Close or reopen it \| `POST /workspaces/{workspace}/work/{number}/close` (with `reason`, or `repo` and `commit`), `…/reopen` \|
163	+	\| Its repositories \| `GET /workspaces/{workspace}/work/{number}/links` \|
164	+	\| Link or unlink a repository \| `POST` or `DELETE /workspaces/{workspace}/work/{number}/links` \|
165	+	\| Its labels \| `GET`, `POST`, `PUT` or `DELETE /workspaces/{workspace}/work/{number}/labels`, `DELETE …/labels/{label}` \|
166	+	\| Comment \| `POST /workspaces/{workspace}/work/{number}/comments`; `PATCH` or `DELETE /workspaces/{workspace}/work/comments/{id}` \|
167	+	\| React \| `POST /workspaces/{workspace}/work/{number}/reactions` \|
168	+	\| 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 \|
169	+	\| Its decisions, with its pull requests' \| `GET /workspaces/{workspace}/work/{number}/decisions` \|
170	+	\| Watch it \| `GET`, `PUT` or `DELETE /workspaces/{workspace}/work/{number}/subscription` \|
171	+	\| Its work context \| `GET /workspaces/{workspace}/work/{number}/work` \|
172	+	\| Claim, release, hand off \| `POST /workspaces/{workspace}/work/{number}/claim`, `…/release`, `…/handoff` \|
173	+	\| Bring work items in from a tracker \| `POST /workspaces/{workspace}/work/import` \|
174	+	\| A repository's work items \| `GET /repos/{owner}/{name}/work` \|
175	+	\| What `#N` names \| `GET /repos/{owner}/{name}/refs/{number}`, or `GET /workspaces/{workspace}/refs/{number}` \|
176	+	\| The workspace's labels and milestones \| `/workspaces/{workspace}/labels`, `/workspaces/{workspace}/milestones` \|
177	+
178	+	```sh
179	+	curl -X POST https://api.g1t.sh/workspaces/acme/work \
180	+	-H "Authorization: Bearer $G1T_TOKEN" \
181	+	-H "Content-Type: application/json" \
182	+	-d '{"title": "Sign-in times out", "repo": "acme/web", "targets": ["acme/web", "acme/api"]}'
183	+	```
184	+
185	+	A work item has `workspace`, `number`, `title`, `body`, `state`, `reason`,
186	+	`labels`, `milestone`, `assignees`, `blocked_by`, `repos` (each with
187	+	`path`, `role`, `landed` and, for one that was an issue, its
188	+	`legacy_number`) and `resolutions` (each with `repo` and the `pull` or
189	+	`commit` that landed it). Reading work items needs a token with
190	+	`work:read`, and changing them `work:write`.
191	+
192	+	## The Claude Code plugin
193	+
194	+	The [Claude Code plugin](/guides/claude-code-plugin/) does the
195	+	bookkeeping for Claude Code, so Claude works on work items the way this
196	+	page describes without being told each time:
197	+
198	+	- At the start of a session, in a working copy of a g1t repository,
199	+	it finds the work item: the one the session claimed before, `G1T_ITEM`,
200	+	or one named by the branch (`42-fix-login`, `item-42`, `fix/42`). It
201	+	gives Claude that work item's context (`g1t work view`) and tells it to
202	+	claim it. With none, it tells Claude to just work, and to claim or file
203	+	a work item only once the work becomes a change.
204	+	- It records the session: its prompts, its tool calls (never what
205	+	they returned), the files, commits and branches it touched, and each
206	+	subagent as a session of its own.
207	+	- It ties the session to the work item Claude claims, starts a pull
208	+	request for, or attaches to, and gives Claude `G1T_SESSION` for the
209	+	commit trailer. It never claims anything itself.
210	+	- It shows coordination updates before Claude's tools and prompts,
211	+	until they are acknowledged.
212	+	- It adds g1t's MCP server, the skills below, and the `/g1t:claim`,
213	+	`/g1t:handoff` and `/g1t:status` commands.
214	+
215	+	The plugin's hooks need the g1t CLI 0.4.0 or later.
216	+
217	+	### The work-on-item skill
218	+
219	+	`/g1t:work-on-item 12` (or asking Claude to work on a work item) takes it
220	+	from start to merge:
221	+
222	+	1. Read the work item: `g1t work view 12`.
223	+	2. Check who else is on it and what it waits on, carry on an existing pull
224	+	request rather than start another, and link a target the work needs.
225	+	3. Claim it, with a note on its scope, the interfaces it touches, what it
226	+	depends on and the checks it will run.
227	+	4. Make a branch named after it, `12-…`.
228	+	5. Open a draft pull request early: `g1t pr create --item 12 --draft --fill`.
229	+	6. Commit with the `G1t-Session` trailer, and push often.
230	+	7. Watch the checks (`g1t pr checks --watch`), and read a failure's logs.
231	+	8. Mark it ready with a summary, and merge. A pull request that does only
232	+	part of the work says `Part of #12`; the last says `Closes #12`.
233	+	9. Hand it off with a note if it stops before the work is done.
234	+
235	+	Work that has no work item yet starts by looking for one, then
236	+	`g1t work claim --title`. Alongside it, the coordinate skill keeps a
237	+	long session in step with others, and fix-integration fixes a pull
238	+	request the merge queue found failing together with others. Sessions g1t
239	+	starts on your Anthropic account use the same skills.
240	+
241	+	## Hand a work item to g1t
242	+
243	+	You can also hand a work item to a session g1t starts for you, on the
244	+	workspace's own Anthropic account: Start a session on its page,
245	+	Assign to g1t, `@g1t` in a comment, or `g1t work dispatch 12`. See
246	+	[start a session on your Anthropic account](/guides/sessions/#start-a-session-on-your-anthropic-account)
247	+	and [assign g1t, or ask it in the thread](/guides/sessions/#assign-g1t-or-ask-it-in-the-thread).

1	+	---
2	+	title: The Board
3	+	description: The workspace's backlog as it moves, in five stages from Backlog to Done. Each work item's stage follows from what is true of it, its claims, sessions, pull requests and landings, so there is nothing to drag.
4	+	---
5	+
6	+	Board, in Work's sidebar, at `g1t.sh/<workspace>/-/work/board`, is
7	+	the backlog as it moves. Its columns are stages, and a work item's stage
8	+	comes from what is true of it: who is on it, its pull requests, where it
9	+	has landed. There is nothing to drag. Do the work, and the card moves.
10	+
11	+	## The stages
12	+
13	+	\| Stage \| Holds the work items \|
14	+	\| --- \| --- \|
15	+	\| Backlog \| Open, and nobody is on it. \|
16	+	\| In progress \| Claimed or assigned, with a live session on it, or with a draft pull request. \|
17	+	\| In review \| With a pull request open for review. \|
18	+	\| Landing \| Landed in some of its target repositories, still missing in others. \|
19	+	\| Done \| Closed in the last 14 days. \|
20	+
21	+	A work item is in the first stage that holds for it, in the order
22	+	Done, Landing, In review, In progress, Backlog. So a
23	+	work item with one pull request in review and another still a draft is
24	+	In review, and one that has landed in one of its two targets is
25	+	Landing whatever else is going on. A work item closed more than 14
26	+	days ago leaves the Board; the Work list's Closed still has it.
27	+
28	+	## How a work item moves
29	+
30	+	A typical work item goes left to right as the work happens:
31	+
32	+	1. Backlog. Someone files it. Nobody has claimed it, it has no
33	+	assignee, no session is on it and it has no pull request.
34	+	2. In progress. Someone [claims it](/work/claims-and-dependencies/#claims)
35	+	(`g1t work claim 12`), it is assigned, a [session](/work/sessions/)
36	+	starts on it, or a draft pull request is opened for it
37	+	(`g1t pr create --item 12` opens a draft). A pull request a live session
38	+	is on counts too.
39	+	3. In review. Its pull request is marked ready for review.
40	+	4. Landing. For a work item with several targets: its pull request
41	+	merged in one repository and the others are still to land. A work item
42	+	with no target, or one, skips this stage: it closes as soon as it lands.
43	+	5. Done. It closed: every target landed, or someone closed it. See
44	+	[closing work items](/work/closing/).
45	+
46	+	It moves back as well: a claim released or expired with nobody else on it
47	+	and no pull request sends it back to Backlog, and reopening a work item
48	+	clears where it landed, so it goes back to whatever stage its pull
49	+	requests and claims put it in.
50	+
51	+	## Reading the Board
52	+
53	+	Each column lists its work items most recently changed first, and Done
54	+	most recently closed first. Each card shows the work item's title, number
55	+	and repositories, and who is on it: up to three people (its assignees,
56	+	whoever claimed it, whoever runs a session on it), up to two of its live
57	+	sessions, then "+2" for the rest. Choose a card to open the work item.
58	+
59	+	The Board follows the work as it happens, without reloading, and checks
60	+	again every 30 seconds while a session is live, since a session going idle
61	+	sends no event.
62	+
63	+	- One repository's: filter it with `?repo=<name>`. Board on the
64	+	Work list filtered to a repository keeps the filter.
65	+	- On a phone the Board shows one stage at a time, with a button for
66	+	each and how many it holds; the address keeps it as `?stage=landing`.
67	+	- In the phone app, Board at the top of Work shows the stages one
68	+	under another, with a chip for each to show one alone.
69	+
70	+	New work item is on the Board too.

874	874		\| `packages:read` \| Pull container images and install private [packages](/guides/packages/). Public ones need no scope. \|
875	875		\| `packages:write` \| Push container images and publish packages; with the Admin role on a package, change its settings \|
876	876		\| `packages:delete` \| Delete and restore packages and their versions \|
877		−	\| `work:read` \| Read [work items](/guides/work-items/) and their comments, and the workspace's [labels](/guides/labels/) and [milestones](/guides/milestones/) \|
	877	+	\| `work:read` \| Read [work items](/work/work-items/) and their comments, and the workspace's [labels](/work/labels/) and [milestones](/work/milestones/) \|
878	878		\| `work:write` \| Open, edit, link, claim, close, comment on and react to work items; manage labels and milestones \|
879	879		\| `pull_requests:read` \| Read pull requests, their changes, sessions and merge queues \|
880	880		\| `pull_requests:write` \| Open, review, comment on, close and merge pull requests \|

709	709		\| --- \| --- \|
710	710		\| Home \| Where you're needed across the workspace, and what happened while you were away. See [Home](/guides/home/). \|
711	711		\| Explore \| g1t beyond your workspaces: public projects, people and other workspaces. \|
712		−	\| Work \| The workspace's work items, their [Board](/guides/work-items/#the-board), and its labels and milestones, at `g1t.sh/<workspace>/-/work`; and its Sessions, what is cooking across the workspace (the sessions live now in every repository you can read, the merge queues, what just landed and what happened), at `g1t.sh/<workspace>/-/work/sessions`. Every member has it, with Code access or not. See [work items](/guides/work-items/) and [the Sessions page](/guides/sessions/#the-sessions-page). \|
	712	+	\| Work \| The workspace's work items, their [Board](/work/board/), and its labels and milestones, at `g1t.sh/<workspace>/-/work`; and its Sessions, what is cooking across the workspace (the sessions live now in every repository you can read, the merge queues, what just landed and what happened), at `g1t.sh/<workspace>/-/work/sessions`. Every member has it, with Code access or not. See [work items](/work/work-items/) and [the Sessions page](/work/sessions/). \|
713	713		\| Chat \| Channels and messages. See [Chat](/guides/chat/). \|
714	714		\| Code \| Projects, pull requests and checks. Not shown to a member without Code access. \|
715	715		\| Artifacts \| Documents, decks and pages. See [artifacts](/guides/artifacts/). \|
⋯
913	913		you are in.
914	914
915	915		Review N that need you jumps to the list, and New work item opens
916		−	a new [work item](/guides/work-items/) of the workspace, filed in the
	916	+	a new [work item](/work/work-items/) of the workspace, filed in the
917	917		project you pick.
918	918
919	919		\| Tab \| What it lists \|

22	22		\| Access token \| `g1t_…`, personal or a workspace's, with scopes \| The API, MCP, git, the CLI \| `user_for_access_token` \|
23	23		\| OAuth access token \| Issued by `POST /oauth/token`, refreshed with `g1r_…` \| MCP clients, the phone app, apps you authorise \| `user_for_access_token` \|
24	24		\| Job token \| `G1T_TOKEN` in a workflow job \| Actions, for that job alone \| `user_for_access_token` \|
25		−	\| Run credential \| Made per sandbox run, up to 6 hours, or per [session](/guides/sessions/) g1t starts on Claude Managed Agents, up to 12 \| Sandboxes; a session's agent, for the API, MCP, git and the CLI \| `user_for_access_token` \|
	25	+	\| Run credential \| Made per sandbox run, up to 6 hours, or per [session](/guides/sessions/#start-a-session-on-your-anthropic-account) g1t starts on Claude Managed Agents, up to 12 \| Sandboxes; a session's agent, for the API, MCP, git and the CLI \| `user_for_access_token` \|
26	26		\| git password \| Your account's password \| git, only without two-factor authentication \| `user_for_git_credentials` \|
27	27
28	28		The CLI signs in with the device flow of RFC 8628 (`/device/code`, then
⋯
67	67		\| Repository \| Read, Triage, Write, Maintain and Admin, given to a person, a team, or everyone in the workspace as its base permission \|
68	68		\| Outside collaborators \| A repository role for someone who is not a member \|
69	69
70		−	A [work item](/guides/work-items/) belongs to the workspace, so it has no
	70	+	A [work item](/work/work-items/) belongs to the workspace, so it has no
71	71		repository role of its own. `item_role` gives the viewer the higher of
72	72		their role through workspace membership and their permission on the work
73	73		item's origin repository, if it has one. `can_item` and `check_item` judge

15	15		## Work items and pull requests
16	16
17	17		A work item belongs to a workspace, not to a repository
18		−	([Work items](/guides/work-items/)). `work_items` holds them, numbered per
	18	+	([Work items](/work/work-items/)). `work_items` holds them, numbered per
19	19		workspace, with no repository of their own. `work_item_repos` links each
20	20		to any number of the workspace's repositories, one row per repository, in
21	21		a role:
⋯
76	76		as `work.migrated`, for the other services to rewrite what they keep. Old
77	77		`/<owner>/<repo>/issues/<n>` links and `#N` references resolve through
78	78		`legacy_number` ([Issues became work
79		−	items](/about/issues-became-work-items/)).
	79	+	items](/work/from-issues/)).
80	80
81	81		## Coordination
82	82
⋯
117	117		is blocked by and blocks, its decision records, and its latest
118	118		coordination events. A session's entries on a pull request are what
119	119		Blame reads to show the agent's account of a line ([Sessions and
120		−	why-blame](/guides/why-blame/)). [Sessions, claims and
121		−	dependencies](/guides/sessions/) has the calls.
	120	+	why-blame](/guides/why-blame/)). [Claims and
	121	+	dependencies](/work/claims-and-dependencies/) has the calls.
122	122
123	123		## Checks and statuses
124	124

39	39		your minutes, just because you copied it.
40	40		- Work items filed in it. A fork usually exists to change code and
41	41		propose it back; the conversation stays on the parent's
42		−	[work items](/guides/work-items/). Turn them on in the
	42	+	[work items](/work/work-items/). Turn them on in the
43	43		fork's settings if it becomes a project of its own.
44	44
45	45		Deployments stay off until the fork's own project is set up.

37	37		A work item says what should change. People open them, coding agents open
38	38		them, and so can anything with an access token, such as an error tracker
39	39		reporting a crash. They are under Work, after Home and
40		−	Explore in the left rail; see [work items](/guides/work-items/).
	40	+	Explore in the left rail; see [work items](/work/work-items/).
41	41
42	42		A work item has:
43	43
⋯
60	60		A workspace starts with a set of labels such as `bug`, `enhancement` and
61	61		`question`, shared by all its repositories; anyone with the Triage role
62	62		can make more as they label. A work item or pull request carries up to 20.
63		−	See [labels](/guides/labels/).
	63	+	See [labels](/work/labels/).
64	64
65	65		## Pull requests
66	66
⋯
224	224		on the work item, and in Work's Sessions
225	225		(`g1t.sh/<workspace>/-/work/sessions`), which shows who is working on
226	226		what right now across its repositories. See
227		−	[sessions, claims and dependencies](/guides/sessions/).
	227	+	[sessions](/work/sessions/) and [claims and dependencies](/work/claims-and-dependencies/).
228	228
229	229		Each entry is tied to the commit that was the head when it was recorded,
230	230		so Blame on any file can show not only the commit that last changed a

112	112
113	113		### Work items
114	114
115		−	[Work items](/guides/work-items/) belong to the workspace, not to one
	115	+	[Work items](/work/work-items/) belong to the workspace, not to one
116	116		repository, and so do its labels and milestones.
117	117
118	118		- The workspace's members see every work item.

158	158		Nothing starts until you choose on the card:
159	159
160	160		- Start session runs it on your workspace's Anthropic account as a
161		−	[Claude Managed Agents session](/guides/sessions/), with g1t's tools and
	161	+	[Claude Managed Agents session](/guides/sessions/#start-a-session-on-your-anthropic-account), with g1t's tools and
162	162		skills beside your own. It shows when an owner has connected Anthropic.
163	163		- Copy Claude Code command copies a `claude` command that runs it on
164	164		your computer with the [g1t plugin](/guides/claude-code-plugin/), with
165	165		your own skills, settings and subagents.
166	166
167	167		Either way the session is tied to the work item: it shows on the work
168		−	item, on the workspace's [Sessions](/guides/sessions/#the-sessions-page)
	168	+	item, on the workspace's [Sessions](/work/sessions/)
169	169		and on its own session page, with
170	170		its subagents, and Ask can tell you where it stands. If a session already
171	171		holds the work item, Ask

44	44		\| Required checks, approvals, being up to date \| As the rules covering it ask \| As the rules covering it ask; nothing when none cover it \|
45	45		\| [Merge queue](/guides/merge-queue/) \| Joins it, when a rule requires it \| Never; it merges directly \|
46	46		\| Catching up \| Merges the default branch in \| Merges its base in \|
47		−	\| Its [work item](/guides/work-items/) \| Records the repository as landed when it merges, and closes once every target has \| Nothing lands; it stays open \|
	47	+	\| Its [work item](/work/work-items/) \| Records the repository as landed when it merges, and closes once every target has \| Nothing lands; it stays open \|
48	48
49	49		Merging still needs the Write role. Under Settings → Rules, **What holds
50	50		for a branch** shows every rule that covers a branch.

16	16		\| Push code \| git over HTTPS, signed in with `g1t auth setup-git` or an [access token](/guides/authentication/#access-tokens) \|
17	17		\| Start the agent when something happens \| [Webhooks](/guides/webhooks/), or a [workflow](/guides/actions/) on `work_item` or `work_item_comment` \|
18	18		\| Show people how a change was made \| The pull request's [session](/guides/why-blame/#sessions) \|
19		−	\| See who is working on what, and not collide \| [Sessions, claims and dependencies](/guides/sessions/) \|
	19	+	\| See who is working on what, and not collide \| [Claims and dependencies](/work/claims-and-dependencies/) \|
20	20		\| Script anything else \| The [REST API](/reference/api/), which has the same operations as the tools \|
21	21
22	22		The agent runs where you run it: on your machine, in your CI, or on a
⋯
129	129		anyway (`session` with `start`), with a `title` saying what it is for: the
130	130		team sees it in Live now on the project's overview, under its pull
131	131		request or branch, and on the workspace's
132		−	[Sessions](/guides/sessions/#the-sessions-page). When the work becomes a change others
	132	+	[Sessions](/work/sessions/). When the work becomes a change others
133	133		should know about (a branch to push, a pull request), look for its work
134	134		item (`work_item` with `list` or `list_claims`) and claim it. If there is
135	135		none, `work_item` with `claim`, a `title` and no `number` opens one, with
⋯
215	215		put secrets in a session: g1t takes out what looks like a credential, and
216	216		shows what a session recorded only to the workspace's members (a prompt
217	217		only to whoever typed it), but that is a safety net. See
218		−	[Who sees what](/guides/sessions/#who-sees-what).
	218	+	[Who sees what](/work/sessions/#who-sees-what).
219	219
220	220		### Recording sessions automatically
221	221

121	121		into the default branch closes the work item. The trailer ties each commit,
122	122		and the pull request it lands in, to the session; the pull request's
123	123		Session tab shows how it was made. See
124		−	[Sessions, claims and dependencies](/guides/sessions/).
	124	+	[Sessions](/work/sessions/).
125	125
126	126		With no workflows in `.g1t/workflows` there are no checks to wait for.
127	127		To have the agent add CI, ask for it; pushing a workflow file needs the

512	512		\| `reviewers` \| Usernames whose review is asked for when the pull request opens. A team (`org/team`) is skipped. Also applies to security updates. \| \|
513	513		\| `registries` \| The [registries](#private-registries) the entry uses: a list of names, or `"*"` for all of them. \| \|
514	514		\| `target-branch` \| The branch updates start from and merge into. Its manifests are read, each update is made from it, and its pull request's [base](/guides/base-branches/) is that branch. The default branch's protection does not cover it. \| The default branch \|
515		−	\| `labels` \| The [labels](/guides/labels/) put on each pull request. A label the repository lacks is created. `labels: []` puts none on. \| `dependencies` and the ecosystem's label \|
516		−	\| `milestone` \| The number of a [milestone](/guides/milestones/) to put each pull request in. A number the repository has no milestone for is skipped. \| \|
	515	+	\| `labels` \| The [labels](/work/labels/) put on each pull request. A label the repository lacks is created. `labels: []` puts none on. \| `dependencies` and the ecosystem's label \|
	516	+	\| `milestone` \| The number of a [milestone](/work/milestones/) to put each pull request in. A number the repository has no milestone for is skipped. \| \|
517	517		\| `vendor` \| Read. Vendored copies of dependencies are not updated. \| `false` \|
518	518		\| `insecure-external-code-execution` \| Read. g1t never runs a manifest's code while updating it. \| \|
519	519		\| `name` \| A name for the entry, 3 to 100 characters, shown in the footer of its pull requests. \| \|

327	327		- It lands the work items its commits name. A commit pushed to the
328	328		default branch whose message says `Fixes #12`, `Closes #12` or another
329	329		closing keyword marks this repository as landed on that
330		−	[work item](/guides/work-items/), and the work item records which commit
	330	+	[work item](/work/work-items/), and the work item records which commit
331	331		landed it and who pushed it. The work item closes as completed once every
332	332		repository it targets has landed, or at once when it has no target.
333	333		`Part of #12` links the commit without landing anything. Up to 250
⋯
344	344		A repository whose Land work items with merged linked pull requests
345	345		setting is off lands no work items either way. In a commit message on g1t,
346	346		`#12` links to that work item or pull request; see
347		−	[one number for the workspace](/guides/work-items/#one-number-for-the-workspace).
	347	+	[one number for the workspace](/work/work-items/#one-number-for-the-workspace).
348	348
349	349		## Limits
350	350

83	83		GitHub account, and import from the accounts an owner connected.
84	84		4. Tick the repositories to bring across. You see only repositories that
85	85		both you and the app can reach.
86		−	5. Choose whether to copy their issues, as [work items](/guides/work-items/).
	86	+	5. Choose whether to copy their issues, as [work items](/work/work-items/).
87	87		6. Choose Bring to g1t.
88	88
89	89		Each repository becomes a repository on g1t with the same name, private if

323	323		\| Commits are pushed to a project's default branch, or a tag is pushed \| The workspace's projects (the first 25) \|
324	324		\| A pull request is opened, reviewed, merged or closed, a comment changes, or a work item linked to one of them changes \| The same projects \|
325	325		\| A workflow run or a job in it starts or finishes, a build or deployment moves, or a release or package is published \| The same projects \|
326		−	\| A [session](/guides/sessions/) starts or ends \| The same projects \|
	326	+	\| A [session](/work/sessions/) starts or ends \| The same projects \|
327	327		\| Something comes to need you, or you deal with it elsewhere \| Your notifications \|
328	328
329	329		A busy workspace sends changes all the time, so Home refreshes a second

92	92
93	93		## Alerts
94	94
95		−	An alert source opens [work items](/guides/work-items/) filed in one
	95	+	An alert source opens [work items](/work/work-items/) filed in one
96	96		repository, their origin. Each problem it reports is one work item:
97	97
98	98		- The first alert opens a work item labelled `bug` (or the label you set)

194	194
195	195		### Work items
196	196
197		−	On Settings → Repository, under Features. [Work items](/guides/work-items/)
	197	+	On Settings → Repository, under Features. [Work items](/work/work-items/)
198	198		belong to the workspace; these settings say how this repository takes part.
199	199
200	200		\| Setting \| Field \| Default \| What it does \|
⋯
347	347
348	348		Everything stays with the repository: its git data, pull requests,
349	349		workflow runs, deployments, settings, secrets and webhooks, and the
350		−	[work items](/guides/work-items/) linked to it stay linked. Its old address
	350	+	[work items](/work/work-items/) linked to it stay linked. Its old address
351	351		keeps working, the same way as after a
352	352		[transfer](/guides/transferring-repositories/#old-addresses):
353	353

268	268		4. A [decision record](/guides/why-blame/#decision-records) of kind
269	269		`integration_failure`, confidence `tested`, keeps it, with the
270	270		combination, the check, the suspects, `bisected` and `landed` as
271		−	evidence. [`get_work`](/guides/sessions/)'s `last_integration_failure`
	271	+	evidence. [`get_work`](/work/agents/#pick-up-a-work-item)'s `last_integration_failure`
272	272		is the latest of these.
273	273		5. The `integration.failed` [event](/guides/webhooks/#events) carries the
274	274		same to webhooks and to anyone following the repository's events:
⋯
287	287		one that answers for it marked, the check that failed (linked to its run),
288	288		what it fails with, and the fix once one is recorded. Its work item shows the
289	289		same under its pull requests, and the workspace's
290		−	[Sessions](/guides/sessions/#the-sessions-page) lists it under **What
	290	+	[Sessions](/work/sessions/) lists it under **What
291	291		happened**.
292	292
293	293		### Getting back in the queue

19	19
20	20		Notifications hold one thread for each thing you were told about:
21	21
22		−	- a [work item](/guides/work-items/)
	22	+	- a [work item](/work/work-items/)
23	23		- a pull request
24	24		- a workflow on one branch
25	25		- a deployment: a project's production, or one pull request's preview

129	129		- A work item is shown to the members of its workspace, and to anyone who
130	130		can read the repository it was filed in (its origin). One filed in a
131	131		public repository is shown to everyone; one with no origin only to
132		−	members. See [who sees a work item](/guides/work-items/#who-sees-a-work-item).
	132	+	members. See [who sees a work item](/work/work-items/#who-sees-a-work-item).
133	133		- People and workspaces are public, as their pages are. Search never shows
134	134		which workspaces someone belongs to.
135	135

78	78
79	79		\| \| \|
80	80		\| --- \| --- \|
81		−	\| Work items \| [Work items](/guides/work-items/) belong to the workspace, so they stay in the old one, with their numbers. \|
	81	+	\| Work items \| [Work items](/work/work-items/) belong to the workspace, so they stay in the old one, with their numbers. \|
82	82		\| Labels and milestones \| They are the workspace's, and stay with it. \|
83	83		\| Workspace secrets and variables \| The old workspace's stop reaching the repository; the new workspace's start, if they reach every repository or name this one. \|
84	84		\| Workspace webhooks \| The old workspace's stop hearing about the repository; the new one's start. \|

11	11
12	12		A pull request's session records how the change was made, entry by entry,
13	13		as it happens. Entries come from `record_session` on the pull request, and
14		−	from any [harness session](/guides/sessions/#sessions) attached to it:
	14	+	from any [harness session](/guides/sessions/#record-a-session) attached to it:
15	15
16	16		\| Kind \| What it holds \|
17	17		\| --- \| --- \|
⋯
31	31		Outside the workspace only g1t's notes show there, and members see a
32	32		prompt or a tool's output only when it is their own; what looks like a
33	33		credential is taken out of all of it
34		−	([Who sees what](/guides/sessions/#who-sees-what)). Still, do not put
	34	+	([Who sees what](/work/sessions/#who-sees-what)). Still, do not put
35	35		secrets in one.
36	36
37	37		### Recording a session

flagon-io/g1t

Docs: Work has a section of its own

Comments

97	97		g1t work new --title "Greeting should name the caller" --body "Take a name from the first argument."
98	98		```
99	99
100		−	A [work item](/guides/work-items/) belongs to the workspace; opened
	100	+	A [work item](/work/work-items/) belongs to the workspace; opened
101	101		from the repository, it has the repository as its origin.
102	102
103	103		Say what is wrong or wanted, and what done means if you know it. Your