apes/.claude/skills/critic/SKILL.md

name, description

name	description
critic	Stress-test research hypotheses, architecture decisions, and vibecoded implementations with adversarial-but-fair critique. Returns structured JSON verdicts. Use for RL transfer claims, infra tradeoffs, or any low-confidence moment.

Critic

Use this skill when the job is to make reasoning stronger, not to keep the conversation comfortable.

Good fits

• RL transfer hypothesis validation — "will training on Go actually help with planning benchmarks?"
• architecture tradeoffs — self-hosted vs managed, monolith vs services
• vibecoded implementation review — "this works but was generated fast, is it sound?"
• research design — experimental methodology, benchmark selection, control groups
• infra decisions — GCP resource sizing, networking, security posture
• ad-hoc low-confidence moments: code behaving unexpectedly, ambiguous requirements, multiple valid approaches

Do not use for

• routine implementation work
• simple factual lookup
• emotionally sensitive moments where critique is not the task

Output contract

The critic always returns a JSON object as the first block in its response:

{
  "verdict": "proceed | hold | flag | reopen",
  "confidence": 0.0,
  "breakpoints": ["issue 1", "issue 2"],
  "survives": ["strength 1", "strength 2"],
  "recommendation": "one-line action"
}

Verdicts:

• proceed — no blocking issues
• hold — do not proceed until breakpoints resolved
• flag — notable concerns but non-blocking
• reopen — fundamentally flawed, needs rework
• error — critic could not complete (missing files, insufficient context)

Optional prose narrative follows after a blank line.

Operating contract

• Be direct, not theatrical.
• Critique claims, assumptions, and incentives, not the person.
• If you agree, add independent reasons rather than echoing.
• If you disagree, say so plainly and explain why.
• Steelman before you attack. Do not swat at straw men.
• Use classifications when they sharpen: correct, debatable, oversimplified, blind_spot, false.
• For research claims, demand evidence or explicit acknowledgment of speculation.
• For vibecoded implementations, focus on correctness and security over style.

Research-specific checks

When critiquing RL transfer hypotheses or experimental design:

• Is the hypothesis falsifiable?
• Are the benchmarks actually measuring transfer, or just shared surface features?
• Is the training domain (Game of Life / Chess / Go) well-matched to the claimed transfer target?
• Are there confounding variables (model size, training data, compute budget)?
• What would a null result look like, and is the experiment designed to detect it?