Is qa-review safe to install?

SaferSkills independently audited qa-review (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.claude/skills/qa-review/SKILL.md · 1 file

.claude/skills/qa-review/SKILL.md4.8 KB · Markdown

name: qa-review

description: Perform a thorough code review. Use when the user requests a review, wants to verify code quality, or before merging a PR.

context: fork

background: false

Code Review

Objective

Identify quality, security, and maintainability issues BEFORE merge.

Native features first

Claude Code ships a native `/code-review` that owns the review execution: effort levels from low to max, --fix to apply findings, --comment to post inline PR comments, and ultra for a multi-agent cloud review. Prefer it to run the review.

This skill's delta is the conventions the review is held to — the checklist below (incl. the substance-check.sh gate native review does not run), the naming tables, and the severity taxonomy. Use them to brief or grade a native /code-review run, or as the manual protocol where the native command is unavailable.

Instructions

1. Overview

# View the changes
git diff main...HEAD --stat
git log main...HEAD --oneline

2. Review checklist

#### Code quality

[ ] Readability (clear names, short functions)
[ ] DRY (no duplication)
[ ] SOLID (single responsibility)
[ ] Reasonable complexity
[ ] No over-engineering (YAGNI: no speculative options/abstraction; could a stdlib/native/one-liner replace custom code?)

#### Typing (TypeScript)

[ ] No any
[ ] Explicit types on public APIs
[ ] Well-defined interfaces

#### Tests

[ ] Tests present and relevant
[ ] Edge cases covered
[ ] Mocks limited to I/O
[ ] Substance: no hollow tests / stubs — run ./scripts/substance-check.sh <changed-files> (flags no-assertion / always-true / skipped / empty / stub; a green suite over hollow tests is not "done")

#### Security

[ ] Inputs validated
[ ] No hardcoded secrets
[ ] No injection possible

#### Performance

[ ] No N+1 queries
[ ] No possible infinite loops
[ ] Memory managed correctly

3. Comment format

[TYPE] file:line - comment

Types:
- [CRITICAL] - Blocking, must be fixed
- [IMPORTANT] - Should be fixed
- [SUGGESTION] - Optional improvement
- [QUESTION] - Clarification needed
- [NITPICK] - Minor detail

Expected output

## Review: [PR Title]

### Summary
- **Files modified**: X
- **Lines added**: +Y
- **Lines removed**: -Z
- **Verdict**: Approve / Request Changes / Comment

### Positive points
- [Point 1]
- [Point 2]

### Issues identified

#### Critical
- [CRITICAL] `file.ts:42` - Description

#### Important
- [IMPORTANT] `file.ts:87` - Description

### Suggestions
- [SUGGESTION] `file.ts:123` - Description

### Final checklist
- [ ] Code readable and maintainable
- [ ] Sufficient tests
- [ ] No security issue
- [ ] Acceptable performance

Naming analysis

Naming rules to verify

Element	Convention	Good examples	Bad examples
Variables	Descriptive, camelCase	`userCount`, `isActive`	`x`, `tmp`, `data`
Functions	Verb + noun, camelCase	`getUserById`, `validateEmail`	`process`, `handle`, `do`
Booleans	Prefix is/has/can/should	`isValid`, `hasPermission`	`valid`, `permission`
Constants	SCREAMING_SNAKE	`MAX_RETRY_COUNT`	`maxRetry`
Classes	PascalCase, noun	`UserService`, `OrderRepository`	`Manager`, `Helper`
Interfaces	PascalCase, descriptive	`UserProfile`, `PaymentMethod`	`IUser`, `DataType`

Naming smells to detect

Smell	Problem	Fix
Generic name	`data`, `result`, `temp`, `info`	Name based on content
Abbreviation	`usr`, `btn`, `msg`, `idx`	Write in full
Double negation	`!isNotValid`, `!disableButton`	`isValid`, `enableButton`
Type in the name	`userArray`, `nameString`	`users`, `name`
Inappropriate length	Short global variable, long local	Reverse: long global, short local
Misleading name	`getUser` that modifies	`fetchAndUpdateUser`

Patterns to look for

# Single-character variables (except i, j in loops)
\b[a-z]\b\s*[=:]

# Generic names
\b(data|result|temp|tmp|info|item|obj|val|res)\b\s*[=:]

# Booleans without prefix
\b(active|valid|visible|enabled|disabled|open|closed)\b\s*[=:]

Rules

Be constructive, not destructive
Explain the WHY
Propose alternatives
Distinguish blocking vs nice-to-have
Verify naming consistency in the code review

qa-review— agent skill

Is qa-review safe to install?

Code Review

Objective

Native features first

Instructions

1. Overview

2. Review checklist

3. Comment format

Expected output

Naming analysis

Naming rules to verify

Naming smells to detect

Patterns to look for

Rules

See also

Audit the pieces. Scan the whole. Decide.