本文へ移動
cccskills
無料GitHub で公開

critical-thinking

Audit the reasoning of a document or argument (memo, proposal, investment analysis, board paper, article, the user's own draft): claims, evidence, unstated assumptions, logical gaps, fallacies, and what would falsify it, each anchored to quoted text. Use whenever the user wants reasoning examined, in any language ("audit this argument", "is this analysis sound", "poke holes in this proposal", "review the logic of my draft"; Vietnamese "phản biện giúp tôi", "soi lập luận này", "tài liệu này có lỗ hổng gì", "góp ý bản nháp của tôi"), even when they never say "critical thinking". Also use when the user drops a document and asks whether to trust or act on it, or asks to see their reasoning profile. Not for company-level strategic bets (strategy-board) or learning a topic through dialogue (socratic-questor).

インストール方法を見る

含まれるファイル(10)

  • SKILL.md11.7 KB
  • README.md7.3 KB
  • README.vi.md9.4 KB
  • README.zh.md6.9 KB
  • references/argument-anatomy.md6.6 KB
  • references/audit-report.md9.5 KB
  • references/coaching.md6.5 KB
  • references/fallacies-biases.md23.2 KB
  • references/rubric.md13.1 KB
  • scripts/init-workspace.sh2.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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:

LabelMeaning
[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):

ModeWhenDepth
Quick auditShort docs, low stakes, time pressureSkeleton + top 3 findings
Deep auditLoad-bearing decisions, long or dense docsFull anatomy + rubric + fallacy scan (read references/rubric.md and references/fallacies-biases.md)
Draft reviewThe document is the user's own writingFortify, 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: skipped in the calibration log. If most of the recent sessions are skips, mention it once in the next progress review — the pattern is theirs to see, not yours to nag about.
  • Never grade the commit itself in the moment. The comparison step does that work structurally; commentary like "good catch!" trains the user to perform for the coach (Ennis/Norris: dispositions are fakeable the moment the assessment's purpose shows).

3 — Audit

Dissect per references/argument-anatomy.md: map the conclusion, the claims that carry it, the evidence offered, the warrants connecting them, and the unstated assumptions. For deep audits, then grade against references/rubric.md and scan against references/fallacies-biases.md. Write the report per references/audit-report.md.

Do the analysis fresh — the audit must not anchor on the user's commit. You read their answers to record them; set them aside while auditing, then return to them in step 4.

4 — Compare

The comparison is where the coaching value lives — treat discrepancies between the user's commit and the audit as the day's most useful output, not as an afterthought:

  • Caught: findings the user's commit anticipated (list them plainly).
  • Missed: findings the commit didn't see — each tagged with its finding type, because the type is the trainable pattern. Missing one [ASSUME] is noise; missing [ASSUME] in six straight sessions is a blind spot with a name.
  • Phantom: weaknesses the user predicted that the audit didn't confirm — worth a sentence on why the concern didn't materialize.
  • Calibration: their stated confidence vs. how the audit landed, as one row appended to calibration.md.

No praise, no scolding — just the delta, in plain sight. When the same miss-type shows up for the third time, name the pattern explicitly and, if a flashcard tool is available, offer once to turn it into a spaced-repetition card.

5 — Update the books

Append the session file, the calibration row, and — only when a pattern has genuinely recurred, not after every session — update profile.md. The profile records patterns with evidence (session links), never personality judgments. "Missed [GAP] findings in 4 of last 6 audits of financial documents" is a profile entry; "tends to be gullible" is not.

Draft review mode

When the document is the user's own, the job inverts: you are the sparring partner they hired to find the holes before their real audience does. Same anatomy, same finding types, same honesty — plus:

  • Lead with what the argument gets right structurally (they need to know which pillars can bear more weight, not just which crack).
  • For each finding, sketch the repair, not just the flaw: what evidence, qualifier, or restructuring would close it.
  • Steelman the opposition: the strongest objection a hostile reader will raise, and where in the draft to pre-empt it.
  • Audit the decision structure, not just the claims: does the draft define stage-gates, go/no-go criteria, or conditions under which the author would stop? Proposals fail sophisticated readers on missing decision structure as often as on weak evidence — and it is the cheapest repair on this list.
  • Commit-first still applies, in inverted form: "Where do you think a hostile reader attacks this first?"

Progress review mode

Read profile.md and calibration.md, then report like an honest coach: top recurring miss-types with their trend (improving? stuck?), calibration drift (systematically overconfident? on which document types?), commit-skip rate, and one concrete suggestion for what to watch in the next audits. Where the record is thin, say so — three sessions is an anecdote, not a trend.

Boundaries

  • strategy-board owns company-level strategic bets that deserve a full advisory board. If an audit reveals the document is really a major strategic decision in disguise, finish the audit, then point there.
  • socratic-questor owns learning a topic through dialogue. This skill examines a specific argument, not a field of knowledge.
  • market-researcher / deep-research own establishing external facts. When an audit hinges on whether a market claim is factually true, flag it [CANNOT-ASSESS] and suggest a research pass — don't play fact-checker from memory.
  • design-thinking owns understanding users. An audit of a "users want X" claim checks the reasoning offered, not what users actually want.

References

  • references/argument-anatomy.md — how to dissect: Toulmin mapping, claim/evidence/assumption extraction, quote discipline. Read for every audit.
  • references/rubric.md — Paul–Elder standards × Ennis abilities as an operational grading rubric. Read for deep audits.
  • references/fallacies-biases.md — detection catalog for the fallacy and bias scan. Read for deep audits; consult in quick audits only when you smell a specific pattern.
  • references/coaching.md — the commit-first protocol in full, the evidence behind it, profile and calibration file formats, and how to run comparisons and progress reviews. Read whenever the workspace is in play.
  • references/audit-report.md — report templates for each mode. Read before writing any report.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Inspect and explain bmad-loop run artifacts under `.bmad-loop/runs/`. Use for live health checks ("is it stuck?", "is the loop alive?", "what is the agent doing?") and post-run forensics ("what happened?", "why did story X fail?", "where did the tokens go?"). Also triggers on "monitor/check/summarize the loop", "why did the run pause?", Vietnamese "theo dõi bmad loop", "phân tích run", "đọc log của run", and equivalent requests in other languages. Use only for bmad-loop's own run artifacts, not application runtime logs or CI-provider build logs.

日本語の概要は準備中です。原文の説明を表示しています。

tronghieu/agent-skills742026年10月10日 更新

Coach structured brainstorming sessions on any topic: diverge on ideas together, then converge on priorities and next steps in a session document. Use whenever the user wants ideas or wants to think out loud, in any language ("brainstorm with me", "give me ideas for…", "help me come up with…", "let's explore options for…", "I'm stuck on the name / the features"; Vietnamese "brainstorm cùng tôi", "cho tôi ý tưởng", "nghĩ cùng tôi xem"), even when they never say "brainstorm". Also use when the user wants multiple perspectives or a devil's-advocate pass on their ideas ("give me different angles", "phản biện mấy ý tưởng này", "party mode"). Not for diagnosing why something is failing (problem-solver), user research (design-thinking), or company-level strategic bets (strategy-board).

日本語の概要は準備中です。原文の説明を表示しています。

tronghieu/agent-skills742026年10月10日 更新

cv-scorer

無料

Score candidate CVs on a 100-point scale against a Job Description. Use this skill when the user wants to evaluate, score, rank, or screen candidate CVs/resumes against a JD. Also trigger when the user mentions 'review CV', 'screen resume', 'rate candidates', 'shortlist', or any context involving matching resumes to job requirements.

日本語の概要は準備中です。原文の説明を表示しています。

tronghieu/agent-skills742026年10月10日 更新

Act as an end-to-end data scientist: turn business questions into defensible analysis, validated models, and decision-ready reports. Use whenever the user asks to analyze, explore, or profile a dataset or CSV/Parquet/Excel file; asks what drives a metric or why a number changed ("why did churn go up?"); wants to test whether a difference is real (A/B tests, experiments, "is this significant?", "how many samples do I need?"); wants a predictive model (churn, forecast, scoring, segmentation, classification, regression); asks to review an existing analysis, notebook, or model for flaws; or needs results written up for decision-makers. Triggers in any language ("phân tích dữ liệu", "xây model dự đoán", "kiểm định A/B"), even when they never say "data science" or "statistics".

日本語の概要は準備中です。原文の説明を表示しています。

tronghieu/agent-skills742026年10月10日 更新

Read, study, and answer questions about long books and papers without loading the whole text into one context window, keeping page-anchored notes as a reusable workspace. Use whenever the user asks to read, study, summarize, analyze, review, or answer questions about a long book, textbook, PDF, EPUB, thesis, dissertation, survey paper, or any document of roughly 50+ pages, in any language (Vietnamese "đọc sách", "tóm tắt sách", "phân tích luận án"). Also use when a `{slug}-notes/` workspace from a previous session sits next to a source file and the user asks a follow-up question about that book. Not for short documents (under ~30 pages) that fit in context; read those directly.

日本語の概要は準備中です。原文の説明を表示しています。

tronghieu/agent-skills742026年10月10日 更新

design-thinking

無料日本語概要

Facilitate a full design-thinking engagement (Empathize, Define, Ideate, Prototype, Test) grounded in real user evidence. Use whenever the user wants to understand users deeply and design a solution for them: "run design thinking", "understand our users", "design user interviews", "synthesize these interview notes", "build personas", "write How-Might-We questions", "prototype this concept", "design a usability test", "our users are churning and we don't know why", in any language ("tư duy thiết kế", "nghiên cứu người dùng", "phỏng vấn khách hàng", "デザイン思考", "设计思维"), even when they never say "design thinking". Also use when the user drops raw interview notes, transcripts, or survey exports and wants insights, personas, or product decisions. Not for "is there a market for X" desk questions (market-researcher).

tronghieu/agent-skills742026年10月10日 更新

tronghieu のスキルをすべて見る

このスキルの問題を報告する