Dotnet techne cross repo impact

Skill Metalnib/dotnet-episteme-skills/skills/dotnet-techne-cross-repo-impact

DotNet Episteme Skills - a curated, manual-first .NET AI skills library rooted in systematic knowledge (episteme) and shaped by disciplined craft (techne), designed for engineers who prioritise precision over hype.

Install

npx -y skills add Metalnib/dotnet-episteme-skills --skill dotnet-techne-cross-repo-impact

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when reviewing a .NET pull request for breaking changes that may affect other microservice repositories. Detects cross-repo API, DTO, endpoint, EF entity, and NuGet-package breaks, and checks whether a compatible downstream PR already exists. Keywords: cross-repo impact, breaking change, microservice compatibility, downstream break, compatible PR, blast radius review, api compatibility, contract break, dto shape change, endpoint break.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

12.0 KB, as published. Nobody here has run it

.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 v1.6.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-synopsis skill 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:
- gh for GitHub (authenticated, repo read).
- glab for GitLab (authenticated, MR read).
- Others acceptable if the agent's harness provides an equivalent searchOpenPrs tool.
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 .git markers 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, DbContext overrides, OnModelCreating configurations, ToTable / HasColumnName calls, or migration files.
DTO classes or records carrying [JsonPropertyName], [DataMember], [JsonConverter], or used as HttpClient request/response bodies.
PackageReference elements in .csproj or Directory.Packages.props where the package is also referenced by other repos.
appsettings.json keys that appear as ConfigurationKey nodes 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 scan to produce head.graph.json.
Scan the base revision (checkout base ref → synopsis scan → base.graph.json).
Run synopsis breaking-diff base.graph.json head.graph.json --json to 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 .git directories 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-failed warning.
If all upstream callers are Ambiguous or Unresolved: cap severity at Medium and add an ambiguous-evidence warning.
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 to the workspace root and print its path.

Always also emit a structured JSON summary for programmatic consumers:

{
  "severity": "<highest finding severity>",
  "counts": { "critical": 0, "high": 0, "medium": 0, "low": 0 },
  "affectedRepos": 0,
  "compatiblePrsFound": 0,
  "compatiblePrsMissing": 0,
  "findings": [
    { "kind": "...", "symbol": "...", "severity": "...", "recommendation": "..." }
  ]
}

Recommendation values: BLOCK | REQUIRE-COORDINATED-PR | FLAG | OK.

Confidence mapping

The report's Confidence field mirrors the weakest Synopsis certainty contributing to the finding:

Synopsis certainty	Confidence
`Exact`	High
`Inferred`	Medium
`Ambiguous`	Low
`Unresolved`	Unknown

When a finding has mixed certainty across its evidence, report the lowest value.

Failure modes

Situation	Behaviour
Synopsis daemon unreachable (Mode A)	Fall back to Mode B. If that also fails, emit a degraded report with `severity: Unknown`, reason stated, and still run standard review skills.
`breaking_diff` returns no changes	Emit the summary JSON with all zero counts and a one-line "no cross-repo-relevant breaking changes detected" note. No markdown report.
`git checkout <base-ref>` fails in Mode B	Fall back to last common commit via `git merge-base`; record a warning in the report.
Compat-PR search CLI absent	Mark all findings `compatiblePr: UNKNOWN`, escalate one level, emit warning in each finding.
LLM suggests a cross-repo caller Synopsis did not report	Reject the suggestion. Every caller in the report must cite a Synopsis node or edge. If evidence is missing, omit the claim.

Skill hygiene

These invariants apply every run. Consumers cannot override them:

Classifier-first citation. Every finding references at least one row from breaking_diff output AND at least one node/edge from blast_radius.
One-pass severity. Severity is computed once in step 6. Do not re-interpret while rendering.
Advisory output only. Recommendations (BLOCK, etc.) are suggestions. Gate enforcement is the code host's responsibility.
Cross-repo only. Internal-only findings are counted but not reported — the standard code-review skills own those.

References

references/severity-rubric.md — full rules table including edge cases.
references/report-schema.md — exact markdown format for cross-repo-impact.md.
references/compat-pr-search.md — heuristics and CLI recipes for GitHub, GitLab, and others.