John

Right or wrong as long as it's my way, I can live with it.

[John @jjb2519]

@NielsPosts_ https://t.co/PCgoboZHH7

[John @jjb2519]

@NielsPosts_ Start a fresh Claude session and have it read your CLAUDE.md, then the repo, and list what's stale or wrong. Then cut it down to build/test commands, a short folder map, and the few rules it keeps breaking. Going in circles is usually old notes fighting the current code.

[John @jjb2519]

https://t.co/UZcuCodQx9

[John @jjb2519]

It's just me building this, not some big company. Try it out and tell me what's missing. I'm reading every reply.

[John @jjb2519]

https://t.co/k3pdGicnfZ

[John @jjb2519]

I'm launching VibeKits on Product Hunt today. It's free stuff I built to keep AI coders from going off the rails.

The main thing is a free rules generator. Pick your project and your tool (Cursor, Claude Code, Lovable, Bolt), flip a few switches, and it writes you an AGENTS.md or CLAUDE.md. It runs in your browser, with no signup.

There's also a free library of ready-made rules files, 57 pages covering 30 kinds of beginner projects. Copy whichever one is closest to what you're building and go. All of it's on GitHub too, free and MIT licensed.

[John @jjb2519]

If you ever committed an API key, deleting the file in the next commit doesn't remove it. It's still in your git history, and on GitHub if you pushed. I rotate the key first (new key, revoke the old one), then add .env to .gitignore. Cleaning history comes after.

[John @jjb2519]

Keep it short. Anthropic says under 200 lines. Mine has 4 parts: what the project is, the commands to run and test it, the rules (concrete ones you can check, like "ask before touching the database"), and how it should report back. /init gives you a starter you can trim. https://t.co/8yktzkShYb

[John @jjb2519]

@j2k_mk Not yet, but that's the exact case I put it there for. Good to know a parent CLAUDE.md can win over AGENTS.md, I'll watch for that.

[John @jjb2519]

@TheNorwegianNFT @delitzer https://t.co/zNKLh0nCSc

[John @jjb2519]

Either one is fine for writing prompts. Lovable runs its own model to build the code anyway. The bigger difference for me was putting my rules in Lovable's Project Knowledge: what the app does, how login and payments work, and what it shouldn't touch. Then ask for one feature per prompt, so you're not re-explaining the app every time and it stops breaking things.

📷Lovable SaaS rules: auth, payments & Knowledge | https://t.co/iEyL0GM9UP

[John @jjb2519]

Codex saves sessions as files in ~/.codex/sessions, so you can sync that folder too, with Syncthing or a private repo, and codex resume on the other machine will see them. Keeping the project at the same folder path on both helps. Just don't sync auth.json. Log in on each machine, and work on one at a time so the files don't clash.

[John @jjb2519]

@northbridgedev Good catch. Edit and Write alone leave the shell wide open. Adding Bash to the matcher now.

[John @jjb2519]

A rule in CLAUDE.md is a request. A hook is enforced.

If something must never happen, like Claude editing .env, I use a PreToolUse hook instead of a rule. It runs before the tool does, and exit code 2 blocks it. What it prints to stderr goes back to Claude as the reason.

[John @jjb2519]

https://t.co/Et5NfKFT1b

[John @jjb2519]

Quick thing I check on any app I build with AI: look at your env vars for anything starting with NEXT_PUBLIC_, VITE_ or EXPO_PUBLIC_. Those get sent to every visitor's browser. Your Stripe secret, Supabase service key and AI API keys have to stay on the server.

I put the 12 things I check before launch on one page, each with a prompt you can paste in.

[John @jjb2519]

@saadkamal Only from inside the project folder, never my home or Downloads folder. Before a session I check for any AGENTS.md or CLAUDE.md I didn't put there, and I keep approval on for shell commands. Treat those files like a script you're about to run.

[John @jjb2519]

@marafipe https://t.co/THUWnqXFIy

[John @jjb2519]

Welcome back! I'd start with Lovable or Bolt right in the browser, nothing to install. Pick one small thing you'd actually use, describe it in plain words, and build just that. Save a working version before every big change so you can always go back. I wrote up how the main ones compare:

[John @jjb2519]

@classicmateon @Fanfulladev @agents Yeah, if it hits something the plan didn't cover I stop it and go back to planning. Cheaper to fix the plan than chase it across five files.