# vibe-security-skill: a checklist agent skill aimed at AI-written app code > A single Agent Skills folder, installed with one npx command, that teaches a coding agent to look for the specific mistakes AI assistants keep shipping: secrets in client env vars, RLS policies that allow everything, prices from the client, tokens in localStorage. **raroque/vibe-security-skill** — Agent skill that audits vibe-coded apps for common security vulnerabilities introduced by AI coding assistants - Repository: https://github.com/raroque/vibe-security-skill - Stars: 1,021 · Forks: 124 - Language: Unknown - License: MIT - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/raroque-vibe-security-skill ## One folder of Markdown, installed with npx The repository contains four files at the top level, `README.md`, `LICENSE`, `CONTRIBUTING.md` and `.gitignore`, plus a single directory named `vibe-security/`. That directory is the entire product. It is an Agent Skills package, the format documented at agentskills.io, which means it loads into Claude Code, OpenAI Codex and other compatible agents rather than running as its own binary or service. Installation is one command for both of the major agents: ```bash npx skills add https://github.com/raroque/vibe-security-skill --skill vibe-security ``` For Codex you pick the platform when prompted. If `npx` is not available the README points at installing Node.js first, with a Homebrew one-liner for macOS and a link to nodejs.org otherwise. There is also a manual route that just copies the folder, which is worth knowing because it means you can read the skill before you trust it with your codebase. The project-level form drops it into `.claude/skills/vibe-security/` for one repository, and the global form drops it into `~/.claude/skills/vibe-security/` so it applies everywhere: ```bash # Project-level (applies to one project) cp -r vibe-security/ .claude/skills/vibe-security/ # Global (applies to all projects) cp -r vibe-security/ ~/.claude/skills/vibe-security/ ``` The repository is MIT licensed with 1,021 stars and 124 forks. It has no releases, no published version numbers and no lock on a schema version, so an update is a fresh copy rather than a dependency bump. ## Why the rules are about assistant behaviour, not generic advice The framing matters for judging the contents. The README argues that assistants are good at building features quickly but consistently get security wrong, naming four examples up front: hardcoding secrets, skipping row-level security, trusting client-submitted prices, and storing tokens in localStorage. The stated premise is that when a person is building fast with AI, the security fundamentals get skipped, and that the assistants are frequently the ones introducing the vulnerability rather than merely failing to stop it. That premise shapes what ends up in the checklist. A generic secure-coding guide tells you to validate input. This one names `NEXT_PUBLIC_`, `VITE_` and `EXPO_PUBLIC_` variable prefixes as a leak vector, `USING (true)` as a policy that is not a policy, `jwt.decode()` without verification as a decode mistaken for a check, and middleware-only auth as a check that can be bypassed by calling the route handler directly. The conditional loading design follows from the same reasoning. Security rules are organized as reference files that the agent loads based on which technologies the project actually uses. Supabase projects get RLS policy checks, Stripe projects get payment flow checks, React Native projects get a check for secrets leaking into the JavaScript bundle. The README's framing is that this avoids wasted context on irrelevant checks, which is the practical difference between a skill you keep installed and one you remove after the first noisy run. The trigger surface is broad by design. Beyond an explicit slash command, the README lists natural phrasings like asking whether code is safe, and notes that the skill also activates on its own while you write or review code touching authentication, payments, database access, API keys or user data. ## The nine categories and what each one catches The README's table is the substance of the skill, and it is worth reading in full because the specificity is the value. Secrets and env vars covers hardcoded API keys, secrets in client-exposed variable prefixes, and a missing `.gitignore`. Database security covers disabled Supabase RLS, policies written as `USING (true)`, policies missing `WITH CHECK`, exposed sensitive fields, Firebase `allow: if true` rules, and Convex without auth. Auth and authorization covers `jwt.decode()` without verify, middleware-only auth, unprotected Server Actions, and tokens in localStorage. Rate limiting is its own category rather than a footnote: missing limits on auth, AI and email endpoints, rate counters that live where the client can tamper with them, and absent billing caps. Payments covers client-submitted prices, missing webhook signature verification, and stale subscription checks, which is the class of bug where a cancelled subscription keeps working because the check cached an old answer. Mobile covers API keys in the JS bundle, `AsyncStorage` for tokens, unsafe deep links, and weak biometric auth. AI and LLM covers exposed AI API keys, no usage caps, prompt injection, and unsafe output rendering. Deployment covers debug mode in production, exposed source maps, missing security headers, and an accessible `.git` directory. Data access closes with SQL injection, Prisma operator injection, `$queryRawUnsafe`, and mass assignment. Read as a whole, the list has a recognisable shape: nearly every entry is a specific API, variable prefix or file setting an assistant writes without being told, which is why it is a better fit for AI-assisted development than a general checklist would be. ## How to trigger it in each agent In Claude Code you invoke `/vibe-security` for a full security audit, or you simply ask in conversation with phrasings like checking the code for security issues or asking whether something is safe. In Codex the equivalent is `$vibe-security`, or describing the task, such as reviewing for vulnerabilities or checking Supabase RLS. The distinction between the two agents is only in the invocation syntax. The underlying content is the same Agent Skills package, which is the point of adopting that format rather than writing Claude-specific configuration. The same applies to the wider claim in the README about working with other compatible agents. Automatic activation is the part that changes daily habits rather than occasional audits. If the skill triggers while you are writing code that handles auth, payments, database access, API keys or user data, then the cost of having it installed is close to zero and the benefit arrives at the moment a mistake is being introduced rather than at review time. Whether an agent can be trusted to reliably auto-trigger on a specific file path is a fair question to ask of any such skill, and one you can answer for yourself by installing it and watching what it does on a real repository. There is no report format, output file or CI mode described anywhere in the README. This is an interactive review skill, not a scanner with an exit code, which matters if you were hoping to gate pull requests on it. ## Maintenance posture and what the repository does not say The repository is small in a way that is appropriate for what it is. There are no releases and no changelog, two open issues, and a last push on 2026-03-15. The README does not claim a maintenance cadence or a support commitment, and the honest reading is that this is a stable artefact rather than an actively evolving tool. That cuts both ways. Security checklists decay as frameworks change, since the specific risk in Supabase or Stripe or Next.js moves over time, and a checklist with no release history gives you no way to tell whether its Supabase guidance reflects last year's API. On the other hand, the rules it does cover are about stable primitives like RLS policies and webhook verification rather than about fast-moving framework internals. Contributions are invited explicitly, and the invitation is specific: if you have found a security anti-pattern that AI assistants keep introducing, add it. `CONTRIBUTING.md` holds the guidelines. That framing tells you what the maintainer wants the project to become, which is a catalogue of assistant failure modes that grows as models and frameworks change. Two things the README does not cover are worth naming. It does not describe how false positives are handled or how the agent is told to prioritise when a rule fires on something intentional, such as a public API key by design. And it does not claim any certification, standard alignment or third-party audit, so it should be read as a well-informed checklist contributed by a consultancy rather than as an assurance artefact. ## Conclusion This skill is worth five minutes to install in any project where an assistant is writing code that touches auth, payments or a database. Its value is not a new idea but specificity: it names the exact variables, policies and API calls that assistants get wrong, and it loads checks conditionally so you are not paying context for rules that do not apply to your stack. What it is not is a substitute for review by a person who owns the security consequences, and the repository is small enough that you can read its reference files and decide for yourself. Install it, trigger a full audit once on an existing project, and treat what it flags as a starting point for your own judgement rather than a verdict. ## FAQ ### What does vibe-security-skill actually do? It is an Agent Skills package for coding assistants that reviews application code for security mistakes AI assistants tend to introduce. Its security rules are split into reference files loaded according to the technologies a project uses, so a Supabase project gets RLS checks and a Stripe project gets payment flow checks rather than a generic list applied to everything. ### How do I install it in Claude Code or Codex? Run `npx skills add https://github.com/raroque/vibe-security-skill --skill vibe-security` and select the agent platform when prompted, choosing Codex for OpenAI Codex. You can also copy the `vibe-security/` folder into `.claude/skills/` in a project for repo-scoped use or into `~/.claude/skills/` to apply it everywhere. ### What security issues does it check for? Nine categories: secrets and env vars, database security such as disabled or permissive RLS, auth and authorization problems like unverified `jwt.decode()` and tokens in localStorage, rate limiting on auth and AI endpoints, payment issues like client-submitted prices and unverified webhooks, mobile problems like keys in the JS bundle, LLM concerns including prompt injection, deployment misconfiguration such as debug mode and exposed source maps, and data access flaws such as SQL and Prisma operator injection. ### Can I run it as part of CI or get a report file? The README describes an interactive review skill rather than a scanner. It is triggered by slash command, by natural language, or automatically when working on authentication, payments, database access, API keys or user data. No report output or exit-code mode is documented, so CI use would need your own wrapper. ## Sources - [Issues](https://github.com/raroque/vibe-security-skill/issues) - [License: MIT](https://github.com/raroque/vibe-security-skill/blob/main/LICENSE) - [raroque/vibe-security-skill on GitHub](https://github.com/raroque/vibe-security-skill) - [README](https://github.com/raroque/vibe-security-skill/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/raroque-vibe-security-skill