Fluxtion is unusually well-suited to being written by an LLM — you author intent (nodes, wiring, audit fields) and the compiler guarantees the behaviour (determinism, audit, replay). You can't introduce a race or a non-deterministic decision by being a careless author; the source-gen step enforces. The trick is bootstrapping the model so it converges fast. Three things do most of the work.
You write nodes; the compiler wires them. Each node is ~30 lines — a few fields, a constructor naming its upstreams, one trigger method — so the model reasons locally, one node at a time, without holding the whole topology in context. Topo-sort, dispatch order and change propagation are all the compiler's job.
And the guarantees survive being machine-written. If the model tries to spawn a thread, mutate state from outside the graph, or skip a trigger annotation, the framework rejects it or the generated processor simply won't dispatch it. The author writes the specification; the compiler is the safety boundary. So the model worries about whether the spec is correct, not whether the code is "deterministic enough".
Timing target: from a Mac with nothing installed to your first audited run in under ten minutes. One setup question, one reconnect and a browser sign-in (optional for setup; needed for processor generation, free). The production trial passed in Manual mode, but did not establish that timing target; downloads, browser approval and the task affect elapsed time. The Fluxtion Analyser is where your assistant shows you the evidence: it opens a run's audit log beside its graph and points at the records that support the explanation. Ask your assistant to set it up, answer one question, and it installs the Analyser, opens it and checks the connection. No Java or JBang needed first (setup downloads one Java 21); the compiler sign-in is optional for setup and needed for processor generation; the audit-analyser bundle can first build its shipped processor without it. Signing in charges nothing; free-plan limits apply.
/plugin marketplace add telaminai/claude-plugins /plugin install fluxtion-analyser@telamin
After marketplace installation, if Claude Code asks, run /reload-plugins --force or start a new session before setup. Then say:
Set up the Fluxtion Analyser and connect it to this assistant.
In the tested interactive terminal, reconnect works without restarting. Run /mcp reconnect plugin:fluxtion-analyser:fluxtion-analyser when asked; the assistant then checks the connection itself.
Set up the Fluxtion Analyser and connect it to this assistant. Follow https://fluxtion-playground.dev/skills/analyser-setup/SKILL.md and ask me before changing anything.
The assistant follows the published, checksum-pinned setup instructions. Claude Code then needs one restart
(/exit, then claude --continue).
analyser-setup plan * rule covers matching plans in that project; analyser-setup apply * is separate. Setup does not change your permission mode.Automatic setup supports macOS with Claude Code in an interactive terminal. The earlier preview passed production marketplace installation; other hosts and managed pre-install remain untested. Linux, Windows and teams that don't let an assistant install software use the manual install. Details, day-2 recovery and team pre-install: Set up with your AI assistant.
CLAUDE.md is the canonical Fluxtion author-orientation — the mental model, the source-gen triage
(symptom → fix), services, build-time generation, the dirty/else branch. In Claude Code,
drop it in as a CLAUDE.md at the repo root (it auto-loads). With
an API/agent, paste it as the system prompt. Pair it with the golden-path guide — the one blessed shape (imperative AOT + audit + named sinks + test) as copy-paste code.
Fluxtion's compile errors are directive — use @AssignToField, add @FluxtionIgnore —
but only help if the model can run the compiler and read them. The browser playground (zero install) or a local mvn build is enough. A model with a run loop beats one without it by a wide margin, because each error names the
next move — so it self-corrects instead of guessing.
LLMs pattern-match working code far better than prose. The template menu tells the model which shape to pick and whether it needs a key; the playground examples are the real code to match. Tell it: "match the closest example before improvising."
Read the Fluxtion orientation doc (CLAUDE.md) and the golden-path guide. Pick a shape from /starter-templates/index.json; match the closest example in the playground before improvising. You have a compile/run loop — Fluxtion's errors are directive, so when one fires it's telling you the fix: apply it and re-run. Reason locally per node; let the compiler handle the topology.
Then point it at the closest playground example for the task and let it iterate against the errors.
Instead of writing nodes, describe the app to an LLM and let it emit a Spring XML file. Drop that file on the project starter and it generates a runnable skeleton — event records, node classes, wiring — for you to fill in. The LLM is a design-time partner; the running app is deterministic Java with no model in it.
Help me design a Spring-defined Fluxtion application. We'll discuss it, then you emit one Spring XML file I can drop on the Fluxtion project starter to generate a runnable skeleton. Read these first, in order. If you cannot fetch a link, say so and I'll paste its contents — do not proceed from memory. 1. Orientation — the core Fluxtion model (nodes, events, compile-time graph, determinism): https://fluxtion-playground.dev/CLAUDE.md 2. Authoring skill — how to run this conversation (describe -> events -> nodes -> wiring -> emit): https://fluxtion-playground.dev/spring-authoring/skill.md 3. XML contract — the exact FluxtionSpringConfig shape you emit and the starter imports: https://fluxtion-playground.dev/spring-authoring/contract.md 4. Worked example — a full run (conversation -> XML -> generated skeleton): https://fluxtion-playground.dev/spring-authoring/example.md Then act as my design partner: ask what the app does, pin the input events, the nodes and which node handles which event, and the dependencies between nodes. Confirm the design in plain English — including anything that will NOT be generated — then emit one valid Spring <beans> XML per the contract: - events as eventTypes (FQCN strings, not eventClasses); - nodes in nodeBeans, and which node handles which event as eventHandlers bindings; - dependencies between nodes as constructor-arg ref; - singular role packages (<base>.node.MyNode, <base>.event.MyEvent — never .nodes/.events); - external services in serviceTypes (FQCN interfaces) + serviceRegistrations (attach each to its consuming node) — never as beans, never constructor-wired; the starter generates @ServiceRegistered callbacks + interface stubs. ignoredBeans is only for genuine non-service support/config beans. Emit exactly one XML file and no Java; the starter generates the stub classes I'll fill in.
The prompt points the model at these — or read them yourself:
FluxtionSpringConfig shape the LLM emits and the starter imports.Read the orientation doc first for the core model; the skill layers on it.
Open the playground, paste the prompt, and let it author against directive errors — no install.