agentsclimarketplace

Git pr ops orchestrator

Skill Sheshiyer/skill-clusters/skills/git-pr-ops-orchestrator

Hub-and-spoke agent-skill clusters, one per stack (Astro·GSAP·Remotion, Tauri, …). Installable via skills.sh.

Install
npx -y skills add Sheshiyer/skill-clusters --skill git-pr-ops-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Route a GitHub PR/issue task to the right skill among the git-pr-ops specialists — read-only review, finding-resolution + safe push, deterministic squash merge, raw gh CLI queries, autonomous issue-to-PR fixing, and repo status / next-wave planning. USE WHEN a user is reviewing, preparing, merging, or shipping work through GitHub PRs and issues but hasn't named the specific step.

SKILL.md

4.7 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

git-pr-ops Orchestrator

The single entry skill for GitHub pull-request and issue operations. It locates the task on the review → prepare → merge delivery pipeline (plus the issue-driven and reporting lanes that feed it) and delegates to one of its specialist spokes. The cross-cutting model every spoke shares — the .local/ artifact handoff, head-SHA pinning, the push/merge safety rules, and the finding-severity contract — lives in git-pr-ops-core; read it before preparing or merging a PR.

Cluster map (spoke → role)

  • review-pr — read-only PR analysis. Produces .local/review.md (human) + .local/review.json (structured findings) and hands off to prepare-pr. Never pushes or merges.
  • prepare-pr — resolves the BLOCKER/IMPORTANT findings from review.json, runs gates, and pushes to the PR head with --force-with-lease. Ends with "PR is ready for /merge-pr".
  • merge-pr — deterministic squash merge, head-SHA pinned, required-check gated, with co-author trailers and post-merge verification. Ends in MERGED, never CLOSED.
  • github — raw gh CLI reference (gh issue, gh pr, gh run, gh api) for ad-hoc queries, CI-run inspection, and JSON/jq filtering.
  • gh-issues — autonomous issue→PR pipeline: fetch issues, spawn parallel sub-agents to fix them and open PRs, then watch and address review comments. Curl + REST API; supports fork mode, watch, and cron.
  • github-next-wave-orchestrator — repo reality scan → Status Report + a prioritized, parallel-where-possible "next wave" of work. Read-only unless the user approves execution.

Routing rules (intent → spoke)

Move one PR through the pipeline (the core flow)

  • "Review this PR" / "is this PR safe to merge?" → review-pr
  • "Fix the review findings and push" / "get this PR ready" → prepare-pr (requires review.json)
  • "Merge it" / "squash and merge" → merge-pr (requires prep.env)

Inspect / query GitHub directly

  • CI run failed, list runs, view logs, one-off gh api / gh pr / gh issue calls → github

Drive issues autonomously

  • "Work through the open issues" / "auto-fix bugs and open PRs" / "watch for new issues" → gh-issues
  • "Address the review comments on the open PRs" → gh-issues --reviews-only

Plan / report

  • "Where is this repo right now?" / "summarize issues" / "run the next wave" → github-next-wave-orchestrator

Multi-step asks fan out in pipeline order. "Review and merge this PR" → review-pr → prepare-pr → merge-pr, with the .local/ artifacts carried forward between each (see git-pr-ops-core).

Standard Operating Flow

  1. Locate the task on the lane: is it one PR (review → prepare → merge), an issue batch (gh-issues), a direct query (github), or a status/plan (github-next-wave-orchestrator)?
  2. If it touches preparing or merging, pull the model from git-pr-ops-core first — the artifact handoff, head-SHA pin, and push/merge safety rules are interlocking, not independent.
  3. Delegate to the spoke(s). The pipeline lane is strictly ordered and gated by artifacts; do not skip review-pr before prepare-pr, or prepare-pr before merge-pr.
  4. Return: chosen spoke(s), the artifact(s) produced or consumed (review.json / prep.env), the PR's gate/check status, and the next action.

Guardrails

See git-pr-ops-core. In short: the pipeline is gated, not optional — review-pr is read-only; prepare-pr pushes only to the PR head with --force-with-lease against a known SHA and never to main; merge-pr pins the head SHA, honors required checks, and ends in MERGED. Never use gh pr merge --auto, never git push to a base branch, never delete a worktree mid-pipeline, and never resolve a PR without its .local artifacts. State every required finding you resolve and every gate result before merging.

Loading spokes on demand

To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:

~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most pr commit review skills give in ~1.1k tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07

  • use conventional commits formatin 127 of 888, across 115 files
  • keep subject line under 72 charactersin 62 of 888, across 48 files
  • delete branches after mergein 51 of 888, across 38 files
  • use imperative mood in subject linein 51 of 888, across 42 files
  • use imperative mood in commit messagesin 44 of 888
  • verify directory is ignored before creating worktreein 43 of 888, across 12 files
  • generate a conventional commit messagein 43 of 888
  • add unignored worktree directories to gitignorein 42 of 888, across 10 files
  • make atomic commitsin 39 of 888, across 27 files
  • run tests before committingin 36 of 888, across 25 files
  • verify clean test baselinein 35 of 888, across 9 files
  • split unrelated changes into separate commitsin 35 of 888, across 30 files

Said here and by no other author read

  • route tasks to the correct specialist spoke
  • process multi-step requests in strict pipeline order
  • read the core skill model before preparing or merging
  • load spoke instructions on demand before delegating
  • return the chosen spoke and produced artifacts
  • state resolved findings and gate results before merging

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.