loop-skills

Autonomously watch a single pull request and drive its review feedback, failing CI checks, AND merge conflicts to completion without supervision: each round fetch every unaddressed review and comment (Claude, CodeRabbit, Copilot, other bots, humans), the PR's check runs (tests, lint, type, build, security), and its mergeability; address the actionable ones (resolving conflicts by merging the base branch into the head), commit, push, reply/resolve threads, and re-request review from bots whose change requests were addressed, then loop until a quiet round or a safety cap. Use whenever the user wants to 'watch a PR', 'babysit a PR', 'keep addressing PR comments until done', 'fix the failing checks', 'get CI green', 'resolve the merge conflict on PR #N', 'auto-respond to reviews', or run a hands-off review-response loop on ONE PR, even if they don't name this skill. Pass --single-pass (or --max-rounds 1) for one autonomous round, no loop. For MANY stacked PRs from a parent ticket, see /implement-full-spec.

(beta/experimental) Host-agnostic, N-model variant of multi-llm-convergence: drive any artifact (plan, PRD, design doc, spec, or implementation diff) to cross-model consensus from Claude, Codex, Gemini, or another capable host by rotating multiple built-in reviewer families through one uniform read-only reviewer protocol, hard preflight, local-only source grounding, per-round commits, and a full clean-cycle convergence rule. Use for 'beta convergence', 'N-model convergence', 'run convergence from Codex/Gemini/Claude', or 'converge with multiple models'. For the stable Claude Code loop, use multi-llm-convergence instead.

Drive any artifact to convergence by alternating two genuinely different LLM reviewers — a Codex reviewer and an independent Claude review subagent — applying each round's findings and looping until BOTH independently agree it clears the bar (default: no critical/high findings). Artifact-agnostic: works on a plan, PRD, design doc, spec, or implementation diff. Use whenever the user says 'have two LLMs converge on this', 'loop Claude and Codex until they agree', 'review and revise until consensus', 'iterate this plan/PRD/spec until there are no blockers', or wants cross-model agreement rather than one reviewer's opinion. Prefer this over a single review pass whenever the user wants different models to actually agree on an end result. NOT pr-autopilot (one GitHub PR's comment threads) — this is the artifact-agnostic, alternating-different-models, iterate-to-consensus loop.

Drive a single unit of work — one spec, ticket, finding, or change request — from spec to a committed, reviewed result with a dev team of coordinating agents: Dev → QA → Reviewer/code-review in a bounded cycle. Runs as an agent team when the harness supports one, else coordinated subagents, so it works across agents and models. Use whenever the operator wants a change implemented with rigor instead of a quick edit: 'use a dev team to build and verify this', 'fire off the dev team on this', 'spin up the dev/QA/review agents', 'implement this with a dev/QA/review loop', 'drive this change through dev then QA then code review', 'QA and review this before committing'. This is also the per-subtask engine behind implement-full-spec — that skill calls this dev team once per subtask, then handles stacking, PRs, and review-response on its own. Use this skill for ONE unit of work; for a parent ticket with many subtasks shipped as stacked PRs, use implement-full-spec (which delegates here).

Use when the operator points at a parent ticket, audit, RFC, design doc, or multi-finding report with N actionable subtasks and wants every subtask shipped as its own stacked pull request, then driven to merge-ready by addressing every bot/human review comment and re-requesting review per round. Triggers on: 'fix all subtasks of [ticket]', 'work through P1/P2/P3 items', 'open a PR per finding and stack them', 'ship the audit remediations', 'knock out this report end to end', 'use agent teams to fix [parent]', 'address all comments on these stacked PRs', 'drive the stack to merge-ready', 'do a review-response sweep', 'comment @bot re-review when done'. Depends on the dev-team and pr-autopilot plugins. For a single unit of work, see dev-team; for one PR's review-response, see pr-autopilot.

Import a structured planning document (implementation plan, project plan, design doc with tasks) into a task-tracking system as a ticket hierarchy with dependencies wired. Use whenever the operator says 'break this plan into tickets', 'import this into ClickUp/Linear/Jira/Asana', 'create tickets for this plan', 'turn this doc into tasks', 'set up the project in [tracker]', or any variation of converting a written plan into trackable work items. Also use when the operator references a planning doc and a target tracker URL or list in the same request. Covers hierarchy negotiation, ID mapping, dependency wiring, and the platform-specific gotchas that bite on the first attempt. Includes a readiness check up front that will stop and ask the operator to spec the plan out further if it's not yet structured enough to ticket — refusing to import a half-baked plan is part of the contract, not a failure mode.

Triangulated multi-reviewer code-review orchestrator that runs comprehensive, security, Codex, and Codex adversarial reviews in parallel, then a QA analyst subagent substantiates each finding (verifying any third-party library claims via the context7 MCP) and demotes unsubstantiated ones into an 'Invalidated Findings' section of the timestamped report. Use whenever the user asks for 'a thorough code review,' 'triangulated review,' 'review my changes,' 'multi-reviewer review,' 'run all the reviews,' 'code review with security,' 'pre-PR review,' wants more than a single perspective on pending changes, or invokes the triangulated-code-review orchestrator. Prefer this over a single reviewer whenever the user wants real coverage before opening a PR.