agentleFS
Sign inStart free
ralphkraussralphkrauss/agent-orchestrator/.claude/skills/create-pr/SKILL.md

create-pr

Skill4 starsChanged 6 months agoMITView on GitHub

Create a GitHub pull request with the issue number in the title. Use when user says "create PR", "open PR", "make pull request", or after completing a plan implementation.

  • Commits and pushes

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 178 edited versions we read keep these.

  • 6

    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:

    Create a GitHub pull request with consistent title formatting that includes the issue number.

    line 10
  2. Very specific:

    Before creating a PR, check that /review-pr has been run on this branch:

    line 16
  3. Very specific:

    Check if /review-pr was run in the current session (the user ran it earlier in this conversation)

    line 18
  4. Very specific:

    If not, warn: *"Self-review has not been run.

    line 19
  5. Distinctive:

    If the user confirms to skip, proceed — but note "Self-review skipped" in the PR description

    line 20
  6. Very specific:

    If the user ran /review-pr and there are unresolved Critical findings, warn: *"/review-pr found N unresolved critical findings.

    line 21
  7. Very specific:

    If the branch name starts with a number (e.g., 50-archive-dynamodb-event-store), extract it as the issue number.

    line 28
  8. Distinctive:

    If no issue number is detected, ask the user for it.

    line 29
  9. Very specific:

    No conventional-commit prefixes (feat:, fix:, chore:, etc.)

    line 39
  10. Distinctive:

    Use the plan file to construct the body:

    line 59
  11. Distinctive:

    If a plan exists, derive the summary from the completed tasks in the Implementation Tasks table.

    line 75
  12. Distinctive:

    Create the pull request using the available GitHub tools with:

    line 85

“Common” is measured: kept by at least 6 in 10 of the 178 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
<!-- Generated from .agents/ by scripts/sync-ai-workspace.mjs. Do not edit directly. -->

Create PR

Create a GitHub pull request with consistent title formatting that includes the issue number.

Instructions

Step 0: Verify Self-Review Has Been Run

Before creating a PR, check that /review-pr has been run on this branch:

  1. Check if /review-pr was run in the current session (the user ran it earlier in this conversation)
  2. If not, warn: "Self-review has not been run. Run /review-pr first to catch issues before PR creation?"
  3. If the user confirms to skip, proceed — but note "Self-review skipped" in the PR description
  4. If the user ran /review-pr and there are unresolved Critical findings, warn: "/review-pr found N unresolved critical findings. Resolve them before creating a PR, or proceed anyway?"

This is advisory, not blocking — the user can always override.

Step 1: Determine Issue Number and Branch

  1. Get the current branch: git branch --show-current
  2. If the branch name starts with a number (e.g., 50-archive-dynamodb-event-store), extract it as the issue number.
  3. If no issue number is detected, ask the user for it.

Step 2: Build PR Title

Format: #{issue-number} {Short description} — the issue number MUST be the very first thing in the title. No exceptions.

Rules:

  • Issue number comes first, prefixed with #
  • Single space after the number — no colon, no dash
  • Description starts with a capital letter
  • No conventional-commit prefixes (feat:, fix:, chore:, etc.)

Correct examples:

  • #50 Archive DynamoDB event store
  • #14 Localization infrastructure
  • #148 Allow custom page size in the DataTable

Do NOT use these formats:

  • #50: Title — no colon after the issue number
  • feat: Title (#50) — no conventional-commit prefix, no issue number at end
  • fix: resolve something — missing issue number entirely
  • #50 implement thing — must capitalize first word of description

Derive the short description from:

  • The plan file at plans/{branch-name}/plan.md (use the feature title)
  • The GitHub issue title: fetch the issue details using the available GitHub tools (owner, repo, issue_number) and extract the title from the result
  • Or ask the user

Step 3: Build PR Body

Use the plan file to construct the body:

## Summary

- Bullet point summary of what was implemented (2-5 bullets)

## Issue

Closes #{issue-number}

## Test Plan

- [ ] Verification steps or test commands run

If a plan exists, derive the summary from the completed tasks in the Implementation Tasks table.

Step 4: Push and Create

  1. Push the branch:
git push -u origin HEAD
  1. Create the pull request using the available GitHub tools with:
    • owner: repository owner
    • repo: repository name
    • title: "#{issue-number} {description}"
    • head: current branch name
    • base: "main"
    • body: the PR body from Step 3

Step 5: Return the PR URL

Display the PR URL to the user when done.

Critical Rules

  • Title format is #{number} {Description} -- issue number first, no colon, no prefix, capitalized description. This is non-negotiable.
  • Comment prefix -- if adding PR comments, prefix with **[Claude Code]:**
  • Don't force-push -- use regular git push

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.

Reviews can't be read right now.

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