/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. Reads the implementation plan at docs/plans/main.md. The Retrospective Facilitator uses the plan to compute planned-vs-actual: which tasks shipped, which slipped, which got cut, and where the surprises came from.
2. Reads recent retrospectives under docs/retros/. Patterns across retros (the same issue keeps coming up) are high-signal — the agent surfaces them rather than treating each retro as fresh.
3. 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.
4. 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.
5. 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.
6. Writes the retro doc. Output lands at docs/retros/<YYYY-MM-DD-name>.md (configurable via retrospective.output_path).

#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 on that incident. Format: typically 4ls with the conversation scoped to the incident timeline.

#Parameters

#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.