pr

A command for preparing and opening a pull request, which is a proposed change submitted for review before merging into a code repository.

In plain words
What is it for?
Use it to run project checks, follow the repository workflow, keep feature work in a separate worktree, and prepare a reviewable pull request.
Why use it?
It checks repository rules, existing pull requests, blocking problems, and exposed information before the request is opened.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/azrtydxb/procoder/pr
Clone the repo
git clone --depth 1 https://github.com/azrtydxb/procoder
Per session 20 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,084 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00020 $0.01084
Opus 5 $0.00010 $0.00542
Sonnet 5 $0.00004 $0.00217
Haiku 4.5 $0.00002 $0.00108

Measured 2d ago against content hash d61afcdedf49, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

pr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.kilo/commands/pr.md · 81 lines

How it starts

The opening of the file, as written. The whole thing — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.

The user invoked /procoder:pr with arguments: $ARGUMENTS

Every procoder command below is the procoder binary on PATH.

  1. Read .procoder/github/WORKFLOW.md and follow it — the repo's rules win over this skill's defaults. If it is missing, get the default via procoder templates, write it, then follow it. Default rule: feature work happens in a git worktree (one per branch/agent), never dirtying the default-branch checkout — if this work isn't in one yet, note it and keep the branch clean.

0b. If this branch closes a tracked issue, check whether a pull request is already open for it: gh pr list --state open --search "<issue number>", and the issue's own timeline. Compare each result's head branch against this one. The only PR that is not a reason to stop is the one whose head IS this branch — push to that rather than opening a second one. Anything else, including your own older branch and an agent working under the same account, is somebody already on it: review theirs instead. A second PR for the same fix wastes the reviewer and, when the other one is a contributor's, costs the contributor.

  1. Run procoder git and procoder check. Fix everything BLOCKING before going further — a PR that fails its own gate wastes the reviewer. The gate's info impact lines are the change's blast radius: open each referencing file it names and verify the change breaks nothing there (or run procoder index impact for the full list).
  2. Read the real diff (git diff <default-branch>...HEAD) and the commits. Summarise what actually changed, not what you remember intending.

2a. The docs-impact question — MANDATORY, answered in writing before the self-review: "What does this change alter about what a reader must be told?" Features change the story, not just the reference. Answer with either the list of pages updated (README narrative, docs site pages, the command reference) or the explicit sentence "no reader-visible change because ". A PR without this answer does not get opened — docs lag was our longest-lived escaped-finding class, and mention-checks alone did not catch it (the gate's README must mention families are the mechanical floor, this question is the judgment ceiling).

2b. The pre-PR self-review — the first fresh pair of eyes is OURS, not the downstream reviewer's:

  • Read .procoder/github/REVIEW.md (missing → procoder templates prints the default; write it first).
  • Dispatch a FRESH-context reviewer subagent — not yourself; the author's context hides the author's blind spots — with: the rubric verbatim, the branch diff, and the instruction to report findings as file:line, what breaks, and the fix, ending with a severity-counted verdict or exactly "Nothing found — open the PR."
  • Give that same agent the SECOND lens in the same pass, quoted from /procoder:simplify the way the rubric is quoted: the five tags with their definitions, the one-line finding format <file>:L<line>: <tag> <what>. <replacement>., the rule against inventing a finding, and the exact null result Lean already. Ship. Scope it to the DIFF — the repo sweep belongs to /procoder:release.
  • Report the simplify findings first, the correctness verdict last.
  • Fix every Critical/Important finding (commit them), decide each cut — taking it or saying why not, P-CONTROL — re-run procoder check, and only then continue. Downstream bot reviews are the fallback net — anything they catch later becomes a lesson (see /procoder:merge's reflection step).
  1. Fill .procoder/github/PULL_REQUEST_TEMPLATE.md section by section from that diff. If the template is missing, get it via procoder templates, write it, then fill it.
  2. Write the drafted title and body to a temp file and run procoder scrub <file>. It must say clean — no Co-Authored-By, no "generated with", nothing presenting the work as an AI's. Fix and re-scrub until clean.
  3. Keep the title at 72 characters or fewer — it becomes the squash commit's subject and our own gate flags longer ones.
  4. Show the user the final title and body BEFORE creating anything.
  5. Create the PR with gh pr create --title ... --body-file .... If gh is missing, run procoder init first.
  6. Hand off to /procoder:merge for the gates-and-reviews phase, or offer to run it now.

Read the full file on GitHub · 81 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 81 lines · 20 tokens per session scan A d61afcdedf49

Subscribe to this mod's changes

pr is a command published in the GitHub repository azrtydxb/procoder (196 stars, last pushed 2d ago), licensed Apache-2.0. It adds 20 tokens to every session and 1,084 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.