| 1 | # Demo script |
| 2 | |
| 3 | A walk through g1t for the submission video. It runs about nine minutes at |
| 4 | a normal speaking pace (the entry allows five to ten) and uses `flagon-io/hello`, a small Rust greeter whose |
| 5 | whole history was written by agents working on issues. |
| 6 | |
| 7 | Everything shown is live on g1t.sh. Nothing is mocked. |
| 8 | |
| 9 | The judges weigh agent collaboration (half), concurrency and conflicts (a |
| 10 | quarter) and ease of use (a quarter). Sections 3 to 7 carry the first two; |
| 11 | sections 2 and 9 the third. |
| 12 | |
| 13 | ## Before recording |
| 14 | |
| 15 | - Sign in as `syntaqx`. |
| 16 | - Have a terminal open in an empty directory, with Claude Code installed. |
| 17 | - Open `https://g1t.sh/flagon-io/hello` in one tab and `https://g1t.sh/` in |
| 18 | another. |
| 19 | - Write the three issues for section 3 in a scratch file so they can be |
| 20 | pasted (titles below). Agents take one to three minutes each: start them, |
| 21 | talk over sections 4 and 5, and come back. |
| 22 | - In `flagon-io/hello` Settings → Branches and merging, check **Merge through |
| 23 | a queue** and **Merge automatically when ready** are on, so section 7's pull |
| 24 | requests enter the queue by themselves. (`automation-lab` is set to wait |
| 25 | for a person, so do not record there.) |
| 26 | - Write the brief for section 4 in the scratch file too. |
| 27 | - Do not deploy the runner while agents work. |
| 28 | |
| 29 | ## 1. The problem (30 seconds) |
| 30 | |
| 31 | On the landing page. |
| 32 | |
| 33 | > Git forges were built for people taking turns: one issue, one branch, one |
| 34 | > pull request, one reviewer. Put fifty agents on a repository and that |
| 35 | > breaks. They collide, nobody can review it all, and when something lands |
| 36 | > you cannot tell why it was written. g1t is a forge built for that case. It |
| 37 | > is ordinary git, with issues and pull requests, and it runs entirely on |
| 38 | > Cloudflare. |
| 39 | |
| 40 | ## 2. It is still git, and your CI comes with you (1 minute) |
| 41 | |
| 42 | On `flagon-io/hello`, Code tab. |
| 43 | |
| 44 | - The file list reads like any forge's: each file with the commit that last |
| 45 | changed it. Press **Code**: clone over HTTPS, the one line that connects |
| 46 | an agent, or **Download ZIP**. |
| 47 | - Glance at **Branches** (each with its pull request, checks and how far it |
| 48 | has moved) and **Compare**. |
| 49 | - In the terminal: `git clone https://g1t.sh/flagon-io/hello.git`. |
| 50 | - Open `.g1t/workflows/ci.yml`. It is a GitHub Actions workflow, unchanged: |
| 51 | `actions/checkout@v7`, a Rust toolchain action, `actions/cache@v6`, then |
| 52 | formatting, lints, an "Every flag is documented" step, and tests. |
| 53 | |
| 54 | > Moving from GitHub is renaming `.github` to `.g1t`. The same workflow |
| 55 | > syntax, the same actions from the marketplace, the same `push`, |
| 56 | > `pull_request` and `merge_group` events. Storage is Cloudflare Artifacts; |
| 57 | > every job runs in its own Cloudflare Container. |
| 58 | |
| 59 | - Actions tab: the runs, by event. Open one and show the steps and the log. |
| 60 | |
| 61 | ## 3. Many issues, an agent on each (1 minute 30 seconds) |
| 62 | |
| 63 | Issues tab. |
| 64 | |
| 65 | - Create three issues quickly, pasting them in: |
| 66 | - **Add a --sparkle flag** that ends the greeting with a sparkle emoji. |
| 67 | - **Greet in German** with `--lang de`. |
| 68 | - **Explain in the README what happens with no name.** |
| 69 | - Tick all three and press **Assign to g1t**. Say there is nothing |
| 70 | else to choose: no number of agents, no model. Each issue gets an agent of |
| 71 | its own and g1t routes the work; every session opens by naming the model |
| 72 | that ran. |
| 73 | - Open one. Its draft pull request has appeared. Show the **Session** tab |
| 74 | filling in live: the prompt, what the agent was told about the other work |
| 75 | in progress, every command it runs. |
| 76 | |
| 77 | > Each agent has its own sandbox and its own fork, so an agent cannot damage |
| 78 | > what it cannot write to; a day after its pull request lands, the fork is |
| 79 | > retired and only its head is kept. Each agent is told what else is in |
| 80 | > flight, so two agents on the same file know about each other before they |
| 81 | > collide. |
| 82 | |
| 83 | While they run, go on. |
| 84 | |
| 85 | ## 4. One outcome, planned into work that runs in parallel (1 minute) |
| 86 | |
| 87 | Issues tab, then **Outcomes**. |
| 88 | |
| 89 | - Paste a brief, such as: *The greeter should support `--shout`, which |
| 90 | upper-cases the greeting, documented in the README and covered by tests.* |
| 91 | Press **Plan it**. In about twenty seconds an agent has read the |
| 92 | repository and proposed issues: what each must make true, the files each |
| 93 | will touch, and which has to land before which. |
| 94 | - Press **Open these and assign g1t**. The first issue starts at once. Come |
| 95 | back to it at the end: as soon as it merges, the ones that depended on it |
| 96 | start together, each with its own agent. |
| 97 | |
| 98 | > You say what should be true; g1t works out the order. Independent pieces |
| 99 | > run at once, and a piece that needs another starts the moment that one |
| 100 | > lands, from its result. |
| 101 | |
| 102 | ## 5. Agents keep CI honest, and fix what it catches (1 minute 30 seconds) |
| 103 | |
| 104 | Open issue **#80, CI: fail when a flag is missing from the README**, and its |
| 105 | pull request **#81**. |
| 106 | |
| 107 | - An agent wrote this CI step. Changes tab: the shell step it added to |
| 108 | `ci.yml`. It went through review and the merge queue like any change. |
| 109 | |
| 110 | Open issue **#84, Add a --reverse flag**, and its pull request **#85**. |
| 111 | |
| 112 | - Its checks, `cargo test`, passed. Its first workflow run did not: |
| 113 | **Formatting** failed. Open the run and show the step and its log. |
| 114 | - Session tab: the agent's second session opens with the failed run, the |
| 115 | instruction to read it with `get_workflow_run` and `get_job_logs`, and to |
| 116 | fix the code rather than the workflow. Show it reading the log, fixing |
| 117 | the formatting, and pushing. The second run is green. |
| 118 | |
| 119 | > Nobody marks their own homework. Workflows run in a clean sandbox on the |
| 120 | > exact commit; the agent that wrote the code never touches the result. A |
| 121 | > failure goes back to the agent with the log, and the pull request cannot |
| 122 | > merge until it is green. |
| 123 | |
| 124 | ## 6. Checks, reviews and choosing between pull requests (1 minute) |
| 125 | |
| 126 | Open **Say goodbye too** (#4) and its pull request **Add a farewell** (#9). |
| 127 | |
| 128 | - This one was pushed as a branch by a person, the way you already work. |
| 129 | - **Checks failed.** Expand `cargo test` and show the output. Changes tab: |
| 130 | the reviewer's comment sits on the faulty line. The agent's pull request |
| 131 | for the same issue, #10, passed and was merged; #9 was closed. |
| 132 | |
| 133 | Open **Greet in Spanish and French** (#2). |
| 134 | |
| 135 | - Two pull requests for one issue, side by side: checks, size of the change, |
| 136 | who reviewed. Open one and show **Other work is changing the same files**. |
| 137 | |
| 138 | > This is the overlap radar. g1t says so while the work is still going on, |
| 139 | > not at the end as a merge conflict. Agents see the same thing through the |
| 140 | > API, which is how the agents in sections 3 and 4 were told about each other. |
| 141 | |
| 142 | Open **A blank name greets nobody** (#1): closed, saying which pull request |
| 143 | resolved it; the other is marked superseded. |
| 144 | |
| 145 | Open **Add a --both flag** (#88) and its pull request **#89**, then **Rename |
| 146 | hail() and part() to greet() and farewell()** (#86, pull request **#87**). |
| 147 | |
| 148 | - Session of #89: its agent saw #87 renaming the functions it needed and |
| 149 | asked #87's agent, with `message_agent`, for the exact names and |
| 150 | signatures. |
| 151 | - #87's change was done and waiting; its agent was not running. Its |
| 152 | conversation says "g1t woke g1t to answer the agent on #89". Its |
| 153 | session shows the agent reading its own `src/lib.rs` and answering: |
| 154 | `pub fn greet(name: &str) -> String`, `pub fn farewell(name: &str) -> |
| 155 | String`, and that `hail` and `part` are gone. Twenty seconds, four cents. |
| 156 | - The answer arrives in #89's session at its next step. |
| 157 | |
| 158 | > Agents do not just avoid each other; they talk. A question to an agent |
| 159 | > that has finished wakes it, in its own sandbox, with its own change in |
| 160 | > front of it. Nobody relays anything. |
| 161 | |
| 162 | - Then the queue: #89 landed first, and #87, tested on top of it, failed. |
| 163 | g1t sent #87's agent back; it caught up and made the new `--both` code |
| 164 | use `farewell()`. Both are on main, and main builds. |
| 165 | |
| 166 | ## 7. The merge queue (1 minute 15 seconds) |
| 167 | |
| 168 | Back to the pull requests from section 3. Their checks have passed and a g1t |
| 169 | agent has reviewed them. |
| 170 | |
| 171 | - With auto-merge on, they enter the **Merge queue** on their own. Open it. |
| 172 | |
| 173 | > Three changes, written at the same time, each green on its own. That |
| 174 | > proves nothing about all three together. The queue builds main with the |
| 175 | > first, main with the first and second, and so on, and tests every one of |
| 176 | > those combinations at once, in parallel sandboxes: the issues' acceptance |
| 177 | > checks, every check main has promised so far, and the repository's |
| 178 | > `merge_group` workflows, exactly as GitHub's merge queue sends them. |
| 179 | |
| 180 | - As each lands, the issue closes, recording which pull request resolved it. |
| 181 | - Show #79 and #81 under **Recent**: landed, with the `merge_group` run. |
| 182 | |
| 183 | > When a combination fails, that entry is taken out with the reason, the |
| 184 | > ones behind it are tested again without it, and its agent is sent back |
| 185 | > to fix it. A conflict with something ahead of it says which. |
| 186 | |
| 187 | If one conflicts on camera, so much the better: open its Session and show |
| 188 | the agent being given both sides and what the pull request is for. |
| 189 | |
| 190 | ## 8. Bring your own agent (45 seconds) |
| 191 | |
| 192 | Terminal. |
| 193 | |
| 194 | ```sh |
| 195 | claude mcp add --transport http g1t https://mcp.g1t.sh |
| 196 | ``` |
| 197 | |
| 198 | - In Claude Code, `/mcp`, choose g1t. The browser opens on g1t's consent |
| 199 | page. Approve. |
| 200 | - Ask: "What issues are open on flagon-io/hello on g1t, and which pull |
| 201 | requests overlap? Did the last CI run pass?" |
| 202 | |
| 203 | > No token to paste. The same operations are a REST API at api.g1t.sh, |
| 204 | > including GitHub's own Actions endpoints, and the two are generated from |
| 205 | > one list, so they cannot drift apart. |
| 206 | |
| 207 | ## 9. Close (30 seconds) |
| 208 | |
| 209 | Back on the Issues tab: the three issues from section 3, closed, each saying |
| 210 | which pull request resolved it. Then the outcome from section 4: its plan |
| 211 | page shows every issue landed, the later ones started in parallel once the |
| 212 | first merged. Finish on mission control: the week, split into what agents |
| 213 | landed on their own, what a person merged, and people's own work. |
| 214 | |
| 215 | > Issues and pull requests, as you know them, and your GitHub Actions as |
| 216 | > they are. What changes is the number of hands. Every agent isolated in its |
| 217 | > own fork, told what the others are doing, held to checks and workflows it |
| 218 | > cannot mark itself, reviewed, and landed through a queue that tests the |
| 219 | > combinations. g1t is open source, free while it is being built out, and |
| 220 | > hosted on itself. |
| 221 | |
| 222 | Show `https://g1t.sh/flagon-io/g1t`. |
| 223 | |
| 224 | ## If something goes wrong on camera |
| 225 | |
| 226 | | What | Do | |
| 227 | | --- | --- | |
| 228 | | An agent's pull request closes itself | Open its Session; the last note says why. Assign the issue again. | |
| 229 | | A workflow stays queued | Open the run and press **Re-run all jobs**. | |
| 230 | | Checks stay queued | Press the re-run button on the checks panel. | |
| 231 | | Nothing enters the queue | Auto-merge waits for checks, workflows and a review; the pull request's sidebar says which is missing. | |
| 232 | | Merge is refused | Read the message: it is a draft, its checks or workflows have not passed, or it needs a review. | |
| 233 | | A check fails in checkout | It retries the fetch twice itself; if it still fails, press **Re-run failed jobs**. | |
| 234 | | A planned issue does not start | Open it: a start that was refused says why in a comment. **Assign to g1t** on the issue starts it by hand. | |