agentleFS
kensauruskensaurus/cursor-kenji/skills/workflow-pr/SKILL.md

workflow-pr

Skill9 starsChanged 42 days agoMITView on GitHub

Manage an existing PR lifecycle — review, bot feedback, conflicts, merge. Use when opening a PR from an already-committed branch, addressing review, or merging. Uncommitted working tree to merge-ready → workflow-release-prep.

  • Reads credentials

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Search for pull_request_template.md in repo

    line 80
  2. Distinctive:

    Use template structure for PR description

    line 81
  3. Distinctive:

    Create PR with clear title and description

    line 82
  4. Distinctive:

    Check every 60-90 seconds until checks complete:

    line 90
  5. Very specific:

    All checks must show SUCCESS

    line 122
  6. Distinctive:

    Only after both gates pass and the user explicitly asked to merge:

    line 143
  7. Very specific:

    Fix: Always check mergeable_state, poll again if unstable

    line 170
  8. Distinctive:

    Fix: After every push, re-fetch comments for new threads

    line 176
  9. Distinctive:

    Fix: After addressing each comment, mark thread resolved

    line 179

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

PR Workflow Skill

Degree of freedom: MIXED. Feedback judgment [HIGH freedom]; validations, poll loop, and merge-only-if-asked [LOW freedom — run exactly].

Full checklist for an already-committed branch or an open PR.

Uncommitted / staged / untracked working tree that still needs review, commit, and a merge-ready PR is workflow-release-prep. This skill does not own that sequence.

How to reason

  1. Validate — repo commands green; no secrets in the branch
  2. Open — template + complete description
  3. Drive — poll checks; address every thread
  4. Gate — mergeable_state clean AND threads 0; merge only if asked

Worked example

Validate: pnpm typecheck && pnpm test green; no .env in the diff. Open: PR uses the repo template; title fix(checkout): handle deleted SKU. Drive: CI red on lint → fix, push, re-poll; reply + resolve the bot thread. Gate: mergeable_state=clean, 0 threads; user did not ask to merge → report merge-ready and stop.

Self-critique before reporting

  • Already committed — dirty tree was routed to workflow-release-prep
  • Both gates — never treat mergeable: true as approval
  • Merge gated — no merge unless the user explicitly asked
  • Right owner — uncommitted pile → workflow-release-prep; keep-green loop after open → babysit

Invocation boundary

  • Standalone: open or manage the PR. Merge only when the user explicitly asked to merge.
  • Called by workflow-release-prep: open the PR and return its URL. babysit owns the green loop; the caller stops before merge.

Phase 1: Before Creating PR [LOW freedom — run exactly]

1. Run Validations

JavaScript/TypeScript:

pnpm typecheck && pnpm build && pnpm test
# or: npm run typecheck && npm run build && npm test

Python:

mypy . && python -m pytest && ruff check .

With Makefile:

make typecheck && make build && make test

2. Security Scan

Before committing, verify:

  • No hardcoded paths (/Users/username/...)
  • No secrets, API keys, or tokens
  • No machine-specific values
  • Environment variables for sensitive data

3. Create PR

  1. Search for pull_request_template.md in repo
  2. Use template structure for PR description
  3. Create PR with clear title and description

Phase 2: Monitor PR [LOW freedom — run exactly]

4. Poll Status

Check every 60-90 seconds until checks complete:

Understanding Check Status:

  • mergeable: true → Only means no git conflicts
  • mergeable_state: "clean" → ALL checks passed, safe to merge

Mergeable State Values:

StateMeaningAction
"clean"✅ All passedSafe to merge
"unstable"⚠️ Pending/failingWait, poll again
"blocked"❌ Protection rulesCheck requirements
"behind"⚠️ Needs updateUpdate branch

5. Address Bot Feedback

When reviews complete:

  1. Read every comment - Track unresolved threads
  2. For each issue:
  • Analyze feedback
  • Implement fix
  • Commit and push
  • Reply confirming fix
  • Mark thread resolved
  1. Address every comment — an unresolved thread fails Gate 2

6. Wait for Re-validation

After pushing fixes:

  1. Poll status again
  2. All checks must show SUCCESS
  3. Re-fetch comments for NEW feedback
  4. Repeat until clean

Phase 3: Merge Criteria [LOW freedom — run exactly]

7. Final Checklist

Two gates must pass:

GateCheck
Gate 1mergeable_state == "clean"
Gate 2unresolved_thread_count == 0

Both must be TRUE to merge.

8. Execute Merge

Only after both gates pass and the user explicitly asked to merge:

gh pr merge --merge

Otherwise report that the PR is merge-ready and stop.

9. Verify Success

Confirm merge was successful and report status.


Error Handling

SituationAction
Checks fail 3xPause, ask for guidance
Unclear feedbackAsk clarifying questions
Merge blockedCheck protection rules, report
Checks stuckRun local validation, ask permission

Common Mistakes

❌ Merging when mergeable_state is "unstable"

Fix: Always check mergeable_state, poll again if unstable

❌ Treating mergeable: true as approval

Fix: mergeable ≠ mergeable_state. Check the latter.

❌ Not re-checking comments after push

Fix: After every push, re-fetch comments for new threads

❌ Not marking threads resolved

Fix: After addressing each comment, mark thread resolved


Quick Reference

# Check PR status
gh pr status

# View checks
gh pr checks <number>

# View comments
gh pr view <number> --comments

# Merge (only when both gates pass)
gh pr merge <number> --merge

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.