avant-gardeSAFE

Think before you build. Guard before you ship. A Claude skill: 6 foundation docs + a security gate before any vibe-coded app.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: avant-garde
description: Use whenever the user wants to create, start or prototype a website, web application or SaaS (vibe coding), or asks for code for a new web project. Establishes the 6 foundation documents and the security gate before any code is written.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
---

# Avant-Garde — foundations before code, the guard before go-live

*Think before you build. Guard before you ship.*

## Principle — the human–AI contract

I do not code a new project without written foundations. Whatever the human doesn't decide, I guess — and I guess wrong. These documents are not paperwork: they are **our shared memory**. Every session is a fresh instance; the documents are what lets the human–AI duo resume exactly where it left off, reinventing nothing. Golden rule: **what isn't written doesn't exist.**

This skill stands by its method. If the user wants to code without foundations, I say so once, clearly: what they risk (open database, exposed keys, an unresumable project) against the half hour the documents cost. If they insist, the only path I accept is a **throwaway prototype**: labeled as such in the code and README, never connected to real personal data, never deployed. For any project touching other people's data, I do not skip the security gate.

## Step 1 — Triage (30 seconds)

Ask ONE question: "Will your project have user accounts, a database, payments, or calls to an AI?"
- **No** (static page/site, brochure, portfolio) → **light track**: 3 documents (01-product, 03-design, 06-plan) + the Git/secrets checks from the security gate.
- **Yes** → **full track**: 6 documents + the complete security gate, non-negotiable.

## Step 2 — Interview, document by document

In dependency order: 01 → 02 → 03 → 04 → 05 → 06 (the plan depends on everything else). Method:
- 5 questions maximum at a time, plain language, no unexplained jargon.
- If I can infer an answer from what was already said, I propose it and ask for confirmation.
- I invent NO feature, NO figure, NO tool that wasn't validated. When in doubt: `[TO CONFIRM]` in the document.
- Each document is written into `docs/` as soon as its answers are complete — never all at once.

## Step 3 — The 6 documents (what each contains)

### docs/01-product.md (PRD) — what we're building
- The product in 3 sentences: for whom, what problem, what sets it apart.
- The user types and what each wants to do.
- Features ONE BY ONE with a priority: must-have v1 / nice-to-have / later. A feature = a complete action ("book a table"), not a page.
- **Out of scope for v1, in black and white** — this is the anti-drift line.
- 1-2 measurable success criteria.
- Classic mistake: mixing v1 with the dreams — I build everything I read.

### docs/02-app-flow.md — what happens on click
- List of pages, their URL, who can access them (visitor / signed-in / admin).
- One click-by-click journey per PRD feature, start to finish.
- **The states everyone forgets**: empty, loading, error, success, going back.
- Navigation rules (signed-out user clicks a private page → where?).
- Classic mistake: describing only the happy path — most bugs live in the unwritten states.

### docs/03-design.md — what it looks like
- Colors in hex (background, text, accent, success, error) — never "a warm orange", always `#C2410C`.
- Fonts (headings, body), base sizes, where to load them.
- Base components in 3 lines each: button, card, form, error message.
- Each page's look described in words: what you see first, the order of blocks. A visual reference if available.
- Tone of voice (formal or casual, humor or not).
- Classic mistake: "modern, clean, premium" — those words produce the same site as everyone else's.

### docs/04-tech.md (TRD) — what we build with
- ONE tool per need, frozen: framework, database, auth, e-mails, hosting — and why. If the user doesn't know, I propose, they validate, we freeze.
- External services and their free-tier limits (e-mails/day, database rows) — written down.
- Environment variables by NAME only (`SUPABASE_URL`, ...). Values live in `.env`, never in this document, never in a conversation.
- The forbidden list: no new dependency without approval, no database switch mid-project, no hardcoded key.
- Classic mistake: three tools for one need, or a tool chosen because a video mentioned it.

### docs/05-data.md (back-end schema) — where data lives, who sees it
- Tables field by field, with the links between them.
- **Access rights, table by table**: who reads, who writes, who deletes — per role. This becomes the database's security rules.
- Every piece of personal data flagged: why we collect it, can we do without it, where it is stored (region — pick the right one at project creation for GDPR and local laws), how long we keep it and what happens at the end.
- The schema changes through MIGRATIONS, never by hand.
- Classic mistake: letting the AI create tables as it goes, with no access rules → an open database where any signed-in user reads everything. Rights are written before the first table.

### docs/06-plan.md — what to build, in what order
- Steps that each fit in one session. Too big? Cut it.
- Dependency order: skeleton + design → auth → data → features (PRD priority order) → payments → **security gate** → go-live.
- For each step, ONE sentence the user can verify: "I book a table and receive the e-mail." Until it's true, the step isn't done.
- Finished steps are frozen: they change through a new step, not a drive-by edit.
- Classic mistake: "build everything" in one session — nobody verified anything.

## Step 4 — The security gate (blocking before go-live)

Ten checks, each doable by a non-developer in minutes. I weave them through the documents (05 especially) and replay ALL of them as the final plan step. **I never declare a project ready to ship while a box is unchecked.**

1. **Git step 0**: `.gitignore` created BEFORE the first commit, `.env` in it. Secret scan before every push. A key leaked (even o

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.