One repository of shared context that stays current on its own.

Tares watches commits across your code repos. When a change matters to the team, an agent updates the context repo and opens a pull request. Every teammate and every agent starts from pages that match the code.

set it up in the consoletares on github
context/orders-service.md
# orders-service
Purpose: takes orders over HTTP, writes to Postgres.
## Configuration
DATABASE_URL required
STRIPE_WEBHOOK_SECRET required, verifies Stripe webhooks (a1b2c3d)
## Interfaces
POST /orders, GET /orders/{id}
POST /webhooks/stripe (a1b2c3d)
## Recent changes
- 2026-08-19 a1b2c3d Stripe webhooks, new required secret

Every claim carries the commit it came from, so a reader can check it.

How a commit becomes a pull request.

Point Tares at the repos you work in and the repo where shared context lives. From then on it watches every commit, and when one changes something a teammate must know, a pull request appears. One change, start to finish:

  1. 14:20

    A commit lands

    One source per repo ingests every commit with its changed files, onto that repo's timeline.

    f8b6cc6 billing-service: add GET /invoices/{id}
  2. 14:22

    The trigger fires, once per repo

    New commits on the branch you chose, batched by a short window so one push is one run.

    trigger context_changes → wakes context_maintainer
  3. 14:22

    The agent reads the diff

    Through GitHub's MCP server. It decides whether a teammate must know: interfaces, config, schemas, dependencies, conventions. Refactors and formatting are left alone.

    read(billing-service) → 7 commits · 4 files changed
  4. 14:24

    A pull request opens

    The context page updated in place, every claim carrying the commit it came from, the commits listed in the body.

    PR: billing-service: document GET /invoices/{id} (f8b6cc6)
+ Interfaces: GET /invoices/{id} returns the invoice (f8b6cc6)
  5. later

    A human reviews and merges

    Prefer direct commits instead of pull requests? That is a setting.

Set it up in the console. nothing to deploy.

Connect GitHub, choose the repos to watch and the repo to maintain, click Start. Everything this creates is visible in the console and yours to change, from the agent's instructions to which repos it watches.

  1. GitHub access

    One fine-grained token, stored once under Settings: Contents and Pull requests read and write, Metadata read. Every source and the agent use it; rotate it in one place.

  2. Source repos

    Pick the repos whose commits feed the context, from the list your token can see, or paste owner/name lines. One branch each.

  3. Context repo

    Pick the repo the agent maintains. The wizard looks inside it and keeps your existing pages, updating them in place; or choose one page per source repo plus an index.

  4. Trigger and agent

    Every commit to the branch, the model, and a first look on start that reads the last week of commits so the repo starts current. Click Start.

what Start creates
  • source one per repo, commits with changed files
  • view one timeline per repo
  • trigger fires when commits land, once per repo
  • mcp server GitHub, bound to your token
  • agent reads each diff, updates the pages, opens the pull request
catalog.yaml
projects:
- template: shared_code_context
name: team context
params:
credential: github
source_repos: [acme/orders, acme/billing]
context_repo: acme/context
write_mode: pull_request
# the same setup as a file, for git
the full guidethe cookbook: two repos, three changes, three pull requests
mit · self-hosted · no signup

Shared context for your agents, built by an agent. you review the pull requests.

One token, a few repos, and Start.

set it uptares on github

Want the managed version instead? Start on the cloud.