Explore AI Agent Skills & Claude Prompts

star 19

Orchestrate a multi-agent adversarial review panel where several Claude Code subagents with different perspectives independently review a piece of work, debate with each other, reach (or fail to reach) consensus, then a supreme judge renders the final verdict. Use this skill whenever the user asks for a "review panel", "multi-agent review", "adversarial review", "have agents debate this", "review with multiple perspectives", "panel review", "get different opinions on this code/plan/doc", or invokes /agent-review-panel. Also trigger when a user says things like "I want thorough feedback from different angles", "stress-test this design", "red team this", "get a second (third, fourth) opinion", "fresh eyes on this", "multiple reviewers", "devil's advocate perspective", "every angle covered", "I want agents to argue pros and cons", "independently evaluate", "critical look from security and performance angles", "high-stakes — cover every angle", or "debate the pros and cons". This skill is specifically about launc

schedule Updated 19 days ago

task-framing-claims-need-subagent-grep-verify

When dispatching a sub-agent (Agent / Task) to WRITE content that cross- references existing code paths, explicitly grant + expect grep-driven correction of the dispatcher's task-framing claims. Use when: (1) your prompt to a sub-agent asserts facts about what an existing codebase contains ("X is NOT in v6.1", "Y is already implemented at module Z", "feature F handles case G"); (2) the sub-agent will produce a document, analysis, or design that consumers will treat as authoritative; (3) the sub-agent has Read/Grep/Glob access to the code being claimed about. Without an explicit "verify these claims + tag corrections" instruction, a sub-agent will either (a) faithfully reproduce the dispatcher's wrong claim, or (b) silently substitute its own view without flagging the contradiction — both leave the dispatcher with a doc that LOOKS right but is stale. Companion to `factcheck-subagent-needs-complete-sources` (which covers feeding fact-check agents complete sources) — this skill covers the INVERSION: telling writ

db-access-review-subagent-needs-explicit-probe-budget

When dispatching a code-review / verification / research subagent that has LIVE database or cloud access (BigQuery, gcloud, psql, Bash), give it an EXPLICIT tool-call + wall-time budget and tell it which expensive probes NOT to re-run — otherwise it re-verifies everything from scratch, runs 20-40+ minutes, and can hit a transport "socket connection was closed unexpectedly" error that returns NO final message (its entire investigation output is LOST and it is NOT resumable unless a continue/ SendMessage tool exists). Use when: (1) you're about to dispatch a `general-purpose` agent to review a PR / verify findings with live-DB or gcloud access; (2) an Agent call returned `API Error: The socket connection was closed unexpectedly` with `tool_uses: N` (>0) but `subagent_tokens: 0` / no verdict — its work happened but the result was never delivered; (3) a review agent has been running >20-30 min with no return; (4) you already validated the heavy probes yourself and just want a static diff review + the fast test. F

schedule Updated 24 days ago

git-amend-hits-async-post-commit-hook-commit

Use when a `git commit --amend` silently rewrites the WRONG commit in a repo that has an async/background post-commit hook. Trigger: after a normal commit, `git log` shows an unexpected extra commit on top that a background hook created (`[auto-docs] ...`, a docs/site regen, a changelog/checkbox tick) — and a later `--amend` folds your change into THAT hook commit instead of your feature commit. The amend reports success; no error. Also use proactively before instructing subagents to `--amend` in any repo with a background post-commit hook. Sibling of git-add-u-after-async-post-commit-hook, git-rebase-stalls-async-post-commit-hook, worktree-index-corrupt-async-post-commit-hook.

code-review-subagent-fabricates-specifics-to-inflate-severity

When a code-review subagent (voltagent-qa-sec, opus-tier reviewer, code-reviewer, etc.) reports a HIGH or BLOCKING severity finding, verify any SPECIFIC EVIDENCE the reviewer cites (line numbers, call counts, exact function/symbol names, file paths beyond the obvious diff) BEFORE treating the severity as actionable. Use when: (1) a single-run code-review subagent returns a BLOCKING/HIGH finding justified by concrete numeric evidence like "there are EXACTLY 4 calls at lines 3174, 3230, 3251" or "this affects N files across the repo"; (2) the principle of the finding sounds plausible but you didn't immediately recall the specific symbols cited; (3) you're under time pressure to merge and the BLOCKING tag is the only thing holding you back; (4) the reviewer used opus tier and the confident, specific framing is reading as authoritative; (5) you notice the reviewer's grep would have been trivial (`grep -c "flash.*warning" foo.py`) but the report itself shows no evidence of grep output, only the assertion. Symptom:

schedule Updated 24 days ago

gh-pr-merge-squash-stdout-shows-sibling-files-as-created

Use when `gh pr merge --squash` prints an alarming diffstat — far more files than your PR touched, with `create mode 100644 <file>` lines for files you never added (e.g. handoff docs, sibling-PR artifacts) and an inflated insertion count. This looks like your PR smuggled unrelated content onto the base branch, but it usually has NOT: the echoed diffstat reflects your branch measured against an OLDER ancestor (files from sibling PRs merged to main *after* your branch point show as "created" in that view). The authoritative truth is the squash commit itself. Apply when: (1) `gh pr merge --squash` output shows a file-count / `create mode` lines that don't match your PR, (2) you fear a feature PR pulled in docs/zips/sibling changes, (3) before reacting (revert/force-push) to a scary merge echo. Verify with `git show --stat origin/main` instead of trusting the merge command's stdout.

schedule Updated 24 days ago

gh-pr-merge-unstable-state-needs-auto-and-watch-branch-deletes

Diagnose and recover from two adjacent `gh pr merge` failure modes that masquerade as merge conflicts. Use when: (1) `gh pr merge --squash` (or `--merge`) errors with "To have the pull request merged after all the requirements have been met, add the `--auto` flag" AND "Run the following to resolve the merge conflicts locally" even though you just pushed a clean resolution; (2) `gh pr view <N> --json mergeable,mergeStateStatus` returns `MERGEABLE` + `UNSTABLE` rather than `MERGEABLE` + `CLEAN`; (3) you delete the remote branch (`git push origin --delete <branch>`) immediately after `gh pr merge` returns a conflict warning thinking the merge succeeded — and discover the PR has flipped to `CLOSED` rather than `MERGED`. The actual root cause for (1)/(2) is almost always pending CI / branch-protection checks, NOT real merge conflicts; the fix is `--auto` flag so `gh` queues the merge for when checks pass. For (3) — recovery requires restoring the remote branch (`git push -u origin <branch>` from your local copy) a

git-diff-2dot-vs-3dot-merge-safety

Avoid false-positive "this PR will delete files on main" alarms when reviewing a PR that was branched off an older commit. Use when: (1) `git diff origin/main..pr-branch` shows files being deleted that you DON'T want to lose, but (2) GitHub reports `mergeable: MERGEABLE / mergeStateStatus: CLEAN`, (3) you're about to demand a rebase or block the merge to "preserve" those files. The 2-dot diff is misleading — it shows everything different between two trees, including files added on `main` AFTER the branch point that the branch never saw. The 3-dot diff (`origin/main...pr-branch --diff-filter=D`) respects the merge-base and shows only what the branch actually deleted. Also covers the empty-cherry-pick signal that a "divergent" local commit's content is already on main under a different hash.

pr-conflict-from-mid-flight-merges

Diagnose and resolve a GitHub PR that flips to CONFLICTING / DIRTY (or "This branch has conflicts that must be resolved") because OTHER PRs landed on `main` while this PR was open. Use when: (1) a PR was clean when opened but is now CONFLICTING after hours/days, (2) `gh pr view N --json mergeStateStatus` returns DIRTY / mergeable CONFLICTING, (3) the feature branch has accumulated commits whose content is already on main via a different PR (squash-merged with a different SHA), (4) you need to figure out WHICH PRs landed and which of YOUR commits are now redundant before rebasing. Prescribes a 6-step recipe: gh status → list landed commits → detect redundant cherry-picks → reset to origin tip → rebase → reconcile.

schedule Updated 1 month ago

parallel-pr-scope-overlap-tiebreaker-delta-check

Before applying a handoff prompt's tiebreaker default ("merge the first-mover", "the clean-against-main one", "the one with reviewer APPROVE") to pick a winner between two parallel PRs that implemented the SAME scope, run `gh pr diff` on BOTH and audit for substantive deltas. Use when: (1) a session prompt or handoff doc surfaces a parallel-PR collision and recommends a tiebreaker, (2) two PRs targeting the same issue / same fix area are open simultaneously authored by different sessions, (3) the prompt's recommended winner is the older / cleaner / single-reviewer one — exactly the conditions under which "first-mover" rules can ship the inferior implementation, (4) you're tempted to skip the delta-check because the diffs "are probably substantively equivalent" or the prompt already analyzed them. Symptom of having skipped this check: weeks later a follow-up PR re-implements a correctness improvement that was already in the loser's diff. Sister to `synthetic-id-collision-rebase` (same-id register collisions; m

schedule Updated 1 month ago

synthetic-id-collision-rebase

Fix the "I claimed cat7-7bg, they claimed cat7-7bg, theirs merged first" failure mode when rebasing a PR after parallel sessions land mid-flight. Use when: (1) rebasing a stale PR onto current main produces a conflict in an append-only register file (tracker entries, ADR `NNNN-` prefixes, migration filenames, OpenAPI operationIds, error codes, lessons.md `## N.` numbering), (2) BOTH your branch and a freshly-merged branch added an entry under THE SAME synthetic ID — the collision is namespace, not just text, (3) plain "accept both sides" yields two rows with identical IDs that violate the file's invariant, (4) multiple Claude Code sessions share a working tree and each picked "next free letter" from their local view of the file. Prescribes a reroll workflow: scan ALL taken IDs in current main, pick truly-next-free, replay only your entry under the new ID, regenerate any derived artifacts (site, indexes), force-push. Also covers the variant where git splits the conflict boundary mid-argument-list of a multi-li

code-reviewer-subagent-no-bash-blocked-on-pr-diff

Code-review subagents are frequently provisioned WITHOUT a Bash tool, so they cannot run `gh pr diff`, `git diff`, or `git checkout` — and when you prompt them to "review PR #N, fetch the diff with gh pr diff" they return a BLOCKED report (no review performed), not findings. Use when: (1) dispatching feature-dev:code-reviewer / voltagent-* / Explore agents to review GitHub PRs or branches; (2) a review agent returns "I have no shell/gh/git tool" or "the PR sources are not in the working tree" or reviews `main` (which predates the PR) instead of the PR; (3) one reviewer in a parallel panel comes back BLOCKED while siblings succeeded. Fix: pre-generate per-base diffs to files + point the agent at materialized worktree paths, don't tell it to run gh/git.