How do successful vibe coders use claude.md?

Hi, I'm a successful vibe coder, and this is how I use my claude.md... These rules govern how we build and run. I'm releasing this because I want others a chance to lower the costs of their implementations and see what successful AI full-stack engineers/coder are using with their solution. This is a small claude.md file, it helps teach claude how to manage the repository while I work with it. I feel this particular setup is good for early projects, before they go online, or have any users.

Rule 1 — No ghosting: reusable tech lives in `/scripts/`

Every tool, shell command, query, or operational step that is reusable MUST be a committed file in /scripts/. Do not run know-how ad-hoc in a terminal and lose it. If you run something twice, or it encodes how the business works, script it and wire an npm run alias in package.json. One-off throwaway inspection is fine; anything that is "how we do X" is a script. This is how we avoid losing the tech.

Current scripts: init-db, import-targets, discover, geocode, passive-scan, chrome-recon, rollup, daily-charts, export-dashboard, agent, evolve, hunt, crawl, engage, demonstrate, blog, report, reset, repo-map, guard-confidential, deals, mailer, track, deploy.

Rule 2 — Internal-facing by default; nothing real goes public

Discovered targets, findings, posture scores, leads, and demonstration evidence are CONFIDENTIAL / internal-facing. We do not publish "here are local sites and their bugs." Concretely:

• The dashboard (apps/dashboard) and charts/ are INTERNAL — run locally or behind

auth, never deployed to the open web.

• The public marketing site (apps/marketing) uses only fictional/aggregate examples

for its generic, anonymous content. npm run guard fails the build if any real target host leaks into that generic content.

• The one deliberate exception is the self-serve portal (/portal, backed by

scripts/track.mjs's /api/): a business's own real name, domain, and findings are shown back to that business only, gated by the signed identity cookie minted when they scan their own* printed QR code (lib/session.mjs). This is not "publishing" — it's a client reading their own report. The hard invariant: every portal endpoint resolves the business strictly from the signed cookie, never from a client-supplied id/host/param, so scanning business A's QR can never surface business B's data. Anonymous visitors (no valid cookie, the overwhelming default) always see the generic content, never anyone's real data.

• Engagement evidence lives in engagements/ (gitignored) and is shared with the client

privately, never posted.

Rule 3 — Passive by default; active only under signed authorization; demos are safe

• Lead-gen recon is passive (browser/dig-equivalent). See [agents/_shared/ethics.md](./agents/_shared/ethics.md).
• The portal's "Recheck now" button (POST /api/rescan) runs the exact same passive checks

as npm run scan, on-demand, against the domain tied to the caller's own identity cookie — a site owner re-checking their own site is still passive recon, same as any browser visit. It stays inside Rule 3 because the target is never client-controlled (always the cookie-bound business's own domain) and rate-limited (RESCAN_COOLDOWN_MINUTES) so it can't be repurposed into a probe of anything else.

• When a lead asks us to prove a finding is real, we run the demonstration protocol

(npm run demonstrate <host>) — but only after npm run engage -- authorize … records a signed scope (note the --: it forwards flags through npm). Demonstrations are non-destructive (GET, TLS handshake, client-run PoC files); they never tamper, bypass auth, or exfiltrate real data.

• traits.risk_appetite stays 0 forever (evolution may not raise it). Authorization —

not a trait — is what unlocks the active lane. See [knowledge/90-demonstration-protocol.md](./knowledge/90-demonstration-protocol.md).

Rule 4 — Stack & cadence

React + Tailwind + Vite for apps; Astro for marketing. Analytics-first: charts over words, every day (npm run day → charts/index.html + dashboard). Every finding cites a security.md section.