[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M782FN2XGRRZP9DC7AEZD1XJ":3,"skill-same:01M782FN2XGRRZP9DC7AEZD1XJ":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":6,"ownerHtmlUrl":35,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":36,"install":37,"resources":50},"01M782FN2XGRRZP9DC7AEZD1XJ","adversarial-consensus-review",null,"Perform an evidence-driven adversarial review using two independent reviewers, consensus-based defect confirmation, bounded correction rounds, and independent re-verification. Use when high-confidence validation is required for code, specifications, plans, architecture, configurations, migrations, contracts, or other concrete technical artifacts. Also invoked as ACR (Adversarial Consensus Review), \"revisión adversarial\" or \"revisión por consenso\".","Sayoner-000\u002Fgomemory","Sayoner-000","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F188939990?v=4","01M782DAKG5DXP3YNPM56H7916","Sayoner","01M782DAMM078XHV4NN62TDWDH",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-consensus-review\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: adversarial-consensus-review\r\ndescription: >\r\n  Perform an evidence-driven adversarial review using two independent reviewers,\r\n  consensus-based defect confirmation, bounded correction rounds, and independent\r\n  re-verification. Use when high-confidence validation is required for code,\r\n  specifications, plans, architecture, configurations, migrations, contracts,\r\n  or other concrete technical artifacts. Also invoked as ACR (Adversarial\r\n  Consensus Review), \"revisión adversarial\" or \"revisión por consenso\".\r\nlicense: Apache-2.0\r\nmetadata:\r\n  version: \"1.0.0\"\r\n  category: review\r\n  mode: adversarial-consensus\r\n  portability: vendor-neutral\r\n---\r\n\r\n# Adversarial Consensus Review\r\n\r\nPerform a bounded adversarial review of a concrete technical artifact using two\r\nindependent reviewers.\r\n\r\nThe goal is not to maximize the number of findings.\r\n\r\nThe goal is to identify defects supported by evidence, independently corroborate\r\nthem, correct only sufficiently confirmed problems, and verify those corrections\r\nwithout expanding the original scope unnecessarily.\r\n\r\nThe canonical workflow is:\r\n\r\n    TARGET\r\n       │\r\n       ▼\r\n    FREEZE\r\n       │\r\n       ├───────────────┐\r\n       ▼               ▼\r\n    REVIEWER A      REVIEWER B\r\n    read-only       read-only\r\n       │               │\r\n       └───────┬───────┘\r\n               ▼\r\n         CONSENSUS LEDGER\r\n               │\r\n       ┌───────┼───────────┐\r\n       ▼       ▼           ▼\r\n    CONFIRMED SUSPECT  CONTRADICTION\r\n       │\r\n       ▼\r\n    FIX ACTOR\r\n       │\r\n       ▼\r\n    FIX DELTA\r\n       │\r\n       ├───────────────┐\r\n       ▼               ▼\r\n    REVIEWER A      REVIEWER B\r\n       │               │\r\n       └───────┬───────┘\r\n               ▼\r\n          FINAL VERDICT\r\n               │\r\n      ┌────────┼─────────┐\r\n      ▼        ▼         ▼\r\n  APPROVED  ESCALATED INCOMPLETE\r\n\r\n\r\n# 1. Activation\r\n\r\nUse this skill when the user explicitly requests or clearly requires:\r\n\r\n- adversarial review;\r\n- independent review;\r\n- dual review;\r\n- consensus review;\r\n- cross-checking;\r\n- second opinion;\r\n- deep validation;\r\n- high-confidence review;\r\n- independent verification;\r\n- pre-merge validation;\r\n- pre-release technical validation;\r\n- review of a critical technical artifact.\r\n\r\nA concrete review target MUST exist.\r\n\r\nPossible targets include:\r\n\r\n- source code;\r\n- patches;\r\n- diffs;\r\n- commits;\r\n- pull request changes;\r\n- specifications;\r\n- implementation plans;\r\n- task plans;\r\n- architecture documents;\r\n- API contracts;\r\n- database migrations;\r\n- infrastructure configuration;\r\n- security-sensitive configuration;\r\n- generated artifacts;\r\n- technical design documents.\r\n\r\nDo not activate this skill merely because ordinary review is possible.\r\n\r\n\r\n# 2. Objectives\r\n\r\nThe protocol MUST:\r\n\r\n1. ensure that two reviewers inspect the same target;\r\n2. preserve independence between reviewers;\r\n3. require evidence for actionable findings;\r\n4. distinguish corroborated defects from unconfirmed observations;\r\n5. prevent reviewers from modifying the target;\r\n6. isolate corrective work from review work;\r\n7. restrict corrections to explicitly confirmed findings;\r\n8. perform independent re-verification after corrections;\r\n9. bound correction loops;\r\n10. preserve a clear terminal state;\r\n11. remain independent of any specific model provider, agent framework, editor,\r\n    CLI, IDE, memory system, or orchestration runtime.\r\n\r\n\r\n# 3. Non-Goals\r\n\r\nThis skill is not:\r\n\r\n- a generic linter;\r\n- an automatic formatter;\r\n- a style checker;\r\n- unrestricted autonomous refactoring;\r\n- a replacement for automated tests;\r\n- a replacement for CI\u002FCD;\r\n- a substitute for human approval in unresolved high-risk decisions;\r\n- authorization to commit, push, merge, deploy, publish, or release;\r\n- a mechanism for storing private chain-of-thought;\r\n- a mechanism for forcing agents to invent findings;\r\n- a dependency on any specific AI vendor or runtime.\r\n\r\n\r\n# 4. Core Invariants\r\n\r\nThe following invariants MUST hold for every review.\r\n\r\n## INV-001 — Same Target\r\n\r\nBoth reviewers MUST inspect the same frozen target.\r\n\r\n## INV-002 — Independent Judgment\r\n\r\nNeither reviewer may receive the other reviewer's findings before completing its\r\nown initial judgment.\r\n\r\n## INV-003 — Read-Only Review\r\n\r\nReviewers MUST NOT modify the target.\r\n\r\n## INV-004 — Evidence Required\r\n\r\nA finding cannot become actionable solely because it sounds plausible.\r\n\r\n## INV-005 — Independent Corroboration\r\n\r\nA confirmed finding requires independent corroboration.\r\n\r\n## INV-006 — Bounded Correction\r\n\r\nOnly authorized confirmed findings may trigger corrective work.\r\n\r\n## INV-007 — Fix Traceability\r\n\r\nEvery correction MUST reference the finding or findings it addresses.\r\n\r\n## INV-008 — Re-Verification\r\n\r\nCorrections MUST be independently verified.\r\n\r\n## INV-009 — Round Budget\r\n\r\nCorrection and verification loops MUST be bounded.\r\n\r\n## INV-010 — Fail Closed\r\n\r\nIncomplete review execution MUST NOT produce an APPROVED verdict.\r\n\r\n## INV-011 — Delivery Separation\r\n\r\nReview approval MUST NOT imply authorization to commit, merge, deploy, publish,\r\nor release.\r\n\r\n## INV-012 — No Chain-of-Thought Persistence\r\n\r\nPrivate reasoning or chain-of-thought MUST NOT be requested, required, persisted,\r\nor used as a review artifact.\r\n\r\n\r\n# 5. Terminology\r\n\r\n## Target\r\n\r\nThe exact artifact being reviewed.\r\n\r\n## Frozen Target\r\n\r\nAn immutable or sufficiently stable representation of the target used by all\r\nreviewers in a round.\r\n\r\n## Reviewer\r\n\r\nAn independent read-only agent responsible for defect discovery.\r\n\r\n## Finding\r\n\r\nA structured claim describing a potential defect.\r\n\r\n## Evidence\r\n\r\nConcrete information supporting a finding.\r\n\r\n## Consensus Ledger\r\n\r\nThe normalized result produced by comparing reviewer findings.\r\n\r\n## Confirmed Finding\r\n\r\nA defect independently identified by both reviewers.\r\n\r\n## Suspect Finding\r\n\r\nA defect identified by only one reviewer.\r\n\r\n## Contradiction\r\n\r\nA case where reviewers produce materially incompatible conclusions about the same\r\nbehavior.\r\n\r\n## Fix Actor\r\n\r\nAn agent permitted to modify the target to resolve explicitly authorized\r\nconfirmed findings.\r\n\r\n## Fix Delta\r\n\r\nThe exact changes produced by corrective work.\r\n\r\n## Re-Judgment\r\n\r\nA scoped independent review of whether a confirmed defect was resolved and\r\nwhether its correction introduced a directly related regression.\r\n\r\n\r\n# 6. Phase 0 — Resolve Applicable Context\r\n\r\nBefore reviewing the target, resolve the technical context necessary to judge it\r\ncorrectly.\r\n\r\nRelevant context may include:\r\n\r\n- repository instructions;\r\n- architecture decisions;\r\n- specifications;\r\n- project conventions;\r\n- acceptance criteria;\r\n- coding standards;\r\n- API contracts;\r\n- security constraints;\r\n- design requirements;\r\n- applicable skills;\r\n- task definitions.\r\n\r\nBoth reviewers MUST receive materially equivalent project constraints.\r\n\r\nDo not provide one reviewer with privileged information unavailable to the other\r\nunless the difference is intrinsic to the target.\r\n\r\n\r\n# 7. Phase 1 — Freeze the Target\r\n\r\nBefore launching reviewers, establish a stable target identity.\r\n\r\nUse the strongest available identifier.\r\n\r\nPreferred order:\r\n\r\n1. immutable artifact digest;\r\n2. commit or revision identifier;\r\n3. tree hash;\r\n4. exact diff;\r\n5. exact file set and content digest;\r\n6. stable document revision;\r\n7. explicitly captured scope.\r\n\r\nRecord at minimum:\r\n\r\n    target:\r\n      type:\r\n      identity:\r\n      revision:\r\n      digest:\r\n      scope:\r\n\r\nIf no immutable identifier exists, record enough information to guarantee that\r\nboth reviewers inspect the same content.\r\n\r\nIf the target changes during the review, invalidate the round and restart from\r\nthe new frozen target.\r\n\r\n\r\n# 8. Phase 2 — Independent Review\r\n\r\nCreate two logically independent reviewers:\r\n\r\n    reviewer-a\r\n    reviewer-b\r\n\r\nParallel execution is preferred when supported, but it is not required.\r\n\r\nIf only sequential execution is possible:\r\n\r\n1. execute Reviewer A;\r\n2. preserve its result without exposing it to Reviewer B;\r\n3. execute Reviewer B from the original frozen target;\r\n4. compare results only after both reviews finish.\r\n\r\nReviewer B MUST NOT be asked to:\r\n\r\n- validate Reviewer A;\r\n- confirm Reviewer A;\r\n- critique Reviewer A;\r\n- refute Reviewer A;\r\n- rank Reviewer A's findings.\r\n\r\nThat would be sequential validation rather than independent review.\r\n\r\n\r\n# 9. Reviewer Diversity\r\n\r\nWhen the runtime supports model selection, prefer reviewer diversity.\r\n\r\nPreferred order:\r\n\r\n1. different model families;\r\n2. different models;\r\n3. different providers;\r\n4. different reasoning configurations;\r\n5. isolated executions of the same model.\r\n\r\nModel diversity improves independence but is not mandatory.\r\n\r\nDo not claim strong model independence when both reviewers share effectively the\r\nsame model and context.\r\n\r\nWhen available, record:\r\n\r\n    reviewer_a:\r\n      provider:\r\n      model:\r\n      configuration:\r\n\r\n    reviewer_b:\r\n      provider:\r\n      model:\r\n      configuration:\r\n\r\n    independence:\r\n      level: full | partial | degraded\r\n      reason:\r\n\r\n\r\n# 10. Reviewer Permissions\r\n\r\nReviewers MUST operate in read-only mode.\r\n\r\nThey MAY:\r\n\r\n- read files;\r\n- inspect diffs;\r\n- inspect history;\r\n- search code;\r\n- trace control flow;\r\n- inspect specifications;\r\n- inspect contracts;\r\n- execute non-mutating diagnostic commands;\r\n- run tests that do not modify the target;\r\n- gather runtime evidence;\r\n- analyze dependency relationships.\r\n\r\nThey MUST NOT:\r\n\r\n- edit files;\r\n- apply patches;\r\n- rewrite documents;\r\n- refactor code;\r\n- commit;\r\n- push;\r\n- merge;\r\n- create pull requests;\r\n- deploy;\r\n- publish;\r\n- modify persistent memory;\r\n- delegate corrective work;\r\n- change the review target.\r\n\r\n\r\n# 11. Review Criteria\r\n\r\nUnless the user specifies narrower criteria, reviewers SHOULD inspect:\r\n\r\n1. functional correctness;\r\n2. behavioral regressions;\r\n3. edge cases;\r\n4. error handling;\r\n5. state consistency;\r\n6. concurrency;\r\n7. race conditions;\r\n8. resource lifecycle;\r\n9. security boundaries;\r\n10. authorization and permissions;\r\n11. data integrity;\r\n12. API compatibility;\r\n13. contract compatibility;\r\n14. backwards compatibility;\r\n15. performance pathologies;\r\n16. failure recovery;\r\n17. implementation\u002Fspecification consistency;\r\n18. architecture violations;\r\n19. unsafe assumptions;\r\n20. repository-specific invariants.\r\n\r\nDo not manufacture findings merely to cover every category.\r\n\r\n\r\n# 12. Evidence-First Review\r\n\r\nEvery actionable finding MUST include concrete evidence.\r\n\r\nAcceptable evidence includes:\r\n\r\n- exact path and location;\r\n- failing test;\r\n- reproducible scenario;\r\n- deterministic execution path;\r\n- violated invariant;\r\n- contract contradiction;\r\n- invalid state transition;\r\n- runtime trace;\r\n- security boundary violation;\r\n- incorrect API behavior;\r\n- data corruption path;\r\n- concurrency schedule;\r\n- static analysis result.\r\n\r\nAvoid treating the following as defects without stronger evidence:\r\n\r\n- stylistic preference;\r\n- personal design preference;\r\n- vague suspicion;\r\n- hypothetical scenarios with no reachable execution path;\r\n- speculative performance concerns;\r\n- optional refactors;\r\n- alternative implementations;\r\n- purely aesthetic improvements.\r\n\r\n\r\n# 13. Severity Model\r\n\r\nUse only the following severities.\r\n\r\n## CRITICAL\r\n\r\nA defect that can plausibly cause:\r\n\r\n- security compromise;\r\n- privilege escalation;\r\n- unrecoverable data loss;\r\n- large-scale corruption;\r\n- catastrophic service failure;\r\n- severe violation of a trust boundary.\r\n\r\n## HIGH\r\n\r\nA significant defect causing:\r\n\r\n- reproducible functional failure;\r\n- major behavioral regression;\r\n- incorrect persistent state;\r\n- broken external contract;\r\n- serious concurrency defect;\r\n- significant production failure;\r\n- unsafe error handling.\r\n\r\n## MEDIUM\r\n\r\nA real defect with bounded impact.\r\n\r\nExamples:\r\n\r\n- incorrect edge-case behavior;\r\n- localized inconsistency;\r\n- incomplete validation;\r\n- recoverable failure;\r\n- bounded performance issue.\r\n\r\n## LOW\r\n\r\nA minor correctness or robustness defect with limited operational impact.\r\n\r\n## INFO\r\n\r\nA non-blocking observation.\r\n\r\nExamples:\r\n\r\n- readability;\r\n- style;\r\n- optional refactor;\r\n- documentation suggestion;\r\n- alternative design;\r\n- unverified concern.\r\n\r\n\r\n# 14. Finding Format\r\n\r\nEach reviewer MUST return structured findings.\r\n\r\nPreferred representation:\r\n\r\n    {\r\n      \"findings\": [\r\n        {\r\n          \"id\": \"A-001\",\r\n          \"location\": \"path\u002Ffile.ext:120-137\",\r\n          \"severity\": \"HIGH\",\r\n          \"category\": \"concurrency\",\r\n          \"claim\": \"Concurrent updates can overwrite a newer state.\",\r\n          \"evidence_class\": \"deterministic\",\r\n          \"evidence\": [\r\n            \"The state is read before entering the protected update boundary.\",\r\n            \"Two concurrent requests can observe the same previous value.\"\r\n          ],\r\n          \"confidence\": \"high\"\r\n        }\r\n      ],\r\n      \"inspected\": [\r\n        \"path\u002Ffile.ext\",\r\n        \"path\u002Ffile_test.ext\"\r\n      ]\r\n    }\r\n\r\nReviewer identifiers SHOULD use:\r\n\r\n    A-001\r\n    A-002\r\n\r\nand:\r\n\r\n    B-001\r\n    B-002\r\n\r\nThe exact serialization format MAY differ when the runtime requires another\r\nstructured format.\r\n\r\n\r\n# 15. Evidence Classes\r\n\r\nUse one of:\r\n\r\n- deterministic;\r\n- reproduced;\r\n- contract;\r\n- test-failure;\r\n- static-analysis;\r\n- runtime-observation;\r\n- probabilistic.\r\n\r\nPrefer:\r\n\r\n    deterministic\r\n    reproduced\r\n    contract\r\n    test-failure\r\n\r\nover weaker speculative evidence.\r\n\r\nProbabilistic findings require stronger corroboration before corrective action.\r\n\r\n\r\n# 16. Reviewer Prompt Contract\r\n\r\nWhen spawning or instructing a reviewer, preserve the following behavioral\r\ncontract:\r\n\r\n    You are an independent reviewer.\r\n\r\n    Review the frozen target from first principles.\r\n\r\n    Do not modify the target.\r\n\r\n    Do not ask for another reviewer's findings.\r\n\r\n    Do not assume another reviewer agrees with you.\r\n\r\n    Do not manufacture findings.\r\n\r\n    Every defect must describe concrete incorrect behavior and include evidence.\r\n\r\n    Return structured findings only.\r\n\r\n    If no meaningful defect exists, return an empty findings collection.\r\n\r\nRuntime-specific syntax MAY differ, but these semantics MUST remain intact.\r\n\r\n\r\n# 17. Phase 3 — Consensus\r\n\r\nOnly the orchestrator or consensus component may compare the reviewer outputs.\r\n\r\nIt MUST:\r\n\r\n1. validate reviewer result structure;\r\n2. reject malformed findings when necessary;\r\n3. normalize equivalent terminology;\r\n4. match findings by underlying defect;\r\n5. preserve disagreement;\r\n6. preserve unsupported single-reviewer observations;\r\n7. generate the consensus ledger.\r\n\r\nThe consensus process MUST NOT invent new defects.\r\n\r\n\r\n# 18. Finding Equivalence\r\n\r\nTwo findings SHOULD be considered equivalent when they describe substantially\r\nthe same:\r\n\r\n- failing behavior;\r\n- causal mechanism;\r\n- affected execution path;\r\n- affected invariant;\r\n- affected component.\r\n\r\nTextual similarity alone is insufficient.\r\n\r\nExample:\r\n\r\nReviewer A:\r\n\r\n    Concurrent writes can overwrite state.\r\n\r\nReviewer B:\r\n\r\n    Two requests can persist updates derived from the same stale state.\r\n\r\nThese findings may represent the same underlying defect even though their wording\r\ndiffers.\r\n\r\n\r\n# 19. Consensus Classes\r\n\r\nEach normalized finding MUST be classified as one of:\r\n\r\n## CONFIRMED\r\n\r\nBoth reviewers independently identified the same underlying defect.\r\n\r\n## SUSPECT\r\n\r\nOnly one reviewer identified the defect.\r\n\r\n## CONTRADICTION\r\n\r\nThe reviewers reached incompatible conclusions about the same behavior or\r\ninvariant.\r\n\r\n## INFO\r\n\r\nNon-blocking observation.\r\n\r\n\r\n# 20. Consensus Ledger\r\n\r\nThe orchestrator SHOULD produce a ledger equivalent to:\r\n\r\n    target:\r\n      identity:\r\n      revision:\r\n      digest:\r\n\r\n    reviewers:\r\n      reviewer_a:\r\n        model:\r\n      reviewer_b:\r\n        model:\r\n\r\n    consensus:\r\n\r\n      confirmed:\r\n        - id: C-001\r\n          severity: HIGH\r\n          sources:\r\n            - A-001\r\n            - B-003\r\n          claim:\r\n          evidence:\r\n          status: open\r\n\r\n      suspect:\r\n        - id: S-001\r\n          source: A-004\r\n          severity: MEDIUM\r\n          claim:\r\n\r\n      contradictions:\r\n        - id: X-001\r\n          subject:\r\n          reviewer_a:\r\n          reviewer_b:\r\n\r\n      info: []\r\n\r\n\r\n# 21. Correction Policy\r\n\r\nBy default, automatic or pre-authorized corrective work is permitted only for:\r\n\r\n    CONFIRMED + CRITICAL\r\n    CONFIRMED + HIGH\r\n\r\nThe following MUST NOT trigger automatic correction by default:\r\n\r\n    SUSPECT\r\n    CONTRADICTION\r\n    MEDIUM\r\n    LOW\r\n    INFO\r\n\r\nThe user or calling system MAY define a stricter or broader policy.\r\n\r\nContradictory severe findings SHOULD be escalated rather than guessed.\r\n\r\n\r\n# 22. Human Authorization\r\n\r\nIf the user requested review only, do not modify the target.\r\n\r\nIf the user explicitly requested:\r\n\r\n- review and fix;\r\n- review until approved;\r\n- fix confirmed defects;\r\n- validate and correct;\r\n\r\nthen corrective work may proceed according to the configured policy.\r\n\r\nReview authorization and write authorization are separate concepts.\r\n\r\n\r\n# 23. Phase 4 — Fix Actor\r\n\r\nCorrective work SHOULD be performed by an actor separate from the initial\r\nreviewers when the runtime supports delegation.\r\n\r\nThe Fix Actor receives only:\r\n\r\n- frozen target identity;\r\n- authorized confirmed findings;\r\n- evidence for those findings;\r\n- applicable project rules;\r\n- allowed correction scope.\r\n\r\nThe Fix Actor SHOULD NOT receive unrelated suspect findings unless explicitly\r\nauthorized.\r\n\r\n\r\n# 24. Minimal Correction Principle\r\n\r\nFor every authorized finding:\r\n\r\n1. identify the smallest sufficient correction;\r\n2. modify only necessary scope;\r\n3. preserve unrelated behavior;\r\n4. add or update focused verification when appropriate;\r\n5. execute relevant validation;\r\n6. record changed artifacts;\r\n7. record which finding the change addresses.\r\n\r\nDo not perform opportunistic cleanup.\r\n\r\n\r\n# 25. Fix Actor Restrictions\r\n\r\nThe Fix Actor MUST NOT:\r\n\r\n- fix SUSPECT findings without authorization;\r\n- resolve INFO observations opportunistically;\r\n- perform unrelated refactors;\r\n- redesign unrelated architecture;\r\n- expand public APIs unnecessarily;\r\n- alter unrelated files for cleanup;\r\n- commit;\r\n- push;\r\n- merge;\r\n- deploy;\r\n- release;\r\n\r\nunless separately authorized by the calling workflow.\r\n\r\n\r\n# 26. Fix Delta\r\n\r\nAfter corrective work, freeze the resulting delta.\r\n\r\nRecord:\r\n\r\n    fix_delta:\r\n      base_target:\r\n      fixed_target:\r\n      findings_addressed:\r\n      modified_paths:\r\n      diff_identity:\r\n      verification:\r\n\r\nThe fixed target becomes a new immutable review revision.\r\n\r\n\r\n# 27. Phase 5 — Re-Judgment\r\n\r\nAfter correction, two reviewers MUST independently verify the fix.\r\n\r\nRe-judgment is intentionally narrower than the initial review.\r\n\r\nInspect:\r\n\r\n1. whether the original confirmed defect was resolved;\r\n2. whether the relevant invariant now holds;\r\n3. whether the correction directly introduced a regression.\r\n\r\nDo not silently turn re-judgment into an unrestricted new code review.\r\n\r\n\r\n# 28. Re-Judgment Finding States\r\n\r\nFor every confirmed finding, reviewers MUST classify the result as:\r\n\r\n    RESOLVED\r\n    UNRESOLVED\r\n    REGRESSED\r\n\r\nA new finding may be introduced during re-judgment only when it is causally\r\nrelated to the correction.\r\n\r\nUnrelated observations belong to another review cycle.\r\n\r\n\r\n# 29. Re-Judgment Prompt Contract\r\n\r\nUse semantics equivalent to:\r\n\r\n    You are independently verifying a correction.\r\n\r\n    Inspect the original confirmed defect and the fix delta.\r\n\r\n    Determine whether the defect is RESOLVED, UNRESOLVED, or REGRESSED.\r\n\r\n    Check for regressions caused directly by the correction.\r\n\r\n    Do not perform an unrelated full review.\r\n\r\n    Do not modify the target.\r\n\r\n    Return structured evidence.\r\n\r\n\r\n# 30. Round Budget\r\n\r\nThe protocol MUST be bounded.\r\n\r\nDefault maximum:\r\n\r\n    initial_review: 1\r\n    fix_rounds: 2\r\n    rejudgment_rounds: 2\r\n\r\nCanonical maximum flow:\r\n\r\n    INITIAL REVIEW\r\n         │\r\n         ▼\r\n      FIX #1\r\n         │\r\n         ▼\r\n    RE-JUDGMENT\r\n         │\r\n         ▼\r\n      FIX #2\r\n         │\r\n         ▼\r\n    RE-JUDGMENT\r\n         │\r\n         ▼\r\n      ESCALATE\r\n\r\nNever silently extend the configured budget.\r\n\r\n\r\n# 31. Failure Handling\r\n\r\n## Reviewer Unavailable\r\n\r\nIf one required reviewer cannot execute:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\nDo not substitute one review for two.\r\n\r\n## Target Unavailable\r\n\r\nIf a reviewer cannot inspect the required target:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\n## Target Changed\r\n\r\nInvalidate the current round and restart against the new frozen target.\r\n\r\n## Duplicate Reviewer Execution\r\n\r\nIf two outputs originate from the same effective execution or one output was\r\ncopied from another, treat them as one review.\r\n\r\n## Malformed Reviewer Result\r\n\r\nAttempt only bounded normalization.\r\n\r\nIf the result cannot be interpreted reliably:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\n## Severe Contradiction\r\n\r\nIf reviewers disagree materially on a CRITICAL or HIGH behavior:\r\n\r\n    VERDICT: ESCALATED\r\n\r\nunless an explicitly authorized arbitration mechanism exists.\r\n\r\n\r\n# 32. Independence Levels\r\n\r\nReport the effective independence when possible.\r\n\r\n## FULL\r\n\r\nExamples:\r\n\r\n- separate agents;\r\n- isolated contexts;\r\n- different models;\r\n- equivalent access to the same frozen target.\r\n\r\n## PARTIAL\r\n\r\nExamples:\r\n\r\n- isolated agents using the same model;\r\n- sequential independent execution with clean context boundaries.\r\n\r\n## DEGRADED\r\n\r\nExamples:\r\n\r\n- one runtime performing two simulated passes;\r\n- context isolation cannot be guaranteed;\r\n- same agent must emulate both reviewer roles.\r\n\r\nWhen independence is degraded, state it explicitly.\r\n\r\nNever present degraded review as fully independent multi-agent review.\r\n\r\n\r\n# 33. Runtime Adaptation\r\n\r\nThis skill MUST remain runtime-agnostic.\r\n\r\nA runtime may implement reviewer isolation using:\r\n\r\n- subagents;\r\n- worker agents;\r\n- child sessions;\r\n- isolated model invocations;\r\n- agent pools;\r\n- remote agents;\r\n- separate CLI processes;\r\n- tool-driven executions;\r\n- workflow nodes.\r\n\r\nThe implementation mechanism is irrelevant as long as the protocol invariants\r\nhold.\r\n\r\n\r\n# 34. No-Subagent Fallback\r\n\r\nIf the runtime lacks subagents but can perform isolated passes:\r\n\r\n1. preserve the frozen target;\r\n2. execute Review Pass A;\r\n3. remove its findings from active context;\r\n4. execute Review Pass B independently;\r\n5. compare only after both passes complete.\r\n\r\nReport:\r\n\r\n    independence: degraded\r\n\r\nor:\r\n\r\n    independence: partial\r\n\r\ndepending on the actual isolation guarantees.\r\n\r\nIf genuine isolation cannot be approximated responsibly, prefer:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\nover pretending the protocol was fully executed.\r\n\r\n\r\n# 35. Final Verification\r\n\r\nFinal verification is separate from initial defect discovery.\r\n\r\nBefore APPROVED, confirm:\r\n\r\n- both required reviewers executed;\r\n- both inspected the same target revision;\r\n- confirmed severe findings are resolved;\r\n- no unresolved severe contradiction remains;\r\n- required focused tests passed;\r\n- broader relevant validation passed when feasible;\r\n- the correction remained within authorized scope;\r\n- no correction-caused severe regression remains;\r\n- the round budget was respected.\r\n\r\n\r\n# 36. Terminal States\r\n\r\nOnly the following terminal states are valid:\r\n\r\n    APPROVED\r\n    ESCALATED\r\n    INCOMPLETE\r\n\r\n## APPROVED\r\n\r\nUse when:\r\n\r\n- the required independent review completed;\r\n- no unresolved confirmed CRITICAL or HIGH finding remains;\r\n- no unresolved severe contradiction remains;\r\n- required correction verification completed.\r\n\r\n## ESCALATED\r\n\r\nUse when:\r\n\r\n- a severe defect remains after the allowed correction rounds;\r\n- reviewers materially disagree on a severe issue;\r\n- correction requires judgment beyond the allowed scope;\r\n- human intervention is required.\r\n\r\n## INCOMPLETE\r\n\r\nUse when:\r\n\r\n- a required reviewer could not execute;\r\n- target identity could not be preserved;\r\n- reviewer evidence is unusable;\r\n- protocol invariants could not be satisfied.\r\n\r\n\r\n# 37. Final Output\r\n\r\nPreferred result:\r\n\r\n    ADVERSARIAL CONSENSUS REVIEW\r\n\r\n    Target:\r\n    Revision:\r\n    Independence:\r\n    Review rounds:\r\n    Fix rounds:\r\n\r\n    Confirmed:\r\n    Suspect:\r\n    Contradictions:\r\n    Info:\r\n\r\n    Corrections:\r\n    Re-judgment:\r\n    Verification:\r\n\r\n    VERDICT: APPROVED\r\n\r\nor:\r\n\r\n    VERDICT: ESCALATED\r\n\r\nor:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\nReturn exactly one terminal verdict.\r\n\r\n\r\n# 38. Memory and Persistence\r\n\r\nThis skill does not require a memory system.\r\n\r\nIf the runtime provides persistent memory, it MAY preserve reusable review\r\nknowledge.\r\n\r\nAppropriate knowledge includes:\r\n\r\n- confirmed defect pattern;\r\n- affected component;\r\n- root cause summary;\r\n- resolution summary;\r\n- prevention rule;\r\n- validation performed;\r\n- final verdict.\r\n\r\nDo NOT persist:\r\n\r\n- private chain-of-thought;\r\n- hidden reasoning;\r\n- speculative reviewer deliberation;\r\n- duplicated raw transcripts;\r\n- irrelevant temporary observations.\r\n\r\nPrefer distilled knowledge over conversation logs.\r\n\r\n\r\n# 39. Reusable Review Learning\r\n\r\nA resolved confirmed finding MAY be transformed conceptually into:\r\n\r\n    review_learning:\r\n      category:\r\n      component:\r\n      problem:\r\n      root_cause:\r\n      resolution:\r\n      prevention:\r\n      verification:\r\n      confidence:\r\n\r\nPromotion SHOULD generally require:\r\n\r\n    CONFIRMED\r\n    AND\r\n    RESOLVED\r\n    AND\r\n    REUSABLE\r\n\r\nMemory behavior is optional and MUST NOT affect the correctness of the review\r\nprotocol.\r\n\r\n\r\n# 40. Security\r\n\r\nReviewers and corrective actors MUST obey the security boundaries of the calling\r\nenvironment.\r\n\r\nDo not request elevated privileges merely to complete the protocol.\r\n\r\nNever expose or persist:\r\n\r\n- credentials;\r\n- authentication tokens;\r\n- private keys;\r\n- secrets;\r\n- unnecessary sensitive information;\r\n- private chain-of-thought.\r\n\r\nIf security-sensitive information is encountered, reference only the minimum\r\nevidence required to describe the defect safely.\r\n\r\n\r\n# 41. Delivery Boundary\r\n\r\nAn APPROVED verdict means only:\r\n\r\n    the reviewed target satisfied this review protocol.\r\n\r\nIt does NOT mean:\r\n\r\n    commit authorized\r\n    push authorized\r\n    PR authorized\r\n    merge authorized\r\n    deployment authorized\r\n    production release authorized\r\n    publication authorized\r\n\r\nThose actions require separate instructions or workflow policy.\r\n\r\n\r\n# 42. Recommended Orchestration\r\n\r\nWhen full agent capabilities exist, prefer:\r\n\r\n    ORCHESTRATOR\r\n        │\r\n        ├── REVIEWER A\r\n        │      read-only\r\n        │\r\n        ├── REVIEWER B\r\n        │      read-only\r\n        │\r\n        └── FIX ACTOR\r\n               write only when authorized\r\n\r\nThe orchestrator owns:\r\n\r\n- target freezing;\r\n- reviewer isolation;\r\n- result collection;\r\n- consensus;\r\n- correction authorization;\r\n- round accounting;\r\n- terminal verdict.\r\n\r\nReviewers own:\r\n\r\n- independent defect discovery;\r\n- evidence production.\r\n\r\nThe Fix Actor owns:\r\n\r\n- bounded correction.\r\n\r\nNo single role should silently assume all three responsibilities when role\r\nseparation is available.\r\n\r\n## Follow-up Review (Cumulative)\r\n\r\nWhen a previous review of the same work already reached a terminal state and\r\nthe target has changed since (for example, after corrections), start a\r\nfollow-up review linked to it instead of reviewing everything again.\r\n\r\nA follow-up review:\r\n\r\n- inherits what the previous review settled: CONFIRMED findings resolved in\r\n  its last round, and SUSPECT and INFO findings already classified;\r\n- never inherits an unresolved CONFIRMED finding or a CONTRADICTION: those stay\r\n  open and are reviewed again;\r\n- limits the reviewers to the delta: the files that changed between the\r\n  previous target and the new one;\r\n- does not re-adjudicate an inherited finding whose files did not change;\r\n- reopens an inherited finding, linked to it, when one of its files changed.\r\n\r\nThe orchestrator:\r\n\r\n1. Links the new review to the previous terminal review.\r\n2. Gives each reviewer the delta and the inherited list, without the other\r\n   reviewer's results.\r\n3. Builds consensus only for findings that are not settled.\r\n\r\nThe terminal guarantees do not change: a missing or failed reviewer still\r\nyields INCOMPLETE, and a confirmed CRITICAL or HIGH finding left unresolved\r\nstill prevents APPROVED.\r\n\r\nIf the runtime keeps a review ledger that supports linked reviews, use it\r\nrather than pasting the lists by hand. A typical contract: the operation that\r\nstarts a review accepts the previous review identifier (`since_review_id`) and\r\nreturns the `delta`, the `inherited` findings with their `consensus_id`, and\r\n`instructions` for the reviewers. A reviewer who reports an inherited finding\r\nagain cites it with `settled_ref` (its `consensus_id`); the ledger, not the\r\nreviewer, decides whether it stays settled.\r\n\r\n\r\n# 43. Recommended Invocation Examples\r\n\r\nCode:\r\n\r\n    Perform an adversarial consensus review of the current diff.\r\n\r\nSpecification:\r\n\r\n    Use adversarial-consensus-review on this specification before implementation.\r\n\r\nArchitecture:\r\n\r\n    Independently review this architecture with two reviewers and report only\r\n    corroborated high-confidence defects.\r\n\r\nImplementation plus correction:\r\n\r\n    Implement the requested change, then run adversarial-consensus-review.\r\n    Correct confirmed HIGH or CRITICAL defects and re-verify them before\r\n    completion.\r\n\r\nReview only:\r\n\r\n    Review the current implementation using adversarial-consensus-review.\r\n    Do not modify anything.\r\n\r\nPre-delivery:\r\n\r\n    Run adversarial-consensus-review before considering this work ready for\r\n    delivery. Do not commit or push.\r\n\r\n\r\n# 44. Reviewer Template\r\n\r\nUse an equivalent template when the runtime requires explicit reviewer\r\ninstructions:\r\n\r\n    ROLE\r\n\r\n    You are independent Reviewer {A|B}.\r\n\r\n    TARGET\r\n\r\n    {frozen target identity}\r\n\r\n    SCOPE\r\n\r\n    {exact review scope}\r\n\r\n    PROJECT CONTEXT\r\n\r\n    {applicable rules and contracts}\r\n\r\n    FOLLOW-UP (only when this review is linked to a previous one)\r\n\r\n    Delta (review only these files): {delta}\r\n    Inherited findings (already settled; do not report them again):\r\n    {inherited: consensus_id, claim, files}\r\n    If an inherited finding reappears, report it with\r\n    \"settled_ref\": {consensus_id}.\r\n\r\n    CONTRACT\r\n\r\n    - Review independently.\r\n    - Do not modify the target.\r\n    - Do not request another reviewer's findings.\r\n    - Do not infer another reviewer's conclusions.\r\n    - Do not manufacture defects.\r\n    - Every actionable finding requires concrete evidence.\r\n    - Return structured findings.\r\n    - An empty findings set is valid.\r\n\r\n    OUTPUT\r\n\r\n    {\r\n      \"findings\": [\r\n        {\r\n          \"id\": \"{A|B}-001\",\r\n          \"location\": \"\",\r\n          \"severity\": \"CRITICAL|HIGH|MEDIUM|LOW|INFO\",\r\n          \"category\": \"\",\r\n          \"claim\": \"\",\r\n          \"evidence_class\": \"\",\r\n          \"evidence\": [],\r\n          \"confidence\": \"high|medium|low\",\r\n          \"settled_ref\": 0\r\n        }\r\n      ],\r\n      \"inspected\": []\r\n    }\r\n\r\n\r\n# 45. Fix Actor Template\r\n\r\nUse equivalent semantics:\r\n\r\n    ROLE\r\n\r\n    You are the bounded correction actor.\r\n\r\n    TARGET\r\n\r\n    {target identity}\r\n\r\n    AUTHORIZED FINDINGS\r\n\r\n    {confirmed findings authorized for correction}\r\n\r\n    CONTRACT\r\n\r\n    - Correct only authorized confirmed findings.\r\n    - Use the smallest sufficient change.\r\n    - Preserve unrelated behavior.\r\n    - Do not perform opportunistic cleanup.\r\n    - Add focused verification when appropriate.\r\n    - Record modified artifacts and validation.\r\n    - Do not commit, push, merge, deploy, or release unless separately authorized.\r\n\r\n    OUTPUT\r\n\r\n    {\r\n      \"work_units\": [\r\n        {\r\n          \"finding_id\": \"C-001\",\r\n          \"modified_paths\": [],\r\n          \"change_summary\": \"\",\r\n          \"verification\": []\r\n        }\r\n      ]\r\n    }\r\n\r\n\r\n# 46. Re-Judgment Template\r\n\r\nUse equivalent semantics:\r\n\r\n    ROLE\r\n\r\n    You are independent Reviewer {A|B} performing scoped re-verification.\r\n\r\n    ORIGINAL FINDING\r\n\r\n    {confirmed finding}\r\n\r\n    FIX DELTA\r\n\r\n    {exact corrective delta}\r\n\r\n    CONTRACT\r\n\r\n    Determine whether the original defect is:\r\n\r\n    - RESOLVED\r\n    - UNRESOLVED\r\n    - REGRESSED\r\n\r\n    Check only the original defect, relevant invariants, and regressions directly\r\n    introduced by the fix.\r\n\r\n    Do not perform an unrelated full review.\r\n\r\n    Do not modify the target.\r\n\r\n    OUTPUT\r\n\r\n    {\r\n      \"finding_id\": \"C-001\",\r\n      \"status\": \"RESOLVED|UNRESOLVED|REGRESSED\",\r\n      \"evidence\": []\r\n    }\r\n\r\n\r\n# 47. Design Principle\r\n\r\nThe fundamental rule of this skill is:\r\n\r\n> Independent evidence precedes consensus, consensus precedes correction, and\r\n> correction precedes re-verification.\r\n\r\nA reviewer is not valuable because it produces more findings.\r\n\r\nA reviewer is valuable when it identifies a concrete defect that can be\r\nexplained, evidenced, independently corroborated, corrected with bounded scope,\r\nand verified afterward.\r\n\r\nWhen the runtime offers stronger isolation, multiple models, subagents, memory,\r\nor orchestration capabilities, use them to strengthen the protocol.\r\n\r\nNever make the protocol dependent on them.\n","# Adversarial Consensus Review\r\n\r\nPerform a bounded adversarial review of a concrete technical artifact using two\r\nindependent reviewers.\r\n\r\nThe goal is not to maximize the number of findings.\r\n\r\nThe goal is to identify defects supported by evidence, independently corroborate\r\nthem, correct only sufficiently confirmed problems, and verify those corrections\r\nwithout expanding the original scope unnecessarily.\r\n\r\nThe canonical workflow is:\r\n\r\n    TARGET\r\n       │\r\n       ▼\r\n    FREEZE\r\n       │\r\n       ├───────────────┐\r\n       ▼               ▼\r\n    REVIEWER A      REVIEWER B\r\n    read-only       read-only\r\n       │               │\r\n       └───────┬───────┘\r\n               ▼\r\n         CONSENSUS LEDGER\r\n               │\r\n       ┌───────┼───────────┐\r\n       ▼       ▼           ▼\r\n    CONFIRMED SUSPECT  CONTRADICTION\r\n       │\r\n       ▼\r\n    FIX ACTOR\r\n       │\r\n       ▼\r\n    FIX DELTA\r\n       │\r\n       ├───────────────┐\r\n       ▼               ▼\r\n    REVIEWER A      REVIEWER B\r\n       │               │\r\n       └───────┬───────┘\r\n               ▼\r\n          FINAL VERDICT\r\n               │\r\n      ┌────────┼─────────┐\r\n      ▼        ▼         ▼\r\n  APPROVED  ESCALATED INCOMPLETE\r\n\r\n\r\n# 1. Activation\r\n\r\nUse this skill when the user explicitly requests or clearly requires:\r\n\r\n- adversarial review;\r\n- independent review;\r\n- dual review;\r\n- consensus review;\r\n- cross-checking;\r\n- second opinion;\r\n- deep validation;\r\n- high-confidence review;\r\n- independent verification;\r\n- pre-merge validation;\r\n- pre-release technical validation;\r\n- review of a critical technical artifact.\r\n\r\nA concrete review target MUST exist.\r\n\r\nPossible targets include:\r\n\r\n- source code;\r\n- patches;\r\n- diffs;\r\n- commits;\r\n- pull request changes;\r\n- specifications;\r\n- implementation plans;\r\n- task plans;\r\n- architecture documents;\r\n- API contracts;\r\n- database migrations;\r\n- infrastructure configuration;\r\n- security-sensitive configuration;\r\n- generated artifacts;\r\n- technical design documents.\r\n\r\nDo not activate this skill merely because ordinary review is possible.\r\n\r\n\r\n# 2. Objectives\r\n\r\nThe protocol MUST:\r\n\r\n1. ensure that two reviewers inspect the same target;\r\n2. preserve independence between reviewers;\r\n3. require evidence for actionable findings;\r\n4. distinguish corroborated defects from unconfirmed observations;\r\n5. prevent reviewers from modifying the target;\r\n6. isolate corrective work from review work;\r\n7. restrict corrections to explicitly confirmed findings;\r\n8. perform independent re-verification after corrections;\r\n9. bound correction loops;\r\n10. preserve a clear terminal state;\r\n11. remain independent of any specific model provider, agent framework, editor,\r\n    CLI, IDE, memory system, or orchestration runtime.\r\n\r\n\r\n# 3. Non-Goals\r\n\r\nThis skill is not:\r\n\r\n- a generic linter;\r\n- an automatic formatter;\r\n- a style checker;\r\n- unrestricted autonomous refactoring;\r\n- a replacement for automated tests;\r\n- a replacement for CI\u002FCD;\r\n- a substitute for human approval in unresolved high-risk decisions;\r\n- authorization to commit, push, merge, deploy, publish, or release;\r\n- a mechanism for storing private chain-of-thought;\r\n- a mechanism for forcing agents to invent findings;\r\n- a dependency on any specific AI vendor or runtime.\r\n\r\n\r\n# 4. Core Invariants\r\n\r\nThe following invariants MUST hold for every review.\r\n\r\n## INV-001 — Same Target\r\n\r\nBoth reviewers MUST inspect the same frozen target.\r\n\r\n## INV-002 — Independent Judgment\r\n\r\nNeither reviewer may receive the other reviewer's findings before completing its\r\nown initial judgment.\r\n\r\n## INV-003 — Read-Only Review\r\n\r\nReviewers MUST NOT modify the target.\r\n\r\n## INV-004 — Evidence Required\r\n\r\nA finding cannot become actionable solely because it sounds plausible.\r\n\r\n## INV-005 — Independent Corroboration\r\n\r\nA confirmed finding requires independent corroboration.\r\n\r\n## INV-006 — Bounded Correction\r\n\r\nOnly authorized confirmed findings may trigger corrective work.\r\n\r\n## INV-007 — Fix Traceability\r\n\r\nEvery correction MUST reference the finding or findings it addresses.\r\n\r\n## INV-008 — Re-Verification\r\n\r\nCorrections MUST be independently verified.\r\n\r\n## INV-009 — Round Budget\r\n\r\nCorrection and verification loops MUST be bounded.\r\n\r\n## INV-010 — Fail Closed\r\n\r\nIncomplete review execution MUST NOT produce an APPROVED verdict.\r\n\r\n## INV-011 — Delivery Separation\r\n\r\nReview approval MUST NOT imply authorization to commit, merge, deploy, publish,\r\nor release.\r\n\r\n## INV-012 — No Chain-of-Thought Persistence\r\n\r\nPrivate reasoning or chain-of-thought MUST NOT be requested, required, persisted,\r\nor used as a review artifact.\r\n\r\n\r\n# 5. Terminology\r\n\r\n## Target\r\n\r\nThe exact artifact being reviewed.\r\n\r\n## Frozen Target\r\n\r\nAn immutable or sufficiently stable representation of the target used by all\r\nreviewers in a round.\r\n\r\n## Reviewer\r\n\r\nAn independent read-only agent responsible for defect discovery.\r\n\r\n## Finding\r\n\r\nA structured claim describing a potential defect.\r\n\r\n## Evidence\r\n\r\nConcrete information supporting a finding.\r\n\r\n## Consensus Ledger\r\n\r\nThe normalized result produced by comparing reviewer findings.\r\n\r\n## Confirmed Finding\r\n\r\nA defect independently identified by both reviewers.\r\n\r\n## Suspect Finding\r\n\r\nA defect identified by only one reviewer.\r\n\r\n## Contradiction\r\n\r\nA case where reviewers produce materially incompatible conclusions about the same\r\nbehavior.\r\n\r\n## Fix Actor\r\n\r\nAn agent permitted to modify the target to resolve explicitly authorized\r\nconfirmed findings.\r\n\r\n## Fix Delta\r\n\r\nThe exact changes produced by corrective work.\r\n\r\n## Re-Judgment\r\n\r\nA scoped independent review of whether a confirmed defect was resolved and\r\nwhether its correction introduced a directly related regression.\r\n\r\n\r\n# 6. Phase 0 — Resolve Applicable Context\r\n\r\nBefore reviewing the target, resolve the technical context necessary to judge it\r\ncorrectly.\r\n\r\nRelevant context may include:\r\n\r\n- repository instructions;\r\n- architecture decisions;\r\n- specifications;\r\n- project conventions;\r\n- acceptance criteria;\r\n- coding standards;\r\n- API contracts;\r\n- security constraints;\r\n- design requirements;\r\n- applicable skills;\r\n- task definitions.\r\n\r\nBoth reviewers MUST receive materially equivalent project constraints.\r\n\r\nDo not provide one reviewer with privileged information unavailable to the other\r\nunless the difference is intrinsic to the target.\r\n\r\n\r\n# 7. Phase 1 — Freeze the Target\r\n\r\nBefore launching reviewers, establish a stable target identity.\r\n\r\nUse the strongest available identifier.\r\n\r\nPreferred order:\r\n\r\n1. immutable artifact digest;\r\n2. commit or revision identifier;\r\n3. tree hash;\r\n4. exact diff;\r\n5. exact file set and content digest;\r\n6. stable document revision;\r\n7. explicitly captured scope.\r\n\r\nRecord at minimum:\r\n\r\n    target:\r\n      type:\r\n      identity:\r\n      revision:\r\n      digest:\r\n      scope:\r\n\r\nIf no immutable identifier exists, record enough information to guarantee that\r\nboth reviewers inspect the same content.\r\n\r\nIf the target changes during the review, invalidate the round and restart from\r\nthe new frozen target.\r\n\r\n\r\n# 8. Phase 2 — Independent Review\r\n\r\nCreate two logically independent reviewers:\r\n\r\n    reviewer-a\r\n    reviewer-b\r\n\r\nParallel execution is preferred when supported, but it is not required.\r\n\r\nIf only sequential execution is possible:\r\n\r\n1. execute Reviewer A;\r\n2. preserve its result without exposing it to Reviewer B;\r\n3. execute Reviewer B from the original frozen target;\r\n4. compare results only after both reviews finish.\r\n\r\nReviewer B MUST NOT be asked to:\r\n\r\n- validate Reviewer A;\r\n- confirm Reviewer A;\r\n- critique Reviewer A;\r\n- refute Reviewer A;\r\n- rank Reviewer A's findings.\r\n\r\nThat would be sequential validation rather than independent review.\r\n\r\n\r\n# 9. Reviewer Diversity\r\n\r\nWhen the runtime supports model selection, prefer reviewer diversity.\r\n\r\nPreferred order:\r\n\r\n1. different model families;\r\n2. different models;\r\n3. different providers;\r\n4. different reasoning configurations;\r\n5. isolated executions of the same model.\r\n\r\nModel diversity improves independence but is not mandatory.\r\n\r\nDo not claim strong model independence when both reviewers share effectively the\r\nsame model and context.\r\n\r\nWhen available, record:\r\n\r\n    reviewer_a:\r\n      provider:\r\n      model:\r\n      configuration:\r\n\r\n    reviewer_b:\r\n      provider:\r\n      model:\r\n      configuration:\r\n\r\n    independence:\r\n      level: full | partial | degraded\r\n      reason:\r\n\r\n\r\n# 10. Reviewer Permissions\r\n\r\nReviewers MUST operate in read-only mode.\r\n\r\nThey MAY:\r\n\r\n- read files;\r\n- inspect diffs;\r\n- inspect history;\r\n- search code;\r\n- trace control flow;\r\n- inspect specifications;\r\n- inspect contracts;\r\n- execute non-mutating diagnostic commands;\r\n- run tests that do not modify the target;\r\n- gather runtime evidence;\r\n- analyze dependency relationships.\r\n\r\nThey MUST NOT:\r\n\r\n- edit files;\r\n- apply patches;\r\n- rewrite documents;\r\n- refactor code;\r\n- commit;\r\n- push;\r\n- merge;\r\n- create pull requests;\r\n- deploy;\r\n- publish;\r\n- modify persistent memory;\r\n- delegate corrective work;\r\n- change the review target.\r\n\r\n\r\n# 11. Review Criteria\r\n\r\nUnless the user specifies narrower criteria, reviewers SHOULD inspect:\r\n\r\n1. functional correctness;\r\n2. behavioral regressions;\r\n3. edge cases;\r\n4. error handling;\r\n5. state consistency;\r\n6. concurrency;\r\n7. race conditions;\r\n8. resource lifecycle;\r\n9. security boundaries;\r\n10. authorization and permissions;\r\n11. data integrity;\r\n12. API compatibility;\r\n13. contract compatibility;\r\n14. backwards compatibility;\r\n15. performance pathologies;\r\n16. failure recovery;\r\n17. implementation\u002Fspecification consistency;\r\n18. architecture violations;\r\n19. unsafe assumptions;\r\n20. repository-specific invariants.\r\n\r\nDo not manufacture findings merely to cover every category.\r\n\r\n\r\n# 12. Evidence-First Review\r\n\r\nEvery actionable finding MUST include concrete evidence.\r\n\r\nAcceptable evidence includes:\r\n\r\n- exact path and location;\r\n- failing test;\r\n- reproducible scenario;\r\n- deterministic execution path;\r\n- violated invariant;\r\n- contract contradiction;\r\n- invalid state transition;\r\n- runtime trace;\r\n- security boundary violation;\r\n- incorrect API behavior;\r\n- data corruption path;\r\n- concurrency schedule;\r\n- static analysis result.\r\n\r\nAvoid treating the following as defects without stronger evidence:\r\n\r\n- stylistic preference;\r\n- personal design preference;\r\n- vague suspicion;\r\n- hypothetical scenarios with no reachable execution path;\r\n- speculative performance concerns;\r\n- optional refactors;\r\n- alternative implementations;\r\n- purely aesthetic improvements.\r\n\r\n\r\n# 13. Severity Model\r\n\r\nUse only the following severities.\r\n\r\n## CRITICAL\r\n\r\nA defect that can plausibly cause:\r\n\r\n- security compromise;\r\n- privilege escalation;\r\n- unrecoverable data loss;\r\n- large-scale corruption;\r\n- catastrophic service failure;\r\n- severe violation of a trust boundary.\r\n\r\n## HIGH\r\n\r\nA significant defect causing:\r\n\r\n- reproducible functional failure;\r\n- major behavioral regression;\r\n- incorrect persistent state;\r\n- broken external contract;\r\n- serious concurrency defect;\r\n- significant production failure;\r\n- unsafe error handling.\r\n\r\n## MEDIUM\r\n\r\nA real defect with bounded impact.\r\n\r\nExamples:\r\n\r\n- incorrect edge-case behavior;\r\n- localized inconsistency;\r\n- incomplete validation;\r\n- recoverable failure;\r\n- bounded performance issue.\r\n\r\n## LOW\r\n\r\nA minor correctness or robustness defect with limited operational impact.\r\n\r\n## INFO\r\n\r\nA non-blocking observation.\r\n\r\nExamples:\r\n\r\n- readability;\r\n- style;\r\n- optional refactor;\r\n- documentation suggestion;\r\n- alternative design;\r\n- unverified concern.\r\n\r\n\r\n# 14. Finding Format\r\n\r\nEach reviewer MUST return structured findings.\r\n\r\nPreferred representation:\r\n\r\n    {\r\n      \"findings\": [\r\n        {\r\n          \"id\": \"A-001\",\r\n          \"location\": \"path\u002Ffile.ext:120-137\",\r\n          \"severity\": \"HIGH\",\r\n          \"category\": \"concurrency\",\r\n          \"claim\": \"Concurrent updates can overwrite a newer state.\",\r\n          \"evidence_class\": \"deterministic\",\r\n          \"evidence\": [\r\n            \"The state is read before entering the protected update boundary.\",\r\n            \"Two concurrent requests can observe the same previous value.\"\r\n          ],\r\n          \"confidence\": \"high\"\r\n        }\r\n      ],\r\n      \"inspected\": [\r\n        \"path\u002Ffile.ext\",\r\n        \"path\u002Ffile_test.ext\"\r\n      ]\r\n    }\r\n\r\nReviewer identifiers SHOULD use:\r\n\r\n    A-001\r\n    A-002\r\n\r\nand:\r\n\r\n    B-001\r\n    B-002\r\n\r\nThe exact serialization format MAY differ when the runtime requires another\r\nstructured format.\r\n\r\n\r\n# 15. Evidence Classes\r\n\r\nUse one of:\r\n\r\n- deterministic;\r\n- reproduced;\r\n- contract;\r\n- test-failure;\r\n- static-analysis;\r\n- runtime-observation;\r\n- probabilistic.\r\n\r\nPrefer:\r\n\r\n    deterministic\r\n    reproduced\r\n    contract\r\n    test-failure\r\n\r\nover weaker speculative evidence.\r\n\r\nProbabilistic findings require stronger corroboration before corrective action.\r\n\r\n\r\n# 16. Reviewer Prompt Contract\r\n\r\nWhen spawning or instructing a reviewer, preserve the following behavioral\r\ncontract:\r\n\r\n    You are an independent reviewer.\r\n\r\n    Review the frozen target from first principles.\r\n\r\n    Do not modify the target.\r\n\r\n    Do not ask for another reviewer's findings.\r\n\r\n    Do not assume another reviewer agrees with you.\r\n\r\n    Do not manufacture findings.\r\n\r\n    Every defect must describe concrete incorrect behavior and include evidence.\r\n\r\n    Return structured findings only.\r\n\r\n    If no meaningful defect exists, return an empty findings collection.\r\n\r\nRuntime-specific syntax MAY differ, but these semantics MUST remain intact.\r\n\r\n\r\n# 17. Phase 3 — Consensus\r\n\r\nOnly the orchestrator or consensus component may compare the reviewer outputs.\r\n\r\nIt MUST:\r\n\r\n1. validate reviewer result structure;\r\n2. reject malformed findings when necessary;\r\n3. normalize equivalent terminology;\r\n4. match findings by underlying defect;\r\n5. preserve disagreement;\r\n6. preserve unsupported single-reviewer observations;\r\n7. generate the consensus ledger.\r\n\r\nThe consensus process MUST NOT invent new defects.\r\n\r\n\r\n# 18. Finding Equivalence\r\n\r\nTwo findings SHOULD be considered equivalent when they describe substantially\r\nthe same:\r\n\r\n- failing behavior;\r\n- causal mechanism;\r\n- affected execution path;\r\n- affected invariant;\r\n- affected component.\r\n\r\nTextual similarity alone is insufficient.\r\n\r\nExample:\r\n\r\nReviewer A:\r\n\r\n    Concurrent writes can overwrite state.\r\n\r\nReviewer B:\r\n\r\n    Two requests can persist updates derived from the same stale state.\r\n\r\nThese findings may represent the same underlying defect even though their wording\r\ndiffers.\r\n\r\n\r\n# 19. Consensus Classes\r\n\r\nEach normalized finding MUST be classified as one of:\r\n\r\n## CONFIRMED\r\n\r\nBoth reviewers independently identified the same underlying defect.\r\n\r\n## SUSPECT\r\n\r\nOnly one reviewer identified the defect.\r\n\r\n## CONTRADICTION\r\n\r\nThe reviewers reached incompatible conclusions about the same behavior or\r\ninvariant.\r\n\r\n## INFO\r\n\r\nNon-blocking observation.\r\n\r\n\r\n# 20. Consensus Ledger\r\n\r\nThe orchestrator SHOULD produce a ledger equivalent to:\r\n\r\n    target:\r\n      identity:\r\n      revision:\r\n      digest:\r\n\r\n    reviewers:\r\n      reviewer_a:\r\n        model:\r\n      reviewer_b:\r\n        model:\r\n\r\n    consensus:\r\n\r\n      confirmed:\r\n        - id: C-001\r\n          severity: HIGH\r\n          sources:\r\n            - A-001\r\n            - B-003\r\n          claim:\r\n          evidence:\r\n          status: open\r\n\r\n      suspect:\r\n        - id: S-001\r\n          source: A-004\r\n          severity: MEDIUM\r\n          claim:\r\n\r\n      contradictions:\r\n        - id: X-001\r\n          subject:\r\n          reviewer_a:\r\n          reviewer_b:\r\n\r\n      info: []\r\n\r\n\r\n# 21. Correction Policy\r\n\r\nBy default, automatic or pre-authorized corrective work is permitted only for:\r\n\r\n    CONFIRMED + CRITICAL\r\n    CONFIRMED + HIGH\r\n\r\nThe following MUST NOT trigger automatic correction by default:\r\n\r\n    SUSPECT\r\n    CONTRADICTION\r\n    MEDIUM\r\n    LOW\r\n    INFO\r\n\r\nThe user or calling system MAY define a stricter or broader policy.\r\n\r\nContradictory severe findings SHOULD be escalated rather than guessed.\r\n\r\n\r\n# 22. Human Authorization\r\n\r\nIf the user requested review only, do not modify the target.\r\n\r\nIf the user explicitly requested:\r\n\r\n- review and fix;\r\n- review until approved;\r\n- fix confirmed defects;\r\n- validate and correct;\r\n\r\nthen corrective work may proceed according to the configured policy.\r\n\r\nReview authorization and write authorization are separate concepts.\r\n\r\n\r\n# 23. Phase 4 — Fix Actor\r\n\r\nCorrective work SHOULD be performed by an actor separate from the initial\r\nreviewers when the runtime supports delegation.\r\n\r\nThe Fix Actor receives only:\r\n\r\n- frozen target identity;\r\n- authorized confirmed findings;\r\n- evidence for those findings;\r\n- applicable project rules;\r\n- allowed correction scope.\r\n\r\nThe Fix Actor SHOULD NOT receive unrelated suspect findings unless explicitly\r\nauthorized.\r\n\r\n\r\n# 24. Minimal Correction Principle\r\n\r\nFor every authorized finding:\r\n\r\n1. identify the smallest sufficient correction;\r\n2. modify only necessary scope;\r\n3. preserve unrelated behavior;\r\n4. add or update focused verification when appropriate;\r\n5. execute relevant validation;\r\n6. record changed artifacts;\r\n7. record which finding the change addresses.\r\n\r\nDo not perform opportunistic cleanup.\r\n\r\n\r\n# 25. Fix Actor Restrictions\r\n\r\nThe Fix Actor MUST NOT:\r\n\r\n- fix SUSPECT findings without authorization;\r\n- resolve INFO observations opportunistically;\r\n- perform unrelated refactors;\r\n- redesign unrelated architecture;\r\n- expand public APIs unnecessarily;\r\n- alter unrelated files for cleanup;\r\n- commit;\r\n- push;\r\n- merge;\r\n- deploy;\r\n- release;\r\n\r\nunless separately authorized by the calling workflow.\r\n\r\n\r\n# 26. Fix Delta\r\n\r\nAfter corrective work, freeze the resulting delta.\r\n\r\nRecord:\r\n\r\n    fix_delta:\r\n      base_target:\r\n      fixed_target:\r\n      findings_addressed:\r\n      modified_paths:\r\n      diff_identity:\r\n      verification:\r\n\r\nThe fixed target becomes a new immutable review revision.\r\n\r\n\r\n# 27. Phase 5 — Re-Judgment\r\n\r\nAfter correction, two reviewers MUST independently verify the fix.\r\n\r\nRe-judgment is intentionally narrower than the initial review.\r\n\r\nInspect:\r\n\r\n1. whether the original confirmed defect was resolved;\r\n2. whether the relevant invariant now holds;\r\n3. whether the correction directly introduced a regression.\r\n\r\nDo not silently turn re-judgment into an unrestricted new code review.\r\n\r\n\r\n# 28. Re-Judgment Finding States\r\n\r\nFor every confirmed finding, reviewers MUST classify the result as:\r\n\r\n    RESOLVED\r\n    UNRESOLVED\r\n    REGRESSED\r\n\r\nA new finding may be introduced during re-judgment only when it is causally\r\nrelated to the correction.\r\n\r\nUnrelated observations belong to another review cycle.\r\n\r\n\r\n# 29. Re-Judgment Prompt Contract\r\n\r\nUse semantics equivalent to:\r\n\r\n    You are independently verifying a correction.\r\n\r\n    Inspect the original confirmed defect and the fix delta.\r\n\r\n    Determine whether the defect is RESOLVED, UNRESOLVED, or REGRESSED.\r\n\r\n    Check for regressions caused directly by the correction.\r\n\r\n    Do not perform an unrelated full review.\r\n\r\n    Do not modify the target.\r\n\r\n    Return structured evidence.\r\n\r\n\r\n# 30. Round Budget\r\n\r\nThe protocol MUST be bounded.\r\n\r\nDefault maximum:\r\n\r\n    initial_review: 1\r\n    fix_rounds: 2\r\n    rejudgment_rounds: 2\r\n\r\nCanonical maximum flow:\r\n\r\n    INITIAL REVIEW\r\n         │\r\n         ▼\r\n      FIX #1\r\n         │\r\n         ▼\r\n    RE-JUDGMENT\r\n         │\r\n         ▼\r\n      FIX #2\r\n         │\r\n         ▼\r\n    RE-JUDGMENT\r\n         │\r\n         ▼\r\n      ESCALATE\r\n\r\nNever silently extend the configured budget.\r\n\r\n\r\n# 31. Failure Handling\r\n\r\n## Reviewer Unavailable\r\n\r\nIf one required reviewer cannot execute:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\nDo not substitute one review for two.\r\n\r\n## Target Unavailable\r\n\r\nIf a reviewer cannot inspect the required target:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\n## Target Changed\r\n\r\nInvalidate the current round and restart against the new frozen target.\r\n\r\n## Duplicate Reviewer Execution\r\n\r\nIf two outputs originate from the same effective execution or one output was\r\ncopied from another, treat them as one review.\r\n\r\n## Malformed Reviewer Result\r\n\r\nAttempt only bounded normalization.\r\n\r\nIf the result cannot be interpreted reliably:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\n## Severe Contradiction\r\n\r\nIf reviewers disagree materially on a CRITICAL or HIGH behavior:\r\n\r\n    VERDICT: ESCALATED\r\n\r\nunless an explicitly authorized arbitration mechanism exists.\r\n\r\n\r\n# 32. Independence Levels\r\n\r\nReport the effective independence when possible.\r\n\r\n## FULL\r\n\r\nExamples:\r\n\r\n- separate agents;\r\n- isolated contexts;\r\n- different models;\r\n- equivalent access to the same frozen target.\r\n\r\n## PARTIAL\r\n\r\nExamples:\r\n\r\n- isolated agents using the same model;\r\n- sequential independent execution with clean context boundaries.\r\n\r\n## DEGRADED\r\n\r\nExamples:\r\n\r\n- one runtime performing two simulated passes;\r\n- context isolation cannot be guaranteed;\r\n- same agent must emulate both reviewer roles.\r\n\r\nWhen independence is degraded, state it explicitly.\r\n\r\nNever present degraded review as fully independent multi-agent review.\r\n\r\n\r\n# 33. Runtime Adaptation\r\n\r\nThis skill MUST remain runtime-agnostic.\r\n\r\nA runtime may implement reviewer isolation using:\r\n\r\n- subagents;\r\n- worker agents;\r\n- child sessions;\r\n- isolated model invocations;\r\n- agent pools;\r\n- remote agents;\r\n- separate CLI processes;\r\n- tool-driven executions;\r\n- workflow nodes.\r\n\r\nThe implementation mechanism is irrelevant as long as the protocol invariants\r\nhold.\r\n\r\n\r\n# 34. No-Subagent Fallback\r\n\r\nIf the runtime lacks subagents but can perform isolated passes:\r\n\r\n1. preserve the frozen target;\r\n2. execute Review Pass A;\r\n3. remove its findings from active context;\r\n4. execute Review Pass B independently;\r\n5. compare only after both passes complete.\r\n\r\nReport:\r\n\r\n    independence: degraded\r\n\r\nor:\r\n\r\n    independence: partial\r\n\r\ndepending on the actual isolation guarantees.\r\n\r\nIf genuine isolation cannot be approximated responsibly, prefer:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\nover pretending the protocol was fully executed.\r\n\r\n\r\n# 35. Final Verification\r\n\r\nFinal verification is separate from initial defect discovery.\r\n\r\nBefore APPROVED, confirm:\r\n\r\n- both required reviewers executed;\r\n- both inspected the same target revision;\r\n- confirmed severe findings are resolved;\r\n- no unresolved severe contradiction remains;\r\n- required focused tests passed;\r\n- broader relevant validation passed when feasible;\r\n- the correction remained within authorized scope;\r\n- no correction-caused severe regression remains;\r\n- the round budget was respected.\r\n\r\n\r\n# 36. Terminal States\r\n\r\nOnly the following terminal states are valid:\r\n\r\n    APPROVED\r\n    ESCALATED\r\n    INCOMPLETE\r\n\r\n## APPROVED\r\n\r\nUse when:\r\n\r\n- the required independent review completed;\r\n- no unresolved confirmed CRITICAL or HIGH finding remains;\r\n- no unresolved severe contradiction remains;\r\n- required correction verification completed.\r\n\r\n## ESCALATED\r\n\r\nUse when:\r\n\r\n- a severe defect remains after the allowed correction rounds;\r\n- reviewers materially disagree on a severe issue;\r\n- correction requires judgment beyond the allowed scope;\r\n- human intervention is required.\r\n\r\n## INCOMPLETE\r\n\r\nUse when:\r\n\r\n- a required reviewer could not execute;\r\n- target identity could not be preserved;\r\n- reviewer evidence is unusable;\r\n- protocol invariants could not be satisfied.\r\n\r\n\r\n# 37. Final Output\r\n\r\nPreferred result:\r\n\r\n    ADVERSARIAL CONSENSUS REVIEW\r\n\r\n    Target:\r\n    Revision:\r\n    Independence:\r\n    Review rounds:\r\n    Fix rounds:\r\n\r\n    Confirmed:\r\n    Suspect:\r\n    Contradictions:\r\n    Info:\r\n\r\n    Corrections:\r\n    Re-judgment:\r\n    Verification:\r\n\r\n    VERDICT: APPROVED\r\n\r\nor:\r\n\r\n    VERDICT: ESCALATED\r\n\r\nor:\r\n\r\n    VERDICT: INCOMPLETE\r\n\r\nReturn exactly one terminal verdict.\r\n\r\n\r\n# 38. Memory and Persistence\r\n\r\nThis skill does not require a memory system.\r\n\r\nIf the runtime provides persistent memory, it MAY preserve reusable review\r\nknowledge.\r\n\r\nAppropriate knowledge includes:\r\n\r\n- confirmed defect pattern;\r\n- affected component;\r\n- root cause summary;\r\n- resolution summary;\r\n- prevention rule;\r\n- validation performed;\r\n- final verdict.\r\n\r\nDo NOT persist:\r\n\r\n- private chain-of-thought;\r\n- hidden reasoning;\r\n- speculative reviewer deliberation;\r\n- duplicated raw transcripts;\r\n- irrelevant temporary observations.\r\n\r\nPrefer distilled knowledge over conversation logs.\r\n\r\n\r\n# 39. Reusable Review Learning\r\n\r\nA resolved confirmed finding MAY be transformed conceptually into:\r\n\r\n    review_learning:\r\n      category:\r\n      component:\r\n      problem:\r\n      root_cause:\r\n      resolution:\r\n      prevention:\r\n      verification:\r\n      confidence:\r\n\r\nPromotion SHOULD generally require:\r\n\r\n    CONFIRMED\r\n    AND\r\n    RESOLVED\r\n    AND\r\n    REUSABLE\r\n\r\nMemory behavior is optional and MUST NOT affect the correctness of the review\r\nprotocol.\r\n\r\n\r\n# 40. Security\r\n\r\nReviewers and corrective actors MUST obey the security boundaries of the calling\r\nenvironment.\r\n\r\nDo not request elevated privileges merely to complete the protocol.\r\n\r\nNever expose or persist:\r\n\r\n- credentials;\r\n- authentication tokens;\r\n- private keys;\r\n- secrets;\r\n- unnecessary sensitive information;\r\n- private chain-of-thought.\r\n\r\nIf security-sensitive information is encountered, reference only the minimum\r\nevidence required to describe the defect safely.\r\n\r\n\r\n# 41. Delivery Boundary\r\n\r\nAn APPROVED verdict means only:\r\n\r\n    the reviewed target satisfied this review protocol.\r\n\r\nIt does NOT mean:\r\n\r\n    commit authorized\r\n    push authorized\r\n    PR authorized\r\n    merge authorized\r\n    deployment authorized\r\n    production release authorized\r\n    publication authorized\r\n\r\nThose actions require separate instructions or workflow policy.\r\n\r\n\r\n# 42. Recommended Orchestration\r\n\r\nWhen full agent capabilities exist, prefer:\r\n\r\n    ORCHESTRATOR\r\n        │\r\n        ├── REVIEWER A\r\n        │      read-only\r\n        │\r\n        ├── REVIEWER B\r\n        │      read-only\r\n        │\r\n        └── FIX ACTOR\r\n               write only when authorized\r\n\r\nThe orchestrator owns:\r\n\r\n- target freezing;\r\n- reviewer isolation;\r\n- result collection;\r\n- consensus;\r\n- correction authorization;\r\n- round accounting;\r\n- terminal verdict.\r\n\r\nReviewers own:\r\n\r\n- independent defect discovery;\r\n- evidence production.\r\n\r\nThe Fix Actor owns:\r\n\r\n- bounded correction.\r\n\r\nNo single role should silently assume all three responsibilities when role\r\nseparation is available.\r\n\r\n## Follow-up Review (Cumulative)\r\n\r\nWhen a previous review of the same work already reached a terminal state and\r\nthe target has changed since (for example, after corrections), start a\r\nfollow-up review linked to it instead of reviewing everything again.\r\n\r\nA follow-up review:\r\n\r\n- inherits what the previous review settled: CONFIRMED findings resolved in\r\n  its last round, and SUSPECT and INFO findings already classified;\r\n- never inherits an unresolved CONFIRMED finding or a CONTRADICTION: those stay\r\n  open and are reviewed again;\r\n- limits the reviewers to the delta: the files that changed between the\r\n  previous target and the new one;\r\n- does not re-adjudicate an inherited finding whose files did not change;\r\n- reopens an inherited finding, linked to it, when one of its files changed.\r\n\r\nThe orchestrator:\r\n\r\n1. Links the new review to the previous terminal review.\r\n2. Gives each reviewer the delta and the inherited list, without the other\r\n   reviewer's results.\r\n3. Builds consensus only for findings that are not settled.\r\n\r\nThe terminal guarantees do not change: a missing or failed reviewer still\r\nyields INCOMPLETE, and a confirmed CRITICAL or HIGH finding left unresolved\r\nstill prevents APPROVED.\r\n\r\nIf the runtime keeps a review ledger that supports linked reviews, use it\r\nrather than pasting the lists by hand. A typical contract: the operation that\r\nstarts a review accepts the previous review identifier (`since_review_id`) and\r\nreturns the `delta`, the `inherited` findings with their `consensus_id`, and\r\n`instructions` for the reviewers. A reviewer who reports an inherited finding\r\nagain cites it with `settled_ref` (its `consensus_id`); the ledger, not the\r\nreviewer, decides whether it stays settled.\r\n\r\n\r\n# 43. Recommended Invocation Examples\r\n\r\nCode:\r\n\r\n    Perform an adversarial consensus review of the current diff.\r\n\r\nSpecification:\r\n\r\n    Use adversarial-consensus-review on this specification before implementation.\r\n\r\nArchitecture:\r\n\r\n    Independently review this architecture with two reviewers and report only\r\n    corroborated high-confidence defects.\r\n\r\nImplementation plus correction:\r\n\r\n    Implement the requested change, then run adversarial-consensus-review.\r\n    Correct confirmed HIGH or CRITICAL defects and re-verify them before\r\n    completion.\r\n\r\nReview only:\r\n\r\n    Review the current implementation using adversarial-consensus-review.\r\n    Do not modify anything.\r\n\r\nPre-delivery:\r\n\r\n    Run adversarial-consensus-review before considering this work ready for\r\n    delivery. Do not commit or push.\r\n\r\n\r\n# 44. Reviewer Template\r\n\r\nUse an equivalent template when the runtime requires explicit reviewer\r\ninstructions:\r\n\r\n    ROLE\r\n\r\n    You are independent Reviewer {A|B}.\r\n\r\n    TARGET\r\n\r\n    {frozen target identity}\r\n\r\n    SCOPE\r\n\r\n    {exact review scope}\r\n\r\n    PROJECT CONTEXT\r\n\r\n    {applicable rules and contracts}\r\n\r\n    FOLLOW-UP (only when this review is linked to a previous one)\r\n\r\n    Delta (review only these files): {delta}\r\n    Inherited findings (already settled; do not report them again):\r\n    {inherited: consensus_id, claim, files}\r\n    If an inherited finding reappears, report it with\r\n    \"settled_ref\": {consensus_id}.\r\n\r\n    CONTRACT\r\n\r\n    - Review independently.\r\n    - Do not modify the target.\r\n    - Do not request another reviewer's findings.\r\n    - Do not infer another reviewer's conclusions.\r\n    - Do not manufacture defects.\r\n    - Every actionable finding requires concrete evidence.\r\n    - Return structured findings.\r\n    - An empty findings set is valid.\r\n\r\n    OUTPUT\r\n\r\n    {\r\n      \"findings\": [\r\n        {\r\n          \"id\": \"{A|B}-001\",\r\n          \"location\": \"\",\r\n          \"severity\": \"CRITICAL|HIGH|MEDIUM|LOW|INFO\",\r\n          \"category\": \"\",\r\n          \"claim\": \"\",\r\n          \"evidence_class\": \"\",\r\n          \"evidence\": [],\r\n          \"confidence\": \"high|medium|low\",\r\n          \"settled_ref\": 0\r\n        }\r\n      ],\r\n      \"inspected\": []\r\n    }\r\n\r\n\r\n# 45. Fix Actor Template\r\n\r\nUse equivalent semantics:\r\n\r\n    ROLE\r\n\r\n    You are the bounded correction actor.\r\n\r\n    TARGET\r\n\r\n    {target identity}\r\n\r\n    AUTHORIZED FINDINGS\r\n\r\n    {confirmed findings authorized for correction}\r\n\r\n    CONTRACT\r\n\r\n    - Correct only authorized confirmed findings.\r\n    - Use the smallest sufficient change.\r\n    - Preserve unrelated behavior.\r\n    - Do not perform opportunistic cleanup.\r\n    - Add focused verification when appropriate.\r\n    - Record modified artifacts and validation.\r\n    - Do not commit, push, merge, deploy, or release unless separately authorized.\r\n\r\n    OUTPUT\r\n\r\n    {\r\n      \"work_units\": [\r\n        {\r\n          \"finding_id\": \"C-001\",\r\n          \"modified_paths\": [],\r\n          \"change_summary\": \"\",\r\n          \"verification\": []\r\n        }\r\n      ]\r\n    }\r\n\r\n\r\n# 46. Re-Judgment Template\r\n\r\nUse equivalent semantics:\r\n\r\n    ROLE\r\n\r\n    You are independent Reviewer {A|B} performing scoped re-verification.\r\n\r\n    ORIGINAL FINDING\r\n\r\n    {confirmed finding}\r\n\r\n    FIX DELTA\r\n\r\n    {exact corrective delta}\r\n\r\n    CONTRACT\r\n\r\n    Determine whether the original defect is:\r\n\r\n    - RESOLVED\r\n    - UNRESOLVED\r\n    - REGRESSED\r\n\r\n    Check only the original defect, relevant invariants, and regressions directly\r\n    introduced by the fix.\r\n\r\n    Do not perform an unrelated full review.\r\n\r\n    Do not modify the target.\r\n\r\n    OUTPUT\r\n\r\n    {\r\n      \"finding_id\": \"C-001\",\r\n      \"status\": \"RESOLVED|UNRESOLVED|REGRESSED\",\r\n      \"evidence\": []\r\n    }\r\n\r\n\r\n# 47. Design Principle\r\n\r\nThe fundamental rule of this skill is:\r\n\r\n> Independent evidence precedes consensus, consensus precedes correction, and\r\n> correction precedes re-verification.\r\n\r\nA reviewer is not valuable because it produces more findings.\r\n\r\nA reviewer is valuable when it identifies a concrete defect that can be\r\nexplained, evidenced, independently corroborated, corrected with bounded scope,\r\nand verified afterward.\r\n\r\nWhen the runtime offers stronger isolation, multiple models, subagents, memory,\r\nor orchestration capabilities, use them to strengthen the protocol.\r\n\r\nNever make the protocol dependent on them.\n",{"name":5,"license":15,"metadata":24,"description":29},{"mode":25,"version":26,"category":27,"portability":28},"adversarial-consensus","1.0.0","review","vendor-neutral","Perform an evidence-driven adversarial review using two independent reviewers, consensus-based defect confirmation, bounded correction rounds, and independent re-verification. Use when high-confidence validation is required for code, specifications, plans, architecture, configurations, migrations, contracts, or other concrete technical artifacts. Also invoked as ACR (Adversarial Consensus Review), \"revisión adversarial\" or \"revisión por consenso\".\n","main","1676882d080415336becc7cb330f4884fae38567","skills\u002Fadversarial-consensus-review",0,"https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory","https:\u002F\u002Fgithub.com\u002FSayoner-000","2026-11-11 18:07:02",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add Sayoner-000\u002Fgomemory --skill adversarial-consensus-review",{"tool":43,"command":44},"bunx","bunx skills add Sayoner-000\u002Fgomemory --skill adversarial-consensus-review",{"tool":46,"command":47},"pnpm","pnpm dlx skills add Sayoner-000\u002Fgomemory --skill adversarial-consensus-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-consensus-review\u002FSKILL.md",true,[51],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"README.md","REFERENCE","参考文档",3283,"https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-consensus-review\u002FREADME.md",[58,65,72,79,86,93],{"skillNo":59,"name":60,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":61,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M782GNGTC0GPK7ESC00Y7KPP","contracts","MIT","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fspecs\u002F039-socratica-prompt-refinement\u002Fcontracts\u002Fskill.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":61,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M782GHGW43XE514JZ4B90MMF","speckit-gomemory-context-update","Incorporar el resumen de historial de gomemory al contexto de la especificación","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fspecs\u002F012-gomemory-context-distribution\u002Fcontracts\u002Fclaude-artifact\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":61,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M782GG2XKQ1PFF46WRTVD13P","verify-loop","Aplica este flujo para verificar cambios antes de confirmar.","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fverify-loop\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":61,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M782GCRJ1ZW1Q628DGWYNP4V","strategic-compact","Aplica este flujo para resumir y compactar tras un hito.","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic-compact\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":61,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M782G7RR1GRGDJ1WFGH7MWJN","socratica","Refina un prompt en bruto hasta convertirlo en uno fiel y ejecutable (\u002Fsocratica) o examina los supuestos, la evidencia y las alternativas de una propuesta (\u002Fsocratic-q), con un máximo de tres preguntas y aprobación explícita antes de ejecutar nada. Úsala cuando la persona pida mejorar, aclarar o cuestionar un prompt o una propuesta.","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fsocratica\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":61,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M782G61RSQW9XNQ6DKEEDFGG","search-first","Aplica este flujo para buscar antes de construir o añadir dependencias.","https:\u002F\u002Fgithub.com\u002FSayoner-000\u002Fgomemory\u002Fblob\u002Fmain\u002Fskills\u002Fsearch-first\u002FSKILL.md",[],[]]