agentsclimarketplace

Reasoning chain of verification

Skill firststone-vc/reasoning-pack/skills/reasoning-chain-of-verification

Make a cheap model reason like Claude Fable 5 - 11 installable Claude skills: plan-then-execute, self-consistency, reflexion, tree-of-thoughts, verification and more. MIT.

Install
npx -y skills add firststone-vc/reasoning-pack --skill reasoning-chain-of-verification

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use after producing any draft answer that contains checkable factual claims (names, dates, numbers, quotes, list items, citations, claims about a source document, code-behavior claims) — especially summaries, RAG answers, biographical/historical content, or "list all X" tasks. Generates independent verification questions per claim, answers them without looking at the draft, then corrects mismatches. Skip for pure opinion/creative output or when there is nothing factual to check.

SKILL.md

7.4 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it

Chain-of-Verification (CoVe)

What this is

A self-interrogation protocol applied to a draft answer: decompose the draft into atomic factual claims, turn each claim into a standalone verification question, answer those questions independently (without re-reading the draft's own reasoning), then diff the independent answers against the draft and fix whatever doesn't match.

The mechanism that matters is the independence step. If you re-verify a claim by asking "is this right?" while the flawed draft is still in view, the model tends to just re-confirm its own mistake (anchoring) — you get the same hallucination back with more confidence attached. CoVe breaks that loop by answering the verification question cold, then comparing.

What this is NOT

  • Not the adversarial verifier-loop. That technique has a critic persona actively trying to attack/break the answer's logic, arguments, or edge cases. CoVe has no adversary — it's the same model, calmly fact-checking its own concrete claims one at a time. Use verifier-loop for reasoning/logic soundness; use CoVe for factual grounding.
  • Not reflexion. Reflexion retries a whole task across episodes using feedback from failure. CoVe does a single-pass claim-by-claim audit of one draft; it doesn't re-attempt the task from scratch.
  • Not rubric-grader. Rubric-grader scores an output against criteria/weights. CoVe doesn't score — it corrects specific factual errors.
  • A capability multiplier. It cannot verify against knowledge the model doesn't have, and it cannot invent ground truth. It reliably catches claims that are unsupported by the given source, internally inconsistent, or that the model is unsure of once asked directly — not claims where the model is confidently wrong about something with no source to check against.

When to use

  • The draft has multiple checkable atomic facts: dates, quantities, names, quotes, entities, list items, citations.
  • Summarizing or answering from a supplied source (RAG, document Q&A) — the single best use case, since "supported by the source?" is a crisp, checkable question.
  • "List N things that satisfy property X" tasks, where each list item is an independently checkable claim.
  • Biographical, historical, technical-spec, or code-behavior claims where a wrong detail would be embarrassing or costly.

When NOT to use

  • Pure opinion, creative writing, or brainstorming with no factual content — there's nothing to decompose into checkable claims.
  • The draft is a single unified logical/mathematical derivation with no standalone facts to isolate (use verifier-loop's recomputation instead).
  • Trivial, low-stakes answers where the cost of 2-3 extra passes isn't worth it.
  • The claims can't be phrased as questions answerable independently of the draft (e.g., "is this a good title?" — subjective, not factual).

Inputs

  • draft: the baseline response to audit.
  • source (optional but strongly preferred when available): the document, data, or context the draft should be grounded in. Without a source, step 4 falls back to the model's own knowledge, which is weaker verification.

Procedure

  1. Draft. Produce the baseline response normally (no special process yet).

  2. Extract atomic claims. Break the draft into standalone, independently checkable statements — one fact per claim. Avoid compound claims ("X happened in Y and led to Z") — split them.

  3. Generate verification questions. For each claim, write a specific, closed-ended question whose answer would confirm or contradict it. Prefer "What year did X launch?" over "Is it true that X launched in that year?" — the former forces independent derivation, the latter invites a yes-bias.

  4. Answer independently (factored verification). Answer each question fresh, working only from the source (if given) or general knowledge — deliberately without consulting the draft's phrasing or conclusion for that claim. If the source doesn't contain the answer, the correct independent answer is "not stated in source" / "uncertain," not a guess.

  5. Diff and flag. Compare each independent answer to the matching claim in the draft. Mark: match / mismatch / unsupported (no evidence either way).

  6. Revise. Produce the final answer: keep matched claims as-is, correct mismatches, remove or explicitly hedge unsupported claims. Never silently drop a hedge into a confident-sounding sentence — say what's uncertain.

Output format

### Draft
<baseline response>

### Claims & Verification
| # | Claim (from draft) | Verification question | Independent answer | Status |
|---|---|---|---|---|
| 1 | ... | ... | ... | match / mismatch / unsupported |

### Corrections
- Claim #: <what changed and why>

### Final Answer
<revised response, hedged where unresolved>

Worked example

Task: Summarize the following source document.

Source:

"Nimbus Robotics was founded in 2016 in Austin, Texas. The company's flagship product, the Nimbus-7 warehouse robot, launched in 2021 and is used by over 200 retail warehouses. Nimbus Robotics raised $40M in Series B funding in 2022, led by Vantage Capital. The company has 85 employees as of 2024."

Draft (baseline):

"Nimbus Robotics, founded in 2016 in Austin, Texas, makes the Nimbus-7 warehouse robot, released in 2021 and deployed in over 200 warehouses. The company raised $40M in a Series B round in 2022 led by Vantage Capital, and was acquired by a larger logistics firm in 2023. It currently employs 85 people."

Claims & Verification:

#ClaimVerification questionIndependent answer (from source)Status
1Founded 2016, Austin, TXWhere and when was Nimbus Robotics founded?2016, Austin, Texasmatch
2Nimbus-7 launched 2021What is the flagship product and launch year?Nimbus-7, 2021match
3Used by 200+ warehousesHow many warehouses use the Nimbus-7?Over 200 retail warehousesmatch
4$40M Series B, 2022, led by Vantage CapitalFunding amount, round, year, lead investor?$40M, Series B, 2022, Vantage Capitalmatch
5Acquired by a logistics firm in 2023Was the company acquired, by whom, when?Source does not mention any acquisitionunsupported
685 employeesEmployee count, as of when?85 employees, as of 2024match (draft dropped "as of 2024")

Corrections:

  • Claim 5: not stated anywhere in the source — fabricated. Remove.
  • Claim 6: restore the "as of 2024" qualifier for precision.

Final Answer:

"Nimbus Robotics, founded in 2016 in Austin, Texas, makes the Nimbus-7 warehouse robot, released in 2021 and deployed in over 200 retail warehouses. The company raised $40M in a Series B round in 2022 led by Vantage Capital, and had 85 employees as of 2024. (The source does not mention any acquisition.)"

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.