agentleFS
Kuan-AI-comKuan-AI-com/agent-skills/skills/pr-description/SKILL.md

pr-description

Skill0 starsChanged 6 days agoMITView on GitHub

Write a pull request title and description for the current branch, and open the PR if asked. Use when the user says "open a PR", "create a pull request", "write the PR description", "describe my changes for review".

  • Commits and pushes

96 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ao-desktop-dev, bug-triage and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • agentlab-inSkill

    ao-desktop-dev

    Launch, restart, or troubleshoot the real AO Electron desktop app from this repository; run a checkout against isolated or real local AO data; combine PR branches for local UI review; and diagnose stale Electron processes, port conflicts, or preload bridge mismatches. Use whenever asked to run, open, show, or visually verify AO frontend changes in the actual desktop app rather than ao preview, dev:web, or mock data.

    Also in 4 projects that use this

  • jMertaSkill

    bug-triage

    Use when the user reports a bug, regression, runtime error, failing build, or broken test and wants reproduction, diagnosis, root-cause analysis, or an authorized fix. Isolates the shared cause and verifies the smallest relevant change.

    Also in 4 projects that use this

  • saffron-healthSkill

    address-review

    Address PR review comments systematically. Use when responding to code review feedback on a pull request.

    Also in 3 projects that use this

  • NVIDIASkill

    writing-docs

    Use when adding or changing user-facing behavior or documentation in Megatron-Energon, or when creating new .py, .sh or .md files that need license headers.

    Also in 3 projects that use this

  • Sagargupta16Skill

    dependency-audit

    Audit project dependencies for security vulnerabilities, licensing issues, maintenance health, and optimization opportunities. Use it during regular security audits (monthly or quarterly); before a major release when you want to ensure the dependency tree is clean; when evaluating whether to adopt or replace a dependency; after a security advisory affects one of your dependencies; when your install times or bundle sizes have grown noticeably.

    Also in 3 projects that use this

  • PydanticSkill

    i-have-adhd

    Shape every response for an ADHD reader who reviews the work but does not do the coding — the agent does. Use whenever responding to ANY message — coding, debugging, planning, casual. Lead with the result or the decision. Surface anything needing the user's input as a structured question, never buried in prose they'll skim past. No preamble, no recap, no closers. State errors matter-of-factly. Make finished work visible. Trigger even on casual messages and even when brevity wasn't requested.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 91 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the diff of the files that carry the logic (skip lockfiles, generated code, snapshots).

    line 13
  2. Distinctive:

    Call out anything a deploy needs: new env vars, migrations, feature flags, order of deploys.

    line 43
  3. Distinctive:

    Do not paste the diff or list every file.

    line 46

“Common” is measured: kept by at least 6 in 10 of the 91 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Pull request description

1. Gather facts

  • Base branch: the one the user names, else git symbolic-ref refs/remotes/origin/HEAD, else ask. Do not assume main.
  • git status: if there are uncommitted changes, ask whether they belong in the PR.
  • git log <base>..HEAD --oneline and git diff <base>...HEAD --stat.
  • Read the diff of the files that carry the logic (skip lockfiles, generated code, snapshots). Describe what the code does, not what file names suggest.
  • Linked issue: look in branch name and commit messages (#123, PROJ-123).
  • Template: use .github/pull_request_template.md (or PULL_REQUEST_TEMPLATE/, docs/) if it exists. Fill its sections; do not replace it with your own.

2. Write it

Title: under 70 characters, the outcome. Match the repo's title convention (check recent PRs with gh pr list --state merged --limit 10 if available).

Body (when there is no template):

## What
- 2-5 bullets of behavior changes, most important first.

## Why
The problem or goal in 1-3 sentences. Closes #123.

## How to test
1. Exact commands or clicks a reviewer can repeat.
2. Expected result for each.

## Risks
Migrations, config or env changes, breaking API changes, performance, rollout order. "None known" if none.

## Notes for reviewers
Where to start reading, what is mechanical (renames, moves), anything you want a second opinion on.

Rules:

  • "How to test" lists what you or the user actually ran. If nothing was run, say so instead of inventing steps that look verified.
  • Call out anything a deploy needs: new env vars, migrations, feature flags, order of deploys.
  • UI change: say screenshots are needed, or attach them if available.
  • Over ~400 changed lines (excluding generated files): suggest splitting, or explain the order to read it in.
  • Do not paste the diff or list every file.

3. Open the PR (only if asked)

  • Push the branch if it is not on the remote: git push -u origin HEAD.
  • With GitHub CLI, write the body to a temp file and run gh pr create --base <base> --title "<title>" --body-file <file>. Add --draft if work is unfinished.
  • Without gh, give the user the title and body to paste.
  • Print the PR URL at the end.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.