The class in brief
Ekta's whole night argued one shift: stop thinking in prompts, start thinking in systems. Her System Nucleus, a six-part reusable context block, became the tool the class built and then audited for its own weak points, before naming files and placing review checkpoints the same disciplined way. After this page you can build a System Nucleus for one category of your own repeated work, audit a real workflow for where the handoffs lose context, and place a review checkpoint where the risk actually is.
The night at a glance
Why this matters · 6:10 PM
AI doesn't fix broken workflows. It exposes them.
Ekta opened on four learning objectives , then the core argument : a clear system scales cleanly, a messy one just gets amplified faster. The shift underneath everything that followed was named on its own slide, prompts are temporary, systems scale: reusable structures and defined roles instead of rewriting instructions in every new chat.
The framework · 6:19 PM
The north star for this category of work, not this one project.
Names the calls that stay human before AI ever enters the loop.
Where the machine actually contributes, stated as plainly as your own role.
Where brand voice or personal voice lives, so it stops getting re-explained.
The reasoning a teammate, or a model, should apply when a judgment call comes up.
The material that should never need re-uploading.

Definition to keep, from Ekta directly: "an operating system for yourself, based on which all similar types of projects can be run." Save it anywhere: a Google Doc, a Claude Project, a Gemini Gem .
The exercise · 6:22 PM
Not "the Nike deck," a whole category: "client presentations," say . Save it in a Google Doc, Notion, or a Claude, ChatGPT, or Gemini project.
After the break, the room mapped where those same workflows actually fail.
Brief, research, AI exploration, design development, presentation: Ekta built the chain step by step on screen, then named the exact failures between each link. Context lost between steps, feedback trapped in chats, files hard to find, decisions never captured, outputs that can't be reused. Her line stuck: "AI didn't fail. The workflow couldn't support it."
Being deliberate about what you feed AI, and what you don't want it to know. "Context is the most important word." Some people design their systems on purpose; most accrete them by accident, and accidental systems are the ones that break under AI.
The craft · 7:27 to 7:41 PM
Store context once. Reference it everywhere. Name it so a machine can find it.
Operational Systems opened with the trap most people build without noticing , then the fix: one shared project context, whether that's a ChatGPT Project, Claude's Project Knowledge, or NotebookLM . Class 4's GOLD framework got reused here as the saved project brief, so the prompt collapses to one line. Then naming: a show of hands for who has a file called Final_v2 or Final_FINAL, then the fix, a four-question formula.

The judgment · 7:49 PM
Review is important for decisions, not deliverables.
Ekta polled the room before answering : given brief, research, AI exploration, concept directions, design development, presentation, where does one review checkpoint go. The room's own answer was right : right after AI exploration, where you decide which ideas move forward. Review direction, prioritization, quality, and alignment there, not every draft, prompt, file, or revision downstream.
Methods and prompts
Fill six one-sentence rows for one category of your repeated work, then save it somewhere reusable. This is the block you stop re-explaining.
Working prompt
Help me build a System Nucleus for [category of work, e.g. client presentations]. Ask me one question at a time for each: Goal, Your Role, AI's Role, Voice/Style, Decision Logic, Sources. Keep every answer to one sentence, then compile it into a block I can paste at the start of any related project.
You will know it worked whenit asks about each of the six fields one at a time, then hands back a single compiled block you can paste at the start of any related project.
Name the weak handoff in your own process before asking AI to check your read. The point is naming the break, not getting a flattering audit.
Working prompt
Here is a workflow I run: [list the steps]. My own guess at where it breaks: [your answer, and why]. Now you check me: map the actual handoffs between these steps and tell me where context, feedback, or a decision most likely gets lost, and whether my guess was right.
You will know it worked whenit maps the actual handoffs between your steps and tells you plainly whether your own guess about where it breaks was right.
Stop rebuilding the same brief in every new chat. Save it once as project knowledge and reference it, instead of re-pasting it.
Working prompt
Here is my full project brief, using GOLD: Goal [ ], Output [ ], Limitations [ ], Data [ ]. Save this as the reference for everything else in this project, and every time I ask for something, check it against this brief before you answer.
You will know it worked whenlater requests in the same project get checked against the brief you saved, without you having to paste it in again.
Feed the four-question naming formula in once, then let the tool name its own outputs going forward. Don't fix the backlog, just set the convention from here on.
Working prompt
From now on, name every file you generate for me using this formula: [Date]_[Project]_[Type]_[Status]. Ask me for the project and type once at the start of a session, then apply the formula automatically to every output without asking again.
You will know it worked whenevery file it generates from here on carries the date, project, type, and status formula, applied without you asking each time.
Decide where your own review checkpoint belongs before asking AI to check the placement. The right answer is usually right after the machine has generated the widest range of options, not after every step.
Working prompt
Here is my workflow: [list the steps]. My call on where the one review checkpoint should go, and why: [your answer]. Now you check me: does that step carry the highest risk of a wrong direction, and would moving it earlier or later change what gets caught?
You will know it worked whenit tells you plainly whether your chosen checkpoint sits at the highest-risk step, and whether moving it earlier would catch more.
The close · 7:56 PM onward
Exercise 2 turned the room's own nucleus into a test subject : paste your nucleus and a mapped five-to-ten step workflow into a fresh chat with an "AI Workflow Consultant" audit prompt, then get bottlenecks and weak points back as a table . The takeaway was never the audit output itself, it was writing the fixes back into the nucleus so it improves for next time. Ekta's closing slide named the whole night in five lines: build a nucleus, store context once, name consistently, review decisions, and improve systems, not prompts . Next workshop was agents; tonight was laying the foundation before agents use it.
Try this prompt
Quiz me on the six parts of the System Nucleus and Ekta's naming formula. Then give me a messy example workflow and make me place the one review checkpoint correctly.
You will know it worked whenit quizzes you on the six parts of the System Nucleus and the naming formula first, then makes you place the one review checkpoint correctly in a messy example workflow.
The shelf
38 captures, in order. Click any one to see it full size.



























![⭐ Slide: "Good Names Answer Four Questions": When? Project? Type? Status? Formula: [Date]_[Project]_[Type]_[Status].](c11/thumbs/c11-044.jpg)









