convex-docs
プロジェクトに入っているフレームワークの実バージョンを固定し、「提供ドキュメントツール → ページの Markdown/固定版 README → 一般検索(未検証)」という新鮮度の階層で同版のドキュメントを取得し、必要なら node_modules の型定義まで確認してから API を書きます。未確認の API を記憶から書いてしまう事故と、バージョン不一致によるビルドエラーの調査時間を大きく減らせます。
npx skills add https://github.com/convex/agent-skills --skill convex-docsBefore / After 効果比較
1 组記憶から API を書くのが当たり前で、開発者はバージョン番号を手で確認し、複数ページのシグネチャを見比べ、それでも存在しないエクスポートや改名された引数を書いてしまい、ビルドエラーの後に出典を探し直す。1 回の確認に 20 分以上かかる。
この Skill はまず導入済みバージョンを固定し、新鮮度の階層に従って同版のページ Markdown か node_modules の型定義を取得し、正確なシグネチャと出典をそのまま執筆側へ渡す。確認は 20 分台から数分に短縮し、バージョン不一致のエラーはほぼ消える。
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
search_convex_docsis available, use it (it returns version-scoped, reranked answers sized to the context window); (b) else fetch the specific docs page as MARKDOWN — requestdocs.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.
ユーザーレビュー (0)
レビューを書く
レビューなし
統計データ
ユーザー評価
この Skill を評価