ubs
Made by JeffRun Ultimate Bug Scanner (UBS) for code review. Use when reviewing code, checking for bugs, scanning for security issues, validating AI-generated code, or pre-commit quality checks.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
1Updates, enhancements, and release notes for this skill.
New: UBS, bug-scan staged files in under a second before every commit
Run UBS on what you're about to commit; exit 0 means safe to proceed, exit 1 means triage findings, exit 2 means run ubs doctor --fix. The scanner catches what compiles but crashes: null derefs, missed await, leaked file handles, prototype pollution, SQL string concatenation, swallowed exceptions. False positives exist, so triage is part of the loop. 14 finding categories, per-language ignore syntax with mandatory justification, baseline-comparison mode for PR review.
- ubs --staged scans only staged files in under a second; exit 0 = safe to commit, 1 = triage findings, 2 = run ubs doctor --fix. A pre-commit reflex, not a weekly chore
- 14 finding categories in three tiers: 1-5 (null safety, security, missing await, leaks, type coercion) block the commit; 6-10 (division by zero, resource lifecycle, error swallowing, promise-no-catch, array mutation) block the merge; 11-14 are addressed or justified. Numbers map to --skip=N
- Triage flowchart: does the code path execute (no → false positive)? Is there a guard clause (yes → false positive)? Is it validated elsewhere (yes → false positive)? Otherwise it's a real bug; fix the root cause
- Per-language ignore syntax with mandatory justification: // ubs:ignore — <reason> (JS/TS/Go/Rust/Java), # ubs:ignore — <reason> (Python/Ruby/Shell), -- ubs:ignore — <reason> (SQL). Every ignore must say why the code is safe
- --comparison=baseline.json shows only NEW findings against a pinned baseline, so PR review covers what the PR introduced, not what the repo already had
- Output formats: --format=jsonl for per-finding details, --format=sarif for IDE and GitHub Code Scanning integration, --html-report=out.html for shareable dashboards
- AI code validation: after the AI writes code, run ubs <file> --fail-on-warning. The skill lists four patterns AI code is prone to (unchecked .profile.name, missing await, unclosed open(), empty catch) and the category each maps to
- ubs doctor --fix installs missing optional scanners and the AST engine. First-line troubleshooting for exit code 2 or degraded JS/TS scanning
- Composes with multi-pass-bug-hunting (UBS is the Surface-pass driver) and GitHub Actions (the skill's CI workflow uploads SARIF to Code Scanning)
The Golden Rule is short. ubs <changed-files> before every commit. Exit 0 = safe to proceed. Exit 1 = triage findings. Exit 2 = run ubs doctor --fix. Make this a reflex; the cost of skipping it is paid in production.
The Fix-Verify loop is the workflow: scan with --staged (under a second on a typical change set), triage each finding (real bug → fix root cause, never the symptom; false positive → // ubs:ignore — <reason> with a reason), re-run until clean, then commit. Every ubs:ignore requires a justification because uncommented suppressions become the noise that hides the real bugs