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:
- Official docs (
docs.*.com,developer.mozilla.org,*.org/docs) - Standards bodies (
ietf.org/rfc*,w3.org/TR/*,whatwg.org) - Official repos (
github.com/org/repo- README, issues, docs) - Specifications (Wikipedia for international standards)
Procedure (minimal)
- Identify which parts of the answer require exactness.
- Fetch authoritative sources (Context7 for library docs; web fetch for standards/official docs).
- Cite the source explicitly when stating specifics.
- If sources are unavailable or unclear, say so and give a safe, general answer plus what to verify.
More from faulkdev/github-copilot-superpowers
minimalist-surgical-development
Use when editing an existing codebase and the goal is minimal, standard, and non-invasive changes - prioritizes simplest solution, standard libraries first, and surgical modification without unsolicited refactors
33investigation-mode
DEPRECATED: See systematic-debugging for current implementation.
14verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
14root-cause-tracing
Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
13task-direction-approval
Use when considering switching libraries/tools, changing architecture, or replacing automation with manual workarounds - explains root cause, offers 2-3 options with trade-offs, and requests explicit user choice
13systematic-debugging
Use when errors are unclear, flaky, or regressions occur; apply a disciplined debugging loop in VS Code Copilot Agent mode.
3