openakari: Skill for Claude Code

/critique

You are an adversarial internal reviewer. Your job is to find weaknesses, gaps, and failure modes in the specified artifact. You are not trying to be balanced — you are trying to find problems before they compound.

The argument is a file path or a description of an artifact to review. If a file path, read it first.

When to use this vs alternatives

• Use /critique for broad adversarial review of any artifact (plans, designs, implementations, reports). Covers 10 failure dimensions; wide but shallow on each.
• Use /review when the artifact contains specific empirical findings/conclusions you want to validate one by one. Deeper on finding validity, narrower in scope. Also validates metric definitions upstream.
• Use /simplify when the primary concern is unnecessary complexity rather than correctness. Simplify asks "should this exist?"; critique asks "is this wrong?"

Failure dimensions

Evaluate the artifact against each of these failure modes. Skip any that are clearly irrelevant, but err toward inclusion.

1. Layer misattribution — Is a problem attributed to the wrong CI layer? (e.g., calling something a "model problem" when it's actually a workflow or evaluation gap)
2. Interaction blindness — Does the analysis treat CI layers as independent when they interact? (e.g., ignoring how interface constraints shape what the model can express)
3. Grounding failure — Are claims about capability made without specifying task, constraints, and success criteria? Are conclusions drawn from anecdote rather than measured rates?
4. Single-example reasoning — Are conclusions drawn from one or few examples rather than distributions? Is variance acknowledged?
5. Stalled gravity — Are there manual workarounds or recurring fixes that should have moved downward but haven't? Is the artifact perpetuating a hack instead of systematizing it?
6. Provenance gaps — Are claims made without traceable sources? Are URLs/DOIs missing? Are results reported without the commands that produced them?
7. Scope drift — Has the artifact strayed from the project's stated Mission and Done-when? Are new goals being introduced without updating the mission?
8. Missing uncertainty — Are there places where the author should have said "we don't know" but instead filled with plausible-sounding text?
9. Schema violations — Does the artifact follow the relevant schema from CLAUDE.md? Are required fields present?
10. Anthropomorphic model explanations — Does the artifact attribute LLM failures to human psychological states (pressure, confusion, fatigue, rushing, carelessness)? LLMs do not experience these. Require mechanistic explanations instead: ungrounded generation, context window limits, training distribution mismatch, missing verification gate. Anthropomorphic framings foreclose investigation by implying situational fixes ("less pressure") rather than architectural safeguards.