Checks whether a claim is backed by a primary source, a current official page, or a reputable secondary source before that claim becomes published copy. This skill is essential for AI tool directories, MCP server listings, and news summaries where accuracy and trustworthiness directly affect reader decisions and SEO credibility.
Use cases
- Adding a new AI tool to a directory and verifying its pricing, capabilities, and release date against the official source
- Reviewing an MCP server listing where the maintainer's claims about features or compatibility need verification
- Publishing a news summary where a claim about a model's capabilities or a company's acquisition needs a primary source
- Updating an existing entry when a vendor has changed their pricing or deprecated a feature
- Before publishing a comparison between two tools where the stated capabilities need to be verified individually
Key features
- Locate the primary source for the claim—typically the official product page, GitHub README, or press release from the vendor's own channels
- Capture the date of the source and the entity that owns it to establish currency and authority
- Cross-reference the primary source against one additional reputable source to confirm the claim is not disputed or outdated
- Flag any claim that cannot be verified with a primary source as [unverified] rather than smoothing it over or removing it silently
- Document the sources used for each major claim in the entry's metadata so the verification trail is auditable
When to Use This Skill
- When adding a new tool, MCP server, or news item to a directory and verifying claims before publishing
- When updating an existing entry's pricing or feature claims after a vendor change
- When a claim in published content has been disputed by readers and needs to be re-verified
Expected Output
A verified entry with source URLs, capture dates, and a flag for any unverified claims that should be reviewed before publishing.
Frequently Asked Questions
- What counts as a reputable secondary source?
- Established tech publications (not blogs), official documentation from the tool's maintainers, or peer-reviewed research. Avoid tutorials, community posts, or content that is itself citing another secondary source without verification.
- How do I handle claims about future features or roadmaps?
- Do not publish them as facts. If a vendor has announced a roadmap, attribute it explicitly ('as of Q2 2026, the vendor has announced plans to...') and note that future features are subject to change.
- What if the primary source contradicts what the vendor's marketing page says?
- Default to the primary source (the technical documentation or README) over marketing copy. Flag the discrepancy and note it in the entry. Marketing pages frequently overstate capabilities relative to what is actually shipped.
Related
Related
3 Indexed items
Brainstorming before build
Explores goals, constraints, risks, and design options before committing to a specific implementation path. This technique is most valuable when facing product or UX decisions where the wrong choice is expensive to reverse—new features with uncertain user value, architectural pivots, or cross-functional dependencies where each team has a different mental model of the problem.
OpenAI documentation lookup
Prioritizes official OpenAI documentation, model cards, and API references when researching integration details, model capabilities, or API behavior changes. This avoids the noise and staleness of third-party blog posts that may summarize older model versions or incomplete information.
Prompt engineering
Crafts prompts with explicit task framing, role definition, output constraints, citation requirements, and few-shot examples so model responses are consistent, grounded in evidence, and actionable for downstream tasks. Prompt engineering reduces the variability and hallucination risk that comes from under-specified prompts.