# Uncertainty Verification

> Use when providing exact commands, flags, config keys, file paths, API details, standards, or version-specific behavior - enforces verification via official docs (Context7/web fetch), explicit citations, and bans assumption-based specifics

- Skill: `majiayu000/uncertainty-verification` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/uncertainty-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/uncertainty-verification/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/uncertainty-verification

---


# Uncertainty Verification

## Overview

This skill forces verification before stating any specific technical detail that could vary by version, environment, or specification.

## Use when...

- The request asks for **exact** command syntax, flags, or configuration keys
- The answer depends on **version-specific behavior**, deprecations, or recent changes
- The request involves **standards/specs** (RFCs, protocol behavior, i18n/timezone/locale rules)
- The user asks for **exact file paths**, naming conventions, or directory structures
- The answer requires **library-specific APIs** (class names, method signatures, constants)
- Any part of the response would otherwise be based on “typical patterns” or memory

## Symptoms / keywords

Use this skill when the prompt contains or implies keywords like:

- “exact”, “precise”, “verbatim”, “copy/paste”, “flags”, “CLI”, “config key”, “endpoint”, “params”
- “deprecated”, “since vX”, “in 2025”, “changed in”, “breaking change”, “migration”
- “RFC”, “spec”, “standard”, “format”, “timezone”, “locale”, “i18n”, “OAuth”, “HTTP”, “GraphQL”
- “directory structure”, “file path”, “naming convention”, “default location”
- Specific error codes/messages that must be accurate

## Technical Details Requiring Verification

**Don't provide these specific details without checking official documentation:**

- ❌ Exact file paths, directory structures, or naming conventions
- ❌ Specific API endpoints, parameter names, or response formats
- ❌ Exact command syntax, flags, or configuration keys
- ❌ Version-specific features or deprecations
- ❌ Specific error codes or messages
- ❌ Hostname patterns, URL formats, or connection string syntax
- ❌ Library-specific class names, method signatures, or constants

**Required response pattern when uncertain:**

```
"I need to verify this with official documentation. Let me check..."
→ Dispatch a research subagent to execute Context7 or Web fetch and return a Context Package with citations
→ Cite the source explicitly
```

**Enforcement:**

- Treat assumptions as errors requiring immediate correction
- Any specific technical detail = Verify first
- Any format/syntax example = Check documentation
- Any version-dependent behavior = Confirm with official docs

## Uncertainty detection criteria

**Web Fetch Strategy (via research subagent):** Ask the subagent to try `mcp_fetch_fetch` first (fast; good for SSR/static pages like MDN/Wikipedia). If insufficient (title-only, <100 chars, no meaningful content), ask the subagent to fallback to `fetch_webpage` (better for CSR/JavaScript-rendered docs). The subagent must return a cited Context Package.

When ANY of these apply, immediately dispatch a research subagent to perform verification (Context7/web fetch/etc.) and return a cited Context Package:

- Library/framework version-specific behavior or API changes
- Standard format specifications (phone, date, country codes, currency, regex)
- Protocol/RFC specifications (HTTP, OAuth, REST, GraphQL)
- Best practices for security, performance, scalability
- Algorithm implementations or mathematical formulas
- Time zone, locale, internationalization rules
- After Context7 returns incomplete docs (missing examples, types, error handling)

**Forbidden patterns:**

- “Based on my knowledge” without citing sources
- “This should work” without verification
- “I believe the format is...” without confirming the standard
- Implementing first, validating later
- Confidence-based verification skipping
- Providing examples with specific syntax without verification
- Stating “typical patterns” without confirming they apply
- Suggesting “common practices” without checking current standards

**Authoritative sources priority:**

1. Official docs (`docs.*.com`, `developer.mozilla.org`, `*.org/docs`)
2. Standards bodies (`ietf.org/rfc*`, `w3.org/TR/*`, `whatwg.org`)
3. Official repos (`github.com/org/repo` - README, issues, docs)
4. Specifications (Wikipedia for international standards)

## Procedure (minimal)

1. Identify which parts of the answer require exactness.
2. Fetch authoritative sources (Context7 for library docs; web fetch for standards/official docs).
3. Cite the source explicitly when stating specifics.
4. If sources are unavailable or unclear, say so and give a safe, general answer plus what to verify.

