agentsclimarketplace

Pull request message

Skill ankitgoyalio/code-skills/pull-request-message

Agent Skills for Conventional Commits, maintainability code reviews, and pull request descriptions.

Install
npx -y skills add ankitgoyalio/code-skills --skill pull-request-message

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

One thing to look at

  • 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

Draft or revise pull request and merge request descriptions using this repository's repeated workflow that separates motivation, modifications, result, and verified validation. Use when asked to turn a diff, branch, commit list, issue, or existing draft into a concise reviewer-ready PR/MR message.

SKILL.md

3.7 KB, 751 tokens by cl100k_base, as published. Nobody here has run it

Pull Request Message

Core Workflow

  1. Determine the source material:
    • Current local changes.
    • A branch compared with a base branch.
    • A provided diff, commit list, issue, or existing PR/MR draft.
  2. If deriving from a repository, inspect only the smallest useful change set:
    • Run git status --short first.
    • If using current local changes, inspect git diff --stat, git diff, git diff --cached --stat, and git diff --cached as needed.
    • If using a branch comparison, identify the base branch, then inspect git diff --stat <base>...HEAD, git diff <base>...HEAD, and git log --oneline <base>..HEAD as needed.
  3. Summarize the problem the user encounters that this change addresses before describing the implementation.
  4. Draft the PR/MR message using the standard template unless the repository provides its own template.
  5. Include validation only when it was actually run or explicitly provided. If no validation information is available, include a placeholder such as Not run (reason not provided).
  6. Call out risks, migrations, rollout notes, screenshots, or follow-up work when they are relevant to reviewing or merging the change.

Standard Template

## Summary

<One or two sentences describing what this change does.>

## Motivation

<Why this change is needed, what problem it solves, or what context led to it.>

## Modifications

- <Concrete implementation change>
- <Concrete implementation change>
- <Concrete implementation change>

## Result

<What is different after this change lands. Describe user-visible, developer-facing, or operational impact.>

## Validation

- <Command, test, manual check, or "Not run" with a short reason>

Optional sections:

## Screenshots

<Before/after images or a note that screenshots are not applicable.>

## Risks and Rollout

- <Compatibility, migration, deployment, or rollback notes>

## Follow-ups

- <Known remaining work that is intentionally out of scope>

Drafting Rules

  • Prefer Summary over a one-line placeholder at the top. It gives reviewers an immediate answer before they read context.
  • Use Motivation for the "why", not an implementation recap.
  • Use Modifications for reviewable facts from the diff.
  • Use Result for behavior, workflow, API, or documentation impact after the change is merged.
  • Use Validation for tests and checks. Do not mix validation into Result.
  • Keep bullets specific and parallel. Start each bullet with an active verb when it reads naturally.
  • Do not invent issue IDs, benchmarks, screenshots, tests, approvals, or user impact.
  • If information is missing, write a clear placeholder such as Not run (reason not provided) rather than pretending the check happened.
  • Keep the final message concise enough for reviewers to scan.

Output Guidance

  • Provide a complete copy-ready PR/MR description.
  • If the user asks for feedback on a template, briefly explain improvements before giving the revised template.
  • If there are multiple reasonable levels of detail, default to the shorter version and include only review-critical context.
  • Mention any assumptions made from the diff or provided context.

Reference

For examples and template variants, read references/template.md only when the task needs additional examples or a different PR/MR style.

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

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

  • use conventional commits formatin 123 of 888, across 110 files
  • keep subject line under 72 charactersin 60 of 888, across 46 files
  • delete branches after mergein 50 of 888, across 37 files
  • use imperative mood in subject linein 50 of 888, across 41 files
  • use imperative mood in commit messagesin 45 of 888
  • generate a conventional commit messagein 42 of 888
  • make atomic commitsin 37 of 888, across 25 files
  • run tests before committingin 36 of 888, across 24 files
  • run project test suite to verify clean baselinein 35 of 888, across 7 files
  • run detected project setup commandsin 34 of 888, across 6 files
  • wrap commit body at 72 charactersin 32 of 888, across 25 files
  • split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

  • Determine the source material for the change
  • Inspect only the smallest useful change set
  • Summarize the problem before describing the implementation
  • Draft the message using the standard template unless provided
  • Include validation only when actually run or explicitly provided
  • Call out risks migrations rollout notes or follow-up work when relevant

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.