agentsclimarketplace

Pull request writer

Skill WasDavidOliveira/irracional-skills/pull-request-writer

Agent Skills para Cursor & Claude Code: revisão crítica + APIs Bun/Elysia/Drizzle/Zod — padrões que o chat não “inventa” de novo a cada conversa.

Install
npx -y skills add WasDavidOliveira/irracional-skills --skill pull-request-writer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when asked to write or review pull request descriptions, PR summaries, release notes from a PR, or changelog text based on a code diff, ensuring mandatory sections are complete, testable, and reviewer-friendly.

SKILL.md

3.6 KB, 743 tokens by cl100k_base, as published. Nobody here has run it

PR Description

Overview

Write PR descriptions that are short, verifiable, and reviewer-friendly. Always include the required sections in the exact order.

Required Structure

Use this structure in every PR description, in this exact order:

  1. Description of what was done
  2. What was changed
  3. How to test
  4. Breaking changes

Never omit sections. Do not add sections before these four. If optional content is not applicable, write N/A.

Output Contract (Strict)

  • Use the exact section titles shown above.
  • Keep the section order unchanged.
  • Do not use nested bullets.
  • Do not include generic placeholders like "general adjustments".

Writing Rules

  • Prefer objective language and concrete behavior changes.
  • Describe user and reviewer impact, not only implementation details.
  • Keep bullets flat and scannable.
  • Avoid vague statements without specifics.
  • In How to test, include reproducible steps and expected results.
  • Use simple language focused on clarity.
  • Avoid unnecessary jargon, internal slang, or tool noise.
  • Prioritize "what changed for users/reviewers" over implementation trivia.

Section Guidance

Description of what was done

Summarize intent and outcome in 2-4 lines. State what problem was solved and what behavior now exists. Invalid examples: "General refactor", "Various tweaks".

What was changed

List the main changes grouped by behavior or subsystem. Focus on relevant decisions and visible effects. Use 3-7 bullets. Each bullet should map to a concrete change.

How to test

Use mandatory format:

  • Prerequisites
  • Steps
  • Expected result

Include manual and automated validation when applicable. Use numbered steps in execution order. Each expected result must be observable.

Breaking changes

Explicitly state compatibility impact:

  • None
  • or precise migration/action required by consumers

Use this matrix:

  • If none: write None.
  • If present, include:
    • Impact
    • Who needs to act
    • Required migration
    • Timing/recommendation

PR Type Variants

If PR is mostly frontend, include:

  • affected navigation/routes
  • UI states (loading/error/success)
  • responsive and visual regression checks

If PR is mostly backend, include:

  • changed endpoints/contracts
  • changed business rules
  • compatibility impact on consumers

If PR is mostly infrastructure, include:

  • changed environment/configuration
  • deploy/rollback impact
  • operational risk and expected monitoring

Good vs Bad Examples

Description of what was done

Good: "Implements login with redirect to the requested route and clear temporary outage messaging." Bad: "Auth updates."

What was changed

Good: "- Extracted HTTP client into a shared layer with centralized error mapping." Bad: "- General improvements."

How to test

Good: "Numbered steps plus observable expected result for each step." Bad: "Test login and verify."

Breaking changes

Good: "None." Bad: "Might have impact."

Output Template

## Description of what was done
-

## What was changed
-

## How to test
### Prerequisites
- 

### Steps
1. 
2. 
3. 

### Expected result
- 

## Breaking changes
-

Review Checklist

Before finalizing, verify:

  • All required sections exist.
  • Section titles are exact and ordered.
  • How to test is executable by another engineer.
  • Breaking changes is explicit (never implicit).
  • Language is clear, objective, and low-jargon.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most pr commit review skills give in 743 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07

  • use conventional commits formatin 127 of 888, across 115 files
  • keep subject line under 72 charactersin 62 of 888, across 48 files
  • delete branches after mergein 51 of 888, across 38 files
  • use imperative mood in subject linein 51 of 888, across 42 files
  • use imperative mood in commit messagesin 44 of 888
  • verify directory is ignored before creating worktreein 43 of 888, across 12 files
  • generate a conventional commit messagein 43 of 888
  • add unignored worktree directories to gitignorein 42 of 888, across 10 files
  • make atomic commitsin 39 of 888, across 27 files
  • run tests before committingin 36 of 888, across 25 files
  • verify clean test baselinein 35 of 888, across 9 files
  • split unrelated changes into separate commitsin 35 of 888, across 30 files

Said here and by no other author read

  • Include required sections in exact order
  • Never omit sections
  • Write N/A for inapplicable optional content
  • Use exact section titles
  • Do not add sections before the four required ones
  • Keep bullets flat and scannable

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.