feedback_tldr_report_on_completion

name: feedback_tldr_report_on_completion
description: "On each completion of all requested work, give a TLDR report — tokens used, done, to do, issues, options"
metadata:
node_type: memory
type: feedback

originSessionId: 9bfdd6d9-cfef-4ca3-8413-62e3c3e498c2

Two cadences are mandatory, ALWAYS :

1. End-of-turn TLDR memo — every completion, no exceptions (the report below). The user has flagged that statistics were missing — never omit the work-statistics block.
2. ~3-minute status pulses during long work — a one-liner: done / todo / time(or budget) left, so the user is never waiting blind. They actively manage budget+time and named "token usage and time spent" the critical constraint.

When finishing a batch of requested work in the Mapper project, end with a concise TLDR report containing:

• Tokens used — total estimate for the batch (mark it an estimate), plus an accurate per-subagent breakdown.
• Time — approximate elapsed for this part; sub-step durations are exact only where a subagent reports duration_ms.
• Components used — a small table of what did the work and for what:
  • Subagents/agents — type · purpose · tokens · duration (all read from the returned usage block).
  • Tools — which ones · what for (per-tool token counts are NOT itemizable — total only).
  • Skills / hooks — which fired · what for.
• Done — what was completed and shipped (with commit hashes where relevant)
• To do — what remains, in priority order
• Issues — problems found / blockers
• Options — choices the user can make next

Why: The user runs many tasks and needs a fast, scannable status to decide next steps without re-reading the whole transcript. They are token-sensitive and want predictability, and want visibility into which parts of the system (agents/tools/skills/hooks) spent the effort.

How to apply: Keep it tight (a short table or bullets). Tracking is near-zero cost — subagent tokens/durations come from their returned usage blocks (already in context) and the component list is just what you already did, so gather it as you go, not in a separate pass. Measurability limit: the harness does NOT expose per-tool / per-skill token counts or precise wall-clock to the model — report only what's measurable (per-subagent tokens+duration exact; total tokens + time as estimates) and never fabricate per-tool numbers; mark them n/a. Put detailed write-ups in md files (see the [[feedback_no_overengineering]] doc-not-chat rule), and use the TLDR as the chat-level summary. Relates to [[project_context_optimization]].