DOCS · GETTING STARTED

Getting started

Three commands take you from an empty project to a peer-reviewed implementation plan to parallel-executed, tested, merged code. Synthex runs entirely inside your existing Claude Code session — no SDK, no API keys to manage.

1. Add the marketplace

Inside Claude Code, register the LumenAI marketplace where Synthex lives:

/plugin marketplace add bluminal/lumenai

Claude Code confirms the marketplace registration and lists the plugins available — Synthex shows up as one entry.

2. Install Synthex into your project

From the project you want Synthex to manage, run:

/synthex:init

This scaffolds the standard project layout:

  • .synthex/config.yaml — project configuration (review loops, concurrent task count, multi-model review opt-in)
  • docs/reqs/ — product requirements documents
  • docs/plans/ — implementation plans
  • docs/specs/ — technical specifications
  • docs/specs/decisions/ — Architecture Decision Records (ADRs)
  • docs/specs/rfcs/ — Requests for Comments
  • docs/runbooks/ — operational runbooks
  • docs/retros/ — retrospective documents

The /synthex:init command also adds .claude/worktrees/ to your .gitignore (worktrees are how Synthex parallelises tasks) and asks you to pick a concurrent_tasks value: Yolo (every CPU core), Aggressive (75% of cores), or the conservative default of 3.

3. Describe what you want, then ship it

Write a PRD at docs/reqs/main.md. The fastest way is conversational:

/synthex:write-implementation-plan

This pulls in the Product Manager agent. PM interviews you, drafts the plan, runs it through a peer review loop with the Architect, Designer, and Tech Lead, then writes the finalized plan to docs/plans/main.md.

Then execute:

/synthex:next-priority

This identifies the next batch of unblocked, non-overlapping tasks (up to your concurrent_tasks limit), spins up a git worktree per task, delegates each to a Tech Lead instance, and merges the results back as they pass review. Run it repeatedly — once per delivery batch — until the plan is done.

What happens behind the scenes

Every plan task carries a typed acceptance criterion:

TagMeaning
[T]Testable — proven by an automated test that must pass before the task merges
[H]Human-validated — requires your explicit approval before merge
[O]Observational — measurable only after deployment (adoption rates, error reduction)

Code reviews run automatically before any merge: code review + security review as mandatory gates, with optional performance, design-system, and reliability reviewers configurable per project.

Next

  • The full plan — read the plugin README for the complete command + agent reference
  • Source — the plugin's markdown-and-YAML source on GitHub