karim-bhalwani Researcher Skill - Documentation & Fact Verification
Overview
The Researcher skill ensures that technical decisions are based on verified facts and official documentation. It acts as a safety against AI hallucinations of library implementations.
Core Capabilities
- Fact Checking: Verify library versions via
pyproject.toml,package.json, or environment checks. - Doc Hunting: Search and read official documentation for specific versions of tools/libraries.
- Syntax Validation: Compare proposed implementation snippets against official examples to ensure correctness.
- Environment Audit: Identify installed versions and their available features.
Verification Protocol
- Version Audit: Identify the exact version of the technology in use.
- Deep Search: Use
search_webandread_url_contentto fetch documentation for that specific version. - Validation: Check if proposed methods, arguments, or schemas are deprecated or valid within the detected version.
- Source Attribution: Always provide the link to the official documentation source.
When to Use
- When using a third-party library or API.
- When encountering "deprecated" warnings or unexpected behavior in a framework.
- Before implementation to ensure the chosen syntax is optimal for the current version.
Constraints
- NO implementation code. Provide confirmed snippets or links only.
- DO NOT guess. If a documentation source is unavailable, state it clearly.
- Read-Only. Only fetch and report information.
Common Pitfalls
- Outdated Documentation: Copy-pasting from old blog posts instead of checking official docs for the current version. Always verify version compatibility.
- Ignoring Deprecation Warnings: "This still works" isn't good enough. Check changelogs; new versions may break APIs you're using.
- Trusting Stack Overflow: Great for ideas, terrible for truth. Always verify against official documentation and source code.
- Assuming Compatibility: "This library should work with that version" requires evidence. Check dependency specs explicitly.
- Missing Edge Cases: Official docs show the happy path. Check issues/discussions for known gotchas and workarounds.
- Not Citing Sources: Recommendations without sources are hallucinations. Every claim must have a link to official docs or source code.
Integration Points
| Phase | Input From | Output To | Context |
|---|---|---|---|
| Investigation | Question about library/API | Fact verification | Research current version and features |
| Validation | Proposed implementation | implementer |
Confirm proposed syntax matches official docs |
| Decision | Technology comparison | architect |
Provide version-accurate comparisons for arch decisions |
| Prevention | Before implementation | implementer |
Validate approaches against official capabilities |
Outputs & Deliverables
- Primary Output: Verified documentation references, version-accurate code snippets, and source links
- Secondary Output: Compatibility notes and deprecation warnings relevant to the project's versions
- Success Criteria: All claims are backed by authoritative links and examples that match the target version
- Quality Gate:
implementeror requestor review for actionable code snippets
Additional Constraints
- Technical Constraints: Avoid making implementation changes; provide exact references and examples only
- Governance Constraints: Cite official docs and avoid relying on unverified third-party blogs for critical claims