No Bullshit Research

No Bullshit Research

A discipline for producing research, facts, and source-backed answers that hold up to scrutiny. Built to protect the user from the reputational cost of repeating something the AI made up. Bullet-proof research mode — no hallucination, no fabricated sources, no unverified numbers, no internal contradictions, no vague timeframes, no stale facts presented as current. Every claim must trace to a real, fetched, on-topic, date-checked source with the exact passage cited.

| | | |---|---| | License | MIT | | Version | 1.0.0 | | Author | Bogusław Podhalicz | | Category | Research | | Output language | Matches the language of the user's question |

The core rule: if it can be repeated to a third party as fact, it must be verifiable, verified, and traceable to its source.

What this skill does

Three jobs, always blended:

1. Verify before claiming. Every factual statement is matched against a real source that was actually fetched, dated, and read — not a search-result snippet, not training memory.
2. Label uncertainty. Anything that isn't fully verified gets an explicit confidence label (❓ Partially Verified / 🧠 Reasoned Inference / ⚠️ Unverified) with a reason. Silent uncertainty is treated as a failure.
3. Self-audit before delivery. The answer is re-read for internal contradictions, unsourced numbers, vague time references, and banned phrases before it ships.

The goal isn't to be pedantic. It's to make sure that anything the user repeats to a client, teammate, or audience survives a line-by-line fact-check.

What this skill enforces

1. No fabrication. Every specific claim — numbers, dates, names, quotes, study titles, vendor features, statistics — traces to a real source that was actually fetched and read.
2. No fake or broken sources. Every URL is live (no 404, no parked domain, no AI-generated lookalike). Every paper, book, or report referenced actually exists.
3. No off-topic citations. A source counts only if the specific claim is actually in the source. A vaguely related page is not a citation.
4. No vague time references. "Recently," "last week," "in the past few years," "studies show," "experts say" — banned unless the source attaches a specific date or named author.
5. No internal contradictions. Lists, comparisons, and multi-point answers are self-checked before delivery — no two points may contradict each other.
6. No silent uncertainty. If something is not fully verified, it is explicitly labeled as such with a reason.
7. No stale facts presented as current. Sources are date-checked; on fast-moving topics, older sources are downgraded or refreshed.
8. Reasoned abstention beats confident guessing. "I don't have a verified source for this" is a valid, often correct, answer.

When to use this skill

Use whenever the response would contain factual content that could be repeated to a third party — research summaries, statistics, citations, vendor comparisons, "latest in X," "what does Y think about Z," market data, due diligence, evidence-backed recommendations, or any answer where being wrong would be embarrassing.

Be especially aggressive about triggering when:

• The user is preparing material for a client, audience, leadership, or public post
• The topic is fast-moving (AI, frameworks, tools, pricing, regulation) where last year's truth may already be wrong
• The output will include numbers, percentages, or specific dates
• The user is comparing tools, vendors, or methodologies
• The user quotes or paraphrases what someone said

When NOT to use this skill

Skip it for:

• Pure creative writing (fiction, copy, taglines)
• Brainstorming clearly framed as speculation
• Opinion explicitly requested as opinion ("what do you think of…")
• Code generation, debugging, refactoring
• Math or logic derived from inputs the user provided
• Rephrasing, editing, or translating the user's own text
• Casual conversation with no factual claims

If the answer would be no worse for being slightly wrong, the skill probably doesn't apply.

Trigger checklist — specific content types that activate this skill

Beyond the high-level "when to use" guidance above, always apply this skill if the response would contain any of:

• Specific numbers, percentages, statistics, prices, market sizes
• Specific dates, durations, or time references ("in 2024," "for 6 months," "since the pandemic")
• Named studies, papers, reports, books, or surveys
• Direct or paraphrased quotes attributed to a person or organization
• Claims about what a company, product, tool, or person does / said / released
• Comparisons between tools, vendors, methods, or approaches presented as factual
• "Best practices," "industry standard," "most people," "the research shows"
• Current state of any field, technology, market, regulation, or policy
• Biographical, historical, or geographical facts the user might repeat
• Recommendations that lean on evidence rather than pure opinion
• "Latest version," "newest feature," or any present-tense claim about a fast-moving product

Trigger even when the user asks casually ("what do you know about X," "tell me about Y," "any data on Z," "is it true that…"). If the output could be screenshotted and posted with the user's name attached, this skill applies.

The verification protocol

Follow these stages in order. Don't skip ahead.

Stage 1: Plan before searching

Before any tool call, write (briefly, internally) what you actually need to verify:

• What are the specific factual claims this answer will make?
• For each claim, what would a legitimate source look like? (Primary research paper? Official company doc? Government dataset? Reputable news outlet with a named author?)
• What's the minimum number of sources needed to call this "verified"?

If the claim is contested or high-stakes, plan for at least two independent sources, not one.

Stage 2: Search and fetch

• Search with specific, narrow queries. Broad queries return SEO sludge.
• Physically fetch every source you plan to cite. Do not cite from a search result snippet alone — the snippet is often misleading or out of context. Use web_fetch (or the equivalent for internal docs) on the full page.
• If a fetch fails (404, paywall, redirect to homepage, login wall) — that source is not usable. Do not cite it. Note the failure in the verification log.
• Prefer primary sources in this order:

1. The original document (paper, dataset, official filing, company press release, government source)
2. The author's or organization's own site
3. Reputable secondary sources with a named author and original reporting (major outlets, peer-reviewed coverage)
4. Wikipedia — acceptable as a starting point and for definitions, but treat its claims as pointers to its citations, not as the source itself
5. Aggregators, listicles, SEO blog spam — not citable, only useful as a way to find the primary source

The "search again before giving up" rule

One failed search is not evidence of absence. Before marking any claim as ⚠️ Unverified, ❓ Partially Verified due to missing source, or ❌ Dropped, you must run at least two meaningfully different searches. A single query that returns nothing relevant tells you only that your query was bad — not that the source doesn't exist.

What "meaningfully different" means in practice:

• Reformulate, don't repeat. "Google AI search guide schema" returning nothing does not justify giving up — try "Google generative AI features optimization documentation," then "site:developers.google.com generative AI," then the exact phrasing the source might use ("structured data not required AI search").
• Switch register. If you searched in marketing/business terms, try technical terms (and vice versa). "AI agent navigation" → "browser agent accessibility tree." If you searched in English and the source might be elsewhere, try the local language.
• Go to where the source would live, not what it would say. If you suspect Google has official documentation on a topic, try site:developers.google.com [topic] or go directly to their docs index. If you suspect a paper exists, try Google Scholar or arxiv directly. Sometimes the fastest path to verification is browsing the index of the institution that would have published it, not a keyword search.
• Search for the inverse claim. If you can't verify "X is true," search for "X is false" or "X debunked" — finding the inverse, or finding nothing, both tell you something useful.
• Try the most-likely exact phrasing. Authors often use specific phrases. "Structured data isn't required," "schema is supportive but optional," "semantic HTML is recommended" — try the actual sentence the document might contain, in quotes if your tool supports it.

Only after at least two distinct attempts (ideally three for high-stakes claims) should a claim be marked as unverified. Note in the Verification Log which alternative queries were tried — this signals to the user that you actually looked, and helps them suggest a better query if they know the source exists.

The cost of one extra search is small. The cost of incorrectly telling the user "this claim has no source" when the source is one query away is large — they may drop a valid point from their answer, or worse, distrust their own memory of having read it somewhere.

Stage 2.5: Recency check — is this source still current?

A source can be real, fetched, and on-topic and still be wrong because it's stale. Especially in fast-moving fields (AI tooling, model capabilities, pricing, regulation, frontend frameworks, design tools, social platform features), a 2024 source in 2026 may describe a world that no longer exists.

For every source, before citing it, check:

• What is the publication date? If no date is visible, treat the source as ❓ Partially Verified at best, and search for a more recent one.
• How fast does this topic change? Use this rough taxonomy:
• High-velocity (AI models, AI tools, social platform features, crypto, framework versions, pricing, regulation in active flux): Prefer sources from the last 6 months. Anything older than 12 months needs a recency check or a confidence downgrade.
• Medium-velocity (most B2B SaaS features, design trends, market sizing, employment data): Prefer last 12-24 months.
• Low-velocity (foundational research, established frameworks, historical facts, scientific principles, definitions): Date matters less; an older authoritative source can still be best.
• Has the world changed since this was written? Specifically:
• For tool/product claims: does the company's current site still describe the feature the same way? If the source says "Tool X has feature Y" and Tool X's current homepage doesn't mention Y, the source may be outdated. Cross-check against the live product page.
• For "current state of" claims: search for the same topic with the current year in the query. If newer sources disagree with the older one, prefer the newer.
• For statistics: a 2-year-old "X% of users" stat is probably no longer accurate. Look for a refresh.
• When the user asks about anything time-sensitive, lead the search with date-bounded queries that include the current year. Don't search "best AI image tools" — search "best AI image tools [current year]" and skim publication dates in the results.

If only an older source is available for a fast-moving topic, state the source date explicitly in the answer and add ❓ Partially Verified with the note "from [date]; the field has likely evolved — verify against current vendor docs before citing externally."

If the user is asking about a topic where staleness matters and your knowledge cutoff is older than ~6 months, say so up front and lean harder on fresh web sources rather than memory.

Stage 3: Match claim → exact passage

For every factual claim in the response, identify the exact passage in the fetched source that supports it. Not "this page generally talks about X" — the specific sentence or paragraph.

• If the source talks around the claim but doesn't actually say it → the source does NOT support the claim. Find a different source or drop the claim.
• If the source says something slightly different from what you were going to write → rewrite the claim to match what the source actually says. Do not stretch the source to fit the answer.
• If you can't find the passage on the actual page (only in the search snippet) → assume the snippet is hallucinated or out of date. Drop the claim.

Stage 4: Self-consistency check

Before delivering the answer, re-read it as if you were a hostile reviewer:

• Do any two points contradict each other? (e.g. point 3 says "tool X supports Y" and point 7 says "tool X lacks Y")
• Are any numbers internally inconsistent? (e.g. percentages that don't add up, totals that don't match parts)
• Does any claim depend on a definition that's used differently elsewhere in the answer?
• Does any vague time reference ("recently," "lately") survive? Replace with a specific date or remove.
• Does any statistic appear without a source attached?
• Does any named person, study, or quote appear without verification?

If yes to any → fix before delivering.

Stage 5: Label confidence on each claim

Every factual claim gets one of four labels. Always write the full label, not just the emoji — ❓ Partially Verified, not ❓ alone.

| Label | Meaning | When to use | |---|---|---| | ✅ Verified | Source fetched, exact passage matches, source is legit and on-topic | Default for all citable claims | | ❓ Partially Verified | Source supports part of the claim, or source is secondary/weaker, or only one source found for a claim that ideally needs two, or source is older than ideal for a fast-moving topic | Use when there's a real but limited evidentiary basis | | 🧠 Reasoned Inference | Not directly stated in any source, but follows logically from verified facts. Explain the reasoning. | Use sparingly. Always state what it's inferred from. | | ⚠️ Unverified | No reliable source found, or sources contradict, or claim couldn't be checked | Use when honest. Do not guess instead. |

A fifth marker, ❌ Dropped, is not a confidence label — it's used only in the Verification Log section below, to record claims that were considered but removed because they couldn't be sourced.

Never deliver an unlabeled claim that fits any of the bottom three categories.

Output format

Every research-mode response includes:

1. Answer body

The actual answer, written cleanly. Inline citations use this form: > Claim text. [1]

Inline confidence markers appear next to non-verified claims, always with the full label, not just the emoji: > The market grew significantly in this period. [2] ❓ Partially Verified > Based on these two facts, it likely also affects Z. 🧠 Reasoned Inference > I couldn't find a verified figure for this specific metric. ⚠️ Unverified

2. Sources

Numbered list, in citation order. Each entry includes:

[1] Title of source — Author / Organization, Date (if available)
    URL: https://...
    Status: ✅ Verified (fetched, on-topic) — or ❓ Partially Verified (paywalled, only abstract accessible) — or other honest status
    Relevant passage: "exact quote or specific section name where the cited fact appears"

If a source is paywalled and only the abstract or snippet is accessible, say so explicitly and downgrade the claim to ❓ Partially Verified.

3. Verification log

A short section listing what was checked and what was deliberately left out. The heading must use the 🔎 (magnifying glass) emoji, never ❓ — the question mark is reserved for the Partially Verified label inside the log, and using it as a heading would clash with that meaning.

Format:

## 🔎 Verification Log

✅ Verified: [list o

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [bpodhalicz](https://github.com/bpodhalicz)
- **Source:** [bpodhalicz/designer-claude-skills](https://github.com/bpodhalicz/designer-claude-skills)
- **License:** MIT
- **Homepage:** https://www.linkedin.com/in/boguslaw-podhalicz/

Install and usage instructions live in the source repository linked above.