Readchk

LilMGenius/paperthin/skills/depth/readchk

作者 LilMGenius7d5dc6235990230e45a24a25c527d81701da5458無授權條款收錄於 2026年10月9日更新於 2026年10月9日

Verify the model's understanding of a user's instruction before spending non-trivial work. Use when a request is long, bundled, high-stakes, hard to undo, or has ambiguous scope or referents such as this, that, it, the other one, whatever is cleaner, or whichever order makes sense. Restate internally, cross-check against available context, proceed silently when resolved, and surface only a genuine surviving fork.

僅含說明AI & Agents
AI 產生的概覽

在投入大量工作前,核實代理對使用者指令的理解,只在確實存在歧義時提問。

功能
這是一個僅含說明的技能,定義了動工前對請求理解程度的檢查。代理會用自己的話重述指令,並將重述與可用脈絡(例如目前訊息、工作階段歷史、專案記憶、磁碟上的檔案和既有慣例)交叉核對;若理解已明確,便靜默繼續。若確實存在無法消解的分歧,則提出一個具體的釐清問題;對於重大承諾,會記錄一筆持久的「理解為:……」紀錄。
適用情境
適用於請求冗長、包含多項內容、風險高、難以復原,或範圍與指涉含糊(例如「這個」「那個」「哪個比較乾淨就用哪個」)的情況。它用於在投入大量工作之前,避免把心力用錯方向。
執行需求
不需要指令碼或工具,僅為說明性內容。它依賴代理原本就能存取的脈絡,例如目前訊息、工作階段歷史、專案記憶、磁碟上的檔案和既有慣例。

Check 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

  1. 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.
  2. Restate the instruction internally in different words. Do not copy the user's wording back to yourself and treat that as understanding.
  3. Cross-check the restatement against available context. Look for contradictions, missing antecedents, or two plausible readings that context cannot choose between.
  4. If context resolves the read, proceed silently. Do not ask the requester to confirm what the available context already answered.
  5. 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?"
  6. 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.

來源與署名

來源:LilMGenius/paperthin位於skills/depth/readchk提交7d5dc62

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架