End-of-task reports that are useful later

A short closeout with changed files, commands and results, decisions made, and honest follow-up.

May 27, 2026 · 2 min read · 351 words
.md

A reusable prompt for the final message of a task. It forces a consistent, no-preamble closeout so the next person (or the next session) can pick up instantly.

commands/report.md
---
description: In the final response, list files changed, commands run with their results/verification, decisions made, and any remaining blockers or items
---
 
Produce an end-of-task report.
 
Include:
 
- Files changed (absolute paths, grouped).
- Commands run + their results/verification (typecheck/lint/test/build pass counts).
- Key decisions made and why.
- Remaining blockers or items left for integration / follow-up.
 
Keep it terse and scannable; no preamble.

Mapped to a prompt#

This is a reusable output template rather than an action — hence prompt. It shapes how a task ends rather than doing work itself.

Verification belongs in the report#

Listing the commands run with their actual pass counts turns "it should work" into evidence. Pairing that with grouped file paths and the decisions made gives a complete handoff in a few scannable lines.

What it prevents#

Bad closeouts make the next session expensive. Someone has to rediscover which files changed, which commands actually ran, whether lint failed before the fix, and which tradeoffs were intentional.

This prompt keeps the final message useful when context is moving fast. It is not a diary. It is a compact operating record: changed surface, verification surface, decision surface, and remaining risk. That is enough for a human to continue, review, or revert a local assumption without replaying the whole conversation.

What it should omit#

It should not congratulate the work, restate the full plan, or bury failures under soft language. The report is for the next operator. It should make the current state obvious, including anything that was not verified.

Was this useful?

React if it helped; comment if you have a concrete question, correction, or field note.

-

Discussion (0)

Practical notes, bug stories, and disagreement with receipts are welcome.

No comments yet. A useful first comment is usually a field note: what failed, what held, or what you would check before shipping this idea.
Start the discussion
Markdown is supported. Keep it concrete and useful.