Use these steps as a working checklist and adapt them to the project’s evidence, scope, and constraints.
Context and scope
- Read project instructions that apply to this tool, if present (for example, .cursor/rules or CLAUDE.md); also check the README and manifest when available.
- Before editing, summarize the current architecture and identify only the files the change needs.
- Define the goal as one verifiable outcome; do not expand the task without a reason.
- Before changing an API, identify its consumers, request/response shape, and compatibility needs.
Quality and safety
- For every user input, specify format, length, and unsafe-value validation.
- Never put secrets in code, logs, fixtures, examples, or shipped frontend assets.
- For search pages, check title, description, canonical, robots, headings, links, and source HTML.
- Keep each locale’s own copy, region-appropriate contact examples, and equivalent URLs.
- Make interactive elements keyboard-operable, named for assistive technology, and visibly focused.
Verification and reporting
- Run only checks that support the changed behavior; do not claim commands you did not run.
- Compare acceptance criteria with the result; inspect error paths and a mobile viewport.
- Report changes, commands and actual results, known limitations, and a rollback path.