agentleFS
TermiX-officialTermiX-official/cryptoclaw/.agents/skills/prepare-pr/SKILL.md

prepare-pr

Skill100 starsChanged 9 months agoMITView on GitHub

Prepare a GitHub PR for merge by rebasing onto main, fixing review findings, running gates, committing fixes, and pushing to the PR head branch. Use after /reviewpr. Never merge or push to main.

  • Deletes or force-pushes
  • Installs packages
  • Commits and pushes

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 24

    Distinctive

    This author's own choices. Worth a look.

  • 12

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Ask for PR number or URL.

    line 14
  2. Distinctive:

    If missing, auto-detect from conversation.

    line 15
  3. Very specific:

    Never push to main or origin/main.

    line 20
  4. Distinctive:

    Never run git push without specifying remote and branch explicitly.

    line 21
  5. Distinctive:

    Do not run gateway stop commands.

    line 22
  6. Distinctive:

    Do not run git clean -fdx.

    line 23
  7. Distinctive:

    Do not run git add -A or git add ..

    line 24
  8. Distinctive:

    If delegating, require the delegate to run commands and capture outputs.

    line 29
  9. Very specific:

    If you see "fatal: not a git repository", you are in the wrong directory.

    line 33
  10. Distinctive:

    Do not run git add -A or git add ..

    line 35
  11. Distinctive:

    Run gates and pass.

    line 41
  12. Very specific:

    Write .local/prep.md with a prep summary.

    line 44
  13. Distinctive:

    Create a checklist of all prep steps, print it, then continue and execute the commands.

    line 49
  14. Distinctive:

    Use an isolated worktree for all prep work.

    line 53
  15. Distinctive:

    Run all commands inside the worktree directory.

    line 63
  16. Very specific:

    Run git add <resolved_file> for each file.

    line 110
  17. Distinctive:

    If the rebase gets confusing or you resolve conflicts 3 or more times, stop and report.

    line 113
  18. Very specific:

    Keep a running log in .local/prep.md:

    line 121
  19. Very specific:

    Update CHANGELOG.md if flagged in review

    line 127
  20. Very specific:

    Check .local/review.md section H for guidance.

    line 129
  21. Distinctive:

    If flagged and user-facing:

    line 130
  22. Very specific:

    Check if CHANGELOG.md exists.

    line 132
  23. Distinctive:

    Add a concise entry with PR number and contributor.

    line 139
  24. Distinctive:

    Update docs if flagged in review

    line 141
  25. Very specific:

    Check .local/review.md section G for guidance.

    line 143
  26. Distinctive:

    If flagged, update only docs related to the PR changes.

    line 144
  27. Very specific:

    If committer is not found:

    line 160
  28. Distinctive:

    Run full gates before pushing

    line 166
  29. Distinctive:

    Verify PR is not behind main (Mandatory)

    line 194
  30. Distinctive:

    If still behind main, repeat steps 2 through 9.

    line 203
  31. Distinctive:

    Write prep summary artifacts (Mandatory)

    line 205
  32. Very specific:

    Create or overwrite .local/prep.md and verify it exists and is non-empty:

    line 215
  33. Distinctive:

    If gates passed and push succeeded, print exactly:

    line 234
  34. Very specific:

    Do not delete the worktree on success.

    line 245
  35. Distinctive:

    Never push to main. Only push to the PR head branch.

    line 247
  36. Distinctive:

    Run and pass all gates before pushing.

    line 248

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

Prepare PR

Overview

Prepare a PR branch for merge with review fixes, green gates, and an updated head branch.

Inputs

  • Ask for PR number or URL.
  • If missing, auto-detect from conversation.
  • If ambiguous, ask.

Safety

  • Never push to main or origin/main. Push only to the PR head branch.
  • Never run git push without specifying remote and branch explicitly. Do not run bare git push.
  • Do not run gateway stop commands. Do not kill processes. Do not touch port 18792.
  • Do not run git clean -fdx.
  • Do not run git add -A or git add .. Stage only specific files changed.

Execution Rule

  • Execute the workflow. Do not stop after printing the TODO checklist.
  • If delegating, require the delegate to run commands and capture outputs.

Known Footguns

  • If you see "fatal: not a git repository", you are in the wrong directory. Use ~/openclaw.
  • Do not run git clean -fdx.
  • Do not run git add -A or git add ..

Completion Criteria

  • Rebase PR commits onto origin/main.
  • Fix all BLOCKER and IMPORTANT items from .local/review.md.
  • Run gates and pass.
  • Commit prep changes.
  • Push the updated HEAD back to the PR head branch.
  • Write .local/prep.md with a prep summary.
  • Output exactly: PR is ready for /mergepr.

First: Create a TODO Checklist

Create a checklist of all prep steps, print it, then continue and execute the commands.

Setup: Use a Worktree

Use an isolated worktree for all prep work.

cd ~/openclaw
# Sanity: confirm you are in the repo
git rev-parse --show-toplevel

WORKTREE_DIR=".worktrees/pr-<PR>"

Run all commands inside the worktree directory.

Load Review Findings (Mandatory)

if [ -f .local/review.md ]; then
  echo "Found review findings from /reviewpr"
else
  echo "Missing .local/review.md. Run /reviewpr first and save findings."
  exit 1
fi

# Read it
sed -n '1,200p' .local/review.md

Steps

  1. Identify PR meta (author, head branch, head repo URL)
gh pr view <PR> --json number,title,author,headRefName,baseRefName,headRepository,body --jq '{number,title,author:.author.login,head:.headRefName,base:.baseRefName,headRepo:.headRepository.nameWithOwner,body}'
contrib=$(gh pr view <PR> --json author --jq .author.login)
head=$(gh pr view <PR> --json headRefName --jq .headRefName)
head_repo_url=$(gh pr view <PR> --json headRepository --jq .headRepository.url)
  1. Fetch the PR branch tip into a local ref
git fetch origin pull/<PR>/head:pr-<PR>
  1. Rebase PR commits onto latest main
# Move worktree to the PR tip first
git reset --hard pr-<PR>

# Rebase onto current main
git fetch origin main
git rebase origin/main

If conflicts happen:

  • Resolve each conflicted file.
  • Run git add <resolved_file> for each file.
  • Run git rebase --continue.

If the rebase gets confusing or you resolve conflicts 3 or more times, stop and report.

  1. Fix issues from .local/review.md
  • Fix all BLOCKER and IMPORTANT items.
  • NITs are optional.
  • Keep scope tight.

Keep a running log in .local/prep.md:

  • List which review items you fixed.
  • List which files you touched.
  • Note behavior changes.
  1. Update CHANGELOG.md if flagged in review

Check .local/review.md section H for guidance. If flagged and user-facing:

  • Check if CHANGELOG.md exists.
ls CHANGELOG.md 2>/dev/null
  • Follow existing format.
  • Add a concise entry with PR number and contributor.
  1. Update docs if flagged in review

Check .local/review.md section G for guidance. If flagged, update only docs related to the PR changes.

  1. Commit prep fixes

Stage only specific files:

git add <file1> <file2> ...

Preferred commit tool:

committer "fix: <summary> (#<PR>) (thanks @$contrib)" <changed files>

If committer is not found:

git commit -m "fix: <summary> (#<PR>) (thanks @$contrib)"
  1. Run full gates before pushing
pnpm install
pnpm build
pnpm ui:build
pnpm check
pnpm test

Require all to pass. If something fails, fix, commit, and rerun. Allow at most 3 fix and rerun cycles. If gates still fail after 3 attempts, stop and report the failures. Do not loop indefinitely.

  1. Push updates back to the PR head branch
# Ensure remote for PR head exists
git remote add prhead "$head_repo_url.git" 2>/dev/null || git remote set-url prhead "$head_repo_url.git"

# Use force with lease after rebase
# Double check: $head must NOT be "main" or "master"
echo "Pushing to branch: $head"
if [ "$head" = "main" ] || [ "$head" = "master" ]; then
  echo "ERROR: head branch is main/master. This is wrong. Stopping."
  exit 1
fi
git push --force-with-lease prhead HEAD:$head
  1. Verify PR is not behind main (Mandatory)
git fetch origin main
git fetch origin pull/<PR>/head:pr-<PR>-verify --force
git merge-base --is-ancestor origin/main pr-<PR>-verify && echo "PR is up to date with main" || echo "ERROR: PR is still behind main, rebase again"
git branch -D pr-<PR>-verify 2>/dev/null || true

If still behind main, repeat steps 2 through 9.

  1. Write prep summary artifacts (Mandatory)

Update .local/prep.md with:

  • Current HEAD sha from git rev-parse HEAD.
  • Short bullet list of changes.
  • Gate results.
  • Push confirmation.
  • Rebase verification result.

Create or overwrite .local/prep.md and verify it exists and is non-empty:

git rev-parse HEAD
ls -la .local/prep.md
wc -l .local/prep.md
  1. Output

Include a diff stat summary:

git diff --stat origin/main..HEAD
git diff --shortstat origin/main..HEAD

Report totals: X files changed, Y insertions(+), Z deletions(-).

If gates passed and push succeeded, print exactly:

PR is ready for /mergepr

Otherwise, list remaining failures and stop.

Guardrails

  • Worktree only.
  • Do not delete the worktree on success. /mergepr may reuse it.
  • Do not run gh pr merge.
  • Never push to main. Only push to the PR head branch.
  • Run and pass all gates before pushing.

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.