About sniper-check
sniper-check is a code-quality skill for checking a file, directory, or project after changes. It runs a six-phase workflow in an isolated context and returns only the final validation report.
Key features
- 01Six-phase code-quality workflow
- 02Parallel codebase and documentation research
- 03Grep-based impact analysis
- 04Linter checks and minimal fixes
- 05Final validation report only
Use cases
- 01Check a file after editing
- 02Validate a directory after refactoring
- 03Run a project-wide quality check
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ fusengine/ agents --skill sniper-checkAfter installing, type/sniper-checkin Claude Code to confirm it loaded.
Details
From the project README
Sniper Check runs the full sniper agent 6-phase code-quality workflow (parallel explore-codebase + research-expert, Grep-based impact analysis, linter error detection, minimal correction, re-verification to zero errors) in an isolated forked context, so only the final validation report returns to the parent conversation -- nothing of the investigation itself pollutes it. Use it after any code modification, on a specific file, a directory, or the whole project.
Target: $ARGUMENTS
Sniper Check
Overview
Quick code quality validation using the sniper agent in an isolated forked context. Executes the full 6-phase workflow without polluting the main conversation context.
| Feature | Detail |
|---|---|
| Context | Forked (isolated sub-agent) |
| Agent | sniper (Sonnet) |
| Phases | 6-phase code-quality workflow |
| Result | Only final report returns to parent |
When to Use
| Scenario | Use |
|---|---|
| After code modifications | /sniper-check src/ |
| Validate specific file | /sniper-check path/to/file.ts |
| Full project check | /sniper-check . |
| After refactoring | /sniper-check src/components/ |
Workflow
Execute the mandatory 6-phase code-quality workflow:
- PHASE 1+2 (PARALLEL): Launch both in parallel:
explore-codebase(Haiku) → Architecture discoveryresearch-expert(Sonnet) → Documentation verification
- PHASE 3: Grep all usages → Impact analysis
- PHASE 4: Run linters → Detect errors
- PHASE 5: Apply corrections → Minimal changes
- PHASE 6: Re-run linters → Zero errors
CRITICAL: Phases 1+2 must run in PARALLEL (two Task calls in one message).
Critical Rules
| Rule | Reason |
|---|---|
| Never skip phases 1+2 | Documentation-backed fixes only |
| Always run phases in order | Dependencies between phases |
| Zero linter errors | Non-negotiable exit criteria |
| Minimal changes only | Smallest fix necessary |
Report Format
Return a validation report with:
- Architecture summary (from explore-codebase)
- Documentation references (from research-expert)
- Impact analysis table (usages, risk level)
- Errors fixed (critical, high, medium, low)
- SOLID compliance status
- Final linter status (must be ZERO errors)
Comments
Markdown supported