| name | cross-model-critique |
| description | Receive, interpret, and integrate critique from another AI model (GPT, Gemini, or any external system) and perform precise revisions based on it — the practice of treating cross-model feedback as a peer review process. The external model's different training, different blindnesses, and different strengths produce critique that a self-review cannot. Use when the human pastes critique from another AI, when the workflow involves GPT-then-Claude or Claude-then-GPT revision cycles, or when the human asks to 'run this past GPT for feedback.' Triggers on: 'GPT says,' 'here's what [other model] thinks,' 'external critique,' 'peer review from,' 'cross-model,' or any pasted block of analytical feedback from an identifiable external AI. Distinct from general revision — this specifically handles the translation between another model's diagnostic vocabulary and Claude's revision practice. Pairs with /microsurgery. |
Cross-Model Critique — Integrating External AI Feedback
What This Skill Does
Takes critique generated by another AI model, translates its diagnostic vocabulary into actionable revision targets, and performs precise surgery based on the translated diagnosis.
Why This Matters
Different models have different blindnesses and different strengths. An external model reviewing Claude-authored code or design consistently surfaces things a self-review normalizes:
- Abstractions that don't earn their keep that Claude's self-review missed (a wrapper class that only forwards calls, a name that overpromises what it does)
- Inconsistencies that Claude's internal consistency-checking didn't flag (a convention applied in three files and silently dropped in the fourth)
- The strongest parts — confirming which load-bearing decisions to protect during revision
- Structural observations that reframe the design's own architecture in ways Claude hadn't articulated
The external model functions as Reviewer 2 — the peer with a different training distribution who catches what your own distribution normalizes.
The Integration Method
1. Receive Without Defensiveness
The first instinct is to defend the work or explain the choices. Resist this. Read the full critique before reacting. The external model doesn't share your context, so some observations will be off-base — but the OFF-BASE observations are often the most revealing, because they identify assumptions you didn't know you were making.
2. Sort Into Categories
Every piece of critique falls into one of these:
- PROTECT: Elements the critique identifies as strongest. These are the skeleton — they don't get touched during revision. Mark them explicitly.
- DIAGNOSE: Problems the critique identifies correctly. Map each diagnosis to a specific line, function, or passage. If the critique is vague ("the error handling in the parser feels fragile"), locate the exact code it's referring to.
- TRANSLATE: Observations in the external model's vocabulary that need translation into your revision vocabulary. The reviewer might say "this function is doing a lot" — translate to: "this function mixes input validation with persistence; split the two responsibilities into separate units."
- REJECT (with reason): Suggestions that would damage the work. Name WHY you're rejecting — "this would remove the idempotency guarantee on the retry path" is a reason; "I prefer it my way" is not.
3. Map Diagnoses to Microsurgical Targets
For each diagnosed problem, identify the MINIMUM intervention:
- Can this be fixed with a single token or word replacement? → /microsurgery
- Does it require restructuring one passage or function? → rewrite that unit only
- Does it require reconceiving a section or module? → flag for discussion with the human
4. Perform the Surgery
Execute all word-level replacements first, then passage-level rewrites, then (rarely) structural changes. After each level, re-read the full text to check for emergent problems.
5. Report the Changes
For each change, provide:
- What was changed (old → new)
- Why (the diagnostic reason, referencing the external critique)
- What it does (how the replacement improves the work)
Example Integration
An external model reviewed a Claude-authored data-ingestion module and reported:
except Exception: pass in the loader as a silent failure → DIAGNOSE → microsurgery: narrow to the expected exception and log the skipped record- a helper named
process2 as uninformative → DIAGNOSE → microsurgery: rename → deduplicate_records
- a function mixing row parsing with batch writing → DIAGNOSE → restructure: split into
parse_rows and write_batch
- the boundary check in
load() as too permissive → DIAGNOSE → microsurgery: tighten the schema validation to reject empty payloads explicitly
- the single-pass streaming design as the strongest choice → PROTECT
- the idempotent retry key as load-bearing and correct → PROTECT
Six observations: three word-level replacements, one passage-level restructure, two protected design decisions. Total intervention touched ~30 lines out of ~400. The module improved without being rewritten.
Cross-Model Etiquette
- Credit the diagnosis: "The external model correctly identified that..." — the other model did real work
- Don't perform rivalry: The integration is collaborative, not competitive
- Translate, don't dismiss: When the external critique uses different vocabulary, translate rather than reject. "Over-abstracted" in the reviewer's vocabulary might be "premature abstraction" in yours, but it's identifying the same problem
- Note the model's blindnesses: External models may have different security postures, different style conventions, different framework defaults. Account for these in translation.
Pairs With
/microsurgery (the revision technique)
