| 1 | --- |
| 2 | name: coordinate |
| 3 | description: Stay coordinated with other agents and people while working on a g1t issue. Use for longer work on an issue, when several agents work in one repository, or when asked to watch for overlapping changes, dependencies or merge-queue results. |
| 4 | argument-hint: "[issue number]" |
| 5 | allowed-tools: Bash(g1t:*) Bash(git:*) |
| 6 | --- |
| 7 | |
| 8 | # Coordinate on a g1t issue |
| 9 | |
| 10 | g1t tells everyone working in a repository what changes around them, as |
| 11 | events. Follow the ones about your issue while you work, and act on them |
| 12 | as they come rather than finding out at merge time. |
| 13 | |
| 14 | Issue: $ARGUMENTS (if empty, use the issue this session claimed). |
| 15 | |
| 16 | No issue yet? The session is already recorded on g1t and shows to the |
| 17 | team with what it is for, so there is nothing to coordinate until the |
| 18 | work becomes a change others should know about (a branch to push, a pull |
| 19 | request). Then look for its issue first (`g1t work list`, |
| 20 | `g1t issue list`) and claim it with `g1t work claim N`; if there is none, |
| 21 | open and claim one in one step with `g1t work claim --title "…"`, which |
| 22 | attaches this session to it. Never open issues for questions, |
| 23 | exploration or trivial fixes. |
| 24 | |
| 25 | 1. **Follow its events in the background.** Start |
| 26 | `g1t work events --follow --issue N` as a background command, and read |
| 27 | its output between steps. Each line is one event. Add `--json` for one |
| 28 | JSON object per line. |
| 29 | 2. **React to what arrives:** |
| 30 | |
| 31 | | Event | What to do | |
| 32 | | --- | --- | |
| 33 | | `work.claimed` by someone else | Tell the person who asked you. Agree who goes on; hand off if it is not you. | |
| 34 | | `work.handoff_requested` to you | `g1t work context N`, read the note, then claim it. | |
| 35 | | `overlap.detected` | Another open pull request changes the same files. `g1t pr diff OTHER`, then narrow your change or agree an order on the pull requests. | |
| 36 | | `dependency.changed` | Something this issue waits on changed. If `cleared`, the blockers are gone: pull the default branch and go on. If one was added, stop and say so. | |
| 37 | | `integration.failed` naming your pull request | Use the `fix-integration` skill. | |
| 38 | | `integration.passed` | Nothing to do; the change is landing. | |
| 39 | | `session.ended`, `work.claim_expired` | A collaborator stopped. If their work blocks yours, look at what they left with `g1t work context N`. | |
| 40 | |
| 41 | 3. **Keep your own state true.** The session's heartbeat renews your |
| 42 | claim while you work. If you change course, log why with |
| 43 | `g1t session log --kind note "TEXT"`. |
| 44 | 4. **Hand off cleanly.** When you stop before the issue is done: |
| 45 | `g1t work handoff N --note "what is done, what is left, what to watch out for"` |
| 46 | (add `--to LOGIN` for someone in particular). When it is done, the |
| 47 | claim ends with the merge; `g1t work release N` lets go of it earlier. |
| 48 | 5. **Stop following** when you hand off or the pull request merges: stop |
| 49 | the background command. |
| 50 | |
| 51 | `g1t work list` shows every active claim and session in the repository, |
| 52 | for when you need the whole picture. |