# Status Update > Summarize a long-running agent task as a concise, evidence-backed snapshot — completed outcomes, current activity, remaining work, friction, surprises, and any required user action. - Skill: `abpai/status-update` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add abpai/status-update` - Raw SKILL.md: https://api.skillmd.com/api/skills/abpai/status-update/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: abpai (https://skillmd.com/u/abpai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/abpai/status-update --- # Status Update Give the user an accurate control-panel view of the work, not a transcript. Default to a quick update that is easy to scan and easy to drill into by selecting any bold label. ## Read the request `detailed` (or an equivalent ask for depth) selects the expanded report in [Expand only on request](#expand-only-on-request); anything else is the scope. No argument and no stated scope means the quick update for the whole task. ## Establish current truth Treat a status request as read-only. Do not interrupt workers, edit files, restart commands, deploy, or otherwise alter the task merely to report it. Prefer current primary evidence — repository, PR, CI, or runtime state — over earlier commentary, plans, worker claims, docs, or memory. State important unknowns instead of filling gaps with a plausible story. When reporting another Codex task, resolve the exact task first and read its recent turns; don't ask an active worker for a redundant status report when its existing state is enough. ## Classify the work honestly Use these rules before writing: - **Done** means the outcome exists and its relevant proof passed. An edit, attempted command, worker claim, or open PR is not automatically done. - **Active** means an operation is executing or a worker is presently pursuing it. Name the exact step and the latest meaningful liveness evidence. A plan item marked in progress is not enough by itself. If liveness is stale or unavailable, classify the work as **Unverified**, not Active. - **Unverified** means a claim may be true but current primary evidence is unavailable, stale, or contradictory. Name the last known evidence and its age when that matters. - **Left** means required acceptance work remains. Order it by dependency and decision value, not by file or chronology. - **Friction** is a recoverable problem, repeated rework, slow gate, ambiguity, or failed attempt. Call something a **blocker** only when progress cannot continue without user action or an external state change. - **Surprise** is a new fact that changed the plan, scope, risk, or mental model. Routine test failures and expected iteration are not surprises. - **Locked in** means a durable, verified improvement is present in the actual code, configuration, artifact, or live system. Keep it distinct from work that was merely explored. When the user asks what is locked in, mark those outcome labels with `(locked in)` instead of making them infer it. For parallel work, summarize each meaningful workstream's objective and state. Do not list agents by name unless identity helps the user understand ownership or a dependency. ## Choose the overall signal Open with one of these verdicts and one plain-language sentence: - `On track` — work is advancing with no decision-changing risk. - `At risk` — work is advancing, but a known issue threatens scope, quality, or timing. - `Blocked` — no meaningful progress can continue without an external change that neither the agent nor the user can currently make. - `Waiting on you` — the next required action or decision belongs to the user. - `Idle` — nothing is executing even though autonomous work remains. - `Complete` — the requested outcome and required proof are finished. Exactly one verdict opens the update, so resolve overlaps by this order: `Complete`, then `Waiting on you`, then `Blocked`, then `Idle`, then `At risk`, then `On track`. A stall the user can clear — a credential, a permission, a decision — is `Waiting on you`, not `Blocked`; reserve `Blocked` for a stall that no user action can clear, such as a third-party outage or an upstream fix. Work the team could simply do next is not blocked, however large: it is `Left`, and the verdict reflects whatever else is true. Apply the signal to the scope the user asked about. If a long task drifted into several programs, name the scope in the opening sentence. A documented handoff does not make the original outcome complete unless the user explicitly changed the objective to producing that handoff; otherwise report the original outcome as blocked, waiting, or left. When scope is genuinely ambiguous, give the narrow and broad verdicts in one sentence instead of silently choosing one. ## Write the quick update Keep the default short enough to scan in one pass even when the underlying task is large. Give **Active now** one bullet per genuinely live workstream — never drop a live workstream to save a line — and if more than three are running, group the smaller ones into one bullet and name the count. Collapse related outcomes before adding detail. Use short bullets, concrete outcomes, and bold noun labels that the user can select for follow-up. Omit empty optional sections except `Surprises`, which should say `None that changed the plan` when the user explicitly asked about surprises. Use this shape as a menu, omitting sections that add no decision value: ```markdown **Status — :** **Done** - **:** . Add `(locked in)` to the label only when the user asked what is locked in. **Active now** - **:** . **Left** 1. **:** . 2. **:** . **Friction** - ** ():** . **Surprises** - **:** . **Need from you** - . ``` Do not force every section to contain several bullets. Prefer one strong bullet over a miniature changelog. Include exact PRs, task ids, commands, files, or artifacts only when they provide useful drill-down anchors. ## Expand only on request For `detailed`, preserve the same answer-first order, then add only the relevant detail: - a workstream-by-workstream state; - proof run, failure, and skip details; - resolved versus unresolved issues; - decisions that changed the execution path; - remaining acceptance criteria and their dependencies. Do not repeat the quick summary in longer prose. Keep confirmed facts, judgment, and unknowns distinguishable. ## Final checks Before sending, confirm the update can be understood without reading prior commentary.