Source control for coding agents
Two prompts to copy
Paste one into your coding agent from your repo's root. Both report first and change nothing shared without your yes. The first sticks to what Anthropic's post says; the second is our recommendation for plain git.
Replicate Anthropic's approach (from the post only)
What this does: Your coding agent audits your repo, CI and agent setup against Anthropic's post, quoting the post for every finding, and changes nothing until you approve.
# Replicate Anthropic's approach (from the post only) From the Ask It Something Hard explainer. Not produced or endorsed by Anthropic. Source: https://www.anthropic.com/engineering/redesigning-source-control Audit this repo, its CI and its agent setup against that post, your only source: back each recommendation with a verbatim quote; recommend nothing it does not describe. If you cannot read its full text (no web access, or a summarized fetch), ask me to paste it. Never quote from memory. ## Know the limits - Scion is unreleased and "by no means a suitable replacement for git for general use"; it suits "truly enormous monorepos". - "Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend." Weigh cost before proposing anything agent-heavy. - "we don't expect our solution, or our considerations, to suit every case", though these problems may become "more commonplace over the next six to 12 months". - Its git-side ideas (server-side RPCs) are for forges: list them as asks for your host. - The post gives no git commands. Label every command you use "implementation choice, not from the post". ## Rules - Before approval, only commit the report to a new local branch. - Do not push, open a PR or trigger CI unless asked. Never force-push, rewrite history, delete refs or objects, or run gc or prune. - Ask before touching anything shared: CI, runners, mirrors, caches, forge settings, branch protection, git config, hooks. - Measure from existing logs; run no new clones. Mark gaps "unknown". Keep credentials and private URLs out of the report. ## Steps 1. **Scale.** After `git fetch`, count merges per day (`git rev-list --count --first-parent --since="30 days ago" origin/<default-branch>` over 30; unreliable if shallow), repo size (`git count-objects -vH`), and CI and agent checkouts per day. The post: "over 30,000" merges a day, history "almost 100 GB", "25 million code checkouts per day for CI". For most repos git "is the right design"; "not needed at this scale" is a good verdict. 2. **"Clients are always online."** List jobs fetching full history and which truly need it. 3. **Ask instead of cloning.** "in many cases jobs don't need a local repository at all." Find jobs cloning only to learn "who last changed a line or how two commits are related"; note what your host's API answers. 4. **Git's slice tools, the stopgap the post outgrew.** Shallow clones, sparse checkouts, promisor remotes, mirrors and seeds "bought us time", but seeds "fell further from the tip of main" and diff and blame on partial clones took "more and more care". Carry that caveat. 5. **Caches.** Git mirrors or object caches only. Its mirrors "no longer scaled"; it tiers caches "to isolate failure domains". Report only. 6. **Refs.** "The development lifecycle in Scion discourages refs", a concern of Scion's distributed server. Count `git ls-remote --heads --tags origin | wc -l`; report stale branches only. 7. **Merge queue.** "We haven't been able to effectively replicate the industry standard of a global repository lock on the merge queue", so it "invested in post-merge and pre-deploy automated testing", because "Claude can typically fix these conflicts faster than humans can even identify them". It still runs a merge queue. Never propose removing required checks, branch protection or the queue. 8. **Telling agents "no".** In CLAUDE.md, AGENTS.md, .cursor/rules and git or CI scripts, look for finding when a change merged "by linearly reading the commit log instead of asking" the review tool, and over-engineering "in response to hypothetical concerns". 9. **Review intent.** "Our team members still review every change request for the system, but they now examine the intent of the change". Never propose reducing human review. Check CODEOWNERS and review rules. 10. **Superfans and defences.** Claudes watching "telemetry and logs", plus "fuzzing": say where they would help and at what cost; set none up. ## Deliverable 1. `SOURCE-CONTROL-AUDIT.md`, about a page: step 1 numbers, then a numbered table of step / quote / verdict (applies, done, not needed) / proposed change / risk. Weakening a safeguard is high risk. 2. Stop. I reply with the row numbers to apply. If you cannot ask me, stop here. 3. Make only approved low-risk changes (scripts, docs, agent instructions), one commit each citing its principle; list shared changes awaiting approval. Nothing merges until I review.
Our recommendation: scale your repo for coding agents on plain git
What this does: Your coding agent measures where git slows your agents and CI, then proposes a plain-git version of the post's ideas, each tagged as the post's or ours, and asks before anything shared.
# Scale this repo for coding agents, on plain git Adapt Anthropic's post "Redesigning source control at Anthropic" (https://www.anthropic.com/engineering/redesigning-source-control) to this repo, its agents and CI. Anthropic replaced git with Scion, which the post says "is by no means a suitable replacement for git for general use"; we stay on git. Tags: [POST] (the post says it), [OURS] (our adaptation; never present it as Anthropic's practice). (From the Ask It Something Hard explainer. Not produced or endorsed by Anthropic.) ## Rules - Work in your own worktree: `git fetch origin`, then `git worktree add --no-track -b source-control-audit ../source-control-audit origin/main`. "main" means the default branch (`git symbolic-ref --short refs/remotes/origin/HEAD`). - Measure read-only; create no tokens; redact credentials. - Ask me before anything destructive (deleting branches, worktrees, caches; gc, prune) or shared: CI, branch protection, merge settings, mirrors, servers, deploys, remotes, git config outside this repo, scheduled jobs. CI files and CODEOWNERS count as shared: propose them as diffs. - Never force-push, rewrite history or push. Stage only files you created. - Commands below are proposals; experiment only in a scratch directory. ## Steps 1. **Measure** [OURS]. Mark numbers measured, estimated or unknown. Merges per day: `git rev-list --count --first-parent --since="30 days ago" origin/main` ÷ 30 (under rebase-merge, count merged PRs on the host instead). From CI config and logs: checkouts per day, time and GB spent fetching. Repo size. Agents per machine. **Then stop, report and wait for my go-ahead.** Rough guide (ours): under ~50 merges/day, fetching under ~10% of job time and a few agents means steps 2 and 8 only. 2. **One store, a worktree per agent** [OURS, echoing Scion's per-machine daemon]. Script `git worktree add --no-track -b <agent> ../wt/<agent> origin/main` on one shared clone; one process fetches and runs gc (set `gc.auto=0`). Cleanup: once landed (PR merged, or `git merge-base --is-ancestor <agent> origin/main`), `git worktree remove`, `git branch -d`. If `-d` refuses (squash merges), list the branch for me. Never `-D`. 3. **Fetch less, as a stopgap** [OURS, with git features the post names]. Build-only jobs: `git clone --depth=1`. Jobs reading a few folders: `git clone --filter=blob:none --sparse <url> <dir>`, then in `<dir>`: `git sparse-checkout set <dir1> <dir2>`. The post's caveat: keeping diff and blame working on partial clones "took more and more care". 4. **Ask, don't clone** [POST: jobs query an API, often with no local repo; OURS: how on git]. For jobs cloning only to answer questions (blame, merge base, diff), propose the host's API or one warm-clone service. 5. **Cache in tiers** [OURS, adapting Scion's strict tiering]. Only if many machines fetch at real cost. Machine store, regional mirror, origin; each tier fills misses from the one above. Objects never go stale; refs move, so read them from the origin (`git ls-remote origin refs/heads/main`), then `git fetch <mirror> <sha>`. 6. **Drop the global merge lock** [POST: post-merge and pre-deploy tests, agents fix conflicts; OURS: batched landing]. Only if merging is the bottleneck. Land a batch of reviewed changes, then test (merge queues test first). Main can briefly be red, so gate deploys on pre-deploy tests. On failure, in a throwaway worktree (`git worktree add --detach ../wt/bisect <bad>`): `git bisect start --first-parent <bad> <good>`, `git bisect run <test-cmd>`, `git bisect reset`. Revert the culprit, reviewed: `git revert -m 1 <merge-sha>`, or `git revert <sha>` if squashed. 7. **Record `landed_on`** [OURS, from the post's lesson: tools read the commit log instead of asking the review tool]. Store each change's merge or squash commit on main in its record (the host may already), and point tools scanning `git log` at it. 8. **Humans review intent** [POST]. People check a change's intent and stop agents breaking core constraints or over-engineering against hypothetical concerns. Propose approval rules separating comment-only changes from sensitive logic. 9. **Superfans** [POST; OURS: start with one]. Only for a component that failed recently. Write `docs/superfan-<component>.md`: an agent whose only job is its health, reading its telemetry and logs. Grant no access. Keep normal alerts. ## Deliverable 1. `SOURCE-CONTROL-AUDIT.md`, under a page, summarised in your reply: step 1 numbers, each step fits / doesn't fit / needs my decision, with evidence. 2. Scripts and docs committed, one commit per step that changes a file. 3. Shared or destructive changes as exact commands or diffs for my yes.
Credit. The system, the numbers and the ideas are Anthropic's, from their engineering post Redesigning source control at Anthropic (Oct 13 2026). An independent channel, not produced or endorsed by Anthropic.
Made with AI. These prompts were drafted with Claude. Read a prompt before you hand it to an agent: it will change how your repository works.