I’m working on a new tool whose tagline is the title of this post: Make best use of git and GitHub for AI-assisted software development. Called Bram (“Bram runs agents mindfully”), the tool runs as a Tauri desktop app with three panes: a terminal where you use Claude Code and/or Codex, an agent pane that embodies a workflow (rendered by XMLUI), and an app pane that hot-reloads the app you are developing. The workflow is pretty standard. Things you are working on show up on the Worklist and pass through three phases: proposed → applied → committed. The arrows between the phases are approval gates where you can dwell and iterate with your agents on what you are planning to build, or what you have built and are testing.
Bram expects you to be working in a git repository that’s hosted on GitHub, and it helps you manage a stream of issues and commits. This matters for at least three reasons.
1. It encourages agents to enact a git/gh-centric workflow that makes otherwise chaotic agent-assisted development feel safe, orderly, and accountable.
2. It helps you think clearly about the work you are doing, and proceed in well-defined chunks and sequences.
3. It makes context durable in GitHub, so prior work (and discussion about work) is available to people and agents as new work intersects with old. For example, agents can use comments on issues as architectural decision records.
This is possible because agents are really good at wielding git and GitHub on your behalf. Not long ago I had to stop and think about something as simple as git pull –rebase. Now I can easily perform feats that I rarely attempted before, like hunk-level staging and unstaging. That sounds abstract but here is the concrete need. When you propose a Worklist item, Bram figures out which files are likely to be involved. As you iterate on the proposal that list may grow or shrink. You can have multiple items in the proposed phase, before any code has been written. A second proposal might yield an overlapping list. In that case, Bram alerts you to a tradeoff. You may want to sequence the two items to avoid a merge conflict. In the Before Time that would always have been my choice, because merge conflicts were nightmares for me. I knew it was possible to untangle overlapping commits but I also knew the mechanics would likely defeat me or, even if I prevailed, would destroy my momentum. Now Bram warns about entanglement and gives me a choice. If I toggle between active work items I know I’ll incur merge cost, but the agents’ mastery of git mechanics makes it a reasonable trade-off.
Challenging git mechanics made easy
I asked Claude Code to review our recent sessions and highlight some of the ways that Bram has guided me to effective uses of git.
1. Hunk-level staging (`git add -p` and friends). Composing a focused commit out of a messy working tree by accepting / rejecting individual hunks. The mechanical cost is real — you sit through every hunk, type y/n/s/e, and if you split wrong you start over. Most developers default to `git add .` and live with sprawling commits. Bram does the patience work on your behalf and lands clean, atomic commits.
2. Squash-by-soft-reset (`git reset –soft HEAD~N && git commit`). Turning two consecutive WIP commits into one clean commit without touching the working tree. The flag combinations are intimidating (`–soft` vs `–mixed` vs `–hard`), and getting it wrong loses work. Most developers reach for `git rebase -i`, which requires an interactive editor and breaks in non-interactive contexts. Bram applies the soft-reset pattern as documented in the project conventions — no editor, no panic.
3. History archaeology (`git log -G ‘<regex>’`, `git show <sha>:<path>`). Finding when a string first appeared or disappeared from the codebase, or reading a deleted file at the revision before it was removed. The flags (`-G`, `-S`, `:<path>` ref-spec) are obscure enough that most developers never learn them and instead grep the working tree and miss the history. Bram uses them as the default first move when investigating a regression — “when did this break” becomes a one-liner instead of a half-hour bisect.
These uses are not gratuitous. In the month since its inception Bram has become the most complex piece of software I’ve ever produced. It would not have been possible without git fluency that I was never able to achieve but can now delegate to agents.
Challenging GitHub mechanics made easy
Bram expects that, in addition to git, you have also installed gh, the command-line interface to GitHub. Here are some of the ways Bram has guided me to effective uses of gh (again, courtesy of Claude Code’s session introspection).
1. `gh api` with `–paginate` and `–jq`. Hand-rolled REST queries against the GitHub API with pagination handled and JSON filtered down to exactly the fields you want — e.g. “all open issues across these five repos with label X, formatted as TSV.” Doing this without `gh` means `curl` + Bearer-token auth + manual `Link:` header parsing for pagination + a separate `jq` invocation, and any one of those steps deters most developers from starting. With `gh api –paginate … –jq …` it’s a single shell line; Bram composes them routinely for cross-issue analytics that would be impractical to do by hand.
2. Filtered listing and search (`gh issue list –search ‘…’`, `gh search code`). GitHub’s search syntax (`is:open label:bug -author:dependabot updated:>2026-05-01`) is powerful but finicky enough that hand-typing it is error-prone. The web UI search box is fine for one-offs but doesn’t compose into a script. Bram drops the right `–search` string in once, pipes through `–json` / `–jq`, and the result feeds the next decision — the kind of “show me everything that matches X, then triage” loop that’s tedious to do by clicking.
3. Multi-line body composition with `–body-file`. Authoring a rich issue or PR body (tables, fenced code blocks, embedded diffs) in markdown, then posting it without losing structure to shell-escape hell. The alternative is the web UI’s textarea, which means leaving your terminal, switching to a browser, retyping context, and losing the ability to compose the body programmatically. Bram writes the body to `/tmp/foo.md`, then `gh issue create –body-file /tmp/foo.md` — bodies stay byte-perfect, and the same pattern composes with templates and generated content.
Fluent use of GitHub issues opens up a rich vein to be mined, and Bram’s guidance to agents encourages them to dig into it. You can see a couple of valuable nuggets in issue 170. In that thread I invited Claude Code and Codex to review one anothers’ work, narrate testing with log evidence, cite related work, record architectural pivots, summarize closure, and point to next steps.
When you externalize parts of session logs to a shared space where people and their agents can collaborate, multiple benefits accrue. For people it provides transparency and accountability. Decisions and tactics aren’t squirreled away in dot file on a per-machine-per-user basis. They are accessible to the whole team both interactively and by means of gh APIs that were formerly daunting but now easily wielded by agents on our behalf.
For agents, GitHub is a place to record context, drawn from current work, that powerfully informs future work — again by way of gh APIs that agents easily wield. The release notes that Claude Code has been writing for Bram are a beautiful example of what is now possible. I always aspired to that kind of discipline but stumbled over mechanics. And that was in the Before Time when release cycles like these might be bi-monthly versus daily occurrences.
Here’s a more complete list of git and gh patterns mined from my session logs.
GitHub for the rest of us
A decade ago, in GitHub for the rest of us, I wrote:
The tools that enable software developers to work and the cultures that surround the use of those tools tend to find their way into the mainstream. It seems obvious, in retrospect, that email and instant messaging — both used by developers before anybody else — would have reached the masses. Those modes of communication were relevant to everyone.
It’s less obvious that Git, the tool invented to coordinate the development of the Linux kernel, and GitHub, the tool-based culture that surrounds it, will be as widely relevant. Most people don’t sling code for a living. But as the work products and processes of every profession are increasingly digitized, many of us will gravitate to tools designed to coordinate our work on shared digital artifacts. That’s why Git and GitHub are finding their way into workflows that produce artifacts other than, or in addition to, code.
I hope Bram will help fulfill that promise, and I think it could. Meanwhile it aims to help make otherwise chaotic agent-assisted coding orderly and accountable for non-coders newly empowered by agents, as well as for coders who want to wield git and GitHub more fluently.
Should you try Bram? Honestly I’m not sure. It’s only a month old, and there are only a handful of testers hammering on it, primarily me (using Bram to bootstrap itself) and Andrew Schulman who is using it to develop a tool for LLM-assisted code analysis. We are only an n of 2, but are both finding that Bram’s git/gh workflow is a powerful way to organize and advance our work. You might want to wait a week or two while we iron out some kinks. But if you do tirekick, please let us know how it goes!
