check-latest-framework-docs

name

check-latest-framework-docs

description

Verify the latest official framework documentation before implementing or modifying features. Use when requests involve framework or library behavior, new feature implementation, upgrades, deprecations, API usage, or configuration changes where outdated guidance could cause regressions. Do NOT use for trivial CSS changes, general algorithm questions, or when the user explicitly states they have already checked docs.

Check Latest Framework Docs

Overview

Force a web documentation check before writing framework-related code. Prefer official documentation and release notes, then implement only after confirming the latest relevant guidance.

Trigger Examples

• "Add React Server Components to our Next.js app"
• "Upgrade Playwright from v1.40 to v1.50"
• "Use the new defineRouting API in next-intl"
• "Switch from pages/ to app/ router in Next.js"
• "Add Vitest coverage support — is c8 still the default?"
• Any request involving a framework API, config change, or version migration

Do NOT Trigger

• Trivial styling or CSS-only changes
• General algorithm or data-structure questions
• User explicitly confirms they already checked the docs
• Pure business logic with no framework dependency

Workflow

1. Detect Framework and Local Version

• Inspect repository manifests (package.json, lockfiles, pyproject.toml, go.mod, etc.) to identify the framework and installed version.
• If local version cannot be determined, state that explicitly and proceed with latest stable documentation plus official release notes.

2. Verify Current Documentation on the Web

• Search strategy:
  • Start with <framework> <feature> site:<official-docs-domain> (e.g., playwright locator site:playwright.dev).
  • Follow up with <framework> <version> changelog or <framework> <version> release notes when versions differ.
  • Open the actual pages — do not rely on search snippets alone.
• Confirm the exact API/reference pages relevant to the requested feature.
• Check official changelog or release notes for deprecations and breaking changes between local and latest versions.
• Capture concrete dates when asserting "latest" behavior.

3. Validate Source Quality

• Source priority:
  1. Official docs and official release notes/changelog.
  2. Official maintainer blog posts, RFCs, or migration guides.
  3. Reputable ecosystem references only when official docs are silent.
• Do not use random tutorials as primary authority for implementation decisions.

4. Gate Implementation

• Do not implement until both checks are done:
  1. At least one official API/reference page for the target feature.
  2. At least one official release-note or changelog source when versions differ or behavior is unclear.
• Fallback: After 3 failed search attempts, report what was found and proceed with best available knowledge, clearly flagging all unverified assumptions.
• If web verification is completely unavailable, stop and report the blocker instead of guessing.

5. Apply and Report

• Implement using the verified guidance.
• Use the full report format for upgrades, migrations, or when version mismatches exist.
• Use the abbreviated format for straightforward lookups where versions match and no deprecations apply.

Response Templates

Full Format (upgrades, migrations, version mismatches)