Use when reviewing HTTP API design in a PR or change set — endpoints, routes, HTTP methods, status codes, idempotency, and input validation. Treats the API as a consumer-facing contract and flags resource-orientation, method-semantics, status-code, and trust-boundary violations. Read-only.
Use when checking that the pull request implementation actually fulfills the business requirements stated in the linked issue or task. Returns a plain-language markdown block that is the Functional review half of the two-part CR output (`@rules/code-review/general.mdc` Two-part CR output — Technical & Functional review): a full checklist of every extracted acceptance criterion with its status (Met / Not met / Partial / Divergent) and an explicit Goal met: Yes/No verdict, rendered on every run that has a linked tracker — including the fully affirmative report when every requirement is satisfied. No local file is created and the block is not embedded in the GitHub PR comment.
Use when run code review for a Bugsnag error and publish results to the linked GitHub PR and the Bugsnag error
Use when perform code review for GitHub pull requests and post findings as PR comments plus a non-technical summary to every linked issue
Use when run code review for JIRA issues and publish results to GitHub PR and JIRA
Use when senior PHP code review focused on architecture, business logic, and risk detection. Read-only.
Use when summarizing current PR changes for the development and product team. Analyzes all commits in the current branch, explains the purpose of changes, and produces a clear human-readable report that can be posted either as a GitHub PR comment (Markdown) or as a JIRA comment (Wiki Markup).
Use when a single objective is too large for one pull request and must span multiple sessions or PRs. Turns the objective into a sequenced construction plan of 3-12 one-PR steps, each with a cold-start context brief, dependency edges, and exit criteria, then reviews it adversarially and registers it as Markdown.