Keep shared code context current

GitHub access

Open Use cases, pick Shared code context, click Set up. Step 1 asks for the token: pick a credential you stored before or add one (a name and the token; the ”?” next to the token field repeats the permission table). The token is stored once under Settings > GitHub and used by every source the use case creates and by the agent when it writes. Test shows the GitHub login it belongs to.

Source repositories

Step 2 lists the repositories the token can see; tick the ones whose commits should feed the context (up to 50), or paste owner/name lines. Each row follows one branch, the default branch unless you change it. “Every commit to the branch” is what wakes the agent.

Context repository

Step 3 is the repository the agent maintains. Pick it (it cannot also be a source), the branch pull requests target, and the path where the pages live; leave the path empty for the root. As soon as the repository is picked, the page shows what is at that path, so you can see the layout you are handing over.

Two page layouts:

• Keep the existing pages, update them in place (the default). The agent lists the folder, reads the index and the page that covers the change, corrects what the change made outdated, and adds what is new, keeping the pages’ structure and voice. It creates a page only when nothing existing covers the topic. This is the right choice for a repository that already has its own pages, one per topic.
• One page per source repository plus an index. The agent keeps <repo-name>.md per source repository under the path, with a fixed section template, and a README.md index listing them. The right choice for a fresh folder.

How it writes: open a pull request (recommended; a person merges) or commit straight to the branch.

Trigger and agent

Step 4 names the use case, shows the trigger (every commit to the chosen branch, batched per repository, once per five minutes), lets you pick the model and the round budget (12 by default; reading diffs and pages, writing them and opening a pull request needs more than the plain 6), and previews exactly what Start creates: one commits source per repository, a view with one timeline per repository, the trigger, GitHub’s hosted MCP server registered with your credential (toolsets repos,pull_requests), and the agent.

First look on start (on by default) runs the agent once per source repository over the last seven days of commits, so the context repository starts current instead of waiting for the next commit. Turn it off if the pages are already current or to save model spend.

Click Start. You land on the use case page.

Watch a commit land

Push a commit to one of the source repositories. Within a minute the source ingests it, the trigger fires for that repository, and the agent runs:

1. It calls github__get_commit for each commit in the attached timeline and reads the diff (and specific files with github__get_file_contents when a diff is truncated).
2. It decides whether the change alters anything a teammate or an agent in another repository must know: interfaces and contracts, configuration and environment variables, data schemas, runtime behaviour, dependencies between repositories, conventions. Refactors, tests, formatting and version bumps that change no behaviour are skipped.
3. It reads the covering page in the context repository, corrects statements the change made false first, then adds what is new, with the commit’s short sha next to each claim, and writes it with github__create_or_update_file on a branch named tares/context-<repo>-<date>, then opens the pull request with github__create_pull_request (or commits to the branch, if you chose that).
4. It finishes with a finding on the repository’s timeline: what changed in the context repository and the pull request link, or “no update needed” and why.

The Runs tab on the use case page shows every run with its status, rounds and result; the time opens that run on the agent’s page. Runs marked first look are the ones from Start.