The marketplace

Synthex is a Claude Code plugin distributed through the LumenAI marketplace. The plugin is the unit of installation; the marketplace is the directory of plugins. Both are designed around plain markdown and YAML so the source of truth stays inspectable.

#Install flow

Two commands are all you need. 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 your Claude Code session.

#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
├── hooks/                 # session and event hooks (optional)
└── scripts/               # helper scripts the plugin ships with

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 code generation, no transpilation step. What you see in the repo is exactly what Claude Code reads at install time. There's no "compiled" build artifact masking what the plugin 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 themselves prompts that Claude Code interprets when you run /synthex:<verb>. 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 runs entirely on your machine, inside your Claude Code session. 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. Your .synthex/config.yaml overrides are preserved — the update only refreshes the plugin'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.

#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