Start with the review job—not the tool name
Code review includes several different decisions. A reviewer may need to understand what changed, identify security-sensitive paths, verify behavior, or collect reproducible evidence. Treating all four as one task creates noisy output and unclear ownership.
SkillSignal therefore recommends a small role-based stack. The core Skill explains the diff and its likely impact. A guardrail performs a targeted check with explicit limits. An evidence Skill runs the smallest relevant test or browser flow. The final approval remains with a human who understands the repository and release context.
Four useful Skills—and the boundary of each
differential-review is the strongest starting point when a pull request needs change-focused security reasoning. It prioritizes the diff and surrounding blast radius, but it cannot prove runtime safety or replace architecture knowledge.
Semgrep is useful for fast, rule-based checks and SARIF-compatible evidence. CodeQL goes deeper on interprocedural data flow when the language and database setup are supported. Both can miss issues outside their models, and both can produce findings that require triage.
webapp-testing adds browser-level evidence for local web applications. It can verify an explicit flow, but screenshots and passing steps do not prove every state, browser, accessibility path, or production dependency.
A four-step review stack that stays auditable
First, define the change boundary: target branch, expected behavior, sensitive files, and the decision the review must support. Second, inspect the diff before running broad automation so the guardrail can stay narrow. Third, run the smallest applicable static or behavioral check and preserve its command, scope, and output. Fourth, compare the evidence with the acceptance criteria and record unresolved risks instead of converting a tool result into automatic approval.
- The core review explains changed behavior and likely blast radius.
- Every automated check states its files, rules, language support, and exclusions.
- Behavioral evidence covers the changed flow, not an unrelated smoke test.
- A named reviewer owns the final decision and unresolved exceptions.
Native fit matters less than a reproducible boundary
A Skill may provide a native path for one Agent and a portable SKILL.md path for another. Portability can be valuable, but it is not evidence of equal testing, tool access, or permission behavior. Review the selected Agent's install path and required tools before treating two environments as equivalent.
For review work, reproducibility is the stronger selection signal: can another reviewer see the same source revision, run the same bounded check, and understand why a finding matters? If not, adding more Skills usually increases ambiguity rather than confidence.
Selection checklist
Choose the smallest combination that answers the current review question. Add another Skill only when it owns a distinct role and produces evidence the reviewer will actually use.
- What exact decision must the pull-request review support?
- Which files, commands, network calls, and external services can each Skill access?
- Is the upstream source pinned, and has the Skill been independently runtime-tested?
- What result would make the reviewer stop, escalate, or reject the change?