Open Loop: customizable prompts + flows, domain presets, marketplace

[suleimansh]

Split out from #190 to keep that issue scoped to the extension SPI. This one holds the bigger product direction from @brillout.

The core idea: what The Framework really does is built-in prompts + flows (the loop). Make both fully customizable by the user, and you get an unopinionated, flexible frame. Working name: Open Loop.

Presets

Domain presets bundle a set of flows + prompts:

• "Software Development" (flows for code quality, testing, reviewing; prompts nudging quality/security)
• "Web Development"
• "Product Managing"
• "Biological Science"
• "Data Science"
• ...

Presets can also be collections of presets, for fine-grained composability.

Marketplace

A marketplace of presets and prompts (and maybe skills) on top of Open Loop.

Naming split

• Open Loop = the unopinionated core loop (customizable prompts + flows).
• The Framework = everything on top: hosting, the web UI, the mobile app.

Modes (parameters)

Per-run params that reshape prompts and flows:

• Technical mode — whether the user is technical. Non-technical tailors prompts (e.g. review TLDR: "never mention implementation details, only business flow") and flows (e.g. auto-merge PRs that do not touch business logic).
• Autopilot mode — minimize interruptions; only ask the user for major business-logic decisions.

Business model idea

Mobile app at $1/month.

---

This is a direction to evaluate, not a committed build. #190 stays focused on the mechanical piece we can ship now (self-registering framework-* extensions).

[suleimansh]

Open Loop: where it already is, and the 3 things to decide

Short version: the core of Open Loop is mostly already built. What we ship today is prompts-as-data and a loop that is a rules engine, not a hardcoded flow. So "customizable prompts + flows" is not a rewrite. It is naming, one bundling concept, and a couple of params on top of seams that already exist.

What's already there

• Prompts are data. Each prompt is frontmatter + a markdown body, loaded from a directory (loadPromptsFrom). Anyone can add or edit one without touching code.
• The loop is a policy of rules. The engine takes rules + prompts; defaultLoopRules() is just the built-in web-app policy. Swap the rules, you swap the flow.
• Skills are the knowledge unit. A skill now carries its framing personas plus an llms.txt pointer (just merged). Domain knowledge rides this.
• Discovery already works. framework-* packages self-register and compose in (the SPI we just shipped). The same pattern extends to distributing bundles.

What's genuinely new (the actual Open Loop work)

1. A "domain preset" = one named bundle of {loop rules + prompts + skills}. We have all three as data. We don't yet have the unit that ties them together and can be selected and composed. This is the keystone. Presets-of-presets falls out of making the bundle composable.
2. Modes as params. Technical and Autopilot reshape which rules and prompts apply per run. Small, but needs a home in the run options and in rule conditions.
3. Marketplace = distribution of bundles. The framework-* discovery pattern is the prototype. A marketplace is that plus a registry and an install story.

3 things to decide at the sync

• Naming. Open Loop (core loop) vs The Framework (hosting + UI + mobile) vs the GemStack umbrella. Where does the line sit, and is "Open Loop" the public name?
• Domain-preset shape. Is a domain preset literally {rules, prompts, skills} + signals, defined the same way framework presets are? And do domains detect (like frameworks do from deps) or are they always user-picked? "Biological Science" will not detect from a package.json.
• Scope for a first cut. Smallest shippable Open Loop: one non-web domain preset (say "Software Development" as rules + prompts over the existing loop) plus the two modes, no marketplace yet. That proves the bundle unit end to end. Agree on that as the first slice?

Not building yet. This is to frame the sync.

[suleimansh]

@brillout

[suleimansh]

Two more from Rom to fold in here:

• Domain: the-framework.ai (for The Framework = the hosting + web/mobile UI layer, per the naming split above).
• Business model: a shared team web interface, where a run's sessions can be shared across multiple accounts (teammates watch/steer the same build). Sits alongside the $1/mo mobile idea.

[brillout]

• Domain-preset shape. Is a domain preset literally {rules, prompts, skills} + signals, defined the same way framework presets are?

• Good point, and I agree: presets should also include skills.
• So, yes, a preset is just a collection of loops, prompts, and skills.
• Not sure what you mean with "signals".
• Naming: I'd suggest naming it "loops" instead of "rules". (Because "loops" is what users reason about, whereas "rules" is a technical detail that powers loops.)
• Framework presets: I'd say let's entirely skip framework presets for the MVP. (The ecosystem needs and will eventually find a convention to systematically communicate skills between tools like Vike and agents like Claude Code.)

And do domains detect (like frameworks do from deps) or are they always user-picked? "Biological Science" will not detect from a package.json.

How about we try to make it no-code. So no package.json. (Also, a package.json would "couple" it to JS => not good.)

I'd say:

1. MVP: let's just persist presets in ~/.config/the-framework/ for now (or MacOS/Windows equivalent)
2. Post-MVP: we add accounts and authentication (while supporting a logged-out anonymous quick start.)

• Naming. Open Loop (core loop) vs The Framework (hosting + UI + mobile) vs the GemStack umbrella. Where does the line sit, and is "Open Loop" the public name?

Yes, Open Loop is a public name:

• It's a platform: other (upcoming) AI frameworks can use Open Loop and its marketplace.
  • The marketplace is 100% open source and non-proprietary
  • It's "the Wikipedia of AI prompts, skills, and loops". (I like that sentence, I'll put it on the landing page.)
  • The marketplace is 100% gratis. (Prompts/presets are trivial to create, so paying for it wouldn't make much sense anyways.)
• It's a marketing term: we communicate it as the core technology that powers The Framework.

Technically, Open Loop is just a marketplace, whereas The Framework is the code that glues the marketplace with Claude Code and The Framework's UI.

Maybe Open Loop can simply be a GitHub repository that just collects a bunch of .md files. We can then expose it as an npm package that @gemstack/framework uses. E.g. the-open-loop (I also own the npm org @the-open-loop, and the GitHub org the-open-loop).

Addendum: rules

Technically, what are rules/loops?

Maybe it's just a special prompt that tells AI how to loop itself? Basically a meta prompt: "if code is ugly, then invoke a new AI agent that cleans the code". In other words, it's a meta agent that invokes sub-agents.

Maybe we can rename "rules" to "meta prompts"?

So a preset is basically just this:

• A list of prompts
• A loop (technically a meta prompt)
• A list of skills

Note

I deliberately call it "loop" because that's how users will reason about it, even though technically it's just a meta prompt. (We can explain Open Loop contributors that a "loop" is just a meta prompt.)

I'd say orchastration aspects like avoiding infinite loops (or loops that run for too long) are the concern of AI frameworks (not an Open Loop concern).

Addendum: modes

Technically, how do we implement modes?

Maybe it's a new .md syntax that implements if-conditions?

Maybe, for the MVP, we can just have different meta prompts instead. Let's see if we need real parameters. The UI asks the user if he wants technical control and autopilot, we then select the right meta prompt. Maybe as a frontmatter argument conditions:

loop.md
loop.autopilot.md # sets `conditions: autopilot` in frontmatter => overrides `loop.md`

prompt.md
prompt.technical.md # sets `conditions: technical` in frontmatter => overrides `prompt.md`

But if the .md files are too similar, then maybe we really need a way to compose prompts.

[brillout]

I'd say:

1. MVP: let's just persist presets in ~/.config/the-framework/ for now (or MacOS/Windows equivalent)
2. Post-MVP: we add accounts and authentication (while supporting a logged-out anonymous quick start.)

I've a better idea. How about:

• The user's repository persists the presets and modes (e.g. autopilot is a boolean in a the-framework.yml file)
• When bootstrapping (no the-framework.yml file found)
  => auto-select presets depending on 1. prompt and 2. current directory
  => UI checkboxes [ ] Autopilot and [ ] Technical Control

So, when bootstrapping, there are two levels of meta prompts:

• The meta-meta prompt that asks AI "Read the prompt and the current directory, then select presets accordingly"
• The meta prompt of the preset