Connect the rulebook to changes and user journeys
A fictional neighborhood book exchange is rebuilding its reservation page. A reader chooses a pickup slot, enters contact details and submits through a confirmation dialog. The team maintains React components, TypeScript types and older styles, while conventions live in documents and informal conversations. Formatting can pass even when a change permits duplicate reservations or leaves a keyboard user trapped in the dialog. The useful solution has three evidence layers: executable team conventions, a change-based review, and accessibility checks in real interface states. Record the revision, comparison baseline, page entry point, startup procedure, fixtures and applicable rulebook version. This is an operating method, not a claim that a reader's repository has been tested. Installing a skill does not automatically register a commit hook. Every check needs an explicit integration point, an execution environment and a meaningful failure state.
Scenario one: make standards testable and scoped
Start with import boundaries, export conventions, type requirements, file placement and ownership of component state. For every rule, record an identifier, rationale, applicable directories, positive and negative examples, detection method and exception owner. For example, internal reservation modules may be imported only through their public entry point. A useful counterexample identifies an actual forbidden path rather than saying that architecture is bad. Baseline legacy debt and agree how changed code will converge, instead of charging the author of a small PR for every existing violation. Reuse the project's ESLint, TypeScript and formatting configuration first. Inspect package scripts, lockfiles and workspace layout to establish whether the command covers the target files. ESLint supports configurable rules and plugins; it is inaccurate to declare that it can never detect accessibility or structural concerns. Its actual coverage depends on configuration. Separate formatting, type checking and review responsibilities so the same observation does not appear as three independent defects. Run check-only mode initially. Preserve the command, version, exit status, file locations and diagnostic output. Before applying automatic fixes, explain the proposed file scope and confirm a recoverable baseline for existing work. Review the diff and rerun affected checks afterward. A successful formatter is not evidence that behavior remains correct. Treat generated files, vendored code and fixtures according to their purpose rather than hiding broad directories to make the report look clean. For React or Next projects, React Best Practices fits the component implementation and performance-pattern review step. Its public listing and pinned Vercel source have been checked; the license is MIT. Establish the framework and code context first, and honor explicit business constraints. This skill is not the team's complete rulebook. It does not prove reservation correctness, security or comprehensive accessibility, and performance recommendations still need measurement. Deliver a rule-to-check mapping and an execution record. Identify rules covered by tools, rules covered by review and rules with no implemented check. Give exceptions a scope, reason and review date. When conventions change, update their fixtures as well as the prose so the documented and executable policies do not diverge.
Scenario two: follow the diff into behavior
Confirm the real PR baseline and list affected files and callers. Include deletions, renames, exported types, configuration and dependencies. Looking only at added lines can miss removed validation and broken consumers. In the book exchange, the submit button may change by only a few lines, yet moving request state into a shared module changes the risks around repeated clicks, cancellation and navigation. Review correctness, types and error handling, structure and dependencies, styling and responsive behavior, tests and accessibility. Correctness starts with the product contract: the server confirms remaining capacity; disabling a client button is only an interaction measure. After a network timeout, distinguish an unknown outcome from a confirmed failure. Prompting an immediate retry without considering duplicate writes can introduce a new defect. Type checking catches some inconsistencies, not every contract or runtime data problem. Each finding needs a file location, reproduction condition, expected and observed behavior, impact, evidence and the smallest useful correction. Separate confirmed defects, hypotheses needing validation and optional style suggestions. Explain severity through user impact and reachable paths. When a server contract is missing, state the gap instead of fabricating a test to complete the checklist. Human reviewers remain responsible for critical business decisions and unresolved uncertainty; they should also sample lower-severity results instead of reading only two severity labels. For the dialog repair, propose regression cases: repeated activation creates only one effective reservation; an error preserves entered fields; cancellation does not produce a delayed success notification; reloading reflects the server's actual state. Identify which cases belong in component tests, which require API evidence and which need browser interaction. The deliverable is a reviewable findings register, a proposed patch and regression evidence. Producing a Markdown file alone is not completion of review.
Scenario three: test accessibility in meaningful states
Agree on a target standard, page scope and browser and assistive-technology combinations. This example uses the WCAG 2.2 quick reference to organize checks; it makes no legal compliance determination. The open source axe-core engine is a candidate for automated web checks, with documented rules and MPL-2.0 licensing. Evaluate rule fit, documentation and integration cost rather than popularity. Check the chosen version, dependencies and page-data scope before installing or running an integration. Do not scan just the initial viewport. Prepare an empty form, a selected slot, a validation error, an open confirmation dialog, a pending request and a success state. Record engine and rules configuration, browser, URL, preparation steps and results. Keep items requiring manual judgment separate from passes. Regex inspection can identify certain source patterns but cannot establish operability in the rendered interface. Automated scans do not establish complete WCAG conformance. Follow the keyboard route from the page entry through the form. Check reachability, visible focus and a sensible order. When the dialog opens, inspect initial focus, interaction boundaries, closing behavior and return to the trigger. Errors should have understandable text and a connection to the relevant field; color alone is insufficient feedback. Preserve input after submission failures and explain the next action. If reservation confirmation has a time limit, assess adjustment, extension or removal against the applicable criteria and business exceptions. Do not reduce the needs of an entire group of users to a single timing-tolerance slogan. Webapp Testing fits repeatable local browser journeys. Its pinned Anthropic source and Apache-2.0 license have been checked. It supports Python Playwright observation, interaction, screenshots and logs for a running local application. Prerequisites include startup command, port, approved test accounts and non-sensitive fixtures. It can help repeat keyboard paths, but it does not supply a comprehensive screen-reader assessment, prove backend persistence or establish legal compliance. Do not assume axe-core is already integrated into its package; record any additional integration separately. Deliver the state inventory, automated results, manual journey notes and retest evidence. Arrange user research appropriately when needed instead of substituting robot results for experience. After repairing a label, verify that its name is accurate. Adding ARIA cannot rescue a fundamentally incorrect interaction model.
A practical request and an honest integration
Ask: “Review the book-reservation PR against the current rulebook. List the comparison baseline and rule mapping before proposing changes. Separate static diagnostics, business risks and keyboard journeys. Attach evidence and unverified limits to every finding. Do not update dependencies, register hooks or change remote merge protections as an incidental part of review.” Start with read-only inspection, then agree on a small patch and relevant tests. Before enforcing commit checks, measure execution time and false positives in an agreed environment. Test a compliant fixture, a known violation and a tool-startup failure. Missing dependencies must not be reported as zero violations. Local hooks can be bypassed; whether CI is mandatory depends on actual repository rules. Incremental checks offer quick feedback, but shared configuration, deleted code and cross-module changes can require broader scope. Assign an owner to scheduled full reviews so the system does not merely generate unread reports.
FAQ and troubleshooting
Why use a skill when the standards document exists? Only use it when a repeatable task and a suitable method justify it. Make the rule testable first; a skill can help organize execution but does not automatically create the integration. What does review add to ESLint? Configured static checks cover only part of the problem. Product contracts, actual interaction and uncertain paths still require evidence. If the team cannot write custom rules, start with a few explicit examples and existing configuration rather than promising universal out-of-box enforcement. Why did the number of checks suddenly fall? Inspect file matching, working directory, cache, ignore entries and the comparison baseline. Record environment changes before diagnosing coverage. Why are findings difficult to reproduce? Require a minimal path and applicable rule; finding counts are not a measure of review quality. Is accessibility only for international or compliance teams? Keyboard access, understandable feedback and recoverable input affect ordinary use. Specific legal obligations require separate evaluation for the relevant project and jurisdiction. How often should skill associations change? Revisit public listings, pinned sources, licensing and step-specific scope as the catalog changes, and record review dates and removals. Similar names and rising install counts do not establish suitability. If discovery is needed, verify the official SkillPI Skill Finder source and installation prerequisites before selecting a package for the current step. Do not automatically install an unexplained bundle of tools.
Sources and acceptance boundary
Both originals cover standards enforcement, pre-merge review, accessibility and FAQ; those scenarios remain distinct here with original operating details. References include ESLint official documentation, the axe-core upstream project, the W3C WCAG quick reference and both linked skills' pinned packages. Anonymous anecdotes, popularity figures and unverified timing guarantees are omitted. Acceptance means traceable rules, reproducible findings, repeatable interface paths and explicit unexecuted checks. “An agent reviewed it” is not a quality certificate.