report-progress-eta-analyze

• SKILL.mdcore · 13,371 bytes
• SKILL.mdcore · 13,371 bytes

# Report Progress, ETA, and Analyze

Use existing plans, process state, logs, results and timing receipts to explain how close the authorized outcome is to completion. Refresh cheap, time-sensitive evidence when available; distinguish current observations, older receipts, estimates and unknowns. Reuse the existing run artifacts rather than introducing another ledger or telemetry system.

## Establish progress and remaining work

Report the state of the whole authorized outcome, not just the last command or heartbeat. Lead with what is complete, what remains and the current bottleneck. Distinguish generated, accepted, released and live-verified output. When work has separate deliverables, such as a code release and a content pilot, give each its own state and forecast. Counts of passing tests or completed model calls are supporting evidence, not a percentage of the whole task.

Name the completion boundary being forecast: for example, private review ready, approved release, or live verified. User validation time is separate from processing time. Label every remaining count with its stage and denominator: “writing 0 remaining; assembly 25/66 remaining; final QA pending.” Never show an unqualified “0 remaining” while required downstream work remains. Reused approvals count only for their qualified scope; an automated pass is not manual inspection.

## Use past runs as forecast data

Always give a reasonable provisional ETA when a numerical estimate can be constructed, even if timing evidence is incomplete. State assumptions explicitly and distinguish measured rates from judgment. If a required external hold has no observable resolution time, give a conditional ETA for the remaining work after clearance rather than inventing a recovery time.