Pr hygiene

Skill iCodeCraft/anti-slop/skills/pr-hygiene

Drop-in skills that stop AI coding agents from shipping garbage — kill-slop, security-review, PR hygiene

Install

npx -y skills add iCodeCraft/anti-slop --skill pr-hygiene

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

18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
23 stars23 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

Make PRs merge-ready — tight scope, clear description, no leftover debug, honest test notes. Use when opening a PR, writing a PR description, cleaning a branch before review, or when the user mentions pull request, merge-ready, or PR hygiene.

SKILL.md

1.7 KB, as published. Nobody here has run it

PR Hygiene

Turn the current work into a PR a human can review in one pass.

Before opening

Branch contains one logical change (or clearly labeled stacked commits)
No leftover console.log, debugger, TODO: temp, commented-out blocks you added
No unrelated formatting-only churn
Secrets, .env, and local-only files are not staged
Diff matches the stated goal — nothing "extra helpful"

Description template

Use this structure (adapt section names to the host: GitHub/GitLab):

## Summary
<1–3 bullets: what and why>

## Test plan
- [ ] <how you verified>
- [ ] <edge case worth checking>

## Notes
<risks, follow-ups, screenshots if UI>

Commit / PR title

Imperative, specific: fix checkout: reject expired discount codes
Not: update stuff, fix, WIP, address comments

Reviewer empathy

Call out:

Files that look scary but are mechanical (renames, generated)
Behavior that changed for callers/API consumers
Anything you are unsure about

Anti-patterns

NEVER mix refactor + feature + dependency bump in one PR unless required
NEVER force-push shared branches without warning
NEVER open a PR with "tests TBD" and no plan
NEVER bury breaking changes in the middle of the description

If asked to open the PR

Summarize the diff in your own words first
Draft title + body with the template
List residual risks in one short section