agentleFS
Sign inStart free
AkylasAkylas/oss-weather/.claude/skills/open-pr/SKILL.md

open-pr

Skill459 starsChanged 3 months agoMITView on GitHub

MANDATORY skill for ALL pull requests. Must be used EVERY TIME before creating any pull request. No exceptions.

  • Commits and pushes

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 60 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    ALWAYS: run git push and check for errors returned by any git hooks / CI (this repo has no local husky hooks, so commitlint runs in CI — a …

    line 13
  2. Distinctive:

    ALWAYS: create the PR as draft:

    line 15
  3. Very specific:

    ALWAYS: use --draft — only the user decides when a PR is ready for review

    line 25
  4. Distinctive:

    If the description reads like a changelog of every diff, it's wrong.

    line 36
  5. Very specific:

    Keep it lean: ## Summary, an optional ## Testing, and the Fixes #<issue> line when an issue exists.

    line 54

“Common” is measured: kept by at least 6 in 10 of the 60 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

Generating Pull Requests

Mandatory Process

--auto (caller runs autonomously): skip step 0 sign-off and any push/PR approval wait — proceed directly. Still fix push-hook errors, still --draft.

  1. ALWAYS ensure the change was verified before opening the PR. For logic changes this means the relevant Vitest tests pass (npx vitest run <path>) and yarn svelte-check is clean; for UI/behavioral changes, confirm it by running the app (ns run ios / ns run android), or — when a native run isn't possible — flag that a visual check is still required. Propose the scenarios to verify.
  2. ALWAYS run git push and check for errors returned by any git hooks / CI (this repo has no local husky hooks, so commitlint runs in CI — a bad conventional-commit title/message will fail there, not on push)
  3. ALWAYS fix any errors — autofixup into the relevant commits, or create a new commit if autofixup does not apply
  4. ALWAYS create the PR as draft:
    1. This repo has no .github/PULL_REQUEST_TEMPLATE.md. Read it only if one exists and mirror its structure; otherwise write a clean default body (see "Writing the description" + "Default body" below).
    2. CRITICAL: --template and --body are mutually exclusive in gh pr create. Always use --body with an inline multiline string, never --template:
      gh pr create --draft --title "fix(camera): ..." --body "$(cat <<'EOF'
## Summary
...
EOF
)"
    3. ALWAYS use --draft — only the user decides when a PR is ready for review
    4. The PR title ALWAYS follows the Conventional Commits header (<type>(<scope>): <subject>) — same convention as the commit skill. The squash-merge uses this title as the changelog entry, so it must be a valid conventional commit
    5. ALWAYS reference the tracking issue in the body: Fixes #<issue> / Closes #<issue>

Writing the description

The description is for a human reviewer who needs to grasp what this PR does at a glance. Write the kind of summary you'd write by hand.

  • Summarize the main changes only — the meaningful, functional changes a reviewer needs to know about. A few clear bullet points or short sentences is enough.
  • NEVER dump commit details — do not paste commit messages, do not write a commit-by-commit breakdown. The git history already holds that; repeating it just adds noise.
  • Skip non-important changes — small refactors, formatting, renames, lint fixes. They dilute the signal; leave them out.
  • If the description reads like a changelog of every diff, it's wrong. Clear, concise, high-level — that's the bar.

Default body (no PR template)

The repo has no PR template, so use this structure:

## Summary

<1-4 bullets of the meaningful changes>

## Testing

<what you ran / what still needs a manual visual check>

Fixes #<issue>

Keep it lean: ## Summary, an optional ## Testing, and the Fixes #<issue> line when an issue exists. Add a ## Breaking changes section only when the PR truly breaks something (impact + migration path).

If a template ever gets added

If .github/PULL_REQUEST_TEMPLATE.md exists, mirror its structure instead. The <!-- ... --> HTML comments in it are instructions to the author, not content — strip every one out; they must never appear in the final PR body. Check ([x]) only checklist boxes that genuinely hold; never check a box that isn't true.

Download now (ZIP)

  • Other versions62 projects use a version of this.

    Word for word · 1

    1. Akylas/OSS-DocumentScanner★ 2.6k100% same

    Edited · 0

    None found.

    Wrote their own version · 61

    1. Significant-Gravitas/AutoGPT★ 188ksame name
    2. storybookjs/storybook★ 91ksame name
    3. pascalorg/editor★ 25ksame name
    4. dask/dask★ 14ksame name
    5. polarsource/polar★ 10ksame name
    6. cloudflare/agents★ 5.9ksame name
    7. Kiln-AI/Kiln★ 5.2ksame name
    8. analogjs/analog★ 3.2ksame name
    9. raine/workmux★ 3ksame name
    10. testcontainers/testcontainers-node★ 2.6ksame name

    51 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use address-review, commit-push and 9 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.
    • 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

    • DataCoveySkill

      commit-push

      Commit and push the changes made on this chat session to the current branch. Use best practices from Conventional Commits.

      Also in 3 projects that use this

    • raineSkill

      rebase

      Rebase the current branch with smart conflict resolution.

      Also in 3 projects that use this

    • DockerSkill

      review-pr

      Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.

      Also in 9 projects that use this

    • MicrosoftSkill

      worktree

      Create, reuse or clean up a dedicated git worktree for working on a pull request or a private branch. Use from any PR-scoped workflow that needs an isolated checkout to keep current code and build output untouched.

      Also in 3 projects that use this

    • HashiCorpSkill

      changelog

      Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.

      Also in 4 projects that use this

  • In this repository11 other files it gives its agents.

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.

Check your setup, free