open workflow family

One workflow.
Every harness.

Flux carries work from an idea to a shipped change, with the same contracts wherever you run it.

the map

Input first. Commands second.

A thread, bug report, or idea is the input. Each step below is a command with a boundary, and the contracts shown mirror the shared skills in the repository. No command silently calls the next one.

flux:map ↗ setup

Surveys the whole installation on this machine: agent roots, context manifests, repos, and the three review lenses of each one. Reports what is broken and what would change. Suggested before anything, required by nothing.

Input: nothing (the machine)
Output: inventory, delta since the last run, and an integrity report with one-click remediation
Writes: the agents index; repairs run only where you accept them, one by one

flux:equip ↗ setup

Equips a repository with what it lacks: an execution motor and a local specialist suite. Runs once per repo, outside the cycle.

Input: a repository
Output: motor and specialists the repo was missing
Writes: only where you confirm; never inside the target repo

Idea, thread, or bug reportthe input that starts the work

OPT

flux:refine ↗ optional

A fast SDD in a single round: product brief, technical brief, and a sliced plan, all grounded in the real codebase. Measures scope first and refuses what is too large, handing you the proposed cut.

Input: the same idea, thread, or bug
Output: brief, contracts, and ordered slices; or a reasoned refusal
Writes: vault only; never creates an issue

flux:issue ↗

Turns free-form context into an issue grounded in the real codebase.

Input: thread, text, PR
Output: issue draft; Linear only after approval
Writes: vault draft, optional tracker issue

flux:build ↗

Dispatches implementation to the repository’s native execution motor.

Input: ticket or description + repo
Output: code and PR draft
Writes: dedicated worktree via repo motor

One or more pull requestsfrom here on, the path depends on how many

two lenses, same target — pick by how formal the pass needs to be

flux:peek ↗

A fast, read-only lens for a tree, diff, branch, PR, document, or path.

Input: working tree, range, PR, doc, path
Output: holistic report in chat
Writes: nothing, except explicit `--save`

flux:review ↗

Produces a formal review by reconciling the holistic lens with specialists.

Input: PR or document
Output: structured review artifact
Writes: vault; posts only after approval

one PR, or a delivery made of many

flux:iterate ↗

Closes the loop on one PR: verifies findings, applies corrections, responds, and watches CI. Run up to three independently in parallel; above that, use `land`.

Input: one PR
Output: one PR ready, with replies and CI state
Writes: worktree, commits, push, GitHub actions

flux:land ↗

Coordinates a delivery made of multiple PRs, delegating per-PR iteration and emitting a merge-ready go/no-go.

Input: issue or multi-PR feature
Output: topological order and multi-PR verdict
Writes: keeps PRs ready; never merges

✓

Merge-readythe human decides the merge; no command does it

∞

two standalone lanes — call either one at any point in the work

flux:probe ↗ any point

A standalone investigation lane: turns production telemetry into a quantified dossier, tests the current explanation against the physics of the numbers, and asks whether the server saw what the client reported.

Input: error tracker issue or observability query
Output: dossier with denominators, grounded in code
Writes: vault; never changes state at the source

flux:reply ↗ any point

A standalone communication lane: turn a Slack case into a code-grounded, reviewable draft at any point in the work.

Input: thread permalink
Output: Slack-safe draft and case board
Writes: draft/vault; never sends alone

Input: idea, thread, or bug. One PR: use `flux:iterate`; up to three can be iterated in parallel. More than three PRs: use `flux:land` to coordinate the delivery. Production bug: `flux:probe` measures it before anyone writes an issue. Communication: `flux:reply` turns the case into a draft. Both are standalone and can be called at any point.

Same flow as a diagram source

flowchart TD
  MAP["flux:map · setup"] -. suggested, never required .-> EQUIP["flux:equip · setup"]
  EQUIP -. suggested, never required .-> INPUT
  INPUT([Idea / thread / bug]) --> ISSUE["flux:issue"]
  ISSUE --> BUILD["flux:build"]
  BUILD --> PR([one or more PRs])
  PR --> PEEK["flux:peek · read-only"]
  PR --> REVIEW["flux:review · formal"]
  PEEK --> ITERATE["flux:iterate · one PR"]
  REVIEW --> ITERATE
  PR --> LAND["flux:land · many PRs"]
  ITERATE --> READY([merge-ready])
  LAND --> READY
  PROBE["flux:probe · standalone"] -. available at any point .-> ISSUE
  REPLY["flux:reply · standalone"] -. available at any point .-> READY

start here

Pick your native harness.

One source of truth, installed where you already work.

Claude Code

/plugin marketplace add grippado/flux/plugin install flux@fluxRead the guide ↗

Cursor

git clone github.com/grippado/fluxscripts/install-cursor.shRead the guide ↗

Codex

codex plugin marketplace add grippado/fluxcodex plugin add flux@flux

Install from the repository marketplace, then start a new Codex session.

Read the guide ↗

native by design

Built in its native harness.

The Claude plugin was made by Claude. The Cursor plugin was made by Cursor. The Codex plugin was made by Codex. Each adapter respects its host while the workflow contracts remain shared.

Claude → Claude pluginCursor → Cursor pluginCodex → Codex plugin

not a motor

A family of open workflows.

Flux is not a tool tied to one engine. It is a portable set of decisions, boundaries, and handoffs. New harnesses can speak the same language without forking behavior.

Violeet is the product. Violeeter is the visual system. Flux is a sibling tool built with the same visual language.

make it yours

Bring the next good idea.

Translations, new commands, agents, accessibility improvements, integrations, and new harnesses all belong in the conversation.

Choose a contribution path ↗

“

Choose a focused template, or open a clear RFC with your own structure, thesis, evidence, alternatives, scope, and acceptance criteria.

open invitation

A harness is next.

Bring Flux to another engine without forking the workflow. A good adapter should preserve the shared skills and contracts while translating resource resolution, delegation, and capability limits into its native runtime.

show a real user need and evidence
define the native delegation model
document degraded capabilities and acceptance checks

Choose a proposal type ↗

the wider constellation

Held by [GLabs].

[GLabs] is the umbrella that ties the family together in Violeeter’s visual language.

Violeetthe product · direct reference ↗Violeeterthe visual system · direct reference ↗

One workflow.Every harness.