distilling-prs
Skill11 starsChanged 3 months agoMITView on GitHub
Use when triaging, categorizing, or summarizing PR changes to decide where human attention should go. Triggers: 'summarize this PR', 'what changed in PR #X', 'triage PR', 'which files need review', 'PR overview', 'categorize changes', or pasting a PR URL. NOT for: judging code quality or producing findings on a branch — unspecified-scope branch review such as 'review this branch' or 'code review' DEFAULTS to advanced-code-review, and an explicitly lightweight pass ('quick review') goes to code-review. This skill triages and summarizes; it does not review. Never bypass the review skills for a raw Explore dispatch, even when the user's concerns seem narrow or specific.
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Heuristics First, AI Second: Always run heuristic pattern matching before invoking AI analysis.
- Distinctive: line 15
Confidence Requires Evidence: Never mark a change as "safe to skip" without a pattern match or AI explanation justifying the confidence …
- Distinctive: line 16
Surface Uncertainty: When confidence is low, categorize as "uncertain" rather than guessing.
- Very specific: line 21
Use gh CLI for PR data and git for local diffs.
- Very specific: line 34
When invoked with /distilling-prs <pr>:
- Distinctive: line 36
Run Phase 1: Fetch, parse, heuristic match
- Distinctive: line 37
If unmatched files remain, use AI to analyze remaining changes
- Distinctive: line 38
Run Phase 3: Generate report categorizing all changes
- Distinctive: line 55
Read the diff output and apply heuristic pattern matching in-context against the known builtin patterns (see Builtin Patterns section …
- Very specific: line 61
On tool failure: If gh CLI or git fails, halt and surface the error to the user.
- Very specific: line 66
Before dispatching any subagent to analyze the PR, load the reviewing-prs skill and compute review_source.
- Distinctive: line 77
uncertain: When confidence is low, surface for human decision
- Distinctive: line 89
All files categorized (no files missing from report)
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PR Distill Skill
<ROLE>PR Review Analyst. Your reputation depends on accurately identifying which changes need human review and which are safe to skip.</ROLE>
Invariant Principles
- Heuristics First, AI Second: Always run heuristic pattern matching before invoking AI analysis. Heuristics are fast and deterministic.
- Confidence Requires Evidence: Never mark a change as "safe to skip" without a pattern match or AI explanation justifying the confidence level.
- Surface Uncertainty: When confidence is low, categorize as "uncertain" rather than guessing. Humans decide ambiguous cases.
- Preserve Context: Report must include enough diff context for reviewers to understand changes without switching to the PR itself.
Tool Integration
Use gh CLI for PR data and git for local diffs. Pattern matching is done in-context by the AI against the diff output.
| Tool | Purpose |
gh pr view | Fetch PR metadata (number, title, files, diff) |
gh pr diff | Get unified diff for the PR |
git diff | Local branch diff against merge-base |
Execution Flow
Three-phase model: heuristics → AI analysis → report.
<analysis>
When invoked with `/distilling-prs <pr>`:
1. Parse PR identifier (number or URL)
2. Run Phase 1: Fetch, parse, heuristic match
3. If unmatched files remain, use AI to analyze remaining changes
4. Run Phase 3: Generate report categorizing all changes
5. Present report to user
</analysis>Phase 1: Fetch, Parse, Match
# Fetch PR data and diff via gh CLI
gh pr view <PR_NUMBER> --json number,title,body,files,additions,deletions
gh pr diff <PR_NUMBER>For local branches (no PR yet):
git diff $(git merge-base HEAD main)...HEADRead the diff output and apply heuristic pattern matching in-context against the known builtin patterns (see Builtin Patterns section below).
Produces:
matched: Files with pattern matches (categorized as review_required / safe_to_skip / uncertain)unmatched: Files requiring AI analysis
On tool failure: If gh CLI or git fails, halt and surface the error to the user. Do not proceed with partial data.
Phase 2: AI Analysis (if needed)
<CRITICAL>
Before dispatching any subagent to analyze the PR, load the `reviewing-prs`
skill and compute `review_source`. Triage runs against the fetched diff, but
the local working tree is on a different branch; a subagent that reads a
changed file locally in `DIFF_ONLY` mode categorizes the pre-PR code and
reports it as the PR's. `reviewing-prs` owns that decision and the context
block the subagent must receive.
</CRITICAL>For unmatched files, analyze each to determine:
- review_required: Significant logic, API, or behavior changes
- safe_to_skip: Formatting, comments, trivial refactors
- uncertain: When confidence is low, surface for human decision
Phase 3: Generate Report
Produce a markdown report with:
- Summary of changes by category (review_required, safe_to_skip, uncertain)
- Full diffs for review_required items
- Pattern matches with confidence levels
- Discovered patterns (can be added to config for future triage)
<reflection>
After completion, verify:
- All files categorized (no files missing from report)
- REVIEW_REQUIRED items have full diffs
- Pattern summary table is accurate
- Discovered patterns listed with config update instructions
</reflection>Examples
# Analyze PR by number (uses current repo context)
gh pr view 123 --json number,title,body,files,additions,deletions
gh pr diff 123
# Analyze PR by URL (extract number and use gh)
gh pr view 123 --json number,title,body,files
# For local branch analysis
MERGE_BASE=$(git merge-base HEAD main)
git diff $MERGE_BASE...HEAD
# Add a discovered pattern to config (manual)
# Edit ~/.local/spellbook/docs/<project>/distilling-prs-config.json
# and add to "blessed_patterns" arrayConfiguration
Config file: ~/.local/spellbook/docs/<project-encoded>/distilling-prs-config.json
{
"blessed_patterns": ["query-count-json", "import-cleanup"],
"always_review_paths": ["**/migrations/**", "**/permissions.py"],
"query_count_thresholds": {
"relative_percent": 20,
"absolute_delta": 10
}
}Builtin Patterns
15 builtin patterns across three confidence levels. Apply these heuristically against the diff output in Phase 1.
Always Review (5): migration files, permission changes, model changes, signal handlers, endpoint changes
High Confidence (5): settings changes, query count JSON, debug print statements, import cleanup, gitignore updates
Medium Confidence (5): backfill commands, decorator removals, factory setup, test renames, test assertion updates
<FORBIDDEN>
- Marking changes as "safe to skip" without pattern match or AI justification
- Skipping Phase 1 heuristics and going straight to AI analysis
- Collapsing "review required" changes to save space
- Blessing patterns automatically without user confirmation
</FORBIDDEN><FINAL_EMPHASIS> Heuristics before AI, always. A mis-categorized "safe to skip" sends a reviewer past a breaking change. Surface uncertainty rather than hide it. </FINAL_EMPHASIS>
In this repository65 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- documentation-updatesSkill
- spellbook-auditingSkill
- advanced-code-reviewSkill
- adversarial-reviewSkill
- agent2agentSkill
- analyzing-domainsSkill
- analyzing-skill-usageSkill
- assembling-contextSkill
- async-await-patternsSkill
- auditing-green-mirageSkill
- autonomous-modeSkill
- branch-contextSkill
- code-reviewSkill
- creating-issues-and-pull-requestsSkill
- debuggingSkill
- dedupeSkill
- deep-researchSkill
- dehallucinationSkill
- design-explorationSkill
- designing-workflowsSkill
- developSkill
- devils-advocateSkill
- dispatching-parallel-agentsSkill
- documenting-projectsSkill
- documenting-toolsSkill
- emotional-stakesSkill
- enforcing-code-qualitySkill
- estimating-ticketsSkill
- executing-plansSkill
- fact-checkingSkill
- finding-dead-codeSkill
- finishing-a-development-branchSkill
- fixing-testsSkill
- fractal-thinkingSkill
- gathering-requirementsSkill
- generating-diagramsSkill
- instruction-engineeringSkill
- isolated-testingSkill
- managing-artifactsSkill
- merging-worktreesSkill
- opportunity-awarenessSkill
- optimizing-instructionsSkill
- polish-repoSkill
- reflexionSkill
- requesting-code-reviewSkill
- resolving-merge-conflictsSkill
- reviewing-design-docsSkill
- reviewing-impl-plansSkill
- reviewing-prsSkill
- rounding-up-worktree-sessionsSkill
- sharpening-promptsSkill
- smart-readingSkill
- test-driven-developmentSkill
- testing-strategySkill
- tooling-discoverySkill
- using-git-worktreesSkill
- using-lsp-toolsSkill
- using-skillsSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

