unlearndev/skills

triage

Triage a branch or diff by grouping changed files into feature areas, assigning each a risk tier (High/Medium/Low), and producing a scannable summary that helps decide where to spend review time. Use when the user asks to "triage" a branch, PR, or diff.

First seen May 6, 2026

Installation

$ npx skills add unlearndev/skills --skill triage

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from unlearndev/skills · top by installs.

npx skills add unlearndev/skills

Browse all from unlearndev/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 68
Default branch main
Open issues 0
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Allowed toolsBash(git diff:*), Bash(git log:*), Bash(git merge-base:*), Bash(git rev-parse:*), Bash(git status:*), Read, Grep, Glob

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,798 B
  • docs SUMMARY.md 267 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 98 installs

SKILL.md

Triage

Arguments

Raw arguments: $ARGUMENTS

Parse the arguments as the base branch to diff against. If empty, default to main.

Goal

Produce a risk-ordered map of the changes between the base branch and HEAD, grouped by feature area, so the user can decide where to spend their review time. The output is a triage report — not a review.

Do not perform the review. Do not make suggestions. Do not propose fixes. Do not flag specific lines to verify. The user reads this map and decides for themselves what to dig into.

Instructions

1. Get the diff

Run git diff --name-status <base>...HEAD for a file-level overview, then git diff <base>...HEAD to see the actual changes. If there are no changes, tell the user and stop.

2. Read the changed files

For every changed file, read enough of the file to understand what feature area it belongs to and how risky it is. You don't need to read every line of every file — read enough to categorise it.

3. Group by feature area

Group files by what the code does, not by file type. Good group names: "Authentication", "Notification Delivery", "User Data Mutations", "Schema & Config". Bad group names: "Controllers", "PHP Files", "Vue Components".

Heuristics:

  • A controller + its route + its page + its tests usually form one feature group.
  • A migration + the model changes that go with it form one feature group.
  • A notification class + its trigger + its mail template form one feature group.
  • A side-effect added to an existing flow (e.g. "voting now also subscribes you") is its own small group.
  • Pure refactors with no behavioural change can be a single "Refactor" group.

Each file appears in exactly one group — pick the most relevant one. Keep group names short (2–4 words).

4. Assign a risk tier

Tier each group as High, Medium, or Low.

Always High if the group:

  • Touches authentication or authorization
  • Mutates user data, payments, or billing
  • Modifies permissions or access control
  • Handles sensitive data (passwords, tokens, PII)

Bump up one tier if the group:

  • Has complex conditionals or branching logic
  • Interacts with external services or APIs
  • Contains a large amount of generated code (100+ lines that look like a single AI generation)

Otherwise: pick the tier that matches the blast radius of the change.

5. Identify auto-generated files

Auto-generated files go in a "Skip" section at the bottom. These include:

  • Lockfiles (composer.lock, package-lock.json, pnpm-lock.yaml)
  • Compiled assets (public/build/, dist/)
  • Generated route/type definitions (Wayfinder action/route files, generated TS types)

6. Output the report

Use this exact format:

### ⚠️ High Risk

**[Feature Area Name]**
Reason: [one sentence explaining why this is high risk]
- path/to/file.php (added/modified)
- path/to/other-file.php (modified)

**[Another Feature Area]**
Reason: [one sentence]
- path/to/file.php (added)

### Medium Risk

**[Feature Area Name]**
Reason: [one sentence]
- path/to/file.php (added)

### Low Risk

**[Feature Area Name]**
- path/to/file.php (modified)

### Skip

**Auto-generated**
- path/to/generated/files... (auto-generated — skip)

End with a one-line summary: X groups, Y high-risk files to focus on.

Rules

  • Group by feature area, not by file type. "Auth flow" not "Controllers". "Notification delivery" not "PHP files".
  • One group per file. Pick the most relevant one.
  • Group names: 2–4 words. Short and descriptive.
  • One-line reason per group explaining WHY it's that risk level. Only required for High and Medium tiers — Low can skip the reason.
  • Status suffix on each file: (added), (modified), or (deleted). Match git diff --name-status.
  • Order tiers from highest to lowest risk. High first, then Medium, then Low, then Skip.
  • Omit a tier section if it's empty.
  • If everything fits in one tier, say so and suggest reviewing everything: "This diff is small — review all files".
  • No suggestions, no advice. This is a triage map, not a review. Don't say "verify…", "consider…", "make sure…".
  • No emojis other than the ⚠️ on the High Risk heading.
  • End with a one-line summary: X groups, Y high-risk files to focus on.