How do I keep shared code context current after every commit?

Tares keeps shared code context current by watching commits in your repositories and waking an agent that updates your context repository. The agent opens a pull request for review, so every agent starts from the current code. You set it up from the Shared code context project template in a few steps.

How it works

Tares does the data side and runs the agent. The agent reads and writes GitHub through GitHub’s hosted MCP server, using the same token as the sources. The pieces are:

• One commits source per repository. Each source follows one branch, the default branch unless you change it, and polls every 60 seconds with your token. One project takes up to 50 source repositories.
• A trigger on commits. It fires on every commit to the chosen branch, batched per repository, once per five minutes. A busy day becomes one run per repository per five minutes.
• An agent that reads the change. For each commit in the attached timeline it calls github__get_commit and reads the diff. It updates the context only when the change alters something a teammate or an agent in another repository must know: interfaces, configuration, data schemas, runtime behaviour, dependencies between repositories or conventions. Refactors, tests, formatting and version bumps that change no behaviour are skipped.
• A pull request. The agent reads the page that covers the change, corrects statements the change made false, then adds what is new with the commit’s short sha next to each claim. It writes on a branch named tares/context- followed by the repository and the date, then opens the pull request.
• A finding. Each run ends with a finding on the repository’s timeline: what changed and the pull request link, or “no update needed” and why.

Set it up

1. Start Tares with tares up and set an Anthropic API key under Settings > Model providers or as ANTHROPIC_API_KEY.

   tares up

2. Create a GitHub fine-grained personal access token. Under Repository access, pick the source repositories and the context repository. Set Contents to read and write, Pull requests to read and write, and leave Metadata read-only. GitHub starts every permission at read-only, so check Contents and Pull requests before you generate the token. With Pull requests at read-only the agent can push its branch but the pull request fails.

3. Open Projects, pick Shared code context and click Set up. Pick a stored credential or add one, then use Test to see the GitHub login it belongs to.

4. Tick the source repositories whose commits should feed the context, or paste owner/name lines. Change the branch for a row if you do not want the default branch.

5. Pick the context repository (it cannot also be a source), the branch pull requests target and the path where the pages live. Choose a layout:

   • Keep the existing pages, update them in place (the default) for a repository that already has one page per topic. The agent creates a page only when nothing existing covers the topic.
   • One page per source repository plus an index for a fresh folder.

6. Choose how it writes. Open a pull request is recommended, so a person merges. Committing straight to the branch is the other option.

7. Name the project, pick the model and the round budget (12 by default), and decide on First look on start. It runs the agent once per source repository over the last seven days of commits, so the context starts current. Click Start.

8. Push a commit to a source repository. Within a minute the source ingests it, the trigger fires and the agent runs.

A commits source is an ordinary github source. Written by hand, it looks like this:

- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: repo, field: repo, primary: true }

See GitHub for the credential options and fields, and Keep shared code context current for the full walkthrough.

What you get

• A context repository that is corrected by the commits themselves, instead of going stale the week after it is written.
• A pull request per change, with a short sha next to each claim, so a person reviews every update.
• A card under What the agents found on the project page for each change, showing the pull request or “no update needed”.
• Control after setup. Edit adds or removes repositories, Pause turns off the trigger and agent while sources keep ingesting, and Delete removes what the project created.
• Ordinary objects you can change. Edit the agent’s prompt on its own page if your pages need a different voice, and the project keeps your version.

This fits the wider approach in AI SRE, where shared context gives every agent the same current picture of your code.

When something else fits

• If you want to react only to merged pull requests rather than every commit, write your own trigger on the github source with event_type pull_request and action merged, as in the example on the GitHub page.
• If your pages are already current, or you want to save model spend, turn off First look on start so the agent waits for the next commit.
• Once you trust the agent for a repository, switch from pull requests to direct commits to the branch.

Related