Skip to content
OpenSmartRoute
Skillv1.0.0

pre-release-pr-triage-worktree

Triage open PRs for a release in a dedicated git worktree, classify each into merge/candidate/supersede/defer, and work the loop end-to-end.

by kjuhwa(0) 0 installs
Free
Sign in to install

Free account. Installing gives you the manifest plus copy-paste snippets.

See reviews

About

Imported from kjuhwa/skills-hub (skills/agents/pre-release-pr-triage-worktree/SKILL.md). Install upstream with npx skills add kjuhwa/skills-hub --skill pre-release-pr-triage-worktree. Copyright stays with the author.

Pre-release PR triage (worktree)

When to use

A solo maintainer (or small team) has accumulated 10+ open PRs and wants to land the critical subset before cutting a minor/major release — without losing the changelog narrative and without deep-reviewing everything.

Steps

  1. Create a dedicated PR-review worktree: git worktree add ../<repo>-pr-review -b pr-review-<version> main. Keep the main worktree for release prep (changelog, direct follow-ups); use the review worktree for gh pr checkout so HEAD moves without contaminating release work.
  2. Bulk-gather metadata once: gh pr list --state open --limit 50 --json number,title,author,mergeable,mergeStateStatus,additions,deletions,maintainerCanModify,files. Capture size, mergeable state, file paths (for overlap detection), and whether maintainer can push to the fork.
  3. Sort every PR into one of four tiers:
    • Tier 1 (merge): small, mergeable, clean CI, low review cost.
    • Tier 2 (candidate): 50-200 lines, needs a close read but looks sound.
    • Supersede: covered by something already merged — verify by diff, not by title similarity.
    • Defer: big features, dirty conflicts, draft PRs, anything risky.
  4. Write <VERSION>_PR_TRIAGE.md with a Progress header, per-tier tables (with checkbox status columns), supersede table, defer list, and order-of-attack. The doc is your session state.
  5. For each PR: gh pr checkout N, review via git show HEAD / git show --stat HEAD (NEVER main..HEAD on a stale branch — it lies), git rebase origin/main if behind, and git push <author> HEAD:<branch> --force-with-lease if maintainerCanModify=true. Then gh pr merge N --squash.
  6. Batch obviously-correct one-liners in a loop: for pr in ...; do gh pr merge $pr --squash; done. Verify each with gh pr view $pr --json state,mergeCommit.
  7. For partial-applies: git checkout <pr-sha> -- <files>, review staged, commit with a Co-Authored-By: trailer crediting the original author, then close the PR with a comment naming the applied commit.
  8. Update <VERSION>_PR_TRIAGE.md after every action. If interrupted, the doc is the only source of truth.

Counter / Caveats

  • main..HEAD on a stale PR branch shows every main commit as deletions, turning a 3-line PR into what looks like a 700-line revert. Always review via git show HEAD.
  • Squash-merging an unrebased branch reverts in-between work — rebase first or GitHub's squash computes a bad merge-base diff.
  • mergeable=UNKNOWN is transient after a push; just try the merge and see.
  • Route-ordering bugs (FastAPI-style DELETE /history/failed vs DELETE /history/{id}) are a class of bug that pairs of PRs frequently re-introduce — verify param-path routes land after the literal ones.

Source references: .agents/skills/triage-prs/SKILL.md (the full triage workflow that this skill extracts).

Use it

Copy one of these into your project. Installing also returns the manifest and these snippets.

yaml
targets:
  - https://api.opensmartroute.ai/api/v1/registry/kjuhwa-skills-hub-pre-release-pr-triage-worktree/manifest   # or paste the manifest below

Manifest

An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.

kjuhwa-skills-hub-pre-release-pr-triage-worktree.ocm.jsonjson
{
  "ocm": "1",
  "id": "kjuhwa-skills-hub-pre-release-pr-triage-worktree",
  "kind": "skill",
  "name": "pre-release-pr-triage-worktree",
  "description": "Triage open PRs for a release in a dedicated git worktree, classify each into merge/candidate/supersede/defer, and work the loop end-to-end.",
  "publisher": "kjuhwa",
  "version": "1.0.0",
  "capabilities": {
    "domains": [
      "coding"
    ],
    "tags": [
      "skill-md",
      "release-management",
      "git-worktree",
      "gh-cli",
      "triage",
      "open-source",
      "github"
    ],
    "languages": [
      "en"
    ]
  },
  "quality_prior": 0.6,
  "examples": [
    "Triage open PRs for a release in a dedicated git worktree, classify each into merge/candidate/supersede/defer, and work the loop end-to-end."
  ],
  "primary": false,
  "metadata": {
    "source": {
      "provider": "github",
      "repository": "https://github.com/kjuhwa/skills-hub",
      "path": "skills/agents/pre-release-pr-triage-worktree/SKILL.md",
      "ref": "b8e7275ea024cc3f9d8551b41aa9ebf89b464cd1",
      "url": "https://github.com/kjuhwa/skills-hub/blob/b8e7275ea024cc3f9d8551b41aa9ebf89b464cd1/skills/agents/pre-release-pr-triage-worktree/SKILL.md",
      "key": "kjuhwa/skills-hub/skills/agents/pre-release-pr-triage-worktree/SKILL.md"
    }
  },
  "instructions": "# Pre-release PR triage (worktree)\n\n## When to use\nA solo maintainer (or small team) has accumulated 10+ open PRs and wants to land the critical subset before cutting a minor/major release — without losing the changelog narrative and without deep-reviewing everything.\n\n## Steps\n1. Create a dedicated PR-review worktree: `git worktree add ../<repo>-pr-review -b pr-review-<version> main`. Keep the main worktree for release prep (changelog, direct follow-ups); use the review worktree for `gh pr checkout` so HEAD moves without contaminating release work.\n2. Bulk-gather metadata once: `gh pr list --",
  "cost": {
    "context_tokens": 717
  }
}

Fetch it by URL: GET /api/v1/registry/kjuhwa-skills-hub-pre-release-pr-triage-worktree/manifest?version=1.0.0

Reviews

Star ratings from people who tried it. One review per account; edit yours any time.

No reviews yet. Install it, try it, and be the first to rate it.