agentleFS
vintavinta/hal-9000/skills/pr/SKILL.md

pr

Skill142 starsChanged 22 days agoMITView on GitHub

Use when the user explicitly asks to push the current branch and open a PR, rewrite an open PR's body from its commits, or wait for CI and merge it

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create mode and update mode run these steps where they say "gather PR material":

    line 20
  2. Distinctive:

    Add pr skill for pushing branches and opening PRs

    line 35
  3. Distinctive:

    If exit code 0 (all checks passed):

    line 77
  4. Distinctive:

    If non-zero (check failed):

    line 80
  5. Very specific:

    Run gh pr checks once more to list failed checks and their URLs.

    line 81

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Invoking this skill IS the request. Your task is fully specified here. Never ask what to do.

Run every command bare, exactly as written below: git and gh find the repository from any subdirectory, and a cd does not carry over to the next Bash call in this fork. A cd ... && or $() prefix stops a command matching allowed-tools, and the merge then hits the permission gate.

The user invoked this skill with: "$ARGUMENTS"

Mode comes from the arguments first: create means create mode, update means update mode, merge means merge mode. With none of those three words, including an empty argument, run gh pr view --json state --jq .state 2>/dev/null and let its result decide: a non-zero exit (no PR for this branch) means create mode, OPEN means update mode, any other state means report that state and stop. Merge mode only ever comes from the argument.

PR material

Create mode and update mode run these steps where they say "gather PR material":

  1. git log --format='%n%s' --name-only main..HEAD (fall back to master..HEAD). Each commit is a block: its subject, then the files it touched. A flat log next to a branch-wide diff stat lets the writer guess which commit touched which file.
  2. The PR describes the net change of the branch. A commit whose subject starts with Revert " and the commit it names cancel each other when both sit in the log, as does a later commit that restores what an earlier one removed, and a subject starting with build: bump describes no change. Remove those blocks from the log before passing it on.
  3. git log --format=%b main..HEAD (same fallback). Collect every issue number written as #N or as a GitHub issue URL. Each one becomes a Fix #N line at the end of the body, one per line, no duplicates.
  4. Invoke the write-like-me skill. Pass as argument: "Write a GitHub PR title and body from the material below. Shape the draft as the title on the first line, a blank line, then the body, and nothing else: the caller splits on the first line, so a label or heading would land in the title. The draft goes straight into the caller's next gh command in the same response, never into a reply: a reply with no tool call ends the caller before the PR exists.

Title: one plain-English line under 72 chars that names the change itself, with no fix: or feat: type prefix. GitHub shows titles as plain text, so write file names bare, without backticks. Body: GitHub renders it as markdown, so wrap every file path, command, flag, and identifier in backticks, at every occurrence. Leave out changes a reviewer would not miss, such as ignore files, asset moves, and personal config tweaks, unless the branch holds nothing else. Body shape depends on how many separate changes are left.

One change: 1-3 sentences of prose, what changed and why, no list.

<example> Add pr skill for pushing branches and opening PRs

Adds a pr skill that pushes the current branch, drafts a PR title and body with write-like-me, and opens the PR with gh. Wires it into the plugin manifest and marketplace so it ships with hal-skills. </example>

Two or more changes: one - item per change, each item 1-3 short sentences stating the change and one before/after example when the change has a visible input and output. Give every item its example, not only the first.

<example> Move name-suffix into core rules and protect URLs and slashes
  • Move name-suffix from AI spacing into the core rules.
  • URLs are left alone. Anything starting with http:// or https:// is hidden from the rules, so %E4%B8%AD and /wiki/CJK#CJK survive.
  • / next to CJK never gets spaces anymore. CJK/CJK stays CJK/CJK, same as _. File paths still work: CJK/homeCJK becomes CJK /home CJK.</example>

<material>" followed by the log from step 2, then a closing "</material>" line.

  1. From write-like-me's output, take the first line as title, the rest as body. Append a blank line and the Fix #N lines from step 3 to the body.

Create mode

  1. git rev-parse --abbrev-ref HEAD — abort if main or master.
  2. gh pr view --json url 2>/dev/null — if a PR already exists, report its URL and stop.
  3. git push -u origin HEAD.
  4. Gather PR material.
  5. gh pr create --title "<title>" --body "<body>".
  6. Report the PR URL.

Update mode

  1. gh pr view --json url,state 2>/dev/null — abort if no PR or not open.
  2. git push, alone in its Bash call, every time: it prints Everything up-to-date when nothing is ahead. Abort if it fails.
  3. Gather PR material.
  4. gh pr edit --body "<body>" — the title stays as it is.
  5. Report the PR URL.

Merge mode

  1. gh pr view --json url,number,state — abort if no PR or not open.
  2. git push, alone in its Bash call, every time: it prints Everything up-to-date when nothing is ahead. Abort if it fails.
  3. git rev-parse HEAD, then gh pr view --json headRefOid --jq .headRefOid. If they differ, GitHub has not seen the push yet and gh pr checks would report the old head's runs: wait 15 seconds and compare once more, then abort if they still differ.
  4. gh pr checks --watch — blocks until all checks complete. Use a 10-minute Bash timeout. If the push sent commits and it reports no checks yet, the push just queued them: wait 15 seconds and run it again once. If the call times out instead, the checks are still running: run it again with the same timeout, and after a third timeout report the checks still pending and stop.
  5. If exit code 0 (all checks passed):
    • gh pr merge --merge --delete-branch. It also switches to the base branch, pulls it, and deletes the local branch.
    • Report: merged, remote and local branches cleaned up.
  6. If non-zero (check failed):
    • Run gh pr checks once more to list failed checks and their URLs.
    • Report which checks failed. Take no other action.

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.