review-scope — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited review-scope (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.
Findings & checks · 0 flagged
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.
Determine the appropriate scope for code review based on change size.
Core principle: Major changes need broader review. Minor changes need focused review.
Question to answer: Is this a minor change or a major change?
Review only NEW code.
Indicators:
| Indicator | Example |
|---|---|
| Few files changed | 1-3 files |
| Isolated change | Single function modification |
| No API changes | Internal implementation only |
| No new dependencies | Uses existing code |
| Localized impact | Doesn't affect other modules |
Examples:
Review scope:
Review NEW code AND IMPACTED code.
Indicators:
| Indicator | Example |
|---|---|
| Many files changed | 4+ files |
| Cross-cutting change | Touches multiple modules |
| API changes | Public interface modified |
| New dependencies | Adds libraries or modules |
| Behavioral changes | Affects existing functionality |
| Architecture impact | Changes patterns or structure |
Examples:
Review scope:
┌─────────────────────────────────────┐
│ FILES CHANGED │
└─────────────────┬───────────────────┘
│
▼
┌─────────────────┐
│ > 3 files? │
└────────┬────────┘
│
┌─────────┴─────────┐
│ │
Yes No
│ │
▼ ▼
MAJOR ┌─────────────────┐
│ Public API │
│ changed? │
└────────┬────────┘
│
┌────────┴────────┐
│ │
Yes No
│ │
▼ ▼
MAJOR ┌─────────────────┐
│ Behavioral │
│ change? │
└────────┬────────┘
│
┌────────┴────────┐
│ │
Yes No
│ │
▼ ▼
MAJOR MINORFor major changes, identify impacted code:
# Find all files that import the changed module
grep -r "import.*from.*'./changed-module'" src/
# Find all usages of changed function
grep -r "changedFunction" src/# What does the changed code import?
grep "import" src/changed-file.ts
# Trace the dependency chainChanged function
│
├── Called by: parentFunction() ← Review this
│ │
│ └── Called by: grandparent() ← Review if behavior changed
│
└── Calls: childFunction() ← Review if inputs changed
│
└── Calls: database.save() ← Review if data shape changedBefore starting review, document scope:
## Review Scope: MINOR
**Changed files:**
- src/utils/format.ts (10 lines)
**Review focus:**
- New formatDate() function
- Associated tests
**Not reviewing:**
- Callers of format module (unchanged behavior)## Review Scope: MAJOR
**Changed files:**
- src/services/auth.ts
- src/middleware/authenticate.ts
- src/routes/login.ts
- src/models/session.ts
- tests/auth.test.ts
**Impacted code to review:**
- src/routes/protected/* (use auth middleware)
- src/services/user.ts (calls auth service)
**Integration points:**
- Login flow end-to-end
- Session management
- Protected route access
**Review focus:**
- All changed code
- All callers of auth service
- Auth middleware consumers
- Session handling throughoutAll of minor, PLUS:
If unsure whether change is minor or major:
Default to major. Better to over-review than miss issues.
Sometimes few lines have large impact:
// Small change, but MAJOR scope
// Changing default timeout affects all HTTP calls
const DEFAULT_TIMEOUT = 30000; // Was 5000Review all code affected by the changed behavior.
Many files changed but pure refactor:
// Renamed variable across 20 files
// No behavior changeStill MAJOR for structural review, but behavioral review is lighter.
This skill is called by:
issue-driven-development - Step 9comprehensive-review - Before starting reviewThis skill informs:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.