# Context7 Current-Documentation Discipline

- Before writing code against a third-party library, resolve its current docs
  for the version actually pinned in the project (package.json, lockfile,
  requirements.txt, go.mod) instead of relying on training-data memory.
- If a Context7 MCP server is available, use its two-step flow: resolve the
  library name to a library ID first (resolve-library-id), then fetch docs
  for that ID scoped to the topic at hand; prefer explicit /org/library IDs
  when known. The CLI equivalent is `ctx7 docs <libraryId> <query>`.
- Mention the concrete library version in doc queries; an answer valid for
  v4 may be wrong for v5.
- Never invent method names, config keys, import paths, or CLI flags. If live
  docs are unavailable and memory is uncertain, say so and verify against the
  installed package source in node_modules or site-packages before using it.
- When generated code fails with "is not a function", unknown-option, or
  missing-export errors on a library call, treat stale-API knowledge as the
  prime suspect and re-check current docs before patching around it.
- Prefer documentation retrieved at generation time over cached beliefs
  whenever the two conflict; the fetched, version-matched docs win.