project-guide-validation

Guide Validation

This protocol defines the process for an AI agent to validate the technical accuracy, framework nuances, and evaluation readiness of web guidance. It ensures that guidance is not only correct according to documentation but also robust in practice across different framework reactivity models and target environments.

Validation Checklist

When assigned to validate a guide, create a task list artifact based on this checklist and complete each phase:

• 1. Familiarization
• 2. Best Practices & Accessibility Review
• 3. Expectation Alignment
• 4. Testing and Verification with DevTools MCP (Includes starting server)
• 5. Manual Verification (Only if automated tests pass)
• 6. Feedback Report

---

1. Familiarization

Before performing any verification, read the guide.md file in its entirety:

• Understand the Problem: Identify the core issue the guide is addressing (e.g., reactive state drift, layout shift, performance bottleneck).
• Identify the Solution: Understand the recommended API, property, or architectural approach (e.g., Temporal API, container queries, scheduler.yield).
• Contextualize: Get familiar with the overall structure and flow of the guidance before checking external sources or running tests.

2. Qualitative & Best Practices Review

Critically evaluate the guide's content to ensure it follows established best practices and does not introduce anti-patterns:

• Discipline-Specific Skills: Check if there are finalized "production ready" skill files for the relevant discipline located at guides/<discipline>/skill.md. If they exist, ensure the guide complies with them.
• Accessibility (A11y): Accessibility is a distinct concern that MUST always be evaluated. The canonical reference is guides/accessibility/accessibility/guide.md. Read it first, then apply it as follows:
  • guide.md under review: MUST adhere to every applicable best practice across all sections of the canonical guide (landmarks/headings, ARIA roles, names/descriptions, focus management, keyboard navigation, alt text and SVG treatment, hints and validation, live regions, non-color state indicators, reduced motion, dialog/overlay semantics, and visibility hiding decisions). Recommendations and code samples must not contradict the canonical guide. Pay particular attention to copy-paste safety (code examples must embed the rules they mention, e.g. prefers-reduced-motion, :focus-visible, aria-hidden), multi-indicator state communication, AT-tree synchronization with visibility changes, and post-transition focus management.
  • demo.html under review: NOT held to general a11y best practices — only required to faithfully demonstrate the patterns the guide.md prescribes. If the guide mandates a specific a11y pattern (e.g., aria-live="polite" on toasts, aria-pressed on a toggle, prefers-reduced-motion in CSS), the demo MUST show it. Do not flag demos for missing a11y features that the guide does not call out.
  • expectations.md under review: SHOULD encode the a11y patterns that the guide prescribes as testable expectations, but MUST NOT include prose-only or manual-verification-only requirements that the grader cannot assert.
• Avoid Gating Critical Content: Verify that the guide does not recommend interactive reveal patterns (e.g., following the cursor) that are inaccessible to non-pointer users. Ensure accessible alternatives are provided if such patterns are discussed.
• Internal Consistency: Ensure no deviations from existing skills or established patterns in the project.
• Copy-Paste Safety: Ensure that code examples are complete and safe to copy. If the text recommends a fallback or a constraint (like reduced motion), the code example MUST implement it.