Use Web Design Guidelines by Vercel Labs to review interface source files against its current Web Interface Guidelines. Give your agent a page or component to inspect, identify issues in interaction and accessibility, and receive findings tied to file and line locations for focused follow-up.
Choose a page or interaction that needs a focused interface review. Ask for findings tied to code and observed behavior, distinguishing keyboard access, control semantics, and feedback before deciding which repairs belong in the implementation scope.
Provide files and the interactions to check, such as keyboard input or form errors.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Web Design Guidelines https://github.com/vercel-labs/agent-skills/blob/main/skills/web-design-guidelines/SKILL.md Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Review the checkout form components against current web interface guidelines. Report only actionable file:line findings. Expected deliverable: Actionable file-and-line findings, with the affected interaction and expected behavior.
Web Design Guidelines is a review Skill published by Vercel Labs for checking UI source files against Web Interface Guidelines. Its workflow first retrieves the current rules, then reads the files or patterns named by the user and reports located findings. This makes it useful for reviewing a page or shared component before release, especially when you need issues that can be traced back to implementation. The Skill is a review entry point; the guideline document is maintained separately and should be fetched for each review. Source findings should be checked against the rendered interface, with keyboard and assistive-technology testing added where the task requires it.
Keyboard navigation, inconsistent controls, and release reviews expose different interface problems. See how Web Design Guidelines connects interaction behavior with source locations so findings can guide specific repairs and representative checks after implementation.
A form that is hard to use by keyboard needs its actual focus path and validation failures inspected in code. Review labels, focus states, error messages, and keyboard handlers together. Tie findings to files and lines so the repair addresses the navigation problem rather than just changing the form's appearance.
Similar controls can look aligned while behaving inconsistently. Compare active and navigation states, touch targets, feedback, and interaction semantics across their implementations. Group findings by behavior and recommend how to align them so the review addresses what users can do, not visual taste alone.
A pre-release UI review should be bounded by the new page's diff, shared components, and acceptance interactions. Map each finding to the relevant code owner, then check representative interactions after fixes. This keeps the review actionable without silently turning one page's release into a redesign of unrelated screens.
A page needs to explain what is happening when data is delayed, absent, or cannot be submitted. Inspect the relevant states and controls in both code and the rendered interface, checking whether feedback leads to a useful next action. Report concrete locations and behavior instead of prescribing decorative changes that do not address the user's uncertainty.
A web-interface review needs selected files and a concrete user flow. Apply the current guidelines within that scope, inspect reported locations in the rendered page, and choose repairs only after confirming the behavior that the finding describes.
Provide page or component paths and describe the interaction to review. Include shared components that affect the selected flow.
Ask the agent to fetch the latest Web Interface Guidelines and inspect the named files. Request findings with file and line locations.
Match findings to the rendered UI before editing. Test relevant keyboard, focus, and form behavior after changes.
Read another Skill guide and check its original source before using it.
