/synthex:retrospective/synthex:retrospective

#What it does, end-to-end

/synthex:retrospective/synthex:retrospective is the Learn-phase entry point — the command that closes the loop on a milestone, project, or release. It produces a structured retrospective document under docs/retros/ and surfaces follow-through items so the next Discover cycle starts from a stated baseline rather than collective amnesia.

Each invocation:

1. Resolves the scope. Use scope to name a milestone, phase, or period; without it, the command reads the implementation plan at docs/plans/main.md and picks the most recently completed phase or milestone.
2. Gathers the numbers. The Metrics Analyst pulls quantitative data for the period from the plan, git history, and any available CI/CD data: a DORA snapshot where applicable, planned-vs-actual task completion, and estimation accuracy.
3. Reviews the previous retro under docs/retros/. Last cycle's improvement items are checked first (Done / In Progress / Not Started / Dropped) and a follow-through rate is computed. Patterns across retros (the same issue keeps coming up) are high-signal — the agent surfaces them rather than treating each retro as fresh.
4. Runs the structured retro format. Default: start-stop-continue. Alternatives: 4ls (Liked / Lacked / Learned / Longed-for) and sailboat (Wind / Anchor / Rocks). The format is configured per-project in .synthex/config.yaml.
5. Synthesizes findings. The agent groups related items, ranks by impact, and proposes improvement actions. The cap is max_improvement_items (default 3) — more than three items competing for attention means none get done.
6. Surfaces follow-through items. Each improvement item turns into a candidate task for the next planning cycle. The retro doesn't write into the plan directly — that's the PM's job during the next /synthex:write-implementation-plan/synthex:write-implementation-plan.
7. Writes the retro doc. Output lands at docs/retros/<YYYY-MM-DD-name>.md (configurable via retrospective.output_path), and the command prints a summary: follow-through rate, format, the improvement items with owners and due dates, and what the cycle is celebrating.

#Format options

Configure in .synthex/config.yaml:

retrospective:
  format: start-stop-continue # default
  # format: 4ls
  # format: sailboat
  max_improvement_items: 3

#start-stop-continue

The most common format. The agent prompts for:

• Start: what should we begin doing? (new practices, new safety nets)
• Stop: what should we stop doing? (anti-patterns, wasted effort)
• Continue: what's working that we should keep? (don't drift away from validated practices)

Best for ongoing project teams. The simplicity is the point — three buckets keep the discussion focused.

#4ls

Liked / Lacked / Learned / Longed-for. More reflective, better for cross-team retros where the conversation needs space for context-setting before action items.

#sailboat

A metaphor format: Wind (what's pushing us forward) / Anchor (what's holding us back) / Rocks (risks ahead). Good for offsite-style retros where a more visual framing helps a group converge.

#What good retros look like

The Retrospective Facilitator is calibrated to:

• Surface honest disagreement. A retro where everything is "fine" is usually missing signal. The agent prompts for honest assessments rather than letting the conversation default to comfortable consensus.
• Quantify when possible. Cycle time, lead time, deploy frequency, change-fail rate (DORA metrics) when the project tracks them. "It felt slow" is weaker than "median cycle time was 4.2 days, up from 2.8 last milestone."
• Cap improvements. Three is the default. Teams that bring back ten improvement items per retro typically deliver zero — the cap exists to prevent that pattern.
• Track follow-through. Each retro names which items from the prior retro actually got done. Items that keep recurring without action are escalated as "stuck" rather than re-suggested.

#When to run it

Three natural cadences:

• Milestone close. When docs/plans/main.md shows all tasks in the current milestone as done, run a retro before advancing to the next milestone. Smaller, frequent retros catch issues while context is fresh.
• Project close. A larger retro at the end of a phase or release. Pulls in DORA-style metrics if the project tracks them.
• Incident close. After a production incident, run a focused retro with scope set to the incident.

#Parameters

The output location, format, and improvement-item cap are config keys, not parameters — set retrospective.output_path, retrospective.format, and retrospective.max_improvement_items in .synthex/config.yaml.

#What it does not do

• Modify the plan. Retros surface candidate improvement items, but the Product Manager drafts them into the next plan during /synthex:write-implementation-plan/synthex:write-implementation-plan. Keeping the retro and the plan separate prevents retro recommendations from quietly landing as committed work without review.
• Make people-related judgments. The agent focuses on processes, practices, and artifacts — not individuals. Performance conversations belong in 1:1s, not retros.
• Fix things autonomously. A retro is a discussion artifact. Acting on its findings is a separate, deliberate planning step.