/synthex:write-implementation-plan/synthex:write-implementation-plan
DiscoverPeer-reviewed plan from a PRD — Architect + Designer + Tech Lead.
Invocation
Run from inside Claude Code in any project where Synthex is installed:
/synthex:write-implementation-planSome commands accept parameters; see the source-of-truth file linked below for the full parameter list and workflow.
Lifecycle phase
Discover. From idea to a sharp PRD.
Related agents
- Product Manager · Interactive requirements gathering. Transforms PRDs into milestone-based plans.
- UX Researcher · Personas, journey maps, opportunity-solution trees, heuristic eval.
Source
The command's parameters, workflow, and sub-agent invocations are defined in markdown at bluminal/lumenai/blob/main/plugins/synthex/commands/write-implementation-plan.md.
Last modified:
What it does, end-to-end
/synthex:write-implementation-plan/synthex:write-implementation-plan is the Plan-phase entry point: the command that takes a PRD and produces a peer-reviewed, milestone-and-task implementation plan you can hand to /synthex:next-priority/synthex:next-priority.
Each invocation:
- Reads the PRD at
docs/reqs/main.md(configurable viadocuments.requirements). The PRD is the input contract — every plan task points back to a PRD requirement. - PM drafts the plan. The Product Manager agent structures the work into phases →
milestones → tasks, assigns complexity estimates (S/M/L), surfaces dependencies, and
tags acceptance criteria with their type (
[T]/[H]/[O]). - Parallel reviewer pass. The Architect, Designer, and Tech Lead review the draft in parallel. Each emits structured findings; the Findings Consolidator deduplicates and ranks them by severity.
- PM iterates. The PM addresses every finding at or above
min_severity_to_address(defaulthigh). The cycle repeats up tomax_cyclestimes (default3for plans — one extra cycle since plan defects ripple downstream). - Plan saved. Final output lands at
docs/plans/main.md(configurable viadocuments.implementation_plan). The plan includes phases, milestones, tasks, decisions, open questions, and parallelizable batches per milestone.
Reviewer roster
Default reviewers (configurable in .synthex/config.yaml):
implementation_plan:
reviewers:
- agent: architect
enabled: true
focus: "Technical architecture, feasibility, NFR coverage, missing technical tasks"
- agent: designer
enabled: true
focus: "Design tasks, UX impact, visual/interaction design clarity"
- agent: tech-lead
enabled: true
focus: "Task clarity, acceptance criteria, parallelizability, dependency accuracy"Add specialists for project-specific concerns:
implementation_plan:
reviewers:
- agent: compliance-reviewer
enabled: true
focus: "Regulatory compliance, audit-trail requirements"What makes a good plan
The reviewer prompts are tuned to surface the qualities a plan needs:
- Every task has acceptance criteria. No tag-less tasks. Each criterion is
[T],[H], or[O]. Most tasks have at least one[T]because untestable claims tend to indicate unclear scope. - Parallelizability is explicit. The plan calls out which tasks can run in parallel per milestone, and which sequence dependencies block which.
- Decisions are recorded. Plans include a Decisions table with rationale; the reviewers will flag implicit decisions made during planning that should have been surfaced explicitly.
- Open questions are named. A plan with no open questions is suspicious — most non-trivial work has at least one unresolved item. Calling it out lets future-you see what was unsolved and why a default was chosen.
Common failure modes
The reviewers are calibrated to catch:
- Vague tasks. "Improve search" is not a task. "Reduce p95 search latency from 800ms to ≤300ms on the documented dataset" is.
- Missing acceptance criteria. Every task gets at least one criterion. The reviewers reject tasks that ship without.
- Untestable
[T]s. A[T]tag commits the task to having a passing automated test. When the criterion is structurally untestable, the reviewers either downgrade it to[H]or split it. - Cross-phase boundary creep. Tasks that span two phases (e.g., "ship to prod and run a retrospective") get split — phase boundaries exist for a reason.
Parameters
| Parameter | Description | Default | Required |
|---|---|---|---|
prd_path | Path to the PRD | docs/reqs/main.md | No |
output_path | Where to write the plan | docs/plans/main.md | No |
concurrent_tasks | Maximum recommended parallel tasks per milestone | Value from implementation_plan.concurrent_tasks config (or 3) | No |
When to re-run it
Run /synthex:write-implementation-plan/synthex:write-implementation-plan once per PRD, then iterate the PRD and
plan together as the project progresses. For mid-project re-planning (new PRD addendum, new
constraint), re-running produces a new plan; preserve the old plan as docs/plans/<date>-archived.md
if the lineage matters.
You usually do NOT regenerate the plan after a single completed task — that's /synthex:next-priority/synthex:next-priority's job, which appends completion notes to the existing plan.