dotnet-techne-cross-repo-impact by Metalnib

Decision brief

What it does: where it fits

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.

Best for

Public types, methods, records, or interfaces in an assembly referenced
ASP.NET controllers, minimal-API endpoints, route constants, or HTTP
EF Core entity classes, DbContext overrides, OnModelCreating

Not for

Tasks that require unconfirmed production actions or broad system permissions.
Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

Platform	Status	Evidence	What to check
Codex	Not declared	No explicit evidence	Portability before use
Claude Code	Not declared	No explicit evidence	Portability before use
Cursor	Not declared	No explicit evidence	Portability before use
Gemini CLI	Not declared	No explicit evidence	Portability before use

Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource

npx skills add https://github.com/Metalnib/dotnet-episteme-skills --skill "skills/dotnet-techne-cross-repo-impact"

Safe inspection promptEditorial

Inspect the Agent Skill "dotnet-techne-cross-repo-impact" from https://github.com/Metalnib/dotnet-episteme-skills/blob/d169327d980a07c207b935215342071941c00ff6/skills/dotnet-techne-cross-repo-impact/SKILL.md at commit d169327d980a07c207b935215342071941c00ff6. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

01
Procedure
Mode A: call reindexrepository { path: , ref: }. Wait for response. Inspect returned delta stats to confirm at least one node changed.
Determine the workspace root (the directory containing allIdentify the PR repo, base ref, head SHA, and the list of changed fileskind — paired change kinds (ApiSignatureChange, EndpointRouteChange,
02
Requirements
Synopsis v1.6.0+ binary available, either:
Synopsis v1.6.0+ binary available, either:as a long-running MCP daemon (preferred — fastest, combined multi-repoas a CLI invoked per-run (one-shot mode, no daemon required).
03
When to use this skill
Trigger this skill when a PR diff touches any of:
Public types, methods, records, or interfaces in an assembly referencedASP.NET controllers, minimal-API endpoints, route constants, or HTTPEF Core entity classes, DbContext overrides, OnModelCreating
04
Operating modes
Pick the mode based on what is available:
Call MCP tools on the already-running daemon.Ask the daemon to re-index only the PR repo (reindexrepository) atFastest: typical review in a few seconds of graph work plus the LLM
05
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 (reindexrepository) atFastest: typical review in a few seconds of graph work plus the LLM

Permission review

Static risk signals and limitations

Writes files

medium · line 201

The documentation asks the agent to create, modify, or delete local files.

If not, write the file to the workspace root and print its path.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial

Signal	Value	Evidence type	Meaning
Quality score	92/100	Computed	Documentation, specificity, maintenance, and trust rules
Repository stars	12	Source	Repository attention, not individual Skill quality
Compatibility	0 platforms	Source	Declared in the catalog source record
Usage guide	automated source guide	Editorial	Generated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository: Metalnib/dotnet-episteme-skills
Skill path: skills/dotnet-techne-cross-repo-impact/SKILL.md
Commit: d169327d980a07c207b935215342071941c00ff6
License: MIT
Collected: 2026-08-25
Default branch: main

View the original SKILL.md

.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.

What to verify before installation and use

What does the dotnet-techne-cross-repo-impact source document cover?

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.

How do I install dotnet-techne-cross-repo-impact?

The source record exposes this install command: npx skills add https://github.com/Metalnib/dotnet-episteme-skills --skill "skills/dotnet-techne-cross-repo-impact". Inspect the command and pinned source before running it.

Which permission-related actions were detected?

Static rules flagged write-files in the source; the page lists the matching lines and excerpts.

What it does: where it fits

Best for

Not for

Platform support, with evidence labels

Inspect first. Install second.

What the source asks the agent to do

Procedure

Requirements

When to use this skill

Operating modes

Mode A — Daemon mode (preferred)

Static risk signals and limitations

Writes files

Why each signal appears

Provenance and original SKILL.md

.NET Cross-Repo Impact Analysis

Requirements

When to use this skill

Operating modes

Mode A — Daemon mode (preferred)

Mode B — One-shot mode

Procedure

1. Resolve the workspace and PR

2. Ensure Synopsis sees the head revision

3. Compute classified breaking changes

4. Filter to cross-repo impact

5. Search for compatible downstream PRs

6. Apply severity rules

7. Render the report

Confidence mapping

Failure modes

Skill hygiene

References

See also

What to verify before installation and use

Compare before choosing

software-architecture-analysis

salesforce-apex-log-analyzer-skill

github-code-review

smart-contract-auditing