Extract learnings, discoveries, design implications, and follow-up actions after implementation work, and save the result under docs/implementation-retrospectives/ by default. Use when the user asks what was learned from a change, asks for a reflection after coding, wants to capture insights or discoveries from implementation, wants to record engineering learnings, asks for a retrospective, asks for findings/insights/洞察/学び/発見 from completed work, or when implementation has just finished and it would help to turn the work into reusable engineering knowledge even if the user did not explicitly name the skill.
Extract the durable learnings from implementation work. Focus on insight, not changelog.
Reconstruct the implementation surface.
Separate execution facts from insights.
Identify the strongest learnings.
Distill the result into a small set of high-signal points.
End with implications.
Save the retrospective by default.
docs/implementation-retrospectives/.YYYY-MM-DD-short-topic.md.short-topic from the implementation theme, not from a vague label like retrospective.Use a concise structure that fits the request. Default to:
What changedWhat we learnedDesign implicationsNext follow-upFor deeper write-ups, add:
What surprised usWhat not to generalize yetWhat to record in docsAfter writing the content:
docs/implementation-retrospectives/ by defaultWhen working in a generator-heavy repo like this one, explicitly test whether the insight belongs to one of these buckets:
This classification usually produces better follow-up decisions than a generic retrospective.
The default artifact is a short markdown note under docs/implementation-retrospectives/.
Use this default shape unless the user asked for something else:
Keep the saved note tighter than the reasoning used to derive it. The note should be reusable by a future implementation pass, not a transcript of the whole session.