agentleFS
ronaknnathanironaknnathani/relay/skills/open-pr/SKILL.md

open-pr

Skill43 starsChanged 4 months agoMITView on GitHub

Stage, commit, push, and open a pull request following the author's repository and AGENTS.md conventions — repo-style commit messages, a prose PR summary, and a Testing Done command list. Use when work is finished and the caller wants it committed and a PR opened. Supports --draft and an optional local review before push.

  • Commits and pushes

62 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use review-change, commit-push and 8 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.
  • thlaureSkill

    review-change

    Use this skill when the user asks for a code review, a correctness pass, a check before PR, or asks whether a Signalist change follows project conventions.

    Also in 4 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

  • Codagent-AISkill

    implement-change

    Implements an approved change in one continuous session, with tiered test runs. Use when asked to implement a change from its approved definition, or to invoke codagent:implement-change.

    Also in 3 projects that use this

  • 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

  • SentrySkill

    write-tests

    Write tests following project conventions. Use when adding new tests or modifying existing ones.

    Also in 4 projects that use this

  • HashiCorpSkill

    changelog

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

    Also in 5 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 61 edited versions we read keep these.

  • 0

    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. Very specific:

    Branch-if-on-default gate: Never commit straight onto the default branch.

    line 21
  2. Very specific:

    Use the runtime-provided model identity when available, and the agent's verified no-reply identity for the email.

    line 36

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

Open PR

Take finished work from working tree to open pull request: stage specific files, commit with a repo-style message, push, and open the PR in the author's house style. Read <repo>/AGENTS.md and ~/.config/agents/AGENTS.md first (repo-specific rules win) and follow those preferences for commit messages and PR descriptions. Execute git/gh operations through this skill's bundled scripts/open-pr.sh helper rather than inlining command sequences in the skill.

Flags

  • --draft — open the PR as a draft (gh pr create --draft). Default is open (ready for review).
  • --no-review — skip the optional local review before push.

Process

  1. Branch-if-on-default gate. Never commit straight onto the default branch. Invoke the helper's ensure-branch <slug> command. It hard-fails if the default branch cannot be detected and, when a new branch is needed, reads the branch prefix from the first-time relay config (relay config branch-prefix) rather than hardcoding a personal prefix.
  2. Stage specific files. Invoke the helper's status command, then its stage -- <files...> command for exactly what belongs in this change — never stage the whole tree. Confirm the diff carries no secrets and no formatting churn mixed in with behavior.
  3. Commit in the repo's style. Match the repository's recent commit style and the AGENTS.md preferences. Do not force Conventional Commits unless the repo already uses them. The subject should lead with what changed; include a body only when useful, and make it explain why the change exists rather than restating the diff. Keep refactor commits separate from feature/fix commits (split with separate stage/commit helper calls if both are present). End every message with a Co-authored-by trailer for the actual model/agent currently doing the work; never hardcode a model. Use the runtime-provided model identity when available, and the agent's verified no-reply identity for the email. Then invoke the helper's commit <message-file> command.
  4. Local review before push (skip with --no-review). Review the full diff from the helper's diff command for correctness and leftover debris before it leaves your machine. Dispatch the review skill as a sub-agent when available; otherwise scan it inline.
  5. Push. Invoke the helper's push command.
  6. Prefer the repo's PR template. Fetch it and fill each section from the actual change; only fall back to the body in step 7 when none exists. Use the helper's pr-template command to fetch it.
  7. Open the PR. Title follows the repo's PR-title style. Body follows AGENTS.md: one or two short prose paragraphs focused on why/what, no bullet list, no per-file walkthrough, and a Testing Done section containing only the commands run. Disclose automated authorship with the actual agent/model used, not a hardcoded Claude footer. Add --draft to the helper call only when the caller passed it, and invoke create-pr --title <title> --body-file <body-file>.
  8. Return the PR URL that gh pr create prints, to the caller.

PR body conventions

The body format is in step 7; the red flags and checklist below guard it. The one rule not covered there:

  • Disclose agent authorship in any PR comment you post — mark it as written by an automated agent on the author's behalf; never phrase it as the author's own words.

Red flags

  • Committing onto the default branch instead of branching first.
  • git add . / git add -A instead of staging the specific files.
  • A PR summary that is a bullet list, or that enumerates each file/caller and how the code works.
  • A Testing Done section padded with prose or per-command descriptions instead of bare commands.
  • Refactor squashed into the same commit as a feature/fix; formatting churn mixed with behavior.
  • A commit body that restates the diff ("what") instead of the reason ("why").
  • Hand-rolling a body when the repo ships a PR template; assuming main/master as the base.
  • Missing the actual-model Co-authored-by trailer or automated-authorship disclosure.

Verification checklist

  • HEAD is on a branch using the configured relay branch prefix, not the default branch.
  • Only the intended files were staged (no git add .); diff has no secrets or stray formatting.
  • Commit message matches repo/AGENTS.md style, includes the actual-model Co-authored-by trailer, and keeps refactor separate.
  • PR summary is 1–2 prose paragraphs on why/what — not bullets, not a file-by-file how.
  • Testing Done is just the list of commands run; body discloses the actual automated agent/model.
  • Repo PR template used when present; base branch detected dynamically; --draft applied only if requested.
  • The PR URL was returned to the caller.

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.