Skip to content

Latest commit

 

History

6 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 

Repository files navigation

VibeCheckTech Skills

Claude Code skills that help developers ship AI-generated ("vibe-coded") apps without shipping the security mistakes that come with them. Built by vibechecktech.com, primarily for developers using AI coding agents, but useful on hand-written codebases too.

Background

Shipping an app has never been easier. It's great that more people are getting into software development.

The problem: Projects are released without doing the most basics of security checks. The good news is that vibe-coded apps tend to get burned by the same mistakes, and all of them are checkable.

The goal: These are the most common security mistakes I have seen AI-generated apps make, so we have this skill to identify and report them to us, so that a developer can prove it, enumerate and take appropriate action.

The 14 common mistakes check list

# Check Watch for
1 Broken Auth IDOR/BOLA — an object loaded by ID with no ownership check
2 No Server Side Validation missing per-route schemas; raw client input written straight to the DB or an LLM call
3 No Rate Limiting login, password reset, LLM, email/SMS endpoints with no limits
4 Bad/Missing File Upload Validation type checked only by extension/Content-Type, no size cap, SVG/script uploads
5 Enumeration & Injection Vulnerabilities string-built queries, user-controlled sort/filter/column params
6 Secrets Exposed keys shipped to the browser (NEXT_PUBLIC_*) or committed to git history
7 Exposing PII Data emails and other PII returned in API responses, search, or social features
8 No Logging, Monitoring nor Alerting no error capture, no security event logs, no alerting on spikes
9 No Backups no backups, or backups that have never been restore-tested
10 Admin Panels admin UI living in the same app as customer-facing code, under-audited
11 Supply Chain Vulnerabilities no lockfile, npm install in CI, no audit gate, unpinned/sketchy dependencies
12 Staging & Environment Separation no staging at all, or a public preview environment wired to the production database and live keys
13 Missing Privacy Policy & Terms no legal pages, unfilled templates, terms nobody ever actually accepted
14 GDPR & Data-Protection Compliance analytics firing before consent, no way to delete or export a user's data, undisclosed third parties

Each check is stack-agnostic — it targets the principle and the detection pattern, not a specific language or framework — and is aimed primarily at deployed SaaS web and mobile apps.

Checks 13 and 14 are not legal advice. They verify mechanics that are visible in the code: whether the documents exist and are actually accepted, whether the policy matches the third parties the app really calls, whether tracking waits for consent, and whether a user can get their data deleted. Whether the wording is legally sufficient is a lawyer's call.

Installing VibeCheckTech

The skill lives at skills/vibechecktech-security. Install it into a project so Claude Code can use it, from the target project's root:

npx skills add dannyreg/vibechecktech-skills --skill vibechecktech-security --agent claude-code

This pulls the skill straight from GitHub into .claude/skills/ via the skills CLI — no publishing, no package to install ourselves.

Alternatively, copy the folder in by hand:

mkdir -p /path/to/your-project/.claude/skills
cp -r skills/vibechecktech-security /path/to/your-project/.claude/skills/

Either way, no dependencies to install afterward — the skill's recon scanner (recon.mjs) is a zero-dependency script that just needs Node 18+.

Using the security skill

From within the target project, ask Claude Code to run a security audit — for example:

"Security-audit this repo with vibechecktech-security"

The skill will:

  1. Run recon.mjs against the repo to map where risk concentrates.
  2. Walk the actual route/handler surface of the app (not just what recon matched) against all 14 checks.
  3. Rate each finding by severity, exploitability, and confidence.
  4. Write a prioritized, dated report — security-audit-<YYYY-MM-DD>.md — to the root of the audited repo, with file:line citations and concrete, stack-specific fixes.

This is a static, read-only audit. It reads source code, config, and git history, and only ever writes the report file (and, if you explicitly accept a finding, an entry in an owner-editable exceptions log). It never modifies application code — if you want fixes applied, that's a separate follow-up ask.

Accepting a finding (exceptions log)

Some findings are legitimate judgment calls — e.g. "this app is single-operator and LAN-only." If you tell Claude Code to accept or dismiss a specific finding, it appends an entry to security-audit-exceptions.md at the repo root (creating it if needed) with the rationale, who accepted it, and when. On future audits, a matched finding is tagged Accepted risk with that entry shown alongside it.

This never changes severity. A finding stays at its original severity whether or not it's been accepted — acceptance only changes how the report frames it, never hides it or softens it. Check 6 (secrets) findings always render at full severity regardless of any exception. See references/exceptions-log.md for the entry format and matching rules.

Contributing

Bug reports, new detection patterns, and check improvements are welcome — see CONTRIBUTING.md for how to propose changes and what to keep in sync (SKILL.md, checks/*.md, and recon.mjs all describe the same 14 checks and need to stay consistent).

License

MIT — see LICENSE.


Created by Daniel RegueroVibeCheckTech.

About

A list of skills provided by VibeCheckTech

Resources

Contributing

Stars

19 stars

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages