Workflow Retrospective
Turn observed execution evidence into a small, testable workflow improvement.
Workflow
- Define the reviewed interval, objective, expected workflow, supplied artifacts, and evidence boundary.
- Reconstruct observable events, decisions, delays, rework, failures, recoveries, and outcomes without inferring private motives.
- Identify contributing conditions across problem framing, information, tools, ownership, sequencing, validation, and authority.
- Separate causal evidence from correlation, hindsight, preference, and unsupported explanation.
- Preserve useful behavior and name the smallest material friction or risk worth changing.
- Propose one bounded experiment with an owner, success signal, guardrail, review date, and rollback or rejection condition.
- Record what remains unknown and what evidence would change the conclusion.
Knowledge lifecycle handoff
When the reviewed workflow participates in knowledge-contract.v1, prepare a retrospective object with a stable project-scoped ID, review period, subject IDs, findings, remaining unknowns, evidence status, limitations, and relationships to the evaluated work. Preserve correction history rather than rewriting an earlier retrospective.
A retrospective is after-the-fact interpretation. It does not change the original source snapshot, scenario, forecast, observation, or evaluation. Route a complete research-to-publication workflow to research-to-publication-lifecycle when that skill is installed.
Boundaries
- Use the current task and explicitly supplied artifacts. Do not search raw chats, private histories, unrelated repositories, or broad connector data by default.
- Do not expose chain-of-thought or treat a transcript as an objective record of causality.
- Do not automatically edit skills, repository policy, automation, or configuration.
- Do not turn one event into a universal rule without repeated evidence.
Output
Return Scope, Observed timeline, What helped, What hindered, Contributing conditions, Evidence limits, Improvement experiment, Owner and review date, and Rejected generalizations. If a knowledge-lifecycle handoff was requested, add the proposed retrospective ID, subject relationships, findings, unknowns, and limitations without writing or publishing them automatically.
Continuity and evidence
Review observable communication friction: time spent finding results, repeated discovery after interruption, lost evidence, unnecessary decisions, and corrections needed to resume. Distinguish measured effort from estimates and preference. Compare the current workflow, a small preference change, and a focused skill revision before proposing general adoption.
Read the original acceptance example when checking this behavior.
1---2name: workflow-retrospective3description: Review a completed or paused workflow using supplied artifacts and current task evidence to identify what helped, what failed, why, and which bounded improvement to test next. Invoke explicitly after meaningful work; do not mine private histories or automatically rewrite policy or skills.4license: MIT5---67# Workflow Retrospective89Turn observed execution evidence into a small, testable workflow improvement.1011## Workflow12131. Define the reviewed interval, objective, expected workflow, supplied artifacts, and evidence boundary.142. Reconstruct observable events, decisions, delays, rework, failures, recoveries, and outcomes without inferring private motives.153. Identify contributing conditions across problem framing, information, tools, ownership, sequencing, validation, and authority.164. Separate causal evidence from correlation, hindsight, preference, and unsupported explanation.175. Preserve useful behavior and name the smallest material friction or risk worth changing.186. Propose one bounded experiment with an owner, success signal, guardrail, review date, and rollback or rejection condition.197. Record what remains unknown and what evidence would change the conclusion.2021## Knowledge lifecycle handoff2223When the reviewed workflow participates in `knowledge-contract.v1`, prepare a `retrospective` object with a stable project-scoped ID, review period, subject IDs, findings, remaining unknowns, evidence status, limitations, and relationships to the evaluated work. Preserve correction history rather than rewriting an earlier retrospective.2425A retrospective is after-the-fact interpretation. It does not change the original source snapshot, scenario, forecast, observation, or evaluation. Route a complete research-to-publication workflow to `research-to-publication-lifecycle` when that skill is installed.2627## Boundaries2829- Use the current task and explicitly supplied artifacts. Do not search raw chats, private histories, unrelated repositories, or broad connector data by default.30- Do not expose chain-of-thought or treat a transcript as an objective record of causality.31- Do not automatically edit skills, repository policy, automation, or configuration.32- Do not turn one event into a universal rule without repeated evidence.3334## Output3536Return `Scope`, `Observed timeline`, `What helped`, `What hindered`, `Contributing conditions`, `Evidence limits`, `Improvement experiment`, `Owner and review date`, and `Rejected generalizations`. If a knowledge-lifecycle handoff was requested, add the proposed retrospective ID, subject relationships, findings, unknowns, and limitations without writing or publishing them automatically.3738## Continuity and evidence3940Review observable communication friction: time spent finding results, repeated discovery after interruption, lost evidence, unnecessary decisions, and corrections needed to resume. Distinguish measured effort from estimates and preference. Compare the current workflow, a small preference change, and a focused skill revision before proposing general adoption.4142Read [the original acceptance example](references/continuity-example.md) when checking this behavior.
JovaniPink