agentleFS
dafaalzdafaalz/agent-skills/skills/pull-request/SKILL.md

pull-request

Skill2 starsChanged 51 days agoMITView on GitHub

Use when drafting, reviewing, or structuring pull request descriptions with visual summaries, before-and-after verification evidence, and merge-danger risk assessments. Don't use for atomic git commit messages (use conventional-commit), branch cleanup (run `git branch -d` directly), or direct git push (run `git push` directly after the user reviews the diff).

  • Reads credentials
  • 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 9 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

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 48 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run Steps 1 through 5 in Draft mode (default) or Steps A1 through A3 in Audit mode.

    line 32
  2. Very specific:

    Before drafting, abort if .agents/state/pull-request/HALT_SECRET exists on disk.

    line 118
  3. Very specific:

    Write assembled description to temporary file and append stack navigation if .agents/state/pull-request/stack.json exists:

    line 155
  4. Very specific:

    Read target PR body from .agents/state/pull-request/pr-body.md or path in .agents/state/pull-request/audit-target.txt.

    line 187
  5. Very specific:

    Use this standard layout for .agents/state/pull-request/pr-body.md when no repository template is present:

    line 202

“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

Pull request

Structure pull request bodies that convey intent immediately to reviewers, provide before-and-after verification evidence, and classify operational merge risk.

<HARD-GATE> Write-Target Boundary. In Draft mode, write only to `.agents/state/pull-request/pr-body.md` and `.agents/state/pull-request/`. In Audit mode, do not modify any tracked codebase file. Never run `gh pr create`, `git push`, `git commit`, `gh api` with state-changing methods, `gh pr comment`, `gh release`, or any other network mutation; emit the publish command as text for the user to run. Never alter application code, execute destructive git resets, or amend previous session commits while drafting. </HARD-GATE>

Boundary isolation

Pull request authoring reads git diffs, commit histories, review notes, and test receipts. In Draft and Audit modes, do not execute git push, gh pr create, or any network mutation. The publish command in Step 5 is emitted as text for the user to run, not executed by the skill. If the user asks the skill to run the publish command, refuse and provide the resolved command to the user.

Principles and constraints

  1. Smallest visual summary. Open the pull request with the smallest visual artifact that makes the change clear: an ASCII diagram, a schema diff table, or terminal before-and-after logs.
  2. Concrete verification evidence. Include exact test commands, exit codes, and output snippets. Never assert that changes work without recorded tool verification.
  3. Merge-danger call. Classify every pull request as a two-way door (reversible without state corruption) or a one-way door (destructive migrations, auth alterations, external webhook updates) with an explicit blast radius estimate.
  4. Operational deploy sequencing. For SQL schema alterations, declare the expand-contract phase, lock timeouts, and backward compatibility during rolling rollouts.
  5. Ingest repository templates. When .github/pull_request_template.md or templates under .github/PULL_REQUEST_TEMPLATE/ exist, populate that layout instead of replacing repository structure.
  6. Secret and credential protection. Scan diff lines directly in stream for private keys and tokens without persisting raw secrets to disk. On match, write a blocking state marker, redact raw values from reports, halt drafting, keep git state untouched, and alert the user with file paths. Remove .agents/state/pull-request/HALT_SECRET manually after remediating commits.
  7. Unslop compliance. Zero em dashes, zero en dashes, and zero hyphens acting as dashes. Use colons only before lists, tables, or code blocks.
  8. Line budget. Keep the main pull request template concise and under 250 lines.

Modes

Run Steps 1 through 5 in Draft mode (default) or Steps A1 through A3 in Audit mode.

Draft workflow

Step 1. Base branch resolution, diff inspection, and commit audit

Inspect branch divergence against target base branch before drafting. Abort if a prior unhandled HALT_SECRET marker exists on disk:

set -o pipefail; mkdir -p .agents/state/pull-request
[ -f .agents/state/pull-request/HALT_SECRET ] && { printf 'FATAL: HALT_SECRET marker exists. Remediate commits and remove marker before rerunning.\n' >&2; exit 1; }

CANDIDATE_BASE="${STACK_BASE:-}"
if [ -z "${CANDIDATE_BASE}" ]; then
  UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' 2>/dev/null) && CANDIDATE_BASE="${UPSTREAM}"
  for r in $(git remote 2>/dev/null); do
    SYM=$(git symbolic-ref --short "refs/remotes/${r}/HEAD" 2>/dev/null)
    [ -z "${CANDIDATE_BASE}" ] && [ -n "${SYM}" ] && CANDIDATE_BASE="${SYM}" && break
  done
  TRUNKS=$(git branch -r 2>/dev/null | tr -d ' ' | grep -E '^[^/]+/(main|master|trunk|develop)$' || true)
  [ -z "${CANDIDATE_BASE}" ] && [ "$(printf '%s\n' "${TRUNKS}" | grep -c . || true)" -eq 1 ] && CANDIDATE_BASE="${TRUNKS}"
fi

is_branch=0
case "${CANDIDATE_BASE}" in
  refs/heads/*|refs/remotes/*) git show-ref --verify --quiet "${CANDIDATE_BASE}" 2>/dev/null && is_branch=1 ;;
  ?*)
    git show-ref --verify --quiet "refs/heads/${CANDIDATE_BASE}" 2>/dev/null && is_branch=1
    git show-ref --verify --quiet "refs/remotes/${CANDIDATE_BASE}" 2>/dev/null && is_branch=1
    for r in $(git remote 2>/dev/null); do git show-ref --verify --quiet "refs/remotes/${r}/${CANDIDATE_BASE}" 2>/dev/null && is_branch=1; done ;;
esac
[ "${is_branch}" -eq 1 ] && git rev-parse --verify "${CANDIDATE_BASE}^{commit}" >/dev/null 2>&1 || {
  printf 'FATAL: Base ref %s is not a valid branch commit. Set STACK_BASE=<branch> to disambiguate.\n' "${CANDIDATE_BASE}" >&2; exit 1; }

TARGET_BRANCH="${CANDIDATE_BASE}"
case "${TARGET_BRANCH}" in refs/heads/*) TARGET_BRANCH="${TARGET_BRANCH#refs/heads/}" ;; esac
if ! git show-ref --verify --quiet "refs/heads/${TARGET_BRANCH}" 2>/dev/null; then
  for r in $(git remote 2>/dev/null); do
    case "${TARGET_BRANCH}" in
      refs/remotes/"${r}"/*) C_SHORT="${TARGET_BRANCH#refs/remotes/${r}/}" ;;
      "${r}"/*) C_SHORT="${TARGET_BRANCH#${r}/}" ;;
      *) continue ;;
    esac
    git show-ref --verify --quiet "refs/remotes/${r}/${C_SHORT}" 2>/dev/null && TARGET_BRANCH="${C_SHORT}" && break
  done
fi

git check-ref-format --branch "${TARGET_BRANCH}" 2>/dev/null || { printf 'FATAL: Invalid branch format for target: %s\n' "${TARGET_BRANCH}" >&2; exit 1; }
printf '%s' "${TARGET_BRANCH}" > .agents/state/pull-request/base-ref.txt && printf '%s' "${CANDIDATE_BASE}" > .agents/state/pull-request/candidate-base.txt
git log "${CANDIDATE_BASE}"..HEAD --oneline > .agents/state/pull-request/commit-log.txt && git diff "${CANDIDATE_BASE}"...HEAD --stat > .agents/state/pull-request/diff-stat.txt || {
  printf 'FATAL: Failed to read git history against %s.\n' "${CANDIDATE_BASE}" >&2; exit 1; }

git diff "${CANDIDATE_BASE}"...HEAD --name-only > .agents/state/pull-request/changed-files.txt
SECRET_FILES=$(grep -E '(^|/)(\.env(\.[^/]+)?|\.envrc|credentials([-_.]?[^/]+)?\.json|id_rsa$|[^/]+\.(pem|key))$' .agents/state/pull-request/changed-files.txt | grep -vE '(\.(pub|example|sample|template)(\.json)?|[-_]template.*)$' || true)
[ -n "${SECRET_FILES}" ] && { touch .agents/state/pull-request/HALT_SECRET; printf 'HALT: Sensitive credential or key file in diff.\n' >&2; exit 1; }

git diff "${CANDIDATE_BASE}"...HEAD | awk '
  /^diff --git/ { in_file=1; next }
  in_file && /^\+\+\+ / {
    in_file = 0; if ($0 ~ /^\+\+\+ \/dev\/null/) next
    line = $0; sub(/^\+\+\+ "?b\//, "", line); sub(/"?$/, "", line); file = line; next
  }
  /^@@ -[0-9]+(,[0-9]+)? \+([0-9]+)/ {
    split($3, hunk, ","); lineno = substr(hunk[1], 2) + 0 - 1; next
  }
  /^\+/ && !in_file {
    lineno++; line = substr($0, 2)
    if (line ~ /(gh[pousr]_[a-zA-Z0-9]{20,}|github_pat_[a-zA-Z0-9_]{22,}|AKIA[0-9A-Z]{16}|-----BEGIN [A-Z ]*PRIVATE KEY-----|xox[baprs]-[0-9a-zA-Z]{10,48}|sk-(proj-)?[a-zA-Z0-9_-]{32,}|AIza[0-9A-Za-z_-]{35}|sk_live_[0-9a-zA-Z]{24}|[Bb][Ee][Aa][Rr][Ee][Rr][[:space:]]+[a-zA-Z0-9_.-]+)/) {
      matched = 1
      print "HALT: Credential pattern matched at " file ":" lineno ":[REDACTED_SECRET_MATCH]"
    }
  }
  /^ / && !in_file { lineno++ }
  END { if (matched) exit 42 }
' > .agents/state/pull-request/secret-scan.txt
SCAN_STATUS=$?
[ "${SCAN_STATUS}" -eq 42 ] && { touch .agents/state/pull-request/HALT_SECRET; cat .agents/state/pull-request/secret-scan.txt >&2; exit 1; }
[ "${SCAN_STATUS}" -ne 0 ] && { printf 'FATAL: Secret scan pipeline failed with exit status %d.\n' "${SCAN_STATUS}" >&2; exit 1; }

Identify modified subsystems, schema migrations, breaking changes, and conventional commit adherence.

Completion criterion. test -s .agents/state/pull-request/base-ref.txt, test -s .agents/state/pull-request/commit-log.txt, test -s .agents/state/pull-request/diff-stat.txt, test -f .agents/state/pull-request/secret-scan.txt, test ! -s .agents/state/pull-request/secret-scan.txt, and test ! -f .agents/state/pull-request/HALT_SECRET evaluate successfully.

Step 2. Visual summary formulation

Before drafting, abort if .agents/state/pull-request/HALT_SECRET exists on disk. Construct smallest visual representation that explains core change: ASCII data flow diagram, schema diff table, screenshot table, or command output block. Completion criterion. One compact visual representation drafted communicating primary delta.

Step 3. Merge-danger and blast radius assessment

Evaluate operational risk before assembling final description. Consult references/operational-risk-and-runners.md for definitions:

  • Decision type: Two-way door or One-way door.
  • Blast radius: Low, Medium, or High.
  • Rollback plan: Exact git revert <hash> or multi-step operational recovery plan.
  • For schema alterations, specify expand-contract phase, backward compatibility, and lock limits. For non-database changes, specify storage or cache rollback plans.

Completion criterion. Merge-danger classification, blast radius, rollback plan documented, and SQL deploy invariants specified for schema alterations.

Step 4. Verification evidence compilation

Gather deterministic verification results:

RUNNER_CMD=""
for pair in "pnpm-lock.yaml:pnpm test" "yarn.lock:yarn test" "bun.lockb:bun test" "package-lock.json:npm test" "poetry.lock:poetry run pytest" "uv.lock:uv run pytest" "Pipfile.lock:pipenv run pytest" "composer.lock:vendor/bin/phpunit" "go.mod:go test ./..." "Cargo.lock:cargo test"; do
  lf="${pair%%:*}"
  if [ -f "${lf}" ]; then RUNNER_CMD="${pair#*:}"; break; fi
done
if [ -n "${RUNNER_CMD}" ]; then
  printf '%s\n' "${RUNNER_CMD}" > .agents/state/pull-request/test-command.txt
  eval "${RUNNER_CMD}" > .agents/state/pull-request/test-output.txt 2>&1
  TEST_EXIT=$?; printf '%d\n' "${TEST_EXIT}" > .agents/state/pull-request/test-status.txt && [ "${TEST_EXIT}" -eq 0 ] || { printf 'FATAL: %s failed with code %d.\n' "${RUNNER_CMD}" "${TEST_EXIT}" >&2; exit 1; }
else
  git status -s > .agents/state/pull-request/verification-evidence.txt
fi

Completion criterion. ([ -f .agents/state/pull-request/test-status.txt ] && [ "$(cat .agents/state/pull-request/test-status.txt)" -eq 0 ] && [ -s .agents/state/pull-request/test-output.txt ]) || [ -s .agents/state/pull-request/verification-evidence.txt ] evaluates successfully.

Step 5. Body assembly and registration

Assemble pull request description: ingest repository template if .github/pull_request_template.md or .github/PULL_REQUEST_TEMPLATE/ exists, populating its layout and appending missing visual summary and verification sections; otherwise use default layout below.

Write assembled description to temporary file and append stack navigation if .agents/state/pull-request/stack.json exists:

cat <<'BODY_EOF' > .agents/state/pull-request/pr-body.md.tmp
<assembled markdown description matching repository template or standard layout below>
BODY_EOF
PR_NUM=$(grep -Eo '"parent_pr"[ ]*:[ ]*[0-9]+' .agents/state/pull-request/stack.json 2>/dev/null | grep -Eo '[0-9]+' || true)
[ -s .agents/state/pull-request/stack.json ] && [ "$(printf '%s\n' "${PR_NUM}" | grep -c . || true)" -eq 1 ] && \
  printf '%s' "${PR_NUM}" | grep -Eq '^[1-9][0-9]*$' && \
  printf '\n\n## Stack\n- #%s (Base layer)\n- Current PR (This branch)\n' "${PR_NUM}" >> .agents/state/pull-request/pr-body.md.tmp
mv -- .agents/state/pull-request/pr-body.md.tmp .agents/state/pull-request/pr-body.md

Validate base branch and display publish command for user. Never run gh pr create directly:

[ -s .agents/state/pull-request/base-ref.txt ] || { printf 'FATAL: Missing base-ref.txt. Rerun Step 1.\n' >&2; exit 1; }
BASE_REF=$(cat .agents/state/pull-request/base-ref.txt); CAND_REF="${BASE_REF}"
[ -s .agents/state/pull-request/candidate-base.txt ] && CAND_REF=$(cat .agents/state/pull-request/candidate-base.txt)
if git check-ref-format --branch "${BASE_REF}" 2>/dev/null && git rev-parse --verify "${CAND_REF}^{commit}" >/dev/null 2>&1; then
  printf 'Suggested publish command for user:\ngh pr create --base "%s" --title "type(scope): description" --body-file "$(pwd)/.agents/state/pull-request/pr-body.md"\n' "${BASE_REF}"
else
  printf 'FATAL: Stale or invalid base branch %s. Rerun Step 1.\n' "${BASE_REF}" >&2; exit 1
fi

Register pull request URL immediately when collaborative harness supports PR tracking.

Completion criterion. test -s .agents/state/pull-request/pr-body.md, [ "$(wc -c < .agents/state/pull-request/pr-body.md)" -gt 200 ], and grep -q '^## Summary' .agents/state/pull-request/pr-body.md && grep -q '^## Verification evidence' .agents/state/pull-request/pr-body.md evaluate successfully.

Audit workflow

Audit Step A1. Load and parse target description

Read target PR body from .agents/state/pull-request/pr-body.md or path in .agents/state/pull-request/audit-target.txt. Completion criterion. test -s .agents/state/pull-request/pr-body.md || (test -f .agents/state/pull-request/audit-target.txt && test -s "$(cat .agents/state/pull-request/audit-target.txt)") evaluates successfully.

Audit Step A2. Rubric pass

Evaluate each of the eight Principles and constraints. Record evaluation rows in .agents/state/pull-request/audit-report.md with columns Principle | Status (pass or fail) | Evidence. Completion criterion. test -s .agents/state/pull-request/audit-report.md && [ "$(grep -c '^|' .agents/state/pull-request/audit-report.md)" -ge 10 ] evaluates successfully.

Audit Step A3. Verdict

Emit .agents/state/pull-request/audit-verdict.txt containing a single line: verdict: approve or verdict: changes_requested. Completion criterion. test -f .agents/state/pull-request/audit-verdict.txt && grep -Eq '^verdict: (approve|changes_requested)$' .agents/state/pull-request/audit-verdict.txt evaluates successfully.

Pull request template

Use this standard layout for .agents/state/pull-request/pr-body.md when no repository template is present:

## Summary
[One to two sentences stating objective and mechanism]

### Visual summary
```text
[ASCII diagram, schema delta, or before-and-after flow]
```

## Changes
- [Component]: [Exact change applied]
- [Test]: [Regression test added]

## Merge danger and operational risk
- **Decision type:** [Two-way door | One-way door]
- **Blast radius:** [Low | Medium | High]
- **Rollback strategy:** [git revert <hash> | specific rollback steps]

<!-- Include following block if change alters database schema -->
### Operational deploy invariants
- **Expand-contract phase:** [Phase 1 Expand | Phase 2 Backfill | Phase 3 Read Cutover | Phase 4 Contract]
- **Backward compatibility:** [Verified with existing running instances]
- **Database lock limits:** [SET lock_timeout = '2s'; index CONCURRENTLY]

## Verification evidence
```text
[Command run and test runner output confirming exit code 0]
```

## Related issues
Closes #[Issue Number]

Quick audit checklist

IDTitlePattern descriptionWhy it failsConcrete fix
PR-1No visual summaryPR body contains only prose bulletsReviewers must reconstruct the change from the diffInsert ASCII diagram, schema table, or terminal delta at the top
PR-2Unclassified dangerPR body lacks decision type, blast radius, or rollback strategyReviewer cannot judge merge riskAdd the Merge danger section with decision type, blast radius, and rollback strategy
PR-3No rollbackRollback strategy field absent or emptyReviewer cannot plan reversalCite git revert or an explicit rollback procedure
PR-4Asserted verificationVerification claims stated without command outputClaims are not reproduciblePaste the exact command and its exit code 0 output
PR-5Malformed titlePR title missing standard type or scopeBreaks changelog automationMatch <type>(<scope>): <description> format
PR-6Secret leakAdded diff lines contain credentials or private tokensSecret exposure on pushRemediate commit history, remove HALT_SECRET marker manually, and rerun Step 1
PR-7Unsequenced migrationSQL schema alteration PR lacks deploy invariantsRisk of downtime or table lock during rolloutSpecify expand-contract phase, lock limits, and backward compatibility
PR-8Template ignoredOverwrites repository PR templateDestroys team compliance checksIngest and populate fields in .github/pull_request_template.md or directory template

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.