evidence-first-answer
SolidRequired pre-flight before answering any "why" or "are we" question about revenue, conversion, outbound, traffic, or commercial state. Forces verification of live data and distinguishes planning docs from telemetry. Triggered automatically when the CEO asks "are you sure?" — that phrase means the previous answer was wrong.
Install
Quality Score: 81/100
Skill Content
Details
- Author
- IgorGanapolsky
- Repository
- IgorGanapolsky/ThumbGate
- Created
- 4 months ago
- Last Updated
- today
- Language
- JavaScript
- License
- MIT
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
scientific-method
Use this skill whenever someone doubts a number, demands rigorous proof of a cause, or wants something invented and proven — any time a benchmark, metric, ceiling, or root-cause story must be verified rather than trusted, or a limit must be broken with a built, measured mechanism. Typical situations: a measurement looks suspicious ("2x faster but I don't trust it"); an incident needs its true cause before a decision ("the team blames X — confirm it, no guessing"); ANY production incident, outage, brownout, latency/error spike, regression, or "started failing" / "load suddenly went 5x" / "every component met spec but it still broke" report where the cause is not yet proven — especially when a recent deploy or change is suspected ("is the deploy to blame", "this coincided with the rollout"), since the obvious suspect is exactly what needs a control case; an asserted ceiling or "impossible" limit needs breaking or proving real; numbers need validation before publishing; a problem needs an invented solution that
evidence-investigate
Use when answering questions about the CURRENT state of code, git history, or on-disk files — e.g. "is X installed", "what does Y do", "what branch has Z", "when did W change", "does the running code have feature F". Do NOT use for trivial file existence checks answerable by a single ls, for implementation/edit work, or for questions about mutable external state (APIs, databases, live processes, Telegram history).
deep-grounding
Run a deep-grounding pass BEFORE asserting or analyzing — do not answer from priors on the first source or angle that comes to mind. Ask "where could the evidence for this be?", gather the relevant available sources (project memory, READMEs/docs, the actual code/config, tests, logs/telemetry, tickets, git history, the web — whatever fits the question), and follow the leads they reveal RECURSIVELY, even low-odds ones, until the trail runs dry; THEN reason, grounded, tagging each conclusion with its evidence tier and stating what could not be verified. Use this PROACTIVELY whenever you are about to assert a checkable claim, start a non-trivial analysis / design / diagnosis / recommendation, or answer from "what you already know" — ESPECIALLY when you notice yourself reaching for a conclusion from a single source or a single angle, or when a result BEATS your expectation (favorable surprises are the ones that silently skip verification). Evidence, not more reasoning, is what escapes a wrong prior.