Debating whether to share a project for initial feedback, it's a math game called MathMines, currently on Lovable. Wondering: -How do you know when a version 1 project you're working on is ready/safe to be shared in a community like this one? -What are your security check boxes? -Are there any best practices or protocols one should follow when first launching a project? Still trying to figure out how i could implement Jake's folder system for Version 2, gonna jump into Claude code for that one.

came back after a week offline and spent an hour just reading posts. people are shipping. full agent teams, named specialists, live clients. and i'm still on the foundation. but here's the honest version of what's actually happening. i build something. it works. then i look at it and realise it's not what i actually wanted. so i break it and start again. then halfway through the rebuild, a new idea comes in and now i don't know if i should finish what i started or pivot to the thing that's clearly better. i've rebuilt the same system three times in a month. and the worst part.. each version was better than the last. so was the rebuilding wrong? or is that just what building actually looks like before it locks in? genuinely asking because i can't tell if this is a me problem or if everyone here is quietly doing the same thing and just posting the final version.

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?

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.

For those who missed the first post or just joined: The Lyceum is a 12-week program we're building. Live instruction from Jake and the Eduba team. Small cohorts. Real projects. You build something from week one, not watch tutorials. At the end, a competition with real prizes. Eduba's first certification, backed by the same methodology we've used to train Fortune 500 teams. Now here's what we've locked in since then. The Structure Three 4-week sprints with a 1-week break between each. Not 12 straight weeks of grind. You build, you breathe, you come back sharper. - Sprint 1: Foundation — Core methodology. Everyone starts here. - Sprint 2: Application — You're building. Real project, real progress. - Sprint 3: Capstone — Finish what you started. Demo day prep. The breaks aren't fluff. They're built in so you can catch up, refine, or just live your life without falling behind. The Cohorts Same curriculum across all three. The difference is where your hours go. Technical — Developers, engineers, technical founders. You're building a tool or production system. 30% of your time goes to Claude Code and integrations. Another 30% to production systems and capstone. This is the builder track. Business — Ops, managers, founders, consultants. You're automating a process or designing a system spec. Heavy emphasis on workflow design (30%) and decision frameworks (25%). You direct the work without writing the code. Creator — Marketers, educators, solo operators. You're building a content production system. One person replaces the team. 25% on content pipelines, 20% on workflow design. This is how you scale yourself. Pick the track that matches how you work. The methodology transfers no matter which one you choose. A 4th Cohort? We're considering adding a team cohort if there's enough interest. This would be for companies that want to enroll multiple employees, or for people in the community who want to form their own team and build together. If that sounds like you, let us know in the comments.