pr-description

Files (1)

• SKILL.md

SKILL.md (first lines)

# PR Description

Create a short, accurate description that lets a reviewer understand the purpose, shape, compatibility impact, and best review path without restating the diff.

## Workflow

1. Inspect the diff against the requested base branch or commit. Use the repository's default branch when none is given.
2. Verify important claims in the changed source and tests. Do not infer behavior from filenames alone.
3. Group details by outcome, not by file.
4. Apply the `show-me` skill to express the change with the smallest useful inline visual.
5. Return a short title followed by the four required sections below.

## Required Output

### Goal

Explain in one short paragraph:

- why the change is needed;
- what outcome it delivers;
- who or what is affected.

### Changes

Summarize the meaningful behavioral or architectural changes in a few bullets. Add one or more visuals that make the change easier to understand.

Use `show-me` to choose the visual form:

- a `diff` sketch for before/after structure or behavior;
- a Mermaid flowchart or sequence diagram for component, data, or request flow;
- a call tree for runtime control flow;
- a shallow file or component tree for changed ownership or boundaries.

Keep visuals inline and close to the bullet they explain. Prefer one visual; add another only when it explains a distinct aspect. Include only verified names, relationships, and states. Do not create HTML or external diagram files for a PR body.

### Breaking Changes

Always fill this section.

- Write `None` when the diff introduces no breaking change.
- Otherwise state what breaks, who is affected, and the required migration or rollout action.
- Treat incompatible API, schema, configuration, event, persistence, output-format, required-workflow, and deployment changes as breaking changes.

### Reviewer Guide

Give the reviewer a compact, ordered path through the change:

1. where to start, using repository-relative paths or real symbols;
2. which decisions, invariants, or risky boundaries deserve attention;
3. which tests or checks demonstrate the intended behavior.

Mention only relevant files and checks. Do not turn this section into a file inventory or repeat the Changes section.

## Writing Rules

- Keep every required section, and fill it with change-specific information.
- Prefer outcomes and contracts over implementation narration.
- Keep the title and prose neutral, direct, and concise.
- State uncertainty when the available diff does not prove a claim.
- Do not include raw logs, private reasoning, decorative visuals, a full file list, or a related-issue placeholder.

## Template

```md
# <short PR title>

## Goal

<why this change exists and its outcome>

## Changes

- <meaningful change>

<one or more focused inline visuals>

## Breaking Changes

None

## Reviewer Guide

1. Start with `<path or symbol>` to understand <reason>.
2. Check <decision, invariant, or risk> in `<path or symbol>`.
3. Verify <behavior> with `<test or check>`.
```

From faridz974/skills, MIT.

More from faridz974/skills