agentleFS
drinkspillerdrinkspiller/skills/pull-request/SKILL.md

pull-request

Skill1 starsChanged 5 days agoUnlicenseView on GitHub

Create or update a GitHub Pull Request for any Git repository. Auto-discovers the repo, base branch, and pre-flight commands from the working directory. Prompts the user only when ambiguous.

  • Commits and pushes

53 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use issue-campaign, contracts 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.
  • samchonSkill

    issue-campaign

    Defines the default solo repository-wide issue campaign for typia: exhaustive discovery, lead-vetted issue publication, one unified CI-validated implementation pull request per cycle, solo Self-Review, and repeated rediscovery until a full clean round. Use for broad audits, many issue candidates, or repeated issue-to-pull-request campaigns unless the user explicitly requests parallel or multi-agent execution; do not use for one already-defined issue or an ordinary pull request.

    Also in 3 projects that use this

  • AnthropicSkill

    contracts

    Answer a question across a corpus of contract documents with verified citations. Use when the user asks what a contract says, which contracts have a clause, what changed between amendments, or any question that needs reading and citing across a set of contract files. The corpus must be on the local filesystem (see README).

    Also in 3 projects that use this

  • mfang0126Skill

    development

    Full-stack development workflow skill. Guides the complete cycle from understanding requirements to shipping code via PR with Preview validation.

    Also in 3 projects that use this

  • dragonflydbSkill

    benchmark

    Benchmark Dragonfly (and compare against Valkey/Redis) on local or remote cloud instances, then produce a performance + memory report with charts and a raw-data appendix. Use this whenever the user runs /benchmark, or asks to benchmark / load-test / measure throughput, QPS, latency, or memory efficiency of Dragonfly or another Redis-compatible server, to compare Dragonfly vs Valkey or Redis, or to generate a benchmark report. Trigger it even when the user just describes the goal ("see how fast Dragonfly is on this box", "compare memory per key vs Valkey") without saying the word "benchmark".

    Also in 4 projects that use this

  • VercelSkill

    gh-stack

    Manages stacked PRs and splits multi-part work into reviewable branches with gh-stack. Use for stack creation, viewing, edits, push, submit, sync, rebase, merge, or checkout; when asked to split or isolate work for review; whenever a user mentions a stack, branch layers, dependent PRs, or gh stack; or when a stack is checked out.

    Also in 3 projects that use this

  • carapace-shSkill

    git

    Use when working with Git — object model, references, index, branching, merging, rebasing, remotes, diffs, config, hooks, worktrees, submodules, and plumbing commands. Triggers on: "git", "git branch", "git commit", "git merge", "git rebase", "git checkout", "git stash", "git reset", "git submodule", "git worktree", "git blame", "git bisect", "git reflog", "git hooks", "git config".

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 12 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 48 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    All commands run from the root of the current Git repository.

    line 11
  2. Distinctive:

    Before anything else, detect the repository context:

    line 15
  3. Distinctive:

    If this fails, the current directory is not a Git repo.

    line 23
  4. Very specific:

    Prefer pnpm over npm if a pnpm-lock.yaml exists.

    line 63
  5. Distinctive:

    Only run commands for which the indicator file exists.

    line 64
  6. Very specific:

    Check package.json scripts keys before running — if test, lint, or build scripts are absent, skip that step.

    line 66
  7. Distinctive:

    If any step fails, stop and present the errors.

    line 69
  8. Very specific:

    If not authenticated, ask the user to run gh auth login.

    line 80
  9. Distinctive:

    If there are uncommitted changes, ask the user:

    line 90
  10. Distinctive:

    If yes, invoke the commit-message skill or help generate a commit message.

    line 94
  11. Distinctive:

    Wait for their response.

    line 110
  12. Very specific:

    If a subset is selected, create a new branch from origin/$BASE and cherry-pick the selected commits:

    line 112
  13. Distinctive:

    If an existing PR is found, present it and ask:

    line 134
  14. Very specific:

    Push: Run git push -u origin "<branch>" and stop.

    line 145
  15. Very specific:

    View: Run gh pr view "<branch>" --web and stop.

    line 148
  16. Distinctive:

    Use the commit log and diff (truncate diff to 20k chars) to generate a concise PR title and a detailed PR description in markdown with …

    line 160
  17. Distinctive:

    Present the generated title and description to the user: Ask:

    line 169
  18. Distinctive:

    Wait for their response. Iterate until accepted.

    line 179

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

All commands run from the root of the current Git repository.

Environment Discovery

Before anything else, detect the repository context:

  1. Locate the repo root:

    git rev-parse --show-toplevel

    If this fails, the current directory is not a Git repo. Stop and ask the user to navigate to a Git repository or specify one.

  2. Detect the remote repo identifier (for gh pr create --repo):

    git remote get-url origin

    Parse the owner/repo from the URL (handles both SSH git@github.com:owner/repo.git and HTTPS https://github.com/owner/repo.git formats). If the remote is not GitHub-hosted (e.g., GoB, GitLab, Bitbucket), stop and inform the user that this skill targets GitHub PRs via gh.

  3. Detect the default base branch:

    gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

    Fall back to main if gh is unavailable or the query fails. Store as $BASE.

Pre-flight Checks

Auto-discover and run the project's quality gates. Check for the presence of these files in the repo root, in order:

Indicator fileTest commandLint commandBuild command
package.jsonnpm test or pnpm testnpm run lint or pnpm lintnpm run build or pnpm build
Makefilemake testmake lintmake build
Cargo.tomlcargo testcargo clippycargo build
go.modgo test ./...golangci-lint rungo build ./...
BUILD / BUILD.bazel(skip — use blaze/bazel test)buildifier -lint=warnblaze build or bazel build
pyproject.toml / setup.pypytestruff check .(skip)

Rules:

  • Prefer pnpm over npm if a pnpm-lock.yaml exists.
  • Only run commands for which the indicator file exists. If none are found, skip pre-flight and inform the user.
  • Check package.json scripts keys before running — if test, lint, or build scripts are absent, skip that step.

If any step fails, stop and present the errors. Ask the user whether to fix the issues or bypass and continue.

Verify Prerequisites

  1. Verify GitHub CLI:

    gh auth status

    If not authenticated, ask the user to run gh auth login.

Uncommitted Changes

  1. Check for uncommitted changes:

    git status --porcelain

    If there are uncommitted changes, ask the user:

    You have uncommitted changes. Commit them before creating the PR?

    If yes, invoke the commit-message skill or help generate a commit message.

Commit Selection

  1. Fetch latest remote and list commits unique to this branch:

    git fetch origin "$BASE" 2>/dev/null; git cherry -v "origin/$BASE" HEAD

    Parse the output. Lines starting with + are commits unique to this branch. Present the list to the user and ask:

    These commits will be included in the PR. Include all, or select a subset?

    Wait for their response.

    If a subset is selected, create a new branch from origin/$BASE and cherry-pick the selected commits:

    git checkout -b <new-branch-name> "origin/$BASE"
    git cherry-pick <hash1> <hash2> ...

Check for Existing PR

  1. Get the current branch:

    git branch --show-current
  2. Check for an open PR on this branch:

    gh pr list --head "<branch>" --json url,number,title,body,headRefOid --state open

    If an existing PR is found, present it and ask:

    A PR already exists for this branch: <url>

    1. Push & Update (add new commits)
    2. Update Title & Description only
    3. View in Browser
    4. Exit

    Wait for their response.

    • Push: Run git push -u origin "<branch>" and stop.
    • Update: Continue to the title/description steps below, then use gh pr edit.
    • View: Run gh pr view "<branch>" --web and stop.
    • Exit: Stop.

Generate PR Content

  1. Generate title and description. Get the commit log and diff:

    git log "origin/$BASE..HEAD" --oneline
    git diff "origin/$BASE...HEAD"

    Use the commit log and diff (truncate diff to 20k chars) to generate a concise PR title and a detailed PR description in markdown with sections:

    • ## Summary — what changed and why.
    • ## Key Changes — file-by-file or logical grouping of modifications.
    • ## Security Considerations — any auth, input validation, or data handling changes.
    • ## Verification Results — output of pre-flight checks.
  2. Present the generated title and description to the user. Ask:

    Here is the proposed PR:

    Title: <title>

    Description: <description preview>

    Accept, suggest improvements, or edit manually?

    Wait for their response. Iterate until accepted.

Create or Update PR

  1. Push the branch:

    git push -u origin "<branch>"
  2. Create or update the PR:

    For a new PR:

    gh pr create --repo "<owner>/<repo>" --title "<title>" --body "<body>" --base "$BASE"

    For updating an existing PR:

    gh pr edit <number> --title "<title>" --body "<body>"
  3. Present the PR link prominently in the response:

    PR created: https://github.com/<owner>/<repo>/pull/<number>

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.