Treat release readiness as three different reviews
This original example concerns a community-event registration application accepting fork pull requests. The team wants a safer CI boundary, consistent frontend changes and a usable keyboard recovery path. No workflow was executed, security setting changed or conformance assessment completed for this article. Unverified incident statistics and testimonials from the source are not reproduced as facts.
Record source revision, workflow files, triggers, permissions, secrets, frontend conventions and the user journeys in scope. A syntax check, a successful CI run and an accessibility review answer different questions. Keep their evidence separate. A green pipeline cannot establish that an entire interface is usable or that every dependency is trustworthy.
Scenario one: inspect the Actions trust boundary
For every job, identify the event, code revision checked out, executable inputs, token permissions, secret access, artifacts and downstream consumers. Follow untrusted input through scripts and expressions. A pull_request_target trigger does not itself execute fork code; risk depends on what the workflow does with untrusted content under its available privileges. Explain the concrete boundary instead of labeling the event name alone as an exploit.
Separate untrusted contribution validation from privileged publishing. Do not let a successful-looking artifact automatically cross into a privileged job without checking its origin and intended use. Review third-party actions and immutable references, reusable workflow inputs and runner assumptions. Pinning helps identify code but does not make malicious or vulnerable code harmless.
Review the permissions actually required by each job and how credentials are persisted, passed and logged. Automatic masking is not a promise that every transformed value stays hidden. Use invalid fixtures to inspect report and log behavior. Do not print real secrets to test a redaction rule. Self-hosted runners and persistent state require their own assessment of isolation and cleanup.
zizmor is a documented public static-analysis reference for CI configurations, with an MIT license declared by its project. Evaluate its actual version, supported checks and integration mode before reuse. Static findings require triage, and an integration's exit behavior must be checked before assuming it blocks a merge. This article did not run it and does not present it as a verified SkillPI skill.
The deliverable is a scoped finding record with file references, input path, privilege boundary, evidence and proposed repair. A local static review can find issues before a cloud run but cannot establish that remote permissions, environments or runtime behavior are correct. Verify repairs in an appropriately authorized test environment and retain unexecuted checks as unknown.
Scenario two: apply written frontend conventions
Use the repository's actual naming, directory, component, formatting and commit rules. Distinguish a documented requirement from a reviewer preference. Inspect the existing package scripts and framework version before proposing commands. A generic checklist should not force a project-wide restructuring unrelated to a registration defect.
For the example, a failed registration must retain the user's entered information and expose a recoverable message. Review state handling, validation and request outcomes together. A style fix cannot compensate for a lost form state. Keep formatting changes separate enough that a reviewer can see the behavioral repair.
React Best Practices fits relevant implementation or performance review when the project uses React or Next.js. Provide source and actual build/test commands; performance conclusions need comparable measurements. It is not a workflow security scanner or a replacement for business-logic and authorization checks. Apply relevant rules rather than claiming a rule's example speed gain for this project.
Run existing checks appropriate to the changed files, review the final diff and investigate new dependency or configuration changes. If a convention is ambiguous, document the chosen local interpretation rather than silently claiming an enterprise standard required it. An unavailable build environment is a limitation, not a pass. Preserve a small reproducible fixture for the original defect. Repeating a generated checklist without inspecting code or behavior does not establish adherence.
Scenario three: evaluate accessible user paths
Define the target WCAG version and level as well as pages, states, devices and assistive technologies covered. Use W3C's criteria and explanations as the reference. Automated checks can identify some problems but do not establish complete conformance. Design review, code inspection and actual interaction provide different evidence.
Walk the registration task by keyboard: reach the form, identify labels, enter data, submit, understand errors, correct them and complete the task. Check visible focus, meaningful order and that a modal can be entered and exited appropriately. When an error appears, ensure its information is available without relying only on color or animation. A hidden button or an ARIA attribute alone is not proof of the intended experience.
Review contrast, resizing and content reflow in their relevant states. If time limits exist, inspect the applicable requirements and actual behavior rather than inventing a deadline. Screen-reader behavior needs an identified browser and assistive-technology combination. Record what was observed, what failed and what was not covered. Do not describe one local fixture as certification of an entire service.
Webapp Testing supports local browser paths when a running test site, startup command or address, authorized fixtures and the required Python/Playwright environment are available. It can help retain DOM observations, screenshots and diagnostic evidence. It does not by itself establish screen-reader compatibility or complete WCAG conformance. Keep assistive-technology observations and human assessment separately.
Retest the repaired path and a previously working path. Keep findings tied to criteria and evidence, with reproducible steps and the source revision. Accessibility work belongs throughout design and implementation, not only in a final release gate. A report should make remaining uncertainty visible rather than substituting a reassuring badge.
A bounded practical request
Ask the agent to map trust boundaries in the specified workflows, review the registration change against repository conventions and prepare keyboard success and recovery checks. Require file references and redacted evidence. Do not execute untrusted pull-request code with privileged credentials, modify production security settings or declare conformance from automated results alone. Request a minimal repair proposal before applying changes outside the authorized scope.
If a workflow parses but fails remotely, inspect environment and actual permissions. If a scanner exits successfully despite findings, inspect its integration mode. If lint passes but users lose input, inspect behavior. If keyboard focus disappears after an error, reproduce the state transition instead of only adding labels. If two instruction packages disagree, resolve the conflict against project requirements and host priorities; separate folders do not guarantee that skills cannot conflict.
FAQ, acceptance and sources
Does a small repository need this? Scope can be small while its trust boundaries still matter. Can static review replace a cloud run? It covers static information, not the complete environment. Are conventions subjective? Use written requirements and specific evidence while marking what is not agreed. Does a scan prove conformance? No; report the actual criteria and scope evaluated. Installation, execution and accepted results are separate checkpoints.
References are GitHub Actions secure-use documentation, W3C's WCAG 2.2 quick reference and the zizmor public project, with both original-language sources retained together. The linked skills cover React implementation review and local browser checks only. No original six-tool bundle is implied. Source review, static scanning and runtime observations remain distinct, and no executed scan, permission change or accessibility certification is claimed here.