agentleFS
Sign inStart free
gregwebsgregwebs/skills-sdlc/skills/pull-request/SKILL.md

pull-request

Skill20 starsChanged 44 days agoMITView on GitHub

Send a Github Pull Request of your work. Normally done after completing a ticket/issue. Check on CI and follow up on any failures.

  • 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 10 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

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

  • 0

    Common

    Most of the 48 edited versions we read keep these.

  • 17

    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:

    Update the default branch to the latest from the origin.

    line 23
  2. Distinctive:

    If you were already on the default branch, branch from there.

    line 24
  3. Distinctive:

    If it has been merged, then branch off the updated default (move your changes there).

    line 26
  4. Distinctive:

    If you are working on a sub issue of a parent issue, then look for an active parent branch to use as the base.

    line 29
  5. Distinctive:

    All sub issues that do not have dependencies should use the discovered default branch or the parent branch as their base branch.

    line 30
  6. Distinctive:

    If the issue requires an existing PR to be merged, then the base branch will be the branch for that PR.

    line 32
  7. Distinctive:

    Create it as a Stacked PR.

    line 33
  8. Distinctive:

    If the PR resolves an issue, ensure it is auto-closed by using the "Resolves" keyword: "Resolves #10".

    line 38
  9. Distinctive:

    When you write a commit message, follow these 7 rules: Rule 1: Separate the subject line from the body with a single blank line.

    line 40
  10. Distinctive:

    When CI access is available and the user requested PR follow-up, check the CI run for the PR.

    line 54
  11. Distinctive:

    If there are CI failures, investigate them and change the PR.

    line 55
  12. Distinctive:

    If the CI failures are not related to your work, suggest filing an issue or otherwise fixing them separately.

    line 57
  13. Distinctive:

    If they are related to your work, and the changes needed are not minor, fix them using the same workflow you used to write the code.

    line 58
  14. Distinctive:

    If CI is in progress and the branch has multiple commits, check if there are incomplete runs on older commits that can be canceled.

    line 60
  15. Distinctive:

    Before pushing the PR, squash merge commits into a useful history.

    line 64
  16. Distinctive:

    If additional commits added onto the PR are not useful for history

    line 66
  17. Distinctive:

    if it is best to squash merge the PR into a single commit, tell the user

    line 67

“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

Definitions

PR=Pull Request

Access

Access Github if the capability is available and the user instructs it.

  • skills
    • /github-app skill: push with ${CLAUDE_SKILL_DIR}/../github-app/scripts/gh-app.sh git push, then create the PR with ${CLAUDE_SKILL_DIR}/../github-app/scripts/gh-app.sh pr create
    • /github-actions-ci: check on CI with its bundled helper
  • Github API or MCP
  • github CLI

Branching

Update the default branch to the latest from the origin. If you were already on the default branch, branch from there. Otherwise, check if the current branch has been merged into the updated default (could be a squash merge). If it has been merged, then branch off the updated default (move your changes there). Otherwise, branch off of the current branch. First ensure the updated default is merged into it.

If you are working on a sub issue of a parent issue, then look for an active parent branch to use as the base. All sub issues that do not have dependencies should use the discovered default branch or the parent branch as their base branch.

If the issue requires an existing PR to be merged, then the base branch will be the branch for that PR. Create it as a Stacked PR.

Description

For the PR description, use the /document-changes skill. If the PR resolves an issue, ensure it is auto-closed by using the "Resolves" keyword: "Resolves #10".

When you write a commit message, follow these 7 rules: Rule 1: Separate the subject line from the body with a single blank line. Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit). Rule 3: Capitalize the first letter of the subject line. Rule 4: Do not end the subject line with a period. Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]". Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues. Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how; the message must explain the context and reasoning.

Check on CI

When CI access is available and the user requested PR follow-up, check the CI run for the PR. If there are CI failures, investigate them and change the PR.

If the CI failures are not related to your work, suggest filing an issue or otherwise fixing them separately. If they are related to your work, and the changes needed are not minor, fix them using the same workflow you used to write the code.

If CI is in progress and the branch has multiple commits, check if there are incomplete runs on older commits that can be canceled. Ask the user if you can cancel them unless you are already pre-authorized to cancel.

Cleaning up history

Before pushing the PR, squash merge commits into a useful history. Once the PR is opened, additional commits should be added on so reviewers can see additional changes. If additional commits added onto the PR are not useful for history

  • if it is best to squash merge the PR into a single commit, tell the user
  • otherwise offer to squash a subset of the commits together

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.

Check your setup, free