About 1.5 years of vibe coding, a year-plus of that on Claude Code, building production sites for actual paying clients. Genuinely rewarding ride with plenty of faceplants. My biggest faceplant: I ignored agents and skills until a couple months ago. Big mistake. Here is the whole system I run now, with real examples from my current build. Foundation first. This is the #1 thing I’d change. Most vibe-coded sites look planned-but-basic because people skip straight to “build me a homepage.” Generic input, generic output. Before I ask for a single component, I feed the model the project: brand docs, reference screenshots, and concrete examples of what “good” looks like for this specific brand . Spend the boring hours up front and everything downstream gets faster and stops looking templated. Learn the four primitives and how they fit together. Stop treating Claude Code like a chat box. Four building blocks that work as a system: CLAUDE.md = the constitution. Always-on project rules it reads every session (brand, banned words, hard standards). Memory files = persistent facts across sessions. What’s locked, what’s decided, what broke last time. Agents = specialized roles, each owning one craft. Skills = standardized repeatable processes you invoke like slash commands. Most people use the first one and wonder why output drifts. The actual agents I run. I give each agent a codename and one job, so it’s an opinionated specialist instead of a generalist, and it auto-fires when its domain comes up: Wraith (creative director) = brand filter and page-flow cop. Has authority to kill any section that doesn’t earn its place. Riddle (copywriter) = owns every visible string, the voice, and the banned-words list. Cipher (SEO) = owns H-tags, meta, the keyword map, and internal links. Lattice (structured data) = owns all JSON-LD / Schema.org, tuned for both Google rich results and AI-answer citations. Ember (designer) = layout, spacing, color, hover states, section rhythm. Forge (developer) = architecture, components, TypeScript, performance patterns. Sprite (responsive auditor) = kills horizontal overflow and fixes mobile/tablet/desktop + touch targets. Nitro (performance) = Core Web Vitals. LCP, CLS, INP, bundle size. Vault (database) = Prisma schema, migrations, queries, seed data. Bastion (backend) = API routes, auth, webhooks, server actions. Sentinel (pre-ship) = runs the final checklist (schema, links, alt text, mobile) before anything ships. The win is not “more bots.” It’s that each one carries deep, narrow context and a clear veto, so I am not the bottleneck on every decision. For tough decisions I really ask to organize a round table discussion amongst the core team and come up with plausible solutions form which I can pick one and move… The actual skills I run. Skills standardize a process so it runs the same way every time, and they save serious tokens because a skill can run Python or bash that Claude itself writes instead of the model reading and rewriting files by hand: /page-build = build a new page end to end, running the agent chain in order (Wraith to Cipher to Riddle to Ember to Forge to Sprite to Sentinel). /component-build = build or fix one component or CSS surface. My default for ~70% of work. /copy-pass = rewrite/audit visible text against voice + banned words. /seo-audit = H-tags, meta, schema, alt text, anchors, internal links. /responsive-pass and /performance-pass = the mobile and Core-Web-Vitals sweeps. /ship-ready = the final pre-ship gate. /css-portable-extract = promote a one-off CSS block into a reusable primitive. /session-close = log the session, update memory + docs so the next session starts with full context. Mechanical beats model. Anything repetitive and deterministic is a script, not a 50-file manual edit. A one-liner that strips em-dashes and banned phrases site-wide. An image-audit script that flags any asset not on my CDN. A CDN-upload script. Cheaper in tokens, far more reliable. Build skills around YOUR site’s real recurring needs. The .env.example trick (underused). Set up .gitignore and .env , never paste secrets into chat, and keep .env out of what Claude can read. Then create a .env.example with the same variable names and no values. Claude reads that to know which variables exist and how to use them, without ever seeing a real key. A real image pipeline. I use ImageRouter and taught Claude to produce high-quality, on-brand images on demand. Dedicated agents and skills handle: generating brand-consistent artwork, chroma-key background removal to transparent cutouts, multiple art styles, and storing it all in a structured, catalogued way. Borders and frames are reusable systems, not one-offs. Headless WordPress + Next.js. Clients get a WordPress backend to edit blog posts in a CMS they already know. I connect that backend into Next.js and render on a fast custom front end. Client-friendly editing, no compromise on speed. Don’t trust the model’s memory for facts. Build a fresh knowledge base instead. This is my single most powerful move, and it has two levels. The simple version: when I need to onboard a tool I am not an expert in (say, Railway hosting), I dump the official docs, guides, and API references into one markdown file, let Claude study it, and spin up a specialized Railway agent. It is now a genuine expert and I never had to become one. ++ this is ace and has saved me so much time I can’t even imagine… a skill that pairs the Brave Search API with a layered scraper to build a real knowledge base from thousands of live websites in a few hours. It finds the right URLs, pulls and cleans the actual current content into a folder, then Claude studies that and builds its own up-to-date base. Because it is grounded in real content scraped from real sites, not the model’s training memory, the output is far more accurate, far more current, and the work goes dramatically faster. This one tactic changed the quality ceiling of everything I build. The takeaway: foundation, then the four primitives working together, then grounding the model in real sources instead of its own memory. That is the difference between a site that looks planned and one that’s actually good. Here’s a client site I built this way: www.labyrinthescapegaming.com . Honest feedback welcome, including the harsh kind. Happy to go deeper on any of these in the comments. submitted by /u/mezm3r
Originally posted by u/mezm3r on r/ClaudeCode