From vibesubin
Runs all skills in parallel across a repository, synthesizing findings into a prioritized report. Invoke via /vibesubin for full sweeps, routes vague requests, and fast-paths security incidents like leaked secrets.
npx claudepluginhub subinium/vibesubin --plugin vibesubinThis skill uses the workspace's default tool permissions.
`/vibesubin` is two things at once:
Orchestrates repo security scans (SAST, SCA, secrets, config) with adaptive agent swarms: subagents for small repos, teams for large. Verifies findings, compiles reports.
Detects duplicated code, dead imports, security vulnerabilities, and complexity hotspots using parallel subagents. Run at session end, before commits, merges, or code reviews.
Reviews and verifies code before merge via triage-first checks (up to 16 parallel agents). Pipeline mode verifies vs plans; general mode for PRs/branches/staged changes. Flags findings only.
Share bugs, ideas, or general feedback.
/vibesubin is two things at once:
Both meanings are intentional. The word doubles as a greeting, a command, and a self-description of what the operator is already doing ("vibing with AI on a codebase").
Certain phrases mean "something just leaked" and need an immediate response, not a polite routing menu. If the operator's request contains any of these, skip the normal modes and jump directly to audit-security in incident mode:
.env + any verb like committed, pushed, leaked, exposedsecret leaked, token leaked, key leaked, credential leakedapi key committed, private key exposedaccidentally pushed, accidentally committedbreach, compromised, hackedrevoke, rotate now, urgent securitypushed my password, in git historyFor any of these, the response is:
audit-security's incident runbook immediately. Do not ask what else the operator wants.Only after the incident is contained — credentials rotated, history rewritten, collaborators notified — does it make sense to come back and run the normal sweep for related issues.
When the operator types /vibesubin directly, or says "run vibesubin on this repo" / "full check" / "vibe check", run the full parallel sweep. Do not ask what to do first. Run everything, synthesize, report.
When the operator gives a vague ask ("help", "where do I start", "my repo is a mess") without typing /vibesubin explicitly, fall back to the router below. Ask one short question, then hand off to the right specialist.
The two modes exist because different users need different entry points. The command mode is for "do everything"; the router mode is for "help me narrow down."
Every sweep runs in one of two tones. The default is balanced — honest but warm, direct but not cold. Operators opt in to harsh when they want a review that refuses to soften anything.
Any of these signals activates harsh mode:
/vibesubin harsh or /vibesubin spicyThe explicit Korean / Japanese / Chinese phrases are there on purpose — non-English operators ask for harsh tone in their own language.
tone=harsh in addition to sweep=read-only. Specialists check for this marker and switch to their own harsh-mode output rules.Harsh mode is not about being rude, exaggerating, or inventing findings. It is about refusing to soften the framing when the findings are real. Every harsh statement must still be backed by evidence — the same evidence the balanced version would cite.
Before running, confirm once:
"Running the full vibesubin sweep on this repo. That's nine checks in parallel — refactor safety, security, repo rot, docs, CI setup, secrets/env, project conventions, repo bloat, and design unification. Read-only — nothing gets edited until you approve items from the report. Sound good?"
If the operator says yes, proceed. If they want to narrow the scope (one directory, one file, one area), adjust before launching.
Run all nine sub-skills as parallel task agents (or parallel subagents, depending on the host framework). Do not serialize. Parallelism is load-bearing — sequential execution defeats the whole purpose of the command.
Read-only mode is enforced by the launch instruction itself. Every specialist task MUST begin with the exact token sweep=read-only followed by "produce findings only, do not edit any files, do not run lifecycle workflows." Each specialist has a matching "Sweep mode — read-only audit" section in its SKILL.md that checks for this marker and switches to audit-only output. If a specialist does not see the marker, it will default to its full edit-capable behavior, which is incorrect for a sweep.
Three specialists (fight-repo-rot, audit-security, manage-assets) are pure-diagnosis by default and edit nothing regardless of the marker. The other six (refactor-verify, setup-ci, write-for-ai, manage-secrets-env, project-conventions, unify-design) rely on this marker to stay read-only. Do not launch any of them without it.
Parallel launch targets (the sweep=read-only prefix is mandatory — copy it into every task description verbatim):
parallel {
refactor-verify → "sweep=read-only — produce findings only, do not edit
any files, do not plan a dependency tree, do not run
the 6-step procedure. Snapshot baseline state (tests,
typecheck, lint). Report whether the repo is in a
green baseline ready for refactors, or already red."
audit-security → "sweep=read-only — produce findings only. Run the
ten-category security sweep. Triage every finding.
Report critical / high / medium / false-positive counts."
fight-repo-rot → "sweep=read-only — produce diagnosis only, never edit.
Run the full dead-code scan with HIGH/MEDIUM/LOW
confidence tagging. Also report god files, hotspots,
hardcoded paths, stale TODOs, dependency rot. Include
the hand-off summary."
write-for-ai → "sweep=read-only — produce findings only, do not edit
or create any documentation files. Audit existing docs
(README, CLAUDE.md/AGENTS.md, recent commits and PRs)
against the AI-friendly schema. Report gaps, stale
sections, and the stoplight verdict."
setup-ci → "sweep=read-only — produce findings only, do not
scaffold any workflow files, do not write to
.github/workflows. Inspect the current CI/CD setup.
Report what exists, what's missing, what's broken,
with the stoplight verdict."
manage-secrets-env → "sweep=read-only — produce findings only, do not
scaffold or edit any config files, do not run any
lifecycle workflow (rotate/remove/migrate/provision).
Audit four-bucket placement, .env drift, secret-shaped
.gitignore coverage, tracked-secret files. Report
deviations with stoplight. Any tracked secret is an
immediate hand-off to audit-security."
project-conventions → "sweep=read-only — produce findings only, do not
scaffold or edit any files. Audit branch strategy
vs GitHub Flow, dependency pinning and lockfile
presence, directory layout smells, hardcoded absolute
paths and portability bugs. Report deviations with
stoplight."
manage-assets → "sweep=read-only — produce diagnosis only, never edit.
Scan for large files in the working tree (>10 MB),
large blobs in git history, LFS migration candidates,
asset-directory growth, duplicate binaries. Report
top offenders with size, severity, and hand-off."
unify-design → "sweep=read-only — produce findings only, do not
scaffold any tokens file, do not edit any component.
Detect the framework (Tailwind v3/v4, CSS Modules,
styled-components, MUI, Chakra, vanilla), identify
the BI source of truth (or flag its absence), audit
for hardcoded hex/rgb, arbitrary Tailwind values,
magic px/rem numbers, duplicate Button/Card/Nav/Logo
components. Report drift by file with hotspots."
}
Each specialist writes into its own SKILL.md output format, constrained to read-only. No cross-contamination during the parallel phase.
If harsh mode is active, prepend tone=harsh to every specialist task description above, before sweep=read-only. Example for fight-repo-rot: "tone=harsh, sweep=read-only — produce diagnosis only, never edit. Apply harsh-mode output rules...". Every specialist checks for this marker and switches its output tone accordingly.
When all six specialists return, merge their findings into a single prioritized report. The synthesis rules:
src/api/user.ts is both a churn×complexity hotspot AND has a SQL injection AND has no tests), that file is top priority.# /vibesubin sweep — <repo name> — <date>
## Vibe check
<One paragraph, warm tone, honest summary. "Your repo is in decent shape but
three things stand out..." or "There are four things I'd fix before you ship
the next release..." or "Honestly, this looks clean — here are two small
polish items.">
## What ran
Nine skills in parallel. Each one's full report is in the section below.
- refactor-verify: <green | yellow | red> — <one-line summary>
- audit-security: <green | yellow | red> — <one-line summary>
- fight-repo-rot: <green | yellow | red> — <one-line summary>
- write-for-ai: <green | yellow | red> — <one-line summary>
- setup-ci: <green | yellow | red> — <one-line summary>
- manage-secrets-env: <green | yellow | red> — <one-line summary>
- project-conventions: <green | yellow | red> — <one-line summary>
- manage-assets: <green | yellow | red> — <one-line summary>
- unify-design: <green | yellow | red> — <one-line summary>
## Prioritized fix list (top 10)
Size bucket: **S** = quick win (single file, under an hour), **M** = multi-file or careful (rest of a day), **L** = multi-session (refactor, coordinated change, history rewrite).
| # | File / area | What | Severity | Fix with | Size |
|---|---|---|---|---|---|
| 1 | src/api/user.ts:187 | SQL injection in `get_user_by_email` | CRITICAL | audit-security → refactor-verify | S |
| 2 | src/api/user.ts (whole file) | Hotspot: 870 LOC, 18 CCN, 47 commits / 6mo | HIGH | refactor-verify | L |
| 3 | .env committed in git history | Secret exposure | CRITICAL | audit-security → manage-secrets-env | M |
| ... |
## By specialist
### refactor-verify
<full specialist output>
### audit-security
<full specialist output>
...
## Recommended order of operations
1. **Fix #1 first** — it's a critical security issue and it's a quick win (size S)
2. **Rotate exposed secrets in #3** — concurrently, since no code change needed
3. **Then tackle #2** — the hotspot — because fixing #1 there ties into the split
4. ...
## What I did NOT do
This sweep is read-only. No files were modified. No commits were made.
Approve the fix list and I'll hand off each item to the right specialist.
## Vibe check — verdict
<One-sentence verdict. "Ship it after #1 and #3." or "Don't ship until all
criticals are resolved." or "This is honestly fine; ignore the noise below
the fold.">
If the sweep was launched in harsh mode, the report structure is the same but the tone changes at three specific places:
Vibe check paragraph (harsh): leads with the worst finding in one sentence, no warm-up. "This repo ships a SQL injection, three confirmed-dead god files, and an .env in git history. Fix those before anything else; everything below is secondary." No "decent shape" openings. No "a few things" softening.
Prioritized fix list (harsh): strictly worst-first. No "nice-to-have" tail. No items below severity MEDIUM. If there are fewer than 10 items above MEDIUM, the list is shorter than 10 — don't pad to reach the top-10 quota.
Verdict line (harsh): direct, no hedge. Acceptable forms:
Never "solid with a few things to watch", never "mostly fine", never "some polish items" when harsh mode is active.
The "vibe" part is real but subtle. Specific to-dos:
Do not push the meme further. Adding more "vibe" language makes the report feel juvenile. One section-header joke is enough.
If the operator's request is vague but they didn't invoke the command, route to a specific specialist instead of launching the full sweep. Running all six is expensive; don't do it unless the operator really wants it.
User request
│
├── Contains "refactor" / "move" / "rename" / "split" / "is this working"
│ → refactor-verify
│
├── Contains "secure" / "safe" / "leak" / "vulnerability" / "audit"
│ → audit-security
│
├── Contains "clean up" / "rotting" / "dead code" / "mess" / "hotspot"
│ → fight-repo-rot
│
├── Contains "README" / "document" / "commit message" / "PR" / "CLAUDE.md"
│ → write-for-ai
│
├── Contains "CI" / "deploy" / "GitHub Actions" / "workflow" / "automate deploy"
│ → setup-ci
│
├── Contains ".env" / "secret" / "rotate" / "gitignore" / "api key"
│ → manage-secrets-env
│
├── Contains "branch" / "main or dev" / "dependency" / "dependabot" / "folder structure" / "hardcoded path"
│ → project-conventions
│
├── Contains "repo is huge" / "big files" / "LFS" / "binary in git" / "bloat"
│ → manage-assets
│
├── Contains "design system" / "unify" / "match the brand" / "too many hardcoded"
│ / "why do these pages look different" / "extract to tokens"
│ / "브랜드 일관성" / "디자인 통일"
│ → unify-design
│
├── Contains "full check" / "run vibesubin" / "vibe check" / "everything"
│ → MODE 1 (full sweep)
│
└── None of the above — ambiguous
→ Ask one question: "What's bothering you most right now — the code is
hard to change, something feels unsafe, your repo is messy, your docs
are stale, deploy is manual, or something structural (config / branches
/ env)?"
User: "help" → Ambiguous. Ask the one question above.
User: "can you look at this file" → Too broad. Ask: "What do you want me to look for — is it broken, unsafe, messy, or something else?"
User: "my whole repo is a mess and I don't know where to start" → This is the command mode signal even without /vibesubin. Offer: "I can run the full vibesubin sweep — all six skills in parallel, one prioritized report at the end. Want me to?"
User: "I pushed my .env to github" → Immediate audit-security + manage-secrets-env tandem. Don't route through the umbrella; the urgency is specific.
"fix this SQL injection"), route to the specialist. Don't up-sell the full sweep.If the operator has a specific, narrow task, don't route through vibesubin at all — let the matching specialist fire directly. The umbrella is for exploration and full sweeps, not for tasks that already have an obvious home.
vibesubin is the thing you type when you want your AI to just look. Not to fix, not to explain, not to lecture — just to look and tell you what it sees.