EXAMPLES

Examples

Short, worked walkthroughs of Synthex across the lifecycle: what to run, what happens, and what you end up with. Every command and config key comes straight from the plugin source, linked on each example.

PRD → plan
plan
Turn a PRD into a peer-reviewed implementation plan, with reviewer findings folded in before you see it.
```
# Tighten the PRD first (optional)
/synthex:refine-requirements

# Then plan it: docs/reqs/main.md -> docs/plans/main.md
/synthex:write-implementation-plan
```
What happens: The Product Manager drafts milestones and tasks, then the reviewers in implementation_plan.reviewers (default: architect, design-system-agent, tech-lead) critique the draft in parallel. The PM resolves findings for up to 3 review cycles.
What you get: docs/plans/main.md: milestones, tasks with [T]/[H]/[O] acceptance criteria, dependencies, and what can run in parallel.
write-implementation-plan source ↗
Adding a custom agent
build
Write a Compliance Reviewer as a plain markdown prompt and run it in every code review next to the built-in reviewers.
```
# 1. Write the agent: .claude/agents/compliance-reviewer.md
---
name: compliance-reviewer
---
Review the diff for PII handling, audit logging, and data retention...

# 2. Register it in .synthex/config.yaml
code_review:
  reviewers:
    - code-reviewer
    - security-reviewer
    - prompt: .claude/agents/compliance-reviewer.md

# 3. Review
/synthex:review-code
```
What happens: A reviewers entry can be a prompt file instead of a Synthex agent name. Only name is read from frontmatter (it becomes the attribution id); Synthex appends its findings contract and runs the body alongside the other reviewers.
What you get: Compliance findings deduped, severity-ranked, and attributed in the same report, counting toward the PASS / WARN / FAIL verdict. Works in implementation_plan.reviewers and refine_requirements.reviewers too.
prompt-file reviewers doc ↗
Terraform review
operate
Have the Terraform Plan Reviewer check a plan for destructive changes, security gaps, and cost surprises before apply.
```
terraform plan -out=tfplan
terraform show -no-color tfplan > plan.txt

# Ask the specialist directly...
> Use the terraform-plan-reviewer agent to review plan.txt

# ...or as part of an operational readiness review
/synthex:reliability-review
```
What happens: terraform-plan-reviewer reads the plan output and checks four things: monthly cost deltas, destroy/replace actions that risk data loss, security misconfigurations (open access, missing encryption), and tagging/monitoring practice. reliability-review can call it in parallel when the scope includes Terraform.
What you get: A PASS / WARN / FAIL verdict with findings. It is advisory: it never blocks the apply, you decide.
terraform-plan-reviewer source ↗
Retrospective
learn
Close a milestone with a structured retro grounded in what the plan said versus what actually shipped.
```
/synthex:retrospective "Milestone 2"

# Optional, in .synthex/config.yaml
retrospective:
  format: start-stop-continue
  max_improvement_items: 3
```
What happens: The Metrics Analyst compares planned and actual delivery from the implementation plan and repo history; the Retrospective Facilitator runs the chosen format in blameless language and keeps the improvement list short.
What you get: A retro document in docs/retros/ with at most 3 improvement items, each with an owner, ready to feed the next planning cycle.
retrospective source ↗
Overnight cloud sprint
build
On Cursor, fan the plan out to cloud agents, loop until done, and let routine decisions get made and logged while you sleep.
```
# Cloud clones only see what's pushed
git add -A && git commit -m "wip: before cloud sprint" && git push

/synthex:next-priority --in-cloud --loop --auto-decide --max-iterations 30

# In the morning
git log --grep '^Auto-Decision:'
```
What happens: Each batch of unblocked tasks goes to background cloud agents, one VM and branch per task. The parent merges each branch with --ff-only (or a merge commit) after reviewers pass, then loops. --auto-decide takes the recommended option at discretionary decision points instead of stopping to ask.
What you get: Merged task branches; an Auto-Decision: <question> => <choice> trailer on the commit behind every decision (<sha>^ is the code before it); on Claude Code, a log at .synthex/auto-decide/<session>.jsonl. [H] acceptance criteria are never auto-approved: they are still waiting for you.
next-priority cloud doc ↗
Reuse your existing PR review prompt
build
Already have a CI review prompt? Run it as a Synthex reviewer without rewriting it.
```
# .synthex/config.yaml
code_review:
  reviewers:
    - code-reviewer
    - security-reviewer
    - prompt: .github/scripts/pr-guardian/prompt.md
      id: pr-guardian

/synthex:review-code
```
What happens: Synthex reads the prompt file, ignores frontmatter other than name, and runs the body read-only: instructions to post comments or call gh are ignored. Its output is held to the same findings contract as the other reviewers.
What you get: pr-guardian findings merged into the one report, deduped against code-reviewer and security-reviewer and attributed to pr-guardian. A bad path skips that reviewer, never the review.
prompt-file reviewers doc ↗
A personal kill switch for external models
operate
Make sure your code never goes to an external model CLI, whatever a repo's config asks for.
```
# ~/.config/synthex/config.yaml  (every repo)
multi_model_review:
  enabled: false

# .synthex/config.local.yaml  (this repo only; gitignored)
models:
  profile: premium
```
What happens: Settings resolve project-local > project > user > plugin defaults, but multi_model_review.enabled is restrictive-wins: false in any hand-written layer turns it off. A repo's config can't switch external review back on for you.
What you get: External review off everywhere, plus a per-repo personal tweak (here the premium model tier) that never lands in a commit.
config layers in the README ↗
Loop any prompt until it's done
build
Iterate an arbitrary prompt file until it emits a completion promise, with state that survives restarts.
```
/synthex:loop --prompt-file tasks/migrate-tests.md --completion-promise "MIGRATED" --max-iterations 40

/synthex:list-loops          # what's running, what finished
/synthex:loop --resume-last  # pick up after closing your laptop
/synthex:cancel-loop loop-3f2a
```
What happens: The prompt re-runs until the agent emits <promise>MIGRATED</promise> or the cap is hit (default 20, max 200). State lives in .synthex/loops/<loop-id>.json; pass --loop-isolated for a fresh subagent per iteration.
What you get: A finished task, a resumable loop if you get interrupted, and cancellation that takes effect at the next iteration boundary.
loop source ↗
Second opinion from other models
build
Add Codex, Gemini, Ollama, or other model CLIs as extra reviewers alongside Claude.
```
/synthex:configure-multi-model

# Force the multi-model path for one review
/synthex:review-code --multi-model
```
What happens: The wizard detects installed CLIs (codex, gemini, ollama, llm, aws), checks auth, and warns you what data gets sent. --multi-model skips the complexity gate; the orchestrator fans out to native and external reviewers in parallel.
What you get: One consolidated report whose header says which path ran, e.g. Review path: multi-model (…; reviewers: 2 native + 2 external), with every finding attributed to the model that raised it.
configure-multi-model source ↗

Want to see a specific example next? Open an issue on the LumenAI repository — the most-asked-for examples land first.