.NET Cross-Repo Impact Analysis
Procedural recipe for reviewing a .NET pull request against a multi-repo
microservice workspace: detect breaking changes, trace their blast radius
across repo boundaries, check for a compatible downstream PR, and render
a structured cross-repo-impact.md report.
This skill is procedural only. It does not describe agent identity, default stance, or severity philosophy — those belong in the consuming agent's system prompt. This skill tells the agent how to run the analysis when invoked.
Requirements
- Synopsis v2.0.0+ binary available, either:
- as a long-running MCP daemon (preferred — fastest, combined multi-repo graph kept warm), or
- as a CLI invoked per-run (one-shot mode, no daemon required).
Use the companion
dotnet-techne-synopsisskill to auto-download and detect the binary.
- git on the PATH for diff inspection.
- A code-host CLI on the PATH for compatible-PR search:
ghfor GitHub (authenticated, repo read).glabfor GitLab (authenticated, MR read).- Others acceptable if the agent's harness provides an equivalent
searchOpenPrstool.
- Read access to a workspace root that contains the PR repo AND every
other repo in the fleet as peer directories (Synopsis discovers repos
by
.gitmarkers under the root).
When to use this skill
Trigger this skill when a PR diff touches any of:
- Public types, methods, records, or interfaces in an assembly referenced by other projects.
- ASP.NET controllers, minimal-API endpoints, route constants, or HTTP verb attributes.
- EF Core entity classes,
DbContextoverrides,OnModelCreatingconfigurations,ToTable/HasColumnNamecalls, or migration files. - DTO classes or records carrying
[JsonPropertyName],[DataMember],[JsonConverter], or used asHttpClientrequest/response bodies. PackageReferenceelements in.csprojorDirectory.Packages.propswhere the package is also referenced by other repos.appsettings.jsonkeys that appear asConfigurationKeynodes in the Synopsis graph.
If the diff is pure internal refactor (no public surface change, no cross-repo edges touched), skip this skill and run standard review skills only.
Operating modes
Pick the mode based on what is available:
Mode A — Daemon mode (preferred)
Used when a long-running synopsis mcp daemon is already serving a
combined multi-repo graph (typical deployment for an autonomous review
agent).
- Call MCP tools on the already-running daemon.
- Ask the daemon to re-index only the PR repo (
reindex_repository) at the head SHA before analysis; other repos stay warm. - Fastest: typical review in a few seconds of graph work plus the LLM turns.
Mode B — One-shot mode
Used when Synopsis is not running as a daemon (Claude Code user running this skill manually, CI one-shot, etc.).
- Scan the workspace once with
synopsis scanto producehead.graph.json. - Scan the base revision (checkout base ref →
synopsis scan→base.graph.json). - Run
synopsis breaking-diff base.graph.json head.graph.json --jsonto get classified breaking changes. - Query the head graph for blast radius via
synopsis query symbol --fqn <name> --blast-radius --json.
Both modes produce the same findings; the skill text below uses MCP tool names and notes CLI equivalents where relevant.
Procedure
1. Resolve the workspace and PR
- Determine the workspace root (the directory containing all
microservice repo checkouts). The agent's harness should provide it;
if not, infer from the parent of the PR repo and verify at least two
sibling
.gitdirectories exist. - Identify the PR repo, base ref, head SHA, and the list of changed files
via
git diff --name-only <base>...<head>.
2. Ensure Synopsis sees the head revision
Mode A: call reindex_repository { path: <pr-repo-abs-path>, ref: <head-sha> }.
Wait for response. Inspect returned delta stats to confirm at least one
node changed.
Mode B: synopsis scan <workspace-root> -o head.graph.json
at head SHA, then git checkout <base-ref>, then
synopsis scan <workspace-root> -o base.graph.json, then restore head.
3. Compute classified breaking changes
Mode A: call breaking_diff { before: <base.graph.json>, after: <head.graph.json> }.
(The daemon may cache before as part of its pre-PR baseline; confirm in
the returned metadata.)
Mode B: synopsis breaking-diff base.graph.json head.graph.json --json.
The response is a typed list of changes. Each change has:
kind— paired change kinds (ApiSignatureChange,EndpointRouteChange,EndpointVerbChange,TableRename,NugetVersionBump), removal kinds (ApiRemoved,EndpointRemoved,TableRemoved,PackageRemoved), or detection-pending kinds (DtoShapeChange,EntityColumnChange,SerializationContractChange— not yet emitted; reserved for future pass work).severity— classifier's base severity (Critical/High/Medium/Low).certainty— Synopsis certainty (Exact/Inferred/Ambiguous/Unresolved).affectedNodes[]— graph node IDs touched.beforeSnippet,afterSnippet— one-line summaries.sourceLocation— file + line (where applicable).
If the list is empty, skip to step 7 and emit a clean pass.
4. Filter to cross-repo impact
For each classified change, call blast_radius { symbol: <nodeId>, direction: "upstream", depth: 4 }
(CLI equivalent: synopsis query symbol --fqn <name> --blast-radius --depth 4).
Retain only changes whose upstream callers include at least one node with
repositoryName != prRepo.name. Group hits by downstream repository.
Changes with no cross-repo callers are not reported by this skill — they are handled by the standard code-review skills. Always count them in the summary as "internal-only changes: N".
5. Search for compatible downstream PRs
For each affected downstream repo, search open PRs/MRs that likely fix
the break. See references/compat-pr-search.md for the full heuristic
catalogue; the minimum set:
- Keyword search on the affected symbol's display name and common synonyms.
- Branch-name patterns commonly used in your org (e.g.
fix/*<symbol>*,chore/sync-<pr-number>,bump/<package>-<version>). - Linked-issue lookup: if the PR references issue
#N, search open PRs in downstream repos mentioning that issue number. - Freshness window: only consider PRs opened in the last 30 days (or since the PR under review was opened, whichever is longer).
GitHub example:
gh pr list --repo <owner>/<downstream-repo> --state open \
--search "<symbol> in:title,body" --json number,title,url,headRefName
GitLab example:
glab mr list --repo <group>/<downstream-repo> --state opened \
--search "<symbol>"
Record for each affected repo: compatiblePrUrl: <url> OR compatiblePr: NONE FOUND.
If the search hits its rate limit or errors, mark compatiblePr: UNKNOWN
for that repo and proceed — never fail the whole analysis on search
flakiness.
6. Apply severity rules
Start with the classifier's base severity, then apply these transforms:
- If no compatible PR was found for an affected downstream repo: escalate severity by one level (Low → Medium → High → Critical).
- If compat-PR search returned UNKNOWN: escalate by one level and add a
search-failedwarning. - If all upstream callers are
AmbiguousorUnresolved: cap severity at Medium and add anambiguous-evidencewarning. - Never down-escalate. A change the classifier called Critical stays at least Critical.
See references/severity-rubric.md for the full table including edge
cases.
7. Render the report
Produce the cross-repo-impact.md report following the schema in
references/report-schema.md. Output destinations:
- If the agent has a "post inline comment" capability — post this as a PR review comment.
- If not, write the file