A previous build of the same app shipped 8 phases with green ticks, 61 tests passing, screenshots in every chunk report, done markers everywhere. First launch was a black screen. The contract had drifted three phases earlier. The same context that introduced the drift was the one validating the work. Self-audit can't catch this. The degraded session that produced the bug is the same one evaluating it. So I stopped letting one model do all three jobs. The split Brain holds the spec, the plan, the briefs, the verification judgment. One consistent context across the whole project. Hands execute one chunk at a time against a tight contract. No memory between chunks. Cheap to dispatch, ruthless about scope. Eyes approve the visuals. That's me. Refusing to auto-approve based on a commit message. Shipped a Mac app in three days on this loop. Two phases tagged clean. 123 tests green. Atmospherics visually approved on first build. Zero rebuilds. The five artifacts 1. Spec. What the thing is. Architecture, decisions, and two inventories most specs miss: a craft inventory (the prototype details that aren't in the original brief, every glow and curve) and a staleness inventory (paths and tools that drifted since prior work). 2. Plan. How to build it. Every task is two to five minutes of work, lists files-to-touch, steps, tests, and the exact commit message. TDD baked in. 3. Briefs. Dispatchable units of plan. One per chunk, five to eight tasks each, 60 to 95 lines. 4. Prompts. Paste-ready, no fill-in-the-blanks. Continuation prompts and self-contained fresh-session prompts. 5. Handoff. End-of-session continuity doc. Where things are, the next prompt to paste, decisions made, open items. The next day's session reads it like a contract. The dispatch loop Per chunk: paste prompt, executor runs (5 to 30 min), executor reports, planner verifies with fresh context, approve or correct. Verification is non-negotiable. Git log, file system, test count, snapshot record-flag, launch and look. The executor sometimes claims victory prematurely. The verification step catches it.

This might be a dumb question but what exactly are the practical benefits of taking the folder based approach? Does it provide more efficient use of tokens, more consistent results? How can we demonstrate this so we can sell this idea to others? I tried creating a sample home page using the folder based approach versus standard claude.ai but couldn't really see a big difference.

Context: I want to pitch a few talks to conferences in my field (game audio), and its not something I do regularly so I don't have established workflow for it. I do write linkedin posts and prep for my DND sessions, but that output is significantly different than a 30m to 1hr talk. I've been doing one approach, which I'll outline below, but I'm wondering if others have done this and have a more efficient way of getting to a final result, the below took me 2 sessions both a few hours each, and I'd love to compress that. Wondering about other approaches or resources to help create a better framework. Current process (captured in a skill after finishing last submission): 1. Claude asks : "What could you talk about from memory right now, without looking anything up?" and "What do you know how to do, or think about, that most people in your field don't?" (this takes a long time) 2. feed it which conference, deadline, and format the talk submission is 3. Claude researches past accepted talks for fit and content 4. We lock in thesis, pillars, and target audience (this takes the longest) 5. we do a draft in this order: Description, takeaway, outline 6. Pre-submission review (this part is easy with humanizer and the conference form submission) Wondering if there are places I could improve? And how would others approach this?