# Evidence Gap Detector

> Detect where an idea, task, plan, solution, or claim is relying on missing evidence, unvalidated assumptions, or weak signals. Use when something sounds plausible but may be resting on unknowns, when confidence feels ahead of proof, or when the next step should be guided by what must be verified first.

- Skill: `alubiama/evidence-gap-detector` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add alubiama/evidence-gap-detector`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alubiama/evidence-gap-detector/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Alubiama (https://skillmd.com/u/alubiama)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/alubiama/evidence-gap-detector

---


# Evidence Gap Detector

## Goal

Expose the minimum set of unknowns that materially weaken a proposal and turn them into verification targets.

The job of this skill is not to reject everything. The job is to separate what is known, inferred, assumed, and missing so the next decision is anchored in reality rather than confidence theater.

This skill diagnoses evidence quality. It does not replace the broader proceed/revise verdict from `quality-gate`, and it does not replace problem framing where the core claim is still vague.

## Default Posture

- evidence before certainty
- material unknowns before minor unknowns
- verification targets before argument
- weak signals are not proof
- name what would change the decision

## When To Use

Run this skill when:

- an idea or plan sounds stronger than its evidence base
- the team is moving from reasoning into action
- a proposal depends on several assumptions
- the user is confident but the proof chain is thin
- the next step should be chosen by what must be verified first

This is a strong checkpoint before:

- implementation
- prioritization
- validation design
- architecture commitment
- a `quality-gate` proceed decision

## Scope Boundaries

In scope:

- distinguish knowns from inferences and assumptions
- find missing facts that materially affect the decision
- rank evidence gaps by impact
- state what must be checked next

Out of scope by default:

- deciding the final overall verdict alone
- proving the claim by external research automatically
- listing every possible unknown regardless of relevance
- treating all uncertainty as equally important

## Escalation Conditions

Pause and keep the output narrow when:

- the core claim itself is still too vague to assess
- the object really needs framing more than evidence analysis
- the list of gaps grows without changing the decision
- no gap can be tied to a concrete next check

If the evidence review stays diffuse after one pass, recommend returning to `jtbd`, `quality-gate`, or a narrower validation question.

## Evidence Workflow

1. State the object under review in one sentence.
2. Extract the key claims or implied beliefs.
3. Label each as:
   - `known`
   - `inferred`
   - `assumed`
   - `missing`
4. Identify which missing items would actually change the decision.
5. Rank the gaps by decision impact.
6. Convert the top gaps into concrete verification targets.
7. Recommend the smallest next evidence-building step.

## Core Questions

Use the minimum set needed:

- What is being asserted as true here?
- Which part is actually evidenced?
- Which part is being inferred from weak signals?
- Which assumptions are carrying the proposal?
- What missing fact would change the decision most?
- What is the fastest way to reduce that uncertainty?

## Output Contract

Always return:

1. `object_under_review`
2. `key_claims`
3. `evidence_map`
4. `material_gaps`
5. `gap_priority`
6. `decision_sensitivity`
7. `verification_targets`
8. `confidence_status` (`grounded`, `partly-grounded`, `speculative`)
9. `recommended_followup` (`validation-designer`, `quality-gate`, `jtbd`, `selector`, `research`, `execution`)
10. `next_check`

## Good Evidence Signals

Strong signals:

- claims tied to observable facts or direct inputs
- assumptions named explicitly
- unknowns ranked by impact
- next check is concrete and small

Weak signals:

- high confidence with vague support
- key claims bundled together with no separation
- many unknowns listed with no prioritization
- the proposal proceeds as if missing evidence does not matter

## Guardrails

- Do not treat plausibility as evidence.
- Do not inflate minor unknowns into blockers.
- Do not let one real data point validate a whole chain of assumptions.
- Distinguish evidence, inference, and speculation explicitly.
- If the gaps are low-impact, say so instead of stopping progress.
- Prefer the smallest verification step that could change the decision.
- If the evidence question is too broad, narrow it before adding more gaps.

## Anti-Patterns

Watch for these failure modes:

- skepticism theater
- listing generic unknowns with no decision impact
- using evidence gaps to avoid action forever
- collapsing evidence and interpretation into one statement
- marking everything as uncertain and learning nothing

## Example

Object under review:

`Plan: launch a new AI onboarding assistant next sprint because users are clearly confused.`

Expected shape of response:

1. `object_under_review`: launch plan for AI onboarding assistant next sprint
2. `key_claims`: users are confused; confusion is the main onboarding bottleneck; AI assistant is the best fix; next sprint is the right timing
3. `evidence_map`: confusion partly evidenced; main bottleneck inferred; best-fix claim assumed; timing claim missing
4. `material_gaps`: whether confusion is the dominant drop-off cause; whether assistant beats lighter fixes; whether next sprint timing is justified
5. `gap_priority`: dominant bottleneck first, fix superiority second, timing third
6. `decision_sensitivity`: if confusion is not the primary bottleneck, the whole plan changes
7. `verification_targets`: identify top onboarding drop-off reasons; compare AI assistant vs lighter intervention; check delivery readiness for next sprint
8. `confidence_status`: `speculative`
9. `recommended_followup`: `validation-designer`
10. `next_check`: design one fast test to confirm whether confusion is actually the main onboarding bottleneck