Review an execution

Recover what one execution intended, identify the commits that executed it, and review their combined outcome, current product architecture, and whole test suite. By default, cover implementation, process, and product learning. Leave the project with evidence and, only when needed, a plan for bounded corrections. Do not implement, commit, or push those corrections. A retrospective authorizes product recommendations; it does not grant backlog-write authority. Leave any completed plan and routine completion or backlog actions for dough-story-wrap-up.

Select reviews

Ordinary invocation considers implementation, process, and product review. Choose the enabled set before loading focus-specific context or acting on that focus. Resolve process review before process analysis and before resolving, checking, reading, or writing DearDough.md.

--skip-product omits product analysis and suggestions. It does not change process selection. --skip-process omits process analysis and all log inspection and writing. Both flags may be supplied together. Neither skips implementation review or its correction planning. Skipped or unresolved process review does not skip implementation or product review, and does not suppress their destination writes. Skipped product review does not suppress the shared direction consideration in implementation or enabled process review. Do not covertly review a skipped or unresolved focus or write its destination.

Read this project's optional open-dough.json from the established planning directory: <established-planning-directory>/open-dough.json, defaulting to <project-root>/.planning/open-dough.json when no different planning directory is established by the user or this project's conventions. Resolve that path from this project, not this skill's location. Do not search other projects. Do not use open-dough.json beside this skill.

The file is one optional JSON object. The only recognized setting is this boolean:

{ "skipProcessRetrospective": true }

A missing file, missing skipProcessRetrospective key, or boolean false leaves process review on. Boolean true omits process analysis and all log inspection and writing.

Ignore unrecognized keys. Leave the file unchanged: do not rewrite it, create a missing file, or repair an invalid or unreadable file.

Explicit invocation instructions override the stored preference without editing the file. --skip-process always skips, even when the file is missing or says false. An explicit request to include process review enables it for this invocation even when the file says true; do not add a new flag for that override. Contradictory explicit instructions use ordinary clarification.

If the file is unreadable, is not a JSON object, contains malformed JSON, or sets a recognized key to a non-boolean, process selection is unresolved: report the error, omit process analysis, leave the log untouched, and continue independently supported reviews. An explicit process-selection instruction (--skip-process or an explicit include-process request) resolves that invocation without repairing the file.

Work from these principles

• Original intent is the contract. Recover the feature story or bounded correction input, boundaries, approved changes, and promised proof before judging implementation.
• Commit membership needs evidence. A nearby commit is not part of the execution merely because it is in the same range.
• Judge the aggregate result and current architecture. Review the combined execution outcome and the whole product's conceptual structure, including relevant untouched code. Delivery decomposition is not a design objective; coincident product boundaries need independent domain justification.
• Current truth decides remediation. Report later fixes and do not plan work that is already resolved.
• Execution state decides the destination. Amend an unfinished plan; create a follow-up plan only for a completed execution. A wholly planless quick execution with unresolved completion has neither destination yet.
• The user owns disputed scope and constraints. Stop when evidence cannot distinguish two execution candidates or when a finding would change the source outcome rather than correct it. Use the shared plan-conflict handoff for apparently accidental contractual restrictions; plan compliance does not settle their justification.
• Product learning is not an implementation defect. Keep product recommendations out of correction plans and process findings.
• Direction is a criterion, not a deliverable. Question alignment of work and process with the established near-future direction; never propose or edit that text.

Resolve this project's context

Require one useful clue: a capability or story phrase, correction plan, commit, or the current or supplied execution conversation. Resolve this project's plan location and status vocabulary for planned work, feature-story locations when applicable, cleanup lifecycle, repository navigation, and focused test commands. Preserve existing working-tree changes. A complete bounded correction plan is its source contract; do not require or create a seed for its retrospective. A wholly planless quick execution instead requires its canonical story and enough execution history to establish that slice planning was explicitly skipped. A quick-to-planned execution requires that initial evidence plus its ordinary remaining-work plan and evidence connecting both parts.

Resolve this project's established near-future direction when present. When product review is enabled, resolve backlog and canonical-story conventions when that review needs them. Do not invent a direction, backlog, or feature-story seed location.

If context needed for a review decision is missing, name it and stop that path. Do not invent a plan location, completion rule, or project convention. Return retrospective evidence in the response; do not create a separate artifact unless the user asks. Keep the repository read-only except for the process log when process review is enabled and an allowed plan update described below. Do not create, repair, or rewrite open-dough.json.

Read dough-post-change-refactor and its refactor checks before assessing refactoring residue; apply its smell definitions to the aggregate result without running its editing workflow. Read dough-slice-planning only when unresolved findings need planning, then follow its bounded-correction entry, proof, sizing, and destination gates. Read dough-product-backlog only when product review is enabled and recommendations depend on those conventions.

Recover one execution

Search the current conversation, supplied execution history, current planning material, and Git history in that order. First establish whether the execution used a plan, explicitly ran as one quick slice without creating a plan, began as a quick attempt and continued through an ordinary remaining-work plan, or used a plan that normal cleanup later removed. File absence alone does not establish which case applies.

For planned execution, preserve the existing recovery path: a partial reference or a plan removed by normal cleanup is sufficient when history identifies it. Recover the earliest execution-ready plan, its feature story or bounded-correction input and intended outcome, and any later changes supported by user approval or new evidence. Do not relabel a removed-but-recoverable plan as quick execution.

For quick execution, require conversation evidence that the caller explicitly selected planless execution. Recover the canonical story's goal, boundaries, examples, and promised proof; approved changes from the conversation; related changes and commits; and the available proof. Do not require, invent, or reconstruct a historical plan or substitute execution record. Current chat is sufficient when it contains these facts; otherwise use a supplied transcript.

For a quick attempt continued through planning, recover the initial quick-path selection and attempt from current or supplied conversation evidence, then the ordinary plan linked to the same canonical story and that attempt's remaining work. Treat both parts as one execution. The plan must preserve attributable completed compatible work and proof and must not represent them as earlier planned slices. Recover its remaining slices and later plan changes through the ordinary planned path. Do not manufacture a second execution identity merely because the execution source changed from story-and-chat to plan.

Determine completion from source-specific evidence, not file presence. A plan is complete when every slice is done; a deleted plan needs history evidence of completion. A quick execution is complete only when its conversation and repository evidence establish the delivered story outcome and its required proof. A quick-to-planned execution is complete when the remaining-work plan is complete and the preserved quick-attempt evidence plus planned proof establish the original story outcome without a gap or repeated-work assumption. Missing proof limits the completion or finding conclusion that depends on it; continue independently supported review rather than treating plan absence as failure. If execution kind, continuity, contract, or completion remains ambiguous, name the missing evidence and stop only the affected decision. If two candidates remain equally plausible, ask the user to choose and do not combine them.

Build one manifest of related commits across a quick attempt and its planned continuation when both occurred. Include each SHA with a reason grounded in the plan or story, commit message, diff, or execution transcript. Inspect intervening and nearby commits and exclude unrelated work. Ambiguous attribution limits claims about that commit and findings that depend on it; it does not authorize widening the manifest. Treat planning-only commits as provenance, not product findings.

Use one net diff only when the implementation commits form an uncontaminated range. Otherwise review the selected patches together and inspect their files at the last related implementation commit. Never mutate the worktree to reconstruct history or mix later work into the historical boundary.

Consider near-future direction

For every enabled review, treat the established near-future direction as a high-priority criterion. Read it once from the resolved project location. If it is missing, say alignment cannot be assessed against an established direction and continue the independently supported reviews. Otherwise question apparent alignment and digression. Explain justified exceptions such as urgent fixes. Do not merely assert that the work fits.

Route a supported deviation through that review's existing authority:

• Implementation: supported defects and architectural weaknesses go to bounded correction planning under current truth. A needed product-constraint or promised-outcome change is the user's decision, not a rewritten historical contract.
• Process: produce a process recommendation; do not add it to an implementation correction plan.
• Product: recommend work or priorities. Do not treat a direction mismatch as an implementation defect.

A later change in direction does not retroactively make approved historical work a defect. Judge that work against its original approved contract; use today's direction only for remaining or proposed work.

Never propose or apply a replacement or revision of the direction itself.

Review the outcome

Apply the shared direction consideration. Then compare the feature-story or bounded-correction contract and approved changes with the aggregate code, tests, documentation, and proof at the execution boundary. For the historical assessment of an unfinished plan, judge only the completed slices; do not call unexecuted planned behavior missing or its explicitly temporary predecessor obsolete.

Keep only findings with concrete evidence and plausible impact:

1. bugs or regressions;
2. source-outcome drift or an unresolved scope dispute;
3. refactoring residue in complete implicated concepts;
4. consequential weaknesses in the current whole-product architecture; and
5. test coverage or execution-cost findings under the shared behavioral test guidance.

Assess overall responsibilities, dependencies, and representations against the product's domain, not the story sequence. Ask whether successive examples exercise a coherent model or accumulate special cases. Use the shared refactor checks for concrete concept examination; shared helpers alone do not establish cohesion. Follow architectural evidence beyond the changed files to relevant untouched code, and explain the concrete impact of a weakness, such as divergent domain rules or changes requiring repeated coordinated edits. Whole-product assessment is required; it does not require speculative redesign or treating cosmetic preferences as defects. Apply dough-adr-awareness to genuine architectural constraints and leave conflicting decisions with the human.

Keep historical attribution separate from current assessment: only claim this execution introduced a defect when its provenance supports that claim. An older weakness can warrant current correction without becoming an execution regression.

Identify whether E2E tests drove this execution's development, then assess the whole suite, including older tests outside the story, using tests as behavioral documentation. No newly added E2E tests does not exempt existing coverage from review. Ground retention, detail downgrades, and overlap consolidation in actual coverage and cost findings; preserve important journey documentation and integration proof. Use the project's testing guidance when supplied and the shared black-box fallback otherwise. Whole-suite assessment does not require running every test.

Look explicitly for additions later worked around or replaced: dead branches, flags, callers, fixtures, compatibility paths, overlapping tests, tests of obsolete internals, and documentation that preserves implementation history instead of product truth. An explicit user decision is not drift. Style preferences, speculative redesigns, duplicate symptoms, and unsupported claims are not findings. Do not retain a negative test or documentation merely to prove that temporary behavior is gone unless its absence is an enduring requirement.

Surface a disputed plan restriction through that handoff before planning its removal. Leave the disputed correction pending the human decision, retain genuine constraints, and continue independently supported reviews. Do not silently rewrite the historical contract or treat preservation as resolution.

Use focused read-only checks when they can confirm or dismiss a finding. Do not run broad suites.

Reconcile findings with current truth

Recheck every finding against the current revision and working tree. Report a later fix and deduplicate remaining findings by root cause. Use current evidence to bound needed corrections across the product, including outside the old story's implementation footprint. Preserve existing product promises and genuine constraints using the shared scope distinction; review reach does not authorize new feature promises. If none remain, leave planning unchanged.

Give unresolved test downgrades and consolidation, including older redundant tests, explicit ownership in the bounded correction plan. Name the retained meaningful coverage and integration proof for consolidation; existing retained E2E coverage may suffice. For detail downgrades, make replacement unit coverage a prerequisite to removing or narrowing the corresponding E2E tests. Apply the same current-truth and destination rules as other corrections; the retrospective plans suite cleanup and does not perform it.

For an unfinished plan, update that plan in place. Preserve completed evidence and resume-useful history; place corrective work before remaining planned work and revise overlapping planned slices instead of duplicating them. Do not renumber completed slices. Record the finding and reviewed commit manifest as a concise learning when this project's plan format supports it.

When a planless execution's completion is not established, return the supported review evidence and the exact completion, proof, or attribution gap. There is no plan to amend, and unresolved original story work is not yet a completed execution correction. Do not reconstruct a plan or create a correction plan until evidence establishes the completed execution boundary.

For a completed execution, use dough-slice-planning to create one follow-up plan in this project's established location. Cite the original story and commit manifest as historical provenance, and the current findings as the correction's scope and evidence. State one bounded correction outcome, affected concepts, concrete impact, preserved behavior, and focused proof. This may reach beyond the original story without rewriting its promises or attributing older defects to it. If correction would change product constraints or promised outcomes, stop for the user's decision. Stop likewise when the findings cannot form one bounded correction.

When two authorized reviews cover the same execution, only the designated writer reconciles findings into the plan destination; the other reviewer returns read-only evidence. After any planning change, do not refine or execute that correction unless the user separately requests it. Continue every other enabled review, then report. That restriction applies to correction refinement and implementation, not to other enabled reviews.

Review process only from a real record

When process review is enabled, apply the shared direction consideration, then when the current conversation or a sufficiently complete transcript contains the execution, separately identify evidence-backed process improvements: wasted work, rule-induced churn, a missing stop condition, a disproved sizing or decomposition assumption, avoidable digression from direction, or a useful practice to learn. Consider whether instructions were concise and context was organized for easy consumption, including this retrospective's own avoidable rereading, duplication, or reconstruction. Distinguish necessary investigation from avoidable waste.

Record observations separately from inferred cost and cause. Use token counts only when they are available in the record; otherwise cite the repeated work and qualify the cost. Neither shorter text nor skipped necessary investigation proves improvement. If the record is insufficient for a process conclusion, state that limit instead of manufacturing a finding. Do not infer missing events, edit guidance, require token measurement, or recursively launch another retrospective. Do not put process proposals into the repository correction plan.

Record supported process findings

After process analysis, record its supported findings in the project's canonical DearDough.md. This is a narrow process-recording allowance; it does not authorize other project or product maintenance. Product-only findings and implementation corrections stay in their own destinations. Preserve every unrelated file.

Apply the process-selection result from Select reviews before resolving, checking, reading, or writing the log location. When process review is skipped or unresolved, do not create, read, or edit the log. When enabled review yields no supported process finding, do not create an empty log and leave an existing log unchanged. --skip-product does not suppress process recording.

Use <project-root>/DearDough.md unless the user or this project's conventions explicitly establish another canonical location for that filename. An explicit location wins over the root default. Do not search other projects or invent an alternative. If the project root or canonical location is missing or conflicting, return the findings with that limitation and stop recording only; continue every independently supported review.

Identify the reviewed execution before writing. Reuse an execution identity already present in the log when available. Otherwise combine its canonical plan or story reference with its first related implementation commit. If it has no implementation commit, use an available stable execution-record reference. A later commit, another review, or the review date does not create another execution. If identity evidence is missing or conflicting, return the findings without a countable occurrence, report the limitation, and continue the other reviews. Do not make an identity from today's date or introduce a tracking system.

For a new log, write this minimal Markdown shape, assigning DD-001 upward in the order of supported findings:

# DearDough Process Findings

## DD-001 — <descriptive issue title>

<concise concrete description>

### Occurrences

- Execution: <stable execution identity>
  - Tool: <Codex, Cursor, Claude Code, or another identified tool>
  - Model: <model identifier, when available>
  - Open Dough release: <version | unknown | unreleased | modified>
  - Evidence: <decisive compact references or locators>
  - Observed effect: <what the record shows>
  - Inference: <qualified cause, cost, or uncertainty, only when needed>

Keep observation separate from inference. Use compact references rather than transcript copies. The occurrence rows are the visible count; do not add a redundant total. Record one-off costs, useful practices, potentially general problems, and supported observations about this retrospective without claiming recurrence or generality the evidence does not establish.

Record the tool name for every new occurrence. Use the tool that executed the work, such as Codex, Cursor, or Claude Code, rather than the tool reviewing it. Record the model identifier when the execution evidence supplies it; otherwise omit the Model line instead of guessing or performing a separate lookup. If the executing tool cannot be identified, report the finding without adding a countable occurrence. Do not backfill older rows without supporting evidence.

On every new occurrence, record Open Dough release: as a released version, unknown, unreleased, or modified. This is the Open Dough guidance used while the work ran — not this project's product version, and not the release installed when the retrospective later runs. Resolve it from execution or installation provenance tied to the reviewed work. Do not use a current checkout VERSION, or today's .agents/skills/dough-update/VERSION or .claude/skills/dough-update/VERSION, unless that installation is tied to the work. If the release cannot be established, write unknown. For unreleased or modified guidance, mark that state and attach an available revision and, when known, the base released version — for example modified; revision <rev>; base <version> — rather than a clean released version. Do not guess or backfill a release on older rows; an identical rereview still makes no edit.