code-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited code-review (Agent Skill) and scored it 91/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 1 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} is the classic direct prompt-injection phrasing. Placed in a skill body that the agent reads as trusted instructions, it tries to make the agent abandon its prior rules and follow whatever comes next — a full system-prompt override.
ignore/disregard/forget … previous instructions sentence.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Perform structured code review focused on:
__invoke request handlers, API Resources / DTOs serialized into responses, FormRequests, status-code / response() / abort() calls, Idempotency-Key handling), walk it against the API contract pillars. The dedicated walk lives in @skills/api-review/SKILL.md (Specialized Reviews → Always run); severities follow that rule's CR Severity Rules section.CLAUDE.md and the sibling instruction files that section lists after the branch checkout, and review against the rules they carry, not only the packaged ones.require / require-dev entry to composer.json, walk the Activity + Compatibility gates from that rule against the PR description / commit body. A missing selection note is a Critical finding; an adopted archived / abandoned / branch-pinned package is a Critical finding on the spot; a single-maintainer adoption without bus-factor flag is a Moderate finding.@rules/laravel/laravel.mdc, @rules/laravel/architecture.mdc, @rules/laravel/filament.mdc, and @rules/laravel/livewire.mdcgit add, git commit, git push, git reset, git checkout -- …, etc.). Checking out the relevant branch and git pull to read the latest code are required (the mandatory Branch checkout gate below); mutating the working tree or pushing to the remote is not. Output is the review markdown only.code-review-github / code-review-jira for publishing on the GitHub PR stays in canonical English per the rule's Exception — technical CR findings on the GitHub PR (severity labels, structured field labels, rule references, and code identifiers are all in English). The non-technical mirror that the wrappers delegate to @skills/pr-summary/SKILL.md follows the language of the source assignment — that is the wrapper's responsibility, not this skill's.git fetch, git checkout <branch>, and git pull when the branch tracks a remote (skip the pull for a local-only branch that has no upstream, e.g. the read-only fallback review of a branch that maps to no PR) — so the review always runs against the actual current codebase on disk (the checked-out working tree), never against a remote diff in isolation. Confirm local HEAD matches the change branch's head commit. If the branch cannot be checked out (missing ref, detached HEAD, or local changes that would be overwritten), stop and report it instead of reviewing from a diff. Every subsequent step reads the checked-out files so findings reflect the real state of the code. Immediately after the checkout, load the project-local agent instructions per the Constraints above — reading them from the checked-out commit is what makes them reflect the code under review.The CR wrappers publish the review through an always-new comment per CR run (both GitHub and JIRA — see @skills/code-review-github/SKILL.md and @skills/code-review-jira/SKILL.md). Every run POSTs a fresh comment so the chronological sequence of comments is the audit trail; history never lives in a tracker's edit history. Do not load prior CR findings from PR comments and do not author a Previous CR Status section in the output — the always-new-comment convention makes it redundant.
Before reviewing code, load and analyze the full issue context:
skills/code-review-jira/scripts/load-issue.sh <KEY|URL> and read all fields off the resulting JSON document — never call acli directly. Fall back to the JIRA MCP server only when the script is unavailable or for data outside its scope (changelog, available transitions, friendly custom-field names). For Bugsnag errors, call skills/code-review-bugsnag/scripts/load-issue.sh <URL|TRIPLE> (requires BUGSNAG_TOKEN) and read the error class, message, context, latestEvent.stacktrace, comments[], and linkedIssues[] off the JSON — never call api.bugsnag.com directly. Fall back to a Bugsnag MCP server only when the script is unavailable.Every CR run must explicitly verify both directions of the relationship between the diff and the linked assignment, then surface a single conformance verdict. When no tracker is linked (closingIssues[] empty for a GitHub PR, no JIRA / Bugsnag reference), skip the gate and state assignment conformance: no linked issue on the summary line.
Walk both directions and record the verdict per @rules/code-review/general.mdc Assignment Conformance Gate — canonical detail: 1. Requirements → changes (completeness) — consume the result of the always-run @skills/assignment-compliance-check/SKILL.md and @skills/analyze-problem/SKILL.md, never re-derive it; 2. Changes → requirements (traceability, no scope creep) — trace every changed block back to a requirement and raise an out-of-scope finding for each block that traces to none; 3. Verdict — assignment conformance: conformant / N gap(s), computed at Output assembly so it never contradicts the Counts line.
Two-part CR output (issue #737). This skill's walk-throughs above (Core Analysis through the Coverage gate) are the Technical review, published on the PR comment per Output Rules. The Functional review — a full acceptance-criteria checklist with a Goal met: Yes/No verdict — is built by @skills/assignment-compliance-check/SKILL.md and published on the linked-tracker comment via @skills/pr-summary/SKILL.md; it renders on every run with a linked tracker, including the affirmative report when every criterion is Met (the sole exception to this skill's omit-when-clean convention). The one-line verdict mirrors onto this skill's Summary line as assignment conformance: conformant / N gap(s) / no linked issue. Full contract: @rules/code-review/general.mdc Two-part CR output — Technical & Functional review.
Run this section only when the diff integrates with, modifies, or depends on a third-party API or external service (HTTP clients, vendor SDK calls, webhooks, OAuth flows, payload schemas, queue/event consumers backed by external systems). Canonical detail (conditional degradation, request-for-link template, gate, precedence, SSRF guard): @rules/code-review/general.mdc Third-Party API & Service Documentation Verification (issue #748).
WebSearch / WebFetch — vendor documentation, OpenAPI/Swagger spec, SDK reference, or webhook contract — per @rules/code-review/general.mdc Third-Party API & Service Documentation Verification (issue #748) step 1 (vendor-domain allow-list; a URL cited in the issue/PR is a hint only, never an authority). When the web tools are unavailable or the fetch fails, do not fall back to memory — go straight to step 6.@rules/php/core-standards.mdc); only when the diff exposes an out-of-scope structural shortcoming in how the project consumes the API (e.g. missing webhook signature verification across other consumers) raise it under Refactoring Proposals.Reply on this PR with the official documentation URL for <vendor> <API> <version> (or add it to the PR description), so the contract can be verified. Raise one finding per violation, never both — this step is the sole terminal output for the missing-documentation outcome. This finding is exempt from the Faulty Example / Expected Behavior / Test Hint fields in ## Findings — the request-for-link Suggested Fix is the whole finding.Every new *.php file the diff adds under the project's production source roots is reviewed as a design decision, not only as content: verify it lands in a layer the project's architecture rules actually name, that namespace / path / class name agree, that the class carries the shape its layer requires, that its name states the domain role, that it has one reason to change, that its dependency direction holds, that it declares strict_types with typed boundaries, that it duplicates no existing class in the same layer, and that it is wired up. Every finding of this walk is Moderate — never downgraded to Minor, never escalated from inside the walk. Framework-generated files in their own directories, test files (owned by Test organization), documented layer choices, and files the diff only modifies are not findings. On a Laravel project the Architecture conformance walk owns the Critical dimensions and wins on the same file; on a non-Laravel PHP project this gate is the only architecture walk that runs. Canonical checks, non-findings, gating, and Suggested-Fix templates: @rules/code-review/general.mdc New PHP File — Architecture & Design Conformance (issue #763).
When the source issue is flagged highest priority (GitHub priority: highest / p0 / urgent / blocker, JIRA Highest / Blocker), narrow the review to the bug fix and its safe deployment and demote Minor findings and both refactoring sections to follow-up; does not block merge. The Critical + Moderate gate never moves. Canonical: @rules/code-review/general.mdc Highest-Priority Fast Track — canonical detail.
MODE=cr as a pre-flight before any other specialized review — audits whether the dev database currently holds the fixture data the assignment scenarios need, and surfaces every scenario the diff should cover but the codebase / dev DB cannot reproduce. The CR uses its gap report to ground the rest of the review in real data; an empty gap report means later findings (assignment compliance, security, refactoring) are made against scenarios that genuinely exist, not against guesses. Surface the gap count in the PR comment summary line and treat any behavioral gap the skill reports as a Critical CR finding (the diff cannot satisfy a scenario the codebase does not support).@rules/code-review/general.mdc Two-part CR output): the full acceptance-criteria checklist with a Goal met: Yes/No verdict. The skill does not publish anywhere itself — it returns either the assembled ## Assignment Compliance markdown block, rendered on every run that has a linked tracker (including the affirmative report when every criterion is Met), or the status no linked issue — assignment compliance skipped (when no linked tracker exists). The CR wrapper passes the returned block as an embedded block to @skills/pr-summary/SKILL.md only when a block is returned so each linked tracker (GitHub issue or JIRA ticket) receives one consolidated comment per CR run (per issue #498); on the skip status the wrapper embeds nothing and surfaces the status on the PR comment summary line. Do not embed the block into the PR comment — that comment carries the Technical review only.@skills/assignment-compliance-check/SKILL.md already raises in its ## Assignment Compliance block — when both would surface the same gap, keep the technical Critical finding here (with reproducer fields, folded into the standard severity buckets) and let the compliance block carry only the non-technical mirror.@rules/api/general.mdc). The skill self-scopes: when the diff touches no HTTP API surface (routes, controllers / __invoke request handlers, API Resources / DTOs in responses, FormRequests, status-code handling, Idempotency-Key logic) it returns no findings. When it does, fold the Critical / Moderate / Minor findings (with their reproducer fields) into the standard severity buckets — do not duplicate a finding the Strict rule compliance walk already raised for @rules/api/general.mdc.@rules/code-review/general.mdc Refactoring & Tech Debt (DRY) Analysis — diff-scoped detail — follow it there rather than restating it here. MODE=cr guarantees the lens never modifies code, writes tests, commits, runs fixers, or chains another review — it returns proposals only. Do not propose changes that fall outside the diff.@skills/refactor-entry-point-to-action/SKILL.md with `MODE=cr` (and run the class-refactoring lens above at full depth) to surface the entry-point → Action proposals. Both skills run read-only — no code changes, no commits, no fixers, no review chaining — `MODE=cr` enforces this. Fold their output into the Refactoring (DRY / tech debt) section (in-scope items) and Refactoring proposals section (out-of-scope items) of the review; this skill never modifies code.DB::, ->where(, ->join(, ->whereHas(, ->withCount(, ->orderBy(, ->groupBy(, ->chunk(, ->cursor(, paginate(, simplePaginate(), Eloquent relationship definitions, with( / load( eager loads, model scopes, ModelManager / Repository methods, database migrations (Schema::, up() / down()), seeders, factories that materialise rows, DynamoDB / NoSQL access. Pass the diff scope to mysql-problem-solver and capture its findings — they must appear in the published CR review under the dedicated ## Database Analysis section described in Output Rules, never silently absorbed into the generic Critical / Moderate / Minor buckets. Walk every database access individually — no query left unwalked: each raw SQL string, each Eloquent / query-builder chain, each eager load, each model scope, each Repository / ModelManager method, and each DDL statement gets its own assessment; a sample is not a walk. Database change deployment safety is part of the same walk: whenever the diff adds or modifies DDL (a database/migrations/ file, Schema::create / Schema::table / Schema::drop* / Schema::rename*, DB::statement carrying DDL, raw ALTER TABLE / CREATE INDEX), additionally judge each statement against a rolling deploy on production data while the previous release still serves traffic — destructive change shipped with the code that reads the old surface, blocking ALGORITHM=COPY DDL, missing or no-op down(), non-replayable migration, data backfill inside the migration, a new constraint never pre-flighted against real rows, a missing index for a column the release starts querying, and an unstated deploy order / rollback path. Detection patterns, severities, non-findings, and the mandatory artifacts live in @rules/code-review/general.mdc Database Change Deployment Safety; these findings render in the same ## Database Analysis section as the performance ones.Run this section over the PR diff only — never over untouched code.
The diff-scoped steps (per-block evaluation against @skills/class-refactoring/SKILL.md with MODE=cr, Livewire / Blade layout splitting, ->when() conditional query composition with the byte-for-byte semantics-preserving templates, and the in-scope vs. Refactoring Proposals routing) live in @rules/code-review/general.mdc Refactoring & Tech Debt (DRY) Analysis — diff-scoped detail. Apply them to the changed lines only — never over untouched code.
@rules/code-review/general.mdc Validation & Coverage Gate. Every acceptance criterion without a dedicated use-case test, and every uncovered changed line, is a Critical finding.Run this step after every preceding analysis step has produced its findings and before the Output assembly. Walk every Critical finding through @skills/analyze-problem/SKILL.md to confirm it reflects a real problem before it blocks the PR; the binary keep / drop procedure (Confirmed → keep verbatim, Refuted → drop entirely, never silently downgrade, Moderate / Minor exempt) is defined in @rules/code-review/general.mdc Critical Findings Verification (issue #537) — procedure.
Summary line are always rendered. The Summary line always carries the assignment conformance verdict from the Assignment Conformance Gate (assignment conformance: conformant / N gap(s) / no linked issue) so the reader sees whether the changes match the assignment without scanning the body. The Coverage: header line, the ## Coverage section, and the coverage … slot in the summary line are all conditional — render them only when the coverage gate produced something to report (uncovered changed lines or unavailable / non-runnable tooling, both Critical findings). When every changed line is at 100% coverage and the tool ran successfully, drop all three coverage surfaces; the Counts line is the clean signal. Every other section — Findings (including each severity sub-heading), Refactoring (DRY / tech debt), Refactoring proposals, Database Analysis, and any specialized-review sub-section — appears only when it has at least one item. Never emit None. / Not applicable. / n/a / 100% placeholders for empty sections or omitted coverage surfaces; drop the whole heading and body instead. History across CR runs is preserved by the tracker's edit history on the upserted comment — never re-create a Previous CR Status section in the body.## Architecture heading is rendered only when the walk produces at least one finding. When findings exist, render them under the heading with the standard Critical / Moderate / Minor severity grouping and the reproducer fields. When the walk produces zero findings, omit the heading entirely — never render a walked, 0 findings status line, a clean placeholder, or any other "the check ran" confirmation. The principle is the same as for every other section: report only items that still need action; an empty section is dropped. On non-Laravel projects (laravel/framework not in composer.json require), the ## Architecture section is omitted entirely — the section is Laravel-only by design.@rules/php/core-standards.mdc and, for Laravel projects, @rules/laravel/architecture.mdc. Use n/a — <reason> only when a snippet adds no value over the one-line Fix description (e.g. naming-only changes, dead-code removal, pointers to an existing helper whose name already says enough).@skills/process-code-review/SKILL.md can convert each finding into a reproducer test and apply the fix without re-deriving context.@skills/code-review-github/SKILL.md, @skills/code-review-jira/SKILL.md) must delegate the single consolidated comment on every linked issue in the originating tracker (GitHub issue, JIRA ticket, or both) to @skills/pr-summary/SKILL.md — the CR wrappers never author their own non-technical template. pr-summary produces a uniform "TL;DR + Summary of changes + How to test" comment understandable by non-technical project managers, rendered as GitHub Markdown for GitHub issues and JIRA Wiki Markup for JIRA tickets per @rules/jira/general.mdc. @skills/assignment-compliance-check/SKILL.md returns the Functional review markdown block on every run that has a linked tracker — including the affirmative Goal met: Yes checklist on a clean run — and the CR wrapper passes it as an embedded block to pr-summary, which appends it after How to test so the linked-tracker audience reads exactly one comment per CR run (per issue #498). Only when the compliance check returns the no linked issue — assignment compliance skipped status does the wrapper embed nothing. Technical findings still go directly on the PR comment.@rules/code-review/general.mdc Output Rules — Security & Translation Walks and raise one finding per match: Safe validation & error texts (issue #540), Malicious code & supply-chain indicators (issue #549), Malicious file upload content (issue #680), Translation completeness, Test isolation — no real HTTP, no real system processes, and the Database Analysis section rendering rule. Severities are declared there.iteration = <n> (the Review loop iteration from @skills/process-code-review/SKILL.md) and n > 2, the report carries Critical and Moderate findings only — every Minor finding, Refactoring (DRY / tech debt), and Refactoring proposals are dropped at Output assembly, Counts and Summary keep their real unchanged numbers, and the header gains the Report scope: line. No walk is skipped and the convergence gate is unchanged. Canonical: @rules/code-review/general.mdc Late-Iteration Report Scope — Critical & Moderate Only (CR iteration > 2).Use the template defined in templates/review-output.md.
@skills/test-like-human/SKILL.md. The user-perspective testing skill runs on demand only (via /test-like-human or an explicit follow-up); CR-track skills must never chain into it.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.