DOCS · GET STARTED · AGENT COMPATIBILITY

Now for any agent

Synthex was written for Claude Code and is still developed and used there first. Starting with Synthex 1.0, the same command and specialist workflows are also available to Codex CLI, Grok, Gemini CLI, OpenCode, Hermes Agent, Cursor, and other coding agents that support Agent Skills. One set of reviewed Markdown; no copied prompts to keep in sync.

Choose your installation

HarnessInstallationHow to invoke Synthex
Claude CodeNative LumenAI marketplace plugin/synthex:<command> and plugin agents
Codex CLINative LumenAI marketplace plugin$<skill> or /skills
GrokNative LumenAI marketplace plugin/synthex:<command> or /<command> when the name is free
Gemini CLIWorkspace Agent SkillsAsk for the workflow, or let Gemini activate the relevant skill
OpenCodeProject Agent Skills bundleAsk for the workflow, or let OpenCode load the relevant skill
HermesPlugin tree copied into project/<command> (for example hermes -z "/<command> ...")
CursorCursor Task agent wrappersSynthex agents as Cursor subagents; cloud next-priority

Claude Code, Codex CLI, Gemini CLI, and OpenCode are mechanically tested against the published skill inventory in Synthex's isolated compatibility suite. Grok installs that same inventory through its native marketplace. The harness chooses its own interface; the workflow and specialist source are shared.

Claude Code

Claude Code remains Synthex's home and has the fullest native experience, including namespaced slash commands, plugin agents, hooks, and native looping.

Run these inside Claude Code:

/plugin marketplace add bluminal/lumenai
/plugin install synthex

Then, in the repository you want Synthex to manage:

/synthex:init

See Getting started for the first delivery loop.

Codex CLI

Codex installs the same marketplace and plugin through its CLI:

codex plugin marketplace add bluminal/lumenai
codex plugin add synthex@lumenai

Start a new Codex session after installation. Codex exposes every Synthex command and specialist as a skill. Invoke one explicitly, for example:

$init
$review-code
$architect

Or open /skills and select the workflow you need. The wrappers are deliberately thin: they load the corresponding canonical file in Synthex's commands/ or agents/ directory.

Grok

Grok installs the same marketplace and plugin through its CLI. --trust lets the plugin's skills load, and enable turns the plugin on:

grok plugin marketplace add bluminal/lumenai
grok plugin install synthex --trust

Start a new Grok session after installation. Grok exposes every Synthex command and specialist as a skill. Invoke one explicitly, for example:

/synthex:init
/synthex:review-code
/synthex:architect

When the name does not collide with another skill or a built-in command, the bare form works too, such as /review-code. The wrappers are the same files Codex uses: they load the corresponding canonical file in Synthex's commands/ or agents/ directory. Grok's plugin manifest publishes that skills directory only, so those canonical files are not also registered as a second set of commands and agents.

Gemini CLI

Gemini CLI uses its workspace Agent Skills installation. From the project root, make a temporary source checkout, install each Synthex skill, and copy the small shared-support bundle it reads:

git clone --depth 1 --filter=blob:none --sparse https://github.com/bluminal/lumenai.git .synthex-source
git -C .synthex-source sparse-checkout set plugins/synthex
mkdir -p .gemini
cp -R .synthex-source/plugins/synthex/{agents,commands,config,scripts,docs} .gemini/
for skill in .synthex-source/plugins/synthex/portable-skills/*; do
  gemini skills install "$skill" --scope workspace --consent
done

Use Gemini normally and name the workflow when it helps, such as “use Synthex's review-code skill.” Run gemini skills list to inspect the installed inventory. Keep the source checkout to repeat the install when you update, or remove it after installation; add .synthex-source/ to your .gitignore if you do not want it tracked. If .gemini/ already contains project-managed files, merge the agents/, commands/, config/, scripts/, and docs/ directories deliberately rather than overwriting them.

Upgrading an install from before the skills/ → portable-skills/ rename: uninstall each old skill (gemini skills uninstall <id> --scope workspace), then reinstall from portable-skills/<id> as above.

OpenCode

OpenCode's built-in skill discovery only scans .claude/skills/** and .agents/skills/**, so Synthex's portable-skills/ bundle needs one line of config. From the project root, create the same temporary source checkout and place the complete portable bundle in .agents:

git clone --depth 1 --filter=blob:none --sparse https://github.com/bluminal/lumenai.git .synthex-source
git -C .synthex-source sparse-checkout set plugins/synthex
mkdir -p .agents
cp -R .synthex-source/plugins/synthex/{portable-skills,agents,commands,config,scripts,docs} .agents/

Then point OpenCode at the bundle with an opencode.json at the project root:

{
  "$schema": "https://opencode.ai/config.json",
  "skills": { "paths": [".agents/portable-skills"] }
}

Start OpenCode in that project and ask for a named Synthex workflow, for example “use the Synthex write-implementation-plan skill.” opencode debug skill lists the skills OpenCode discovers. Commit .agents/ when you want the project to carry a reproducible, shared Synthex installation; keep .synthex-source/ ignored or remove it when you no longer need it. If .agents/ already contains project-managed files, merge the copied directories deliberately rather than overwriting them. Upgrading from an install made before the skills/ → portable-skills/ rename: re-copy the bundle and update skills.paths, or OpenCode silently stops seeing Synthex skills.

Hermes Agent

hermes skills install has no local-path form, so place the whole plugin tree in the project and link its skills directory:

cp -R path/to/plugins/synthex <project>/.agents/synthex
ln -s .agents/synthex/portable-skills <project>/.agents/skills
cd <project> && hermes skills trust

Don't nest commands/ or agents/ inside a skill folder: Hermes's Skills Guard scans project skills at load and quarantines any it scores as dangerous, and the canonical files trip its heuristics there. The symlink layout keeps them outside every skill folder. hermes skills trust is per git checkout, so run it again after re-cloning. For headless runs, use hermes -z "/<command> ..." and wrap it in timeout, because a headless clarifying question hangs.

Cursor

Cursor is the host for Synthex's cloud agents. Synthex ships generated Cursor subagent wrappers in the plugin's cursor-agents/ directory, one per Synthex agent. Copy or symlink that directory to your project's .cursor/agents/ (or merge just the roles you want) and the Agents Window discovers them:

mkdir -p .cursor
ln -s path/to/plugins/synthex/cursor-agents .cursor/agents

Each wrapper has Cursor frontmatter — name, description, model: inherit, and readonly: true for advisory roles such as reviewers — and points at the canonical file in agents/. Cursor also loads .claude/agents/; the wrappers are the path with Cursor-native frontmatter.

What Synthex does differently on Cursor:

  • next-priority/synthex:next-priority runs its parallel Tech Leads with run_in_background: true, so a batch really runs in parallel. Reviewers and other gates stay in the foreground.
  • With --in-cloud or next_priority.execution_environment: cloud, each Tech Lead runs as a cloud subagent with its own VM and branch. Configure the repo's environment at cursor.com/agents and grant cloud write access to the remote.
  • Subagents can nest only one level deep.
  • Claude Code tool names map to Cursor's: Bash → Shell, Edit → StrReplace, Agent/Task → Task. Cursor has no AskUserQuestion tool, so questions are asked in chat.
  • Unattended runs use the Agents Window or Cloud Agents with Cursor's in-product approvals.

Headless runs

Every host needs its own approval setting for an unattended run to write Synthex state:

HostHeadless approvalShell-call cap
Claude Code--dangerously-skip-permissions (or --permission-mode bypassPermissions)600 s
Codex CLIcodex exec --sandbox workspace-write120 s
Gemini CLI--approval-mode yolo (headless default denies writes)300 s
OpenCodeopencode run --command <slug> --auto (run without --auto is read-only)120 s
Grokgrok -p ... --yolo --max-turns N120 s
Hermeshermes -z "/<slug> ..." after hermes skills trust; wrap in timeout600 s
CursorCursor Agents Window / Cloud Agents (in-product approvals; Cloud Agents use team env + repo write access)600 s

Set SYNTHEX_HOST=<id> (claude, codex, gemini, opencode, grok, hermes, or cursor) before running Synthex's scripts so their writability hints match your host.

Your AGENTS.md still belongs to you

AGENTS.md is where a project records its own conventions, architecture, test commands, and guardrails. Synthex does not overwrite or replace it. Agent Skills hold reusable workflows; AGENTS.md supplies the project-specific context when your harness honors that convention. If your harness uses a different instruction-file convention, keep using it alongside Synthex.

What is shared—and what stays native

commands/*.md and agents/*.md are the behavioral source of truth. Generated portable-skills/*/SKILL.md entrypoints and cursor-agents/*.md wrappers carry only discovery metadata and instructions to load those canonical files. Editing a workflow therefore changes it for every supported harness.

Claude Code-only primitives remain Claude Code-only: its slash-command UI, plugin hooks, native looping implementation, and Task primitive have no universal equivalent. On another harness, Synthex preserves the workflow's intent and uses that harness's closest available skills and delegation mechanisms. Check the relevant harness documentation for its own authentication, model, and permission setup.

Another Agent Skills host

If your coding agent supports project or workspace Agent Skills, it can use Synthex's portable bundle. Put portable-skills/ and its sibling agents/, commands/, config/, scripts/, and docs/ directories under the host's documented skills root, preserving that layout. The relative links inside each SKILL.md then resolve to the shared canonical source.

Support for an additional harness is accepted when its clean install, full skill discovery, reference handling, and mechanical skill activation have been verified in Synthex's isolated compatibility suite. See the Synthex source to contribute one.

Next