Prelaunch security pass
Skill lexthirteen-ai/founder-survival-kit/skills/prelaunch-security-pass
A plain-language security check for vibe-coded apps before real users and real logins arrive. Walks a founder through the handful of things that actually get small apps compromised (exposed secrets, weak or fake auth, unprotected data, missing input checks) and gives a prioritized fix list. Use before a launch, before taking real users, before handling payments or personal data, or any time someone jokes that they "vibe-coded the 2FA." Finds the real risks, in order, without fear-mongering.From its SKILL.md
npx -y skills add lexthirteen-ai/founder-survival-kit --skill prelaunch-security-passAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, 566 tokens by cl100k_base, as published. Nobody here has run it
Prelaunch Security Pass
The auth memes are funny until the app has real users and real logins. This is the short security check to run before launch, not after the breach, written so a non-engineer can act on it.
When to use
- Before you launch, take real users, or handle payments or personal data.
- After building auth or login with an ai and not being sure it is real.
- Any time the honest answer to "is this secure" is "I have no idea."
Process
Check these in order. Most small-app compromises come from the first three.
- Exposed secrets. Look for api keys, passwords, and tokens committed into the code or shipped to the browser. Move them to environment variables and rotate anything that leaked. This is the single most common and most damaging mistake.
- Auth that only looks like auth. Confirm that login actually protects things: that pages and data meant to be private cannot be reached by editing a url or calling the api directly, and that the check happens on the server, not just hidden in the interface.
- Unprotected data. Check that one user cannot read or change another user's data, that your database is not open to the public internet, and that permissions are enforced on the server side.
- Unchecked input. Confirm user input is validated and that data goes into queries safely, so a crafted input cannot read your whole database or run code.
- The basics. Https everywhere, sensible password rules, rate limits on login, and no verbose error messages leaking internals.
Output
- A findings list, each item rated must-fix-before-launch, should-fix-soon, or fine-for-now.
- For each must-fix, a plain-language explanation of the risk and the specific change to make.
- A one-line honest verdict: is this safe to put in front of real users yet.
Guardrails
- Never handle their credentials. Walk them through rotating a leaked key or setting a variable themselves. Do not ask for secrets, and do not paste real keys anywhere.
- Prioritize ruthlessly. A founder will not do twenty things. Name the three that matter most and get those done.
- Plain language, no fear-mongering. Explain each risk in terms of what could actually happen, calmly, and what stops it.
- This is a pass, not a guarantee. Say clearly that it catches the common, high-impact mistakes and is not a full audit. For payments or health data, recommend a professional review.
Related
Do save-your-work and make-ai-code-legible first. This is a gate on launch-that-converts.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.