Use for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find blind spots", or "tear this apart". Multiple LLM reviewers challenge changes from independent angles.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Spawn one reviewer per configured model to adversarially review code changes. The adversarial signal comes from model diversity, not assigned personas. The deliverable is a synthesized verdict. Do NOT auto-apply changes.
Identify what to review from context:
git diff main...HEAD (or the appropriate base branch) for the full changeset.Package the diff or file contents with any surrounding context files the reviewers need to understand the code.
Before spawning reviewers, state the intent in one clear paragraph from the user's message, commit messages, the PR description if one exists, and the code. If you're unsure about the intent, ask the user before proceeding.
Launch all reviewers in a single message with the Task tool, one per entry on the interrogate reviewers line in the pstack settings file (~/.cursor/rules/pstack-models.mdc in Cursor, ~/.claude/rules/pstack-models.md in Claude Code, ~/.agents/pstack-models.md in other harnesses), labeled Reviewer A, B, and so on to match the entry count. If the file or that line is missing, use the table defaults.
Other harnesses. The spawns in this skill use Cursor's Task tool. In another harness, use its subagent tool: Agent in Claude Code (subagent_type: general-purpose), task in OpenCode (subagent_type: general), spawn_agent in Codex. Keep the prompt and the model. Drop parameters your tool doesn't have. If your harness has no subagent tool, as in Pi without an extension, run each reviewer yourself, one after another.
| Subagent | Default model |
|---|---|
| Reviewer A | claude-opus-5-5-xhigh |
| Reviewer B | grok-4.7-xhigh-fast |
Each reviewer gets subagent_type: generalPurpose, readonly: true, and model set to its configured entry, or its table default when there is no configured line. Omit model for an auto or inherit-parent entry, so that reviewer runs on the parent model.
If your subagent tool rejects a configured entry, run that reviewer on its family's table default and say so. Families go by prefix: claude-*, and grok-* with cursor-grok-* and composer-*. A refused composer-* entry runs on Reviewer B's default. With no family match, use Reviewer A's default. If it rejects a table default, spawn with the closest equivalent from the valid slugs in its error message or your harness's model list (prefer the same family and reasoning tier), and open a separate PR to update the default table. Do not block the review on the slug issue. Never treat an alias entry as a rejected slug or apply either fallback to it.
Read references/reviewer-prompt.md and fill in the same template for every reviewer with the stated intent, the diff or file contents, the rubric from references/rubric.md, and the code-quality lens from references/code-quality-review.md. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the poteto-mode skill.
As results come back, build a unified picture. Parse every reviewer's findings. Merge findings that describe the same issue differently, and note which models raised each one. Findings two or more models raised independently are the highest signal. Read a lone model's finding, but weight it accordingly. Note disagreements. If one model flags something and another explicitly says the opposite, that is context for the verdict.
You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator. Read references/lead-judgment.md for the full framework. Put every finding in one of four buckets, with the model(s) that raised it and a one-line rationale.
[The stated intent paragraph from Step 2]
[Each: description, which models raised it, why it matters.]
[Each: description, which models raised it, the tradeoff.]
[Brief list.]
[Each with a brief rationale.]
[Where models agreed and diverged, and what that pattern tells us.]
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.
中文简介正在准备中。当前显示原文说明。
Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.
中文简介正在准备中。当前显示原文说明。
Use for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via create-skill + unslop, optionally pulling fresh evidence from recent transcripts.
中文简介正在准备中。当前显示原文说明。
Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.
中文简介正在准备中。当前显示原文说明。
Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust.
中文简介正在准备中。当前显示原文说明。
Restate the last message in plain human language, with no jargon.
中文简介正在准备中。当前显示原文说明。