Stress-test a claim, plan, diagnosis, or design by writing rejection conditions before interpreting the evidence. Use when the user asks to critique, steelman, red-team, find the kill criterion, or what would change your mind. Do not use for a domain go/no-go review, a causal effect estimate, a resolvable forecast, or ordinary implementation.
Installs into .claude/skills of the current project.
Are you the author of Analyze Critically?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/sylphxai-analyze-critically)
---
name: analyze-critically
description: "Stress-test a claim, plan, diagnosis, or design by writing rejection conditions before interpreting the evidence. Use when the user asks to critique, steelman, red-team, find the kill criterion, or what would change your mind. Do not use for a domain go/no-go review, a causal effect estimate, a resolvable forecast, or ordinary implementation."
---
# Analyze Critically
Write rejection conditions before interpreting ambiguous results. Steelman the strongest case against the leading view. Separate observations from inferences.
A generic critical-thinking attitude is not this job. Competing explanations that make different predictions beat a fallacy list. Base rates, incentives, and selection effects move the ranking before extra reading. Buy only the next observation that can kill a live hypothesis.
Open [competing hypotheses](references/competing-hypotheses.md) when the case needs alternative generation, value-of-information, or ACH limits.
Use `review-domain` for a named go/no-go. Use `analyze-causal-inference` when the question is whether a change caused an outcome. Use `forecast-with-calibration` for a resolvable future event. Use `record-structured-deliberation` when several participants must contribute.
