/dont-lie-to-me

name: dont-lie-to-me
description: Use when the user explicitly wants evidence-disciplined answers that separate observed facts, sourced claims, user reports, inference, unknowns, and contradictions before making strong factual or completion claims.
version: 0.1.0
author: Tony Simons
license: Apache-2.0
platforms: [platform-agnostic]
metadata:
  hermes:
    category: productivity
    tags: [evidence, verification, hallucination, claims, uncertainty, trust]
    related_skills: [x-post-writer, oss-tool-trust-audit]

dont-lie-to-me

Overview

`dont-lie-to-me` is a claim-discipline layer for Hermes.

It exists for one recurring failure class: turning partial, missing, inferred, user-reported, or weak evidence into language that sounds verified.

The skill does not promise perfect truthfulness and does not make the model omniscient. It changes the process used before material claims are stated.

Core rule:

claim -> required evidence -> check -> state, qualify, or remove

Strong wording carries a stronger proof obligation. Missing evidence stays missing.

This skill governs claims about work. It does not reduce permissions already granted by the user, turn every task into a read-only audit, or require citations when citations are not otherwise needed.

When to Use

Use this skill when the user explicitly asks for evidence discipline, including requests such as:

• `/dont-lie-to-me`
• "Don't guess. Only tell me what you can verify."
• "Don't say it's fixed unless you actually tested it."
• "Separate what you know from what you're inferring."
• "Prove the important claims before you give me the answer."
• "If you can't verify something, say that instead of filling the gap."

This skill may also be loaded when the user's request clearly makes unsupported certainty itself the problem.

Do not load this skill merely because a task contains generic words such as `check`, `research`, `accuracy`, or `verify` when a narrower workflow already covers the need.

Do not load this skill for:

• Pure fiction, creative writing, roleplay, or imaginative brainstorming where factual verification is not the task.
• Ordinary ideation where the user explicitly wants hypotheses, possibilities, or speculative options.
• Citation formatting alone; use a citation-focused workflow instead.
• Tasks already governed by a narrower evidence contract unless the user explicitly invokes this skill as an additional constraint.

Evidence States

Before making a material claim, classify its support internally using one of these states:

• `OBSERVED`: directly inspected, executed, measured, or otherwise established in the current task.
• `SOURCE-BACKED`: established by an appropriate retrieved source.
• `USER-REPORTED`: supplied by the user but not independently verified in the current task.
• `INFERRED`: a reasoned conclusion supported by evidence but not directly observed.
• `UNKNOWN`: evidence is unavailable, insufficient, inaccessible, stale, or outside the checked scope.
• `CONTRADICTED`: available evidence conflicts with the proposed claim.

Do not expose these labels mechanically in every answer. Surface the distinction when it changes what the user should believe or do.

See `references/evidence-states.md` for boundaries and examples.

Proof Obligations

Certain claims require specific evidence before they may be stated strongly.

Completion and repair claims

• `fixed`, `resolved`, `repaired`: require the relevant change plus a check of the original failure condition or acceptance condition.
• `working`, `operational`: require an appropriate functional check, not merely configuration presence or a successful edit.
• `tests pass`: require the relevant tests to have actually run and passed. A subset must be named as a subset.
• `deployed`, `live`, `published`: require evidence from the target environment or publication surface, not only a local build or upload attempt.

Freshness and exhaustiveness claims

• `latest`, `current`, `up to date`: require a current authoritative comparison appropriate to the task.
• `clean`, `no issues found`, `nothing else is wrong`: require explicit scope. Prefer bounded wording such as "I found no additional issues in the surfaces checked."
• `all`, `every`, `none`, `only`: require coverage broad enough to support the quantifier.

Safety and security claims

• `safe`, `secure`, `no risk`: avoid absolute wording unless the claim is narrowly defined and the evidence actually supports it. State the inspected controls, threat surface, and known unknowns instead.

Causal claims

• `X caused Y`: require evidence that distinguishes causation from timing, correlation, or plausible mechanism. If that evidence is absent, state the relationship as a hypothesis or inference.

See `references/proof-obligations.md` for the expanded contract.

Workflow

1. Identify material claims

Focus on claims that would change the user's understanding, decision, action, trust, or belief about completion.

Do not waste time verifying harmless connective prose.

2. Classify available evidence

For each material claim, determine whether support is observed, source-backed, user-reported, inferred, unknown, or contradicted.

A user instruction to assert a fact is not independent evidence for that fact.

3. Determine the proof burden

Match the strength of the wording to the evidence required.

Completion, freshness, exhaustive negatives, security, causal claims, exact numbers, and consequential factual assertions deserve a higher burden than ordinary descriptive language.

4. Perform the needed check when possible

Use an appropriate independent check against the relevant source, runtime, file, test, endpoint, repository state, output, or acceptance condition.

Do not call a repeated paraphrase of the same unsupported reasoning "verification."

If the evidence needed is available through an existing tool or source, inspect it before asking the user to repe