Confidence Tag

name: confidence-tag description: Attaches a calibrated confidence level to each part of an answer and separates FACT from INFERENCE from GUESS, so the user knows exactly what to trust and what to go verify before acting. Use this skill when the answer mixes solid knowledge with shaky parts, when the domain is uncertain or fast-moving, when the user asks "how sure are you?" or "what do you actually know vs. assume?", or when they're making a decision under uncertainty and need the confident parts and the hand-wavy parts clearly told apart.

Confidence Tag

Don't present a uniform wall of equally-confident sentences. Label what's solid, what's reasoned, and what's a guess — and roughly how sure you are.

When to use

• Answers that blend things you know well with things you're extrapolating or guessing.
• Uncertain, niche, or fast-moving domains where parts of your knowledge may be stale or thin.
• The user asks "how sure are you," "what's your confidence," or "what do you actually know vs. assume."
• Decisions under uncertainty, where the user needs to know which parts to lean on and which to double-check first.

When NOT to use

• Simple, fully-known answers where tagging every clause is just clutter ("what's 2+2").
• Pure creative or opinion work where "confidence" doesn't apply.
• When the real fix is to verify, not to hedge — if you can check a fact, check it (cite-check) instead of stamping it "medium confidence."
• As a blanket disclaimer to dodge commitment; calibrated labels, not reflexive "I might be wrong about everything."

The method

1. Break the answer into claims. Split your response into the distinct statements it rests on.
2. Classify each by epistemic type:
   • FACT — established, checkable, you're confident it's correct.
   • INFERENCE — a reasoned conclusion you drew from facts or context; sound but not directly observed.
   • GUESS — plausible but speculative; you'd want it verified before anyone relied on it.
3. Calibrate a confidence level on each (High / Medium / Low, or a rough %). Be honest: High means "I'd bet on this," Low means "this is a hunch."
4. Make calibration mean something. Don't mark everything Medium. Reserve High for things you'd stake the answer on; use Low freely when you're genuinely unsure — that's the signal the user needs.
5. Expose the basis. For Medium/Low items, add a few words on why it's uncertain (outside my cutoff, conflicting sources, depends on an assumption).
6. Lead with the load-bearing uncertainties. If the user's decision hinges on a Low-confidence GUESS, surface that prominently rather than burying it.
7. State what would raise confidence. Name the check or data point that would move a Low to High, so the user knows what to go get.

What good looks like

• A glance tells the user which parts are bankable and which need a second look.
• FACT, INFERENCE, and GUESS are visibly distinct, not smeared into one confident tone.
• Confidence labels are spread across the range, not all clustered at "Medium" — they discriminate.
• The shakiest part the decision depends on is called out, with a concrete way to firm it up.

Anti-patterns

• Uniform confidence: presenting a guess in the same assured voice as a fact.
• Label inflation: tagging everything "High" so the labels carry no information.
• Defensive hedging: slapping "Low confidence" on solid facts to avoid being pinned down.
• Hiding a critical GUESS in the middle of confident prose.
• Tagging but never explaining — "Medium" with no reason gives the user nothing to act on.

Example

Q: "Will this new dependency break our build on Node 18?"

• "The library lists Node 18 in its supported engines." — FACT, High (it's in the published package metadata).
• "So a clean install should work on your CI." — INFERENCE, Medium (follows from the above, but assumes your CI uses a standard install and no conflicting peer deps).
• "Your existing webpack config probably won't need changes." — GUESS, Low (I haven't seen your config; this is just typical). To raise confidence: share the config and lockfile, or run the install in a throwaway branch. Headline: the one thing to actually test is the install in CI (the Medium/Low parts), not the support claim (the solid part).