I Had 11 AI Satellites and No Way to Brainstorm. Here's What Changed.

I had a system that could build software. Architecture, code, tests, deployment, documentation — all handled by named AI Satellites with defined roles and structured outputs.

What I didn’t have was a system for the part that matters most: deciding what to build.

The Gap

The Stella Protocol v4 had 10 Satellites. They covered every phase from system design to deployment monitoring. But when I had a raw idea — “I want to build an app that breaks bad habits” — there was no satellite for that. No structured process. I’d dump the idea into a conversation, get some scattered thoughts, and either jump straight to architecture (too fast) or let the idea sit in an empty directory forever.

Anti-Habit has been an empty folder on my machine for weeks. That’s the symptom.

The Fix: IMU and Five Protocol Changes

IMU — The Brainstorming Satellite

The biggest addition. IMU is a Phase 0 satellite that runs before anything else. When I have a raw idea, IMU runs a structured protocol:

1. Reframe the idea three different ways
2. Validate the pain — who specifically has this problem, why now, what are they doing instead
3. Map adjacent ideas — three related directions worth considering
4. Pre-mortem — top three reasons this fails
5. Define minimum proof — the smallest thing that validates the core bet
6. Output an Idea Brief — a one-page document that becomes the seed for everything after

If IMU can’t find a real user pain in step 2, it vetoes. The idea gets flagged and halted. No research phase, no architecture, no code. Kill it or rethink it.

The Idea Brief is the new gate. I approve it before anything else starts.

Two Tracks: Full and Lightweight

Not every idea needs five DEFINE satellites.

Full Track is for new projects or features over a week of AI execution. Full DEFINE phase: research, architecture, UX, PRD, red team review.

Lightweight Track is for experiments and small features under a week. IMU produces a Mini-PRD directly inside the Idea Brief — problem, features, acceptance criteria — and skips straight to BUILD. No separate research or architecture unless I ask for it.

I decide which track after seeing IMU’s output.

LILITH RED Fires Twice

The spec pass still happens in DEFINE — reviewing the PRD for business logic abuse, scope creep, privacy risks.

New: an implementation audit after all P0 features are built. This one reads actual code. Checks for SQL injection, auth bypass, PII exposure in API responses, unvalidated inputs, hardcoded secrets. Different satellite mode, different checklist.

Silsilah’s data redaction layer is exactly the kind of thing that needs a code-level review, not just a spec-level one.

Phase 2.5: ITERATE

After shipping, user feedback triggers a scoped loop:

1. Describe the feedback or change
2. Scope protocol fires — is this in the PRD?
3. If approved, create a PRD amendment (date + rationale)
4. Edison builds, Lilith Blue tests, Atlas deploys
5. Update the brain files

No full re-planning for a small change. But if amendments accumulate past ~30% new surface area, it flags that a PRD v2 is needed through the full DEFINE phase.

Implicit Activation

I used to write “EDISON — build the login page.” Now I just write “build the login page.” Satellites activate from natural language context. The names exist for documentation and status reporting, not as commands I need to memorize.

The Tooling Question

I also asked a question I’d been sitting on: should I connect external tools for prototyping and UI design?

Tools like Replit, Lovable, v0 for quick prototypes. Figma or Framer for UI.

The logic: when AI builds everything, prototyping in a separate tool means rebuilding from scratch on the real stack. That’s a full wasted cycle. Prototyping natively means the artifact you validate is the artifact you ship.

The exception is brand-level visual design. If a project outgrows “works well and looks clean” and needs genuine visual identity work, that’s when Figma earns its place. Not at MVP stage.

What v5.1 Looks Like Now

PHASE 0: IDEATE       →  IMU (brainstorming + Idea Brief)
PHASE 1: DEFINE       →  Pythagoras Exp + Shaka + ODA + Pythagoras Doc + Lilith Red (spec)
PHASE 2: BUILD        →  Edison + Lilith Blue + Lilith Red (code audit) + Atlas
PHASE 2.5: ITERATE    →  Feedback → scoped PRD amendments → Edison → Lilith Blue
PHASE 3: CLOSE        →  York + Morgans

Plus: lightweight track for small bets, cross-project prioritization when starting a session without a specific project, and an ideas backlog in /brain/ideas.md so nothing gets lost.

The Honest Failure

I had a global CLAUDE.md file that was completely empty.

This is the file that loads into every Claude session, across every project. It’s the single most powerful configuration lever in the system. And it was blank. Every new session started cold — no identity, no stack preferences, no protocol. I was re-explaining who I am and how I work over and over.

The fix was obvious once someone pointed it out: fill the file with the Stella Protocol, communication preferences, active projects, and tech stack defaults. Now every session starts with full context. The overhead of re-explaining dropped to zero.

The lesson: sometimes the biggest productivity gain isn’t a new feature. It’s using the feature you already have.

Satellite: Morgans (this post) · IMU (ideation protocol design) · Pipeline: ITERATE — IMU → Morgans