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: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

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

∞

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. Communication: `flux:reply` is standalone and can be called at any point.

Same flow as a diagram source

flowchart TD
  EQUIP["flux:equip · setup"] -.once per repo.-> 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
  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 proposed

local marketplace → ./plugins/flux@Flux · native subagents

Not in the Plugin Directory yet. Install it from a local marketplace entry until the listing lands.

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.