Skills

Synthex exposes the same commands and agents to several harnesses, each through the entrypoint that harness understands. This page lists all four kinds, what each one contains, and which entries you are meant to call yourself.

#At a glance

All paths are relative to plugins/synthex/. Every one of these is a thin entrypoint. The behavior lives in commands/*.md and agents/*.md, which are the single source of truth for every harness.

#Claude Code slash commands

Each file in commands/ is registered in .claude-plugin/plugin.json and appears in Claude Code as /synthex:<name>. All of them are meant to be run by you. The model tier comes from each command's frontmatter; a command with no model: runs on your session's model.

Claude Code also registers the 25 files in agents/ as plugin subagents. Commands and other agents delegate to them; they are not slash commands.

#Claude Code Workflow engines

Two scripts in workflows/ are Claude Code Workflow scripts. Claude Code discovers them from that directory without a manifest entry. They are the opt-in workflow engines:

Both config keys ship as prose, so neither engine runs until you turn it on:

# .synthex/config.yaml
code_review:
  engine: workflow # prose | workflow
native_looping:
  engine: workflow # prose | workflow

Don't run them yourself. Claude Code registers each workflow under its own name, so both show up in the slash menu (synthex:review-code-engine and synthex:loop-engine). They expect arguments that only the calling command supplies. The loop engine says so in its own metadata: run directly, it returns a harmless fallback result. The review engine, run directly, skips the command's config checks and review loop and has no diff to review. Use /synthex:review-code/synthex:review-code and the --loop flags instead. (The workflows are deliberately not named review-code or loop: a workflow name would shadow the command of the same name.)

Headless runs have nobody to approve the Workflow call, so add a permission allow rule ahead of time: Workflow(synthex:loop-engine) for the loop engine and Workflow(synthex:review-code-engine) for the review engine (or run in auto or bypass mode).

#Portable Agent Skills

portable-skills/ holds one Agent Skills folder per command and one per agent: 22 command skills and 25 agent skills. scripts/generate-codex-skills.mjs generates them (its --check mode reports any that have drifted from their sources). Each SKILL.md carries a name, a description, and (for commands) an argument-hint, then tells the host to read the matching commands/ or agents/ file and follow it.

These are what Codex, Grok, Gemini CLI, OpenCode, and Hermes load. How you call one depends on the host:

• Codex: mention it with $, for example $review-code, or pick it from /skills.
• Grok: /synthex:review-code/synthex:review-code, or /review-code when the name is unambiguous.
• Gemini CLI, OpenCode, Hermes: through the host's own skill mechanism. See Agent compatibility.

#Command skills

Every command skill is meant for you to invoke.

Standing review pool commands need Claude Code's Agent Teams tools. On other hosts they print a notice and stop; use review-code or performance-audit instead.

#Agent skills

Agent skills are for commands and other agents to delegate to, not for you to start a workflow with. Every agent SKILL.md sets user-invocable: false, which keeps it out of Grok's slash menu, and ships an agents/openai.yaml with allow_implicit_invocation: false, so Codex never picks one on its own. Codex still lets you mention a specialist by name (for example $architect) if you want to talk to that role directly.

The internal helpers in the table are plumbing for multi-model review and standing pools. The commands call them; there is no reason to invoke them by hand.

#Cursor Task agents

cursor-agents/ holds one wrapper per agent (25 files), generated by the same script. These are Cursor subagents for the Task tool, not skills. Each file has Cursor frontmatter (name, description, model: inherit, readonly) and points at the canonical agents/<name>.md.

To use them in your project, copy or symlink cursor-agents/ into .cursor/agents/, or merge in the roles you want.

Advisory and gate-only roles are readonly: true, so the Task tool withholds write tools from them:

• architect, code-reviewer, security-reviewer, performance-engineer, terraform-plan-reviewer
• metrics-analyst, retrospective-facilitator, ux-researcher
• findings-consolidator
• bedrock-review-prompter, claude-review-prompter, codex-review-prompter, gemini-review-prompter, llm-review-prompter, ollama-review-prompter

Every other agent (the implementers and orchestrators, such as tech-lead, product-manager, and multi-model-review-orchestrator) is readonly: false. Background versus foreground is chosen per Task call, not in the wrapper.

#Next

• Workflow engines — when the two engines run and what they change
• Agent compatibility — install Synthex in each harness
• Hooks — the event hooks Synthex installs
• Plugin architecture — how the generated entrypoints fit together