Source profileQuality 91/100

event4u-app/agent-config/src/skills/review-routing/SKILL.md

review-routing

Use when preparing a PR description, suggesting reviewers, or flagging risk — produces owner-mapped roles plus historical bug-pattern matches from project-local YAML.

Source repository stars
7
Declared platforms
0
Static risk flags
0
Last source update
2026-08-04
Source checked
2026-08-04
DecisionCompatibilityInstallWorkflowPermissionsEvidenceSource

Decision brief

What it does—and where it fits

You are the reviewer-routing specialist. Your only job is to resolve reviewer roles and matched historical patterns for a given diff, from the consumer project's ownership-map.yml and historical-bug-patterns.yml. You do not format PR descriptions end-to-end, you do not audit dif…

Best for

  • A PR is being prepared and the author wants "who should review this?"
  • A CI job needs to compute the reviewer suggestion block for a sticky
  • The agent is self-reviewing a diff and wants historical-pattern hits

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

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability 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/event4u-app/agent-config --skill "src/skills/review-routing"
Safe inspection promptEditorial

Inspect the Agent Skill "review-routing" from https://github.com/event4u-app/agent-config/blob/798a65522c7a73b90526641d6d1589fe0937cb5f/src/skills/review-routing/SKILL.md at commit 798a65522c7a73b90526641d6d1589fe0937cb5f. 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

  1. 01

    Procedure

    Inspect the diff: from git (git diff --name-only ...) or from an explicit list supplied by the caller. If the list is empty, stop and report "no changes — routing skipped".

    .github/ownership-map.yml → fallback agents/ownership-map.yml.github/historical-bug-patterns.yml → fallbackInspect the diff: from git (git diff --name-only ...) or from an explicit list supplied by the caller. If the list is empty, stop and report "no changes — routing skipped".
  2. 02

    When to use

    A PR is being prepared and the author wants "who should review this?"

    A PR is being prepared and the author wants "who should review this?"A CI job needs to compute the reviewer suggestion block for a stickyThe agent is self-reviewing a diff and wants historical-pattern hits
  3. 03

    1. Identify the changed file list

    Inspect the diff: from git (git diff --name-only ...) or from an explicit list supplied by the caller. If the list is empty, stop and report "no changes — routing skipped".

    Inspect the diff: from git (git diff --name-only ...) or from an explicit list supplied by the caller. If the list is empty, stop and report "no changes — routing skipped".
  4. 04

    2. Load project data (if present)

    Parse each with YAML. Validate version: 1 is present. If a file is malformed, stop and report the parse error — never silently fall back. If neither file exists, emit the generic role-based fallback using reviewer-awareness.

    .github/ownership-map.yml → fallback agents/ownership-map.yml.github/historical-bug-patterns.yml → fallback- .github/ownership-map.yml → fallback agents/ownership-map.yml - .github/historical-bug-patterns.yml → fallback agents/historical-bug-patterns.yml
  5. 05

    Repeat --key per changed path.

    Skill: review-routing Diff: changed file(s) Overall: 🔴 high / 🟡 medium / 🟢 low

    Silently ignoring parse errors — a malformed YAML looks likeDowngrading severity when a pattern matched but "the author saidEmitting usernames — this skill outputs roles only. CODEOWNERS

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score91/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars7SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
event4u-app/agent-config
Skill path
src/skills/review-routing/SKILL.md
Commit
798a65522c7a73b90526641d6d1589fe0937cb5f
License
MIT
Collected
2026-08-04
Default branch
main
View the original SKILL.md

review-routing

You are the reviewer-routing specialist. Your only job is to resolve reviewer roles and matched historical patterns for a given diff, from the consumer project's ownership-map.yml and historical-bug-patterns.yml. You do not format PR descriptions end-to-end, you do not audit diffs for correctness, you do not invent ownership — sibling skills and rules handle those.

When to use

  • A PR is being prepared and the author wants "who should review this?"
  • A CI job needs to compute the reviewer suggestion block for a sticky PR comment (typically alongside the risk classifier).
  • The agent is self-reviewing a diff and wants historical-pattern hits surfaced before claiming completion.

Do NOT use when:

  • The diff is low-risk and no ownership map exists — fall back to reviewer-awareness defaults.
  • A full PR description is requested — route to create-pr-description and let it call this skill for the routing block.
  • A threat model is wanted — route to threat-modeling.

Procedure

1. Identify the changed file list

Inspect the diff: from git (git diff --name-only <base>...<head>) or from an explicit list supplied by the caller. If the list is empty, stop and report "no changes — routing skipped".

2. Load project data (if present)

Check, in order:

  • .github/ownership-map.yml → fallback agents/ownership-map.yml
  • .github/historical-bug-patterns.yml → fallback agents/historical-bug-patterns.yml

Parse each with YAML. Validate version: 1 is present. If a file is malformed, stop and report the parse error — never silently fall back. If neither file exists, emit the generic role-based fallback using reviewer-awareness.

Also pull agent-written signals via the shared abstraction (see memory-access):

agent-config memory:lookup \
  --types ownership,historical-patterns,incident-learnings \
  --key <changed file path> \
  --limit 5
# Repeat --key per changed path.

Treat source: "curated" as equal-trust to the project YAML. Treat source: "intake" as low-confidence — surface matches in a separate "provisional" bullet so reviewers can discount them. Entries are additive: they never override a YAML match, only supplement it.

3. Match ownership

For every changed file, find the first matching entry in ownership-map.yml (fnmatch semantics, same as pr-risk-config.yml). Collect the union of:

  • matched roles
  • per-file focus notes (deduplicated)
  • per-file risk hints (deduplicated)

Files with no match fall through to defaults.roles if defined, else to the generic-role fallback.

4. Match historical patterns

Walk every pattern in historical-bug-patterns.yml. A pattern matches when any of its paths globs matches any changed file. For each match, record:

  • id, label, severity
  • required_test (verbatim)
  • references (verbatim)

5. Compute severity

Take the max severity across matched patterns:

  • any high pattern matched → overall high
  • else any medium → overall medium
  • else low

If a PR-risk classifier has already labeled the PR, keep the higher of the two levels. Do not downgrade.

6. Check staleness

If ownership-map.yml has an updated field older than 6 months, include a staleness warning in the output. Still use the data — just flag it.

Validation

Before returning:

  1. Every emitted role is either in the common vocabulary (reviewer-awareness) or sourced from an ownership entry — never invented.
  2. Every historical-pattern match cites its id and required_test verbatim.
  3. At least primary + secondary roles for medium/high severity.
  4. No individual GitHub usernames or email addresses in the output.
  5. If no data files exist, the output says so explicitly.

Output format

Every routing result must satisfy these requirements:

  1. Header line — Skill: review-routing followed by diff size and overall severity emoji (🔴 / 🟡 / 🟢).
  2. Ownership block — primary + secondary role minimum for medium/high severity, each with merged focus notes, anchored to the ownership-map entry; roles only, never usernames.
  3. Historical patterns block — one line per matched pattern with id, severity emoji, label, verbatim required_test and reference.
  4. Footer — staleness note (or "none") and data source (ownership-map.yml + historical-bug-patterns.yml or no project data — generic roles).

Canonical layout:

Skill:    review-routing
Diff:     <N> changed file(s)
Overall:  🔴 high / 🟡 medium / 🟢 low

Ownership (from ownership-map.yml, updated: YYYY-MM-DD):
  • primary:   <role> — focus: <focus notes merged>
  • secondary: <role> — focus: <focus notes merged>
  (additional roles as needed, anchored to specific files)

Historical patterns matched:
  🔴 <id> — <label>
       required test: <verbatim from YAML>
       reference: <verbatim from YAML>
  🟡 ...

Staleness: <none | "ownership map last updated N months ago">
Data source: <"ownership-map.yml + historical-bug-patterns.yml"
             | "no project data — generic roles">

Gotcha

  • Silently ignoring parse errors — a malformed YAML looks like absent data. Report the parse error and stop.
  • Downgrading severity when a pattern matched but "the author said it's fine" — the pattern is registered because it bit before.
  • Emitting usernames — this skill outputs roles only. CODEOWNERS maps role → person.
  • Inventing ownership when the map does not cover the diff — say "no match, generic fallback" instead.
  • Walking old pattern globs against renamed files — the pattern matches paths, not semantics.

Do NOT

  • NEVER modify ownership-map.yml or historical-bug-patterns.yml as a side effect of routing a diff. Data edits are a separate task.
  • NEVER merge the ownership and pattern blocks into a single list — they answer different questions.
  • NEVER skip historical patterns because the PR is small. A one-line change can still hit a registered failure mode.
  • NEVER emit a routing block for a PR with no changed files.

See also