About readchk
readchk is an agent skill for checking whether an instruction has been understood before work begins. It compares a paraphrase with available context and asks a specific question only when an important ambiguity remains.
Key features
- 01Cross-check paraphrased instructions against context
- 02Find ambiguity, contradictions, and missing references
- 03Proceed silently when context resolves the request
- 04Ask a specific question about unresolved forks
- 05Record interpretations for substantial work
Use cases
- 01Check intent before complex or multi-part tasks
- 02Resolve ambiguous scope or references
- 03Catch misreadings before high-stakes work
- 04Leave an auditable interpretation for substantial work
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/readchkin Claude Code to confirm it loaded.
Details
From the project READMECheck the read before acting: did you understand the instruction correctly enough to spend the work?
Goal
readchk catches misread instructions before they become coherent work against the wrong target. It verifies a claim about the requester's intent against available context: the current message, session history, project memory, files on disk, and established conventions.
This is not factchk: the question is what was meant, not whether a world claim is true.
Workflow
- Recognize the signal: a long or multi-part instruction, ambiguous scope or referents, deliberately flexible wording, or stakes high enough that a wrong guess would cost real work.
- Restate the instruction internally in different words. Do not copy the user's wording back to yourself and treat that as understanding.
- Cross-check the restatement against available context. Look for contradictions, missing antecedents, or two plausible readings that context cannot choose between.
- If context resolves the read, proceed silently. Do not ask the requester to confirm what the available context already answered.
- If a real fork survives, surface one specific clarifying question anchored to the restated understanding. Name the choice; do not ask a vague "does this look right?"
- For substantial work, log one durable "understood as: ..." line before beginning so a later reader can audit whether the work matched the confirmed read.
Rules
- Restate, don't echo. A paraphrase proves you built a model of the request; a verbatim repeat proves little.
- Silent when context resolves it. The default good outcome is invisible. Surfacing a question for a resolved or unambiguous request is a defect.
- One fork at a time. If several ambiguities exist, surface the highest-stakes one first instead of dumping a checklist.
- Never silently resolve a fork that changes the shape of the work.
- Log large commitments, not every turn. Durable read logs are for plans, multi-file changes, irreversible actions, or work a fresh reviewer may need to audit.
Verification
Before proceeding with the work: the restatement is a paraphrase, every surfaced fork is genuinely unresolved by available context, and no substantial work starts without either a silent pass or a resolved fork.