Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.
| g1t has a plugin for Claude Code, in its own marketplace at the repository's root (claude plugin marketplace add https://g1t.sh/flagon-io/g1t.git, then claude plugin install g1t@g1t). Its hooks record each session on g1t through the g1t CLI in a working copy of a g1t repository: SessionStart starts the session (g1t session start --harness claude_code --harness-session-id, idempotent on Claude's session id) and gives Claude the work context of the issue the session claimed or the branch names (g1t work context N, waited for under a second, else a line saying how to load it), or a line on how to claim one; UserPromptSubmit logs the prompt's first 2,000 characters; PostToolUse logs the tool's name and one line on what it was called with, with anything that looks like a secret hidden, and never what it returned, and after a git push that reached the remote sets the session's head commit; Stop sends a heartbeat and SessionEnd ends the session with Claude's reason. The hooks are one Node script with no dependencies that returns at once and runs the CLI in a detached process; when g1t is missing or signed out it records nothing and says so once, and it installs nothing. G1T_RECORD_PROMPTS=0 keeps prompts back and G1T_RECORD=0 records nothing. The plugin also connects g1t's MCP server, has the skills work-on-issue, fix-integration and coordinate and the commands /g1t:claim, /g1t:status and /g1t:handoff, and plugins/other-harnesses has the AGENTS.md lines that do the same with the CLI for Codex and other agents. node --test plugins/claude-code/test/hooks.test.mjs checks the hooks against a stand-in CLI, and CI runs it. | 1 | --- |
| 2 | name: work-on-issue | |
| 3 | description: Work on a g1t issue from start to merge. Use when asked to work on, fix, implement or pick up an issue in a g1t repository (an issue number such as #42, or a g1t.sh issue link). | |
| 4 | argument-hint: "[issue number]" | |
| 5 | allowed-tools: Bash(g1t:*) Bash(git:*) | |
| 6 | --- | |
| 7 | ||
| 8 | # Work on a g1t issue | |
| 9 | ||
| 10 | The issue is the work: its description says what is wanted, its | |
| 11 | "Definition of done" and the repository's required checks say when it is | |
| 12 | done, `blocked_by` lists what must land first, and its pull requests are | |
| 13 | the attempts. Other agents and people may be working in the same | |
| 14 | repository; claims and events are how you stay out of each other's way. | |
| 15 | Every `g1t` command takes `--json` when you need fields rather than text. | |
| 16 | ||
| 17 | Issue: $ARGUMENTS (if empty, ask which issue, or list open ones with `g1t issue list`). | |
| 18 | ||
| 19 | 1. **Load the context.** Run `g1t work context N`. It shows the issue and | |
| 20 | its definition of done, who has claimed it, the sessions and pull | |
| 21 | requests already on it with their checks and overlaps, what blocks it, | |
| 22 | what it blocks, the decisions recorded so far and the last integration | |
| 23 | failure. Read all of it before you change anything. | |
| 24 | 2. **Check it is free to start.** | |
| 25 | - If it is blocked by issues that are still open, say so and stop | |
| 26 | unless you are asked to go on anyway. | |
| 27 | - If someone else holds an active claim, tell the person who asked you, | |
| 28 | and go on only if they say to. Two claims are allowed; they are a | |
| 29 | warning, not a lock. | |
| 30 | - If a pull request for it is already open, prefer continuing that one | |
| 31 | (`g1t pr checkout NUMBER`) over starting another. | |
| 32 | 3. **Claim it.** `g1t work claim N --note "what you are about to do"`. The | |
| 33 | claim belongs to this session and is renewed while the session is | |
| 34 | active. | |
| 35 | 4. **Branch.** From an up-to-date default branch, make a branch whose name | |
| 36 | starts with the issue number, such as `42-short-description`, so the | |
| 37 | session and the next one know which issue it is for. | |
| 38 | 5. **Open a draft pull request early**, as soon as there is a first commit: | |
| 39 | `g1t pr create --issue N --draft --fill`. Others then see your changes, | |
| 40 | and g1t tells you when they overlap with someone else's. | |
| 41 | 6. **Do the work.** Commit in small steps and push often. Run the same | |
| 42 | tests and linters the repository's workflows run before each push. Log | |
| 43 | a decision worth keeping with `g1t session log --kind note "TEXT"`. | |
| 44 | 7. **Watch the checks.** `g1t pr checks --watch --fail-fast`. When one | |
| 45 | fails, `g1t run logs --failed` says why; fix it and push again. | |
| 46 | 8. **Finish.** When the definition of done is met and the checks pass, | |
| 47 | `g1t pr ready --summary "what changed and why"`, then `g1t pr merge` | |
| 48 | when you are allowed to merge. With the merge queue on, merging adds the | |
| 49 | pull request to the queue; if the queue reports an integration failure, | |
| 50 | use the `fix-integration` skill. | |
| 51 | 9. **Let go.** If you stop before it is done, hand it off rather than | |
| 52 | leaving a claim to expire: `g1t work handoff N --note "where it stands, | |
| 53 | what is left, what to watch out for"`. |
