Here's how we build new pages for client's now. Takes about 25% less time. First: an interview. We get the client on a call, follow a structured intake, get everything we need. Claude ingests the transcript and maps the requirements — buyer, intent, conversion action, messaging priorities. That's the foundation. Then Cash, our copywriter agent, writes the copy. Then Ruby, our front-end designer, takes the copy and the client's identity system and builds a clean HTML/CSS mockup. We hand it to the client. They give us feedback. We collect assets — photos, logos, screenshots. Then Cody. Cody has access to the Elementor JSON templates our human designer originally built for this client's site. He reads the approved HTML. He generates a new JSON file in the same structure — same design system, same component logic, same brand patterns. We import that JSON into Elementor. The page is 90% built. The humans still do the review. The humans built the original templates. The humans ran the interview. But the production time? It collapsed. Jake's folder system didn't replace the agency. It restructured where the human work actually lives.

You learned the framework. Now try it on something you're actually working on. Vote below, then drop your prompt structure in the comments. Not the output. The structure. Show us how you set it up.

Practicing building in public and wanted to share what I've built with help from my other writing brainstorming thread from @Deacon Wardlow and @Siv Darmalingum @E G and @David Trammel Using some of their ideas I did research on the writers and topics they suggested using Notebook LM. I synthesized that research into digestible artifacts for claude to extract themes and guidelines for developing conference talks. I then described to Claude the workflow I wanted to build, can share that prompt if people are interested. And then I also used the workspace-builder as a model for the scaffolding for the conference-talk-engine and my own workspace as models for schema in the Claude and Context mds. The output of all of this was a spec document to build the workspace. I incorporated guidelines to use SOLID principles for coding to allow a built workspace to be extended and improved upon over time without having to rebuild the whole workspace, this is because I think it's better to build a prototype fast and then iterate rather than be 100% perfect. You want to spend time to make sure that the spec doesn't produce errors, but some things will only show up with actual use cases. I then researched existing skills relevant to my use case and came up with 2: conference-talk-builder and giving-presentations. I asked claude to evaluate my research and the existing skills to see what gaps could be improved in the existing skill. I then asked it to write the spec After first draft of the spec I ran a reader-test which is a custom skill derived from @Ari Evergreen 's 6 phase workflow. A rough breakdown would be: 1) research data inputs and relevant skills, compile any useful context relevant to your workflow; 2) analyze inputs with claude; 3) describe your ideal workflow and any models you want to emulate, make sure to mention you are building a spec first; 4) review plan for spec; 5) draft the spec using claude; 6) reader-test to qa the spec.