Project retrospective
Extract lessons from what happened without turning the result into blame, self-congratulation, or a transcript.
Inputs
Use the current conversation and any sources the user explicitly places in scope. For files or folders, run bin/project-retrospective SOURCE... to inventory supported text and --emit only when the collected content is appropriate to place in the current context.
Do not search private session stores, chat databases, home directories, or unrelated project history unless the user explicitly names them.
Workflow
- Define the work period, audience, and sources. State any important missing evidence.
- Gather goal statements, plans, tracker state, changed artifacts, validation output, corrections, decisions, failed attempts, and unfinished work.
- Build a factual timeline before interpreting success or friction.
- Analyze with
references/analysis-rubric.md. Separate outcome quality from process quality.
- Draft with
references/retro-template.md. Omit inapplicable sections instead of writing filler.
- Tie each lesson to evidence and a repeatable action. Keep proposed skills or safeguards specific enough to implement.
- Present the retrospective in the requested location. Do not create a permanent retro file unless the user asked for one.
Rules
- Distinguish original goals from later pivots.
- Credit smooth work and successful corrections alongside failures.
- Describe mistakes and communication friction neutrally, with the information available at the time.
- Do not invent message counts, timing, files changed, or causal explanations.
- Quote only short excerpts that materially establish a lesson.
- Exclude credentials, tokens, cookies, private keys, and unrelated personal data.
- Prefer two or three high-value improvements over a long generic suggestion list.
Output
Produce a self-contained retrospective with sources, confidence limits, concrete evidence, and prioritized follow-up actions.
Use agents/analyst.md for an independent retrospective pass.
1---2name: project-retrospective3description: Turn a completed or paused body of work into an evidence-based retrospective covering goals, outcomes, decisions, pivots, effective practices, friction, failed approaches, unfinished work, open questions, and concrete improvements. Use with conversation history, project trackers, session notes, plans, logs, or user-specified files and folders across engineering, research, writing, automation, and other projects.4---56# Project retrospective78Extract lessons from what happened without turning the result into blame, self-congratulation, or a transcript.910## Inputs1112Use the current conversation and any sources the user explicitly places in scope. For files or folders, run `bin/project-retrospective SOURCE...` to inventory supported text and `--emit` only when the collected content is appropriate to place in the current context.1314Do not search private session stores, chat databases, home directories, or unrelated project history unless the user explicitly names them.1516## Workflow17181. Define the work period, audience, and sources. State any important missing evidence.192. Gather goal statements, plans, tracker state, changed artifacts, validation output, corrections, decisions, failed attempts, and unfinished work.203. Build a factual timeline before interpreting success or friction.214. Analyze with [`references/analysis-rubric.md`](references/analysis-rubric.md). Separate outcome quality from process quality.225. Draft with [`references/retro-template.md`](references/retro-template.md). Omit inapplicable sections instead of writing filler.236. Tie each lesson to evidence and a repeatable action. Keep proposed skills or safeguards specific enough to implement.247. Present the retrospective in the requested location. Do not create a permanent retro file unless the user asked for one.2526## Rules2728- Distinguish original goals from later pivots.29- Credit smooth work and successful corrections alongside failures.30- Describe mistakes and communication friction neutrally, with the information available at the time.31- Do not invent message counts, timing, files changed, or causal explanations.32- Quote only short excerpts that materially establish a lesson.33- Exclude credentials, tokens, cookies, private keys, and unrelated personal data.34- Prefer two or three high-value improvements over a long generic suggestion list.3536## Output3738Produce a self-contained retrospective with sources, confidence limits, concrete evidence, and prioritized follow-up actions.3940Use [`agents/analyst.md`](agents/analyst.md) for an independent retrospective pass.
batteryshark