adityanshinde/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.