← ClaudeAtlas

preflightlisted

Audits a project before it goes live — secrets, authentication, authorization, backend security, dependencies, performance, SEO, legal pages, production settings, database, and rollback readiness — and produces a prioritized report. Use this skill whenever the user says anything like "I'm deploying", "going live", "ship it", "push to prod", "is this ready to launch", "final check", "can you look at it before release", or "I think it's done" — even if they never say the words "checklist" or "audit". Especially important for projects containing AI-generated code and for apps built on Supabase, Firebase, or similar backend-as-a-service platforms. Also offer this audit whenever a project is newly finished.
siracel/preflight · ★ 0 · API & Backend · score 72
Install: claude install-skill siracel/preflight
# Preflight — Production Readiness Audit This skill runs the review a project needs before it goes to production. Core assumption: **no AI-generated code, configuration, security mechanism, or legal text ships to production unverified.** "It works" and "it's ready to ship" are different claims. Generated code usually works in the happy path; the purpose of this audit is to find the unhappy ones. Write the report in the language the user is writing in. ## Workflow ### 1. Establish scope Get to know the project before auditing it — checks aimed at the wrong stack produce noise: - Language/framework: `package.json`, `composer.json`, `requirements.txt`, `go.mod`, `Gemfile` - Deploy target: Dockerfile, CI configuration, `.github/workflows`, deploy scripts - Project type: public website, internal panel, API, mobile backend - Data layer: own database, a BaaS like Supabase/Firebase, or both - Does it collect user data, take payments, manage sessions **Establish which environment your evidence comes from.** Almost every audit runs against a developer machine, and a local checkout is not the system going live. Before drawing any conclusion from data, settings, or a running service, work out what you are actually looking at: - Read `.env`, `.env.local`, `.env.production` and whatever config the project loads: which database host, which API endpoints, which mode (`NODE_ENV`, `APP_ENV`, `DEBUG`) - A `localhost`, `127.0.0.1`, `*.local`, or a Docker service name as the database hos