Roles and mods are how you specialize a step’s behavior without writing a new prompt from scratch. Both are drawn from a signed marketplace catalog: 12 flows, 14 roles, 33 mods, and 7 steps, ready to drag onto the canvas or attach to a step.

Roles: the persona

A role is who is doing the work. It contributes a system prompt that frames the step’s whole approach, and exactly one role is active per step — attaching a new one replaces whatever was there before. The catalog spans generalist and specialist personas: frontend-engineer, backend-engineer, full-stack-engineer, mobile-engineer, devops-engineer, data-scientist, ai-engineer, security-researcher, qa-engineer, software-architect, technical-writer, product-manager, design-engineer, incident-responder — 14 in all.

Mods: stackable constraints

A mod is how the work must be done — a constraint layered on top of a role, injected into the step’s system prompt. Unlike roles, any number of compatible mods can stack on the same step (for example test-driven + strict-linting + zero-dependencies together). Mods cannot attach to flows themselves — only to steps — since a flow already carries its own rigid, pre-planned system constraints and stacking a mod on top would fight it.

Most mods are pure prompt injection, but a mod’s registry entry can declare runtime powers — inert, declarative data the executor interprets against a fixed set of built-in capabilities, never arbitrary command execution:

• blockTools — tool names stripped from the step while the mod is active. dry-run blocks write_file, so “no code generation” is a guarantee enforced by the runtime, not just a request in the prompt.
• attachTools — built-in toolsets granted while the mod is active. seo-meta and web-vitals both attach a web-browser tool so they can check their own claims against the live page instead of asserting blind.
• contract — a StepContract fragment merged into the step’s contract and enforced by the guardrail engine. test-driven requires at least one real test-file artifact to exist (*.test.*, *.spec.*, test_*.py, *_test.go, …) before the step is considered done — the Red in Red-Green-Refactor is checked, not assumed.

Exclusive groups

Some mods are mutually exclusive by design, grouped under an exclusiveGroup: only one member of a group can be active on a step at a time, and the loader derives the conflict automatically from the shared group name. Two examples already in the catalog:

• design-system — ds-tailwind and ds-shadcn pin a step to one styling approach; you can’t blend two design systems on the same step.
• output-verbosity — verbose-comments and output-budget pull in opposite directions (maximal explanation vs. minimal tokens), so only one applies at a time.

When stacked mods conflict

Precedence between stacked mods is deterministic, not first-come-first-served: security > correctness > scope > style. A tie between two mods at the same precedence level resolves in favor of whichever was attached first.

Domains

A role or mod can declare domains — frontend, backend, web, data, infra, or universal (role-agnostic, like self-review). Domains are informational, not enforced: the UI hints when a mod’s domain doesn’t match the step’s role (e.g. attaching ds-tailwind to a backend-engineer step), and Text-to-Flow uses them for auto-selection — but nothing blocks the combination outright.

Flows and steps in the catalog

The same signed catalog also ships prebuilt flow templates (12 of them — auto-refiner, auto-optimizer, auto-visual-fixer, brainstorm-cards, and more, several with a -finite variant that bounds an otherwise-infinite refinement loop) and prebuilt step templates (7 — write-failing-tests, review-diff, scaffold-structure, implement-to-green, and others) you can drop onto the canvas as a starting point, the same way you’d attach a role or mod.

Attaching and composing

From the canvas, drag a role or mod card from the marketplace onto a step. See Flow Design for the hands-on walkthrough.

Why the catalog is signed

market/ content is concatenated verbatim into agent system prompts, which makes it a prompt-injection surface — a tampered role or mod file is a tampered agent. Heliox closes that gap cryptographically: every catalog file is hashed (sha256) into a deterministic manifest, and the manifest itself is signed with ed25519. The signature is verified before the catalog loads, so “an unmodified market/ tree” is a technical guarantee, not a social rule about who’s allowed to edit the folder.

Next steps

• Flow Design — attaching roles and mods to steps you’re building.
• Core Concepts — how roles and mods fit the wider execution model.