The marketplace

Synthex was born as a Claude Code plugin distributed through the LumenAI marketplace. The same source now also ships as a portable Agent Skills bundle, so the workflows can run in compatible harnesses without forked prompts. Every distribution path is plain Markdown and YAML, keeping the source of truth inspectable.

#Install flow

#Claude Code

From inside Claude Code:

/plugin marketplace add bluminal/lumenai

This registers the LumenAI marketplace with your local Claude Code install. The command points at the GitHub repository hosting the marketplace manifest; Claude Code reads the manifest and lists every plugin it advertises.

/plugin install synthex

Installs Synthex into your project. From here, all of the /synthex:init/synthex:init,

/synthex:write-implementation-plan/synthex:write-implementation-plan, /synthex:next-priority/synthex:next-priority, and the rest of the command surface are available as /synthex:<verb> invocations.

There are no API keys to configure, no SDKs to vendor, no auxiliary services to run. Everything that matters happens inside the harness you already use.

#Other supported harnesses

Codex CLI and Grok use the same LumenAI marketplace through their native plugin commands. Gemini CLI and OpenCode use the generated Agent Skills bundle. The exact installation path and invocation style are documented in Agent compatibility; the workflow source is the same in every case.

#Is Synthex free? Do I need an API key?

Synthex itself is free and open source — the plugin and skills are plain Markdown and YAML, installed from a public GitHub repository. You do not need a separate API key for Synthex, and there is no Synthex-side account, billing, or telemetry. Your only cost is the model access for the harness you choose; Synthex adds nothing on top.

#What's in a plugin

A plugin is a directory of markdown and YAML. Synthex's source layout, in plain terms:

plugins/synthex/
├── README.md
├── agents/                # one .md file per agent (system prompt + identity)
│   ├── architect.md
│   ├── code-reviewer.md
│   ├── product-manager.md
│   ├── tech-lead.md
│   └── …
├── commands/              # one .md file per slash command
│   ├── init.md
│   ├── next-priority.md
│   ├── write-implementation-plan.md
│   └── …
├── config/
│   └── defaults.yaml      # plugin-shipped configuration defaults
├── skills/                # generated Agent Skills that load canonical Markdown
├── hooks/                 # Claude Code session and event hooks (optional)
└── scripts/               # helpers, including skill generation

Two important properties follow from this shape:

• Source-of-truth is plain text. Every agent's identity, every command's parameters and workflow, every default config value is checked into the same Git repository. Diffs are reviewable. History is auditable.
• No duplicate workflow generation. Agent Skills entrypoints are generated only as thin discovery wrappers; they load the canonical Markdown instead of reproducing its prompts. There is no compiled artifact masking what the workflow actually does.

#Agents

Each agent is one markdown file with YAML frontmatter and a system prompt. The frontmatter sets the model and metadata; the body is the prompt. A tier hierarchy organizes the roster:

• Orchestration tier — Tech Lead, Lead Frontend Engineer, Product Manager. These run on Sonnet and coordinate other agents.
• Specialist tier — Architect, Code Reviewer, Security Reviewer, Quality Engineer, Design System Agent, Performance Engineer, SRE Agent, Technical Writer, and others. These do the domain-specific work the orchestrators delegate.
• Research tier — UX Researcher, Metrics Analyst, Retrospective Facilitator. These produce artifacts that feed the next planning cycle.

Beyond the tier, a few utility agents handle narrow mechanical work — the Findings Consolidator, the Context Bundle Assembler, the Commit Message Author. They run Haiku because their job is structural, not synthetic.

See the agents reference for the full roster with per-agent detail.

#Commands

Each command is one markdown file describing:

• Parameters — what the user can pass.
• Workflow — the explicit step-by-step procedure the orchestrating agent follows.
• Sub-agent invocations — which agents the command delegates to and in what order.
• Outputs — what artifacts the command produces (plans, retros, audit reports).

Commands are prompts that Claude Code interprets when you run /synthex:<verb> and that other Agent Skills hosts load through their own skill interface. There is no compiled command runtime. If you want to know exactly what /synthex:next-priority/synthex:next-priority does, open commands/next-priority.md and read it — that Markdown is the implementation.

See the commands reference for the full list with parameters.

#What runs locally vs. upstream

The plugin or Agent Skills bundle runs entirely on your machine, inside the harness you choose. There's no Synthex server, no remote orchestration plane, no telemetry pipeline. The split:

Synthex does not introduce a new vendor. It composes the tooling you already have.

#Updating Synthex

To pull a newer version of the plugin:

/plugin update synthex

Claude Code refreshes the plugin from the marketplace. Codex follows its plugin update flow; Gemini CLI and OpenCode users refresh the portable bundle by repeating their documented install steps. Your .synthex/config.yaml overrides are preserved because the update refreshes only Synthex's own files. If you script local mirrors of agent or command metadata, follow the resilience pattern this site uses: commit the most recent successful snapshot to your repo and fall back to it on remote-fetch failure so a GitHub outage never breaks your build.

#Versioning and stability

The plugin is versioned at the marketplace level. Breaking changes to agent prompts or command contracts are flagged in the changelog; non-breaking improvements (clearer prompts, better review heuristics, additional specialists) ship without ceremony.

Because everything is Markdown, you can pin to a specific commit of the marketplace if you want to lock in a known-good version of the plugin for a project — the marketplace is just a Git repository. Version 1.0 is the first release to support the shared Agent Skills distribution across multiple harnesses.

#Building your own plugin

The same shape works for project- or organization-specific plugins. Author one or more agents in agents/, one or more commands in commands/, point the marketplace manifest at the repository, and Claude Code can install it the same way it installs Synthex.

See Authoring agents and Authoring commands for the conventions Synthex itself follows when extending its roster.

#Next

• The lifecycle — what you actually do once Synthex is installed
• Getting started — the install + first-loop walkthrough
• Configuration — .synthex/config.yaml reference