Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →milanvrskovy/reasoning-trail
Generate a concise, reviewer-optimised PR description by extracting decisions and reasoning from the current conversation. Trigger whenever the user says 'generate reasoning trail', 'generate PR summary', 'PR description', 'write up for code review', 'summarise this for a PR', 'generate review summary', or similar. Also trigger when the user asks to summarise design decisions, refactoring rationale, or implementation reasoning for peers or reviewers.
Passed 18 of 22 test cases with the skill, and 12 of 22 without it.
and 5 more in the full report
9 fixed9 passed either way1 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
Here is a quick chat log where we discussed updating our internal logging SDK from v2.1.0 to v2.4.0. No architectural changes were made, just updating version numbers and adjusting one deprecated parameter name. Produce a markdown file `pr-summary-sdk-bump.md` structured for code review.
| Checked | Without skill | With skill |
|---|---|---|
| Contains a single sentence in Why this approach stating no design decision was involved. | Missed | Passed |
The instructions your model reads when the skill loads.
Generates a structured PR description from a conversation that contains design decisions, architecture discussion, refactoring rationale, or implementation work. The output is written for a reviewer who was not in the conversation and is reading the code cold.
Try removing a line. If removing it does not harm the reviewer's understanding, the line was good to remove.
Every sentence must earn its place. The summary is not a transcript of the conversation. It is the compressed reasoning trail: only the decisions that survived, the arguments that won, and the things the reviewer needs to verify. Iteration history, rejected tangents, and discovery steps that led nowhere are cut unless a rejected alternative clarifies why the chosen approach is better.
Generate a single markdown document. Use exactly these sections in this order. Omit a section only where the rules below explicitly say to.
# <Short imperative title describing the change>
## Context
<2-3 sentences. What problem is being solved. No assumed prior knowledge.>
## What changed
<Structural and/or behavioral summary. Describe the shape of the change, not a file-by-file diff. Prose for simple changes; short list for multi-part changes. Each item is a full sentence.>
## Why this approach
<The core reasoning. Why this design over alternatives. Fold rejected alternatives in here when they sharpen the argument -- "X was considered but rejected because Y" -- not as a separate catalogue. This section is the primary value of the summary; it captures what the diff cannot show.>
## Behavioural impact
<Breaking changes, behavioural equivalence, or net-new behaviour. For refactors: explicit equivalence claims with the specific evidence (e.g. "Pattern X guarantees Y, so the new extraction is equivalent"). For new features: what existing behaviour is affected, if any.>
## Review focus
<Where the reviewer should spend their time. Concrete: name the methods, files, edge cases, or open questions. If something was verified during the conversation but should be double-checked, say so.>
## Files changed
<One line per file: filename and what changed in it. Omit for PRs with 1-2 files where "What changed" already covers it.>
test cases passed, vs 12 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.