multi-repo-context

name	multi-repo-context
description	Work across several repos at once without losing track of which is which. Use when a task spans a frontend + backend + infra repo, a service and its client, or a repo and a sibling dependency. Builds a scope manifest (repos, roles, boundaries, relationships) the agent keeps in view, and uses recall for cross-repo memory. Trigger with /multi-repo-context or "work across these repos", "set up multi-repo scope", "which repo owns this".
version	0.1.0
user-invocable	true
metadata	{"emoji":"🗂️"}

multi-repo-context

Multi-repo and multi-system work is awkward: the agent forgets which repo owns what, edits the wrong one, or loses the relationship between a service and its client. This skill makes the scope explicit and keeps it in view.

Why this exists

• Power users report multi-repo / multi-system workflows are awkward and hand-orchestrated, and that the agent does not reliably "know" which repos are in scope and how they relate.
• The fix is a small, explicit scope manifest (cheap context) plus durable cross-repo memory (recall), instead of re-discovering the topology every session.

The scope manifest

Produce and keep this small block in view for the task:

## Repo Scope

REPOS (in scope):
- <name> : <path/url> : <role> : <language/stack>
- ...

RELATIONSHIPS:
- <A> --(calls / depends on / deploys / shares schema with)--> <B>
- ...

BOUNDARIES:
- <what each repo owns; what it must NOT change in another>
- contracts/interfaces between them (API shape, schema, events)

TASK SCOPE: <which repos this task may touch; which are read-only reference>

Rules:

• Keep it short (it is always-in-view context; do not paste file trees).
• Mark each repo touch vs read-only. A read-only reference repo is for understanding, not editing.
• When a change crosses a boundary (e.g. an API both sides depend on), call it out explicitly and treat the contract as the source of truth.

How to run

1. Identify the repos involved and their local paths or URLs.
2. For each, one line: role + stack. For each pair that interacts, one relationship line.
3. State which repos the task may edit and which are reference-only.
4. Persist the manifest to memory so the next session recalls it (see recall). Update it when the topology changes.
5. During work, before editing, confirm the file's repo is in the "may touch" set.

Composes with

• recall (MCP): store/recall the manifest and cross-repo decisions across sessions.
• context-warden: keep the manifest lean; do not let per-repo exploration bloat the window.
• orchestrate: when a cross-repo change needs plan -> spec -> gate.

Honest limits

• This is a discipline + manifest, not a build-system integration. It does not wire monorepo tooling; it keeps the agent oriented across repos.
• It does not auto-discover relationships; you state them once (then recall reuses them). Wrong manifest in, wrong orientation out.