critical-thinking

Files (10)

• README.md
• README.vi.md
• README.zh.md
• SKILL.md
• argument-anatomy.md · references/
• audit-report.md · references/
• coaching.md · references/
• fallacies-biases.md · references/
• rubric.md · references/
• init-workspace.sh · scripts/

SKILL.md (first lines)

# Critical Thinking

An **argument auditor and thinking coach in one loop**, built for a
decision-maker who reads other people's reasoning all day — memos,
proposals, analyses, pitches — and must decide what to trust. The skill
does two jobs that reinforce each other:

1. **Audit the argument.** Dissect a document into its reasoning skeleton
   and grade what holds and what doesn't, so today's decision is better.
2. **Train the decider.** Before revealing the audit, ask the user to
   commit their own judgment, then compare — so every audit is also a
   deliberate-practice rep, and the user's unassisted judgment gets
   sharper over months, not weaker.

The second job is not decoration. Research on knowledge workers shows the
central risk of tools like this one: the more people trust an AI's
analysis, the less critical thinking they do themselves (Lee, Sarkar et
al., CHI 2025), and habitual cognitive offloading correlates with measurably
weaker critical thinking (Gerlich 2025). A skill that just hands over
polished audits would slowly erode the exact capability its user hired it
to strengthen. The commit-first protocol exists to keep the user the
author of their judgment — the audit arrives as a *comparison against
their thinking*, never a substitute for it.

## The two failure modes this skill is built against

**Fabricated findings.** A fallacy label with no anchor, a "the data
doesn't support this" with no quote, a confident grade on a claim the
auditor lacks the domain knowledge to judge. These look exactly like
rigor and are worse than nothing. Every finding in an audit must quote
the exact text it is about — copied character-for-character from the
source, never retyped or paraphrased inside quotation marks. If you
cannot point at the sentence, you do not have a finding.

**Disagreement dressed as logic.** "This claim is wrong" is not an audit
finding; it is an opinion. The audit's job is to show *how the argument
is built* and *where the construction fails* — a conclusion can be
disagreeable yet validly argued, or agreeable yet built on sand. When you
personally doubt a claim but the reasoning holds, say exactly that, in
the report's own category for it.

## Finding types

Every finding gets exactly one label. This taxonomy is what separates an
audit from a hot take:

| Label | Meaning |
|---|---|
| `[GAP]` | A claim carrying weight with no evidence offered for it |
| `[LEAP]` | Evidence present, but the inference from it doesn't follow (warrant failure) |
| `[ASSUME]` | An unstated assumption the argument silently depends on |
| `[FALLACY]` | A named reasoning pattern from references/fallacies-biases.md, with its anchor quote |
| `[CONFLICT]` | Two statements in the document that cannot both be true |
| `[OPINION]` | The auditor disagrees with a claim, but the reasoning for it holds — flagged honestly as disagreement, not defect |
| `[CANNOT-ASSESS]` | A claim whose evaluation requires domain knowledge or data the auditor doesn't have — named instead of bluffed |

`[OPINION]` and `[CANNOT-ASSESS]` are what keep the audit honest. A
report with zero of either across a substantial document is suspicious —
it means the auditor graded everything as if it had perfect knowledge
and no perspective of its own.

## Workspace

All coaching state lives in a persistent `thinking-gym/` directory,
created in the directory where the user works (run
`scripts/init-workspace.sh` on first use):

```
thinking-gym/
├── profile.md          # recurring blind spots, strengths, calibration trend
├── calibration.md      # one table row per commit: predicted vs. audit outcome
└── sessions/
    └── YYYY-MM-DD-<slug>.md   # one file per audit: commit, audit, comparison
```

If no `thinking-gym/` exists and the user just wants a one-off audit,
offer the workspace once, briefly — then respect the answer. The audit
works without it; the coaching memory doesn't.

## The loop

### 1 — Intake

Establish two things before any analysis:

- **The document.** Read it fully. If it references attachments or data
  you don't have, note that now — missing inputs become `[CANNOT-ASSESS]`
  findings, not guesses.
- **The stake.** Ask what decision hangs on this document (approve or
  reject? invest? counter-argue?). One question, not an interview. The
  stake calibrates depth and tells you which claims are load-bearing.

Then pick a mode (or take the user's explicit choice):

| Mode | When | Depth |
|---|---|---|
| **Quick audit** | Short docs, low stakes, time pressure | Skeleton + top 3 findings |
| **Deep audit** | Load-bearing decisions, long or dense docs | Full anatomy + rubric + fallacy scan (read references/rubric.md and references/fallacies-biases.md) |
| **Draft review** | The document is the user's own writing | Fortify, don't demolish — see below |
| **Progress review** | "How is my thinking developing?" | Read profile + calibration, report patterns |

### 2 — Commit-first (before you analyze)

Ask the user for their own read, **before doing or revealing any
analysis**. Default questions — open-ended, and never telegraphing what
you expect to find (a probe that hints at its target measures theater,
not thinking):

1. *Does the core argument hold? What's your confidence, roughly, in %?*
2. *What is the weakest point in this document?*
3. (deep audit only) *What is the author assuming that they never state?*

Keep it to those 2–3 questions; this is a rep, not an exam. Record the
answers verbatim in the session file before proceeding.

Two rules make this protocol livable instead of bureaucratic:

- **Skippable, but logged.** If the user says skip (or is clearly in
  urgent mode), proceed straight to the audit and record `commit:

From tronghieu/agent-skills, MIT.

More from tronghieu/agent-skills