Analyzed Aug 1, 2026
get-convex/agent-skills
convex-docs
Pull version-current Convex docs for the version this project uses — pin the installed version, fetch page-as-markdown or check node_modules types, freshness hierarchy — instead of writing a possibly-stale API from memory.
Installation
npx skills add get-convex/agent-skills --skill convex-docs
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Helps users discover and install agent skills when they ask questions like "how do I do X", "fi…
18.6K installsBrowser automation CLI for AI agents. Use when the user needs to interact with websites, includ…
11.9K installsReact and Next.js performance optimization guidelines from Vercel Engineering. This skill shoul…
3.7K installsReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "chec…
4.7K installsBuild, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and …
1.7K installsPrepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Te…
1.5K installsSecurity audits
Partner security reviews for this skill.
Analyzed Aug 1, 2026
Analyzed Aug 1, 2026
0 alerts
Also in this package
Other skills from get-convex/agent-skills · top by installs.
npx skills add get-convex/agent-skills
More details
Agent compatibility
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Repository health
main
Package contents
Files included with this skill beyond the listing page.
-
skill md
SKILL.md3,377 B -
docs
SUMMARY.md245 B
History
- First seen on skills.sh
- First recorded snapshot · 18,732 installs
SKILL.md
<!-- GENERATED from convex-agents content/capabilities/convex-docs.json — do not edit by hand. -->
Pull version-current Convex docs
convex-expert carries baked, plugin-versioned knowledge — excellent for stable idioms, but it goes stale exactly where it hurts: a component that gained a new export, a CLI flag that changed, an API renamed between versions. This capability is the freshness discipline layered on top: pin to the project's real version, fetch the live page cheaply as markdown, and never write an unfamiliar API from memory when the current source is one fetch away.
Workflow
- PIN the version: read the installed
convexversion (node -p "require('./node_modules/convex/package.json').version"orpackage.json), and the versions of any@convex-dev/*components in play. The docs you trust must match THESE versions — version skew is the single largest source of wrong Convex code. - FRESHNESS HIERARCHY (cheapest-correct first, the Supabase-taught order):
(a) if a served docs tool / MCP searchconvexdocs is available, use it (it returns version-scoped, reranked answers sized to the context window); (b) else fetch the specific docs page as MARKDOWN — request docs.convex.dev/<path> and prefer a .md/markdown form when the site serves one (far fewer tokens than HTML), or the component's README at the pinned version; (c) only then fall back to a general web search, and treat its version as unverified. Do NOT skip to writing the API from memory when currentness is in doubt.
- VERIFY against the installed package when it matters: for a component export you're unsure exists, check
node_modules/@convex-dev/<x>/(itspackage.jsonexports, its.d.ts) — the installed types are the ground truth for THIS version, more authoritative than any doc. - USE the fetched fact narrowly: apply the current signature/flag, cite where it came from (page + version), and hand the actual code back to convex-expert to write idiomatically. convex-docs supplies the fresh fact; convex-expert supplies the idiom.
- On a version-mismatch build error (an export/flag that 'should' exist but doesn't): treat it as a currentness question — pin the version, fetch the current API, and correct — rather than guessing a different spelling.
Rules
- Never write an unfamiliar or possibly-renamed Convex/component API from model memory when currentness is in doubt — pin the version and fetch the current source first.
- The installed package's own
exports/.d.tsin node_modules is the ground truth for this version — more authoritative than any doc page. - Follow the freshness hierarchy: served docs tool → page-as-markdown / pinned README → general web (unverified) — cheapest-correct first, fewest tokens.
- Prefer markdown over HTML doc pages — far fewer tokens for the same content.
- Supply the fresh FACT; hand idiomatic code back to convex-expert. This is a freshness layer, not a replacement for the baked knowledge.
- A version-mismatch build error is a currentness question, not a spelling guess — re-pin and re-fetch.