| name | vibe-check |
| description | Judgment linter for vibe-coded output — reads the energy of the code, not just correctness. Use when the user says "vibe check", "check this vibe code", "does this hold up", "sanity check this AI code", or after a fast generation session before committing. |
Vibe Check
Overview
"Vibe check?" — a way of asking what's the energy like right now?
Static linters catch syntax. Code review catches everything but takes time. Vibe-check sits between: a quick judgment pass that asks whether AI-generated code feels like it was written with thought or just generated on autopilot.
Single-agent, one pass. Runs on the diff by default. Surfaces higher-order problems that require reasoning — the things a thoughtful reviewer notices in the first 30 seconds that no regex can detect.
Input
Default: Git diff (staged if present, unstaged otherwise).
/vibe-check
/vibe-check src/auth/
Override: Named files or directories passed as arguments.
Assertion Categories
Each category reads a specific vibe. Findings require AI judgment — if a static linter could catch it, it doesn't belong here.
| Category | The vibe | What it catches |
|---|
| Earned complexity | "This feels over-engineered" | Abstractions that don't justify themselves, premature generalization, indirection without payoff |
| Prompt-shaped code | "This feels shaped by the prompt, not the problem" | Odd boundaries, misnamed concepts, structure that mirrors how the request was worded rather than the domain |
| Missing skepticism | "This feels like nothing can go wrong" | Happy-path-only logic, unchallenged assumptions, no failure modes considered, silent swallowing of errors |
| Cargo-culted patterns | "This feels ceremonial" | Design patterns applied without justification, boilerplate that adds ceremony without value, framework idioms used out of context |
| Integration blindness | "This feels written in a vacuum" | Duplicates existing utilities, contradicts established codebase patterns, ignores conventions visible in surrounding code |
| Shallow naming | "This feels like nobody thought about what it means" | Names describe implementation (handleData, processItems) instead of intent — a signal the author didn't reason about the domain |
| Security surface | "This feels like it trusts too much" | Auth gaps, unsanitized boundaries, trust assumptions — only the ones requiring judgment, not what semgrep catches |
Severity
Each category defaults to a severity level. Users can override per-category.
| Level | Meaning |
|---|
| error | Must address before committing |
| warn | Worth considering, not blocking |
| off | Skip this category |
Defaults:
- error: missing-skepticism, security-surface
- warn: earned-complexity, prompt-shaped-code, cargo-culted-patterns, integration-blindness, shallow-naming
Workflow
1. Gather the Code
Read the git diff or specified files. Identify the languages and frameworks involved.
2. Read the Room
For each assertion category (unless severity is off), scan the code and ask the category's question. Apply language-aware judgment:
- Python: mutable default args, bare
except, implicit None returns
- JavaScript/TypeScript:
== vs ===, unhandled promise rejections, prototype pollution
- Go: unchecked errors, goroutine leaks
- Rust: unnecessary
unwrap(), clone() to satisfy the borrow checker
- General: any language-specific footgun that a vibe coder would hit
3. Report Findings
Group findings by category. Each finding includes:
## Prompt-Shaped Code (warn)
- `src/auth/handler.ts:42` — Function boundary splits "validate" and "authorize" because the prompt asked for them separately, but they share all context and should be one operation
- `src/auth/types.ts:8` — `RequestData` is a generic wrapper that mirrors the prompt's language ("request data") rather than the domain concept (`AuthAttempt`)
4. Summarize
End with a summary line:
vibe-check: 2 errors, 4 warnings across 3 files
5. Escalate (if needed)
When findings are dense (8+ findings or 4+ categories with hits), suggest escalation:
Dense findings across multiple categories — consider running /review for a deeper pass.
Guidelines
- One pass, no back-and-forth. Read the code, report findings, done.
- Be assertive, not exhaustive. Flag what stands out. A vibe check is quick — 30 seconds of focused attention, not a thorough audit.
- Require judgment. Every finding should need reasoning to identify. If
ruff or eslint could catch it, skip it.
- Include file:line references. Every finding points to a specific location.
- Explain the why. Don't just name the smell — say what's wrong with the energy. "This wrapper adds a layer of indirection but every caller passes through unchanged" beats "unnecessary abstraction."
- Respect language idioms. A Go error check isn't cargo cult. A React
useEffect cleanup isn't ceremony. Know the difference.
- No rewrites. Flag the problem, don't fix it. The developer decides what to do.
See Also
/review — Full structured review when vibe-check suggests escalation/naming — Deep dive when shallow-naming findings accumulate/testing — When missing-skepticism reveals untested assumptions/sweep — Post-op damage check; vibe-check is pre-commit, sweep is post-mergeskills/FRAMEWORKS.md — Full framework index
