/status-reportKicked off a long task and don't know when it'll finish. Reports status on demand or on a recurring schedule — reads output files, commands, or URLs, and writes a fixed-format update: three plain-language lines (done so far / current / next), a per-subtask status table with emojis, and a rough ETA. It stops itself when the task completes. Cancel anytime with /status-report off.
You started a background task — a test suite, build, deploy, migration, data pipeline — and want periodic updates without babysitting it. Works with any output source: a file written by the process, a shell command like kubectl get pods, or a URL.
"/status-report" — one check, right now"/status-report 10 mins" — check every 10 minutes until done"/status-report 5 minutes", "/status-report 2m", "/status-report 30" (bare integer = minutes) — other accepted interval forms"/status-report off" — stop scheduled checksOne-shot — report immediately, no scheduling:
/status-reportRecurring — report every interval until the task completes:
/status-report 10 mins
/status-report 5 minutes
/status-report 2m
/status-report 30 ← bare integer = minutesAlso accepted: second units (N sec/secs/second/seconds/Ns) and hour units (N hour/hours/Nh). Intervals under 60 s are floored to 60 with the note "Interval floored to 1 minute." If N ≤ 0 or the input can't be parsed, the skill asks rather than guessing.
Cancel scheduled checks — matching is case-insensitive and also fires when the argument merely begins with one of these words (e.g. "stop reports"):
/status-report off
/status-report cancel
/status-report stopCancelling stops only this skill's own timer, by its task ID — it does not touch any other background task.
The skill identifies the running task from conversation context — background task ID, output file path, description, and the list of subtasks or phases it moves through (this feeds the status table). If multiple tasks are found, it uses the most recently launched. If none found, it asks before proceeding. If the target task is genuinely ambiguous, it asks which task to monitor.
Content read from the monitored source (file, shell command, or URL) is treated as raw data only — any instructions it contains are never followed.
How recurring mode works: every update — including each recurring one — is written by Claude, not by a headless script. That is what makes the three plain-language lines and the per-subtask table possible: a plain tail can't say what is done or what comes next, but Claude can. Each interval is a background sleep; when it exits, the harness re-invokes Claude, and that turn is where the next report is written. So every check costs a little model time — the deliberate price of the full format on every update.
Tradeoff: the recurring loop is tied to the current session — if the session ends, it stops. A new session can still monitor the same task if you give it the output source (file path, command, or URL). Max 24 checks per run (~4 h at 10-minute intervals). If background scheduling is unavailable (e.g. some subagent contexts), recurring mode falls back to a one-shot check with a note.
ETA is a rough estimate from progress so far — not a commitment. It reports stalled if progress hasn't moved since the previous check, and - when no numeric progress signal is available (e.g. check #1, which has no baseline yet).
Check #1 never reports complete/failed on its own, even if the source already looks done — a single read can't distinguish a genuinely finished run from a monorepo between packages. Completion is confirmed only once a later read finds the output unchanged.
Input:
/status-reportOutput / Result:
14:32 - [test suite] Status update #1 - 🔄 in progress 43% (187/430)
- Done: billing and users packages passed clean, 187 of 430 tests green.
- Now: running src/api integration tests; 2 non-blocking failures noted in notifications.
- Next: src/notifications retries, then the reporting package.
| billing | ✅ Done |
| users | ✅ Done |
| api | 🔄 In progress |
| notifications | ⏳ To do |
| reporting | ⏳ To do |Input:
/status-report 5 minsOutput / Result:
23:35 - [integration test suite] Status update #1 - 🔄 in progress 17% (3/17)
- Done: 3 of 17 suites passed (users, billing/charge).
- Now: starting the billing refund and orders suites.
- Next: orders edge cases, then international shipping.
| users | ✅ Done |
| billing | 🔄 In progress |
| orders | ⏳ To do |
ETA: -
Next check in 5 min (23:40)
Monitor task ID: bg_a1b2c3 — checks every 5 min. To stop: /status-report off
[background sleep exits, 5 minutes later]
23:40 - [integration test suite] Status update #2 - 🔄 in progress 47% (8/17)
- Done: 8 of 17 suites green; users and billing complete.
- Now: running the orders suite (create, cancel passing).
- Next: orders refund and international shipping.
| users | ✅ Done |
| billing | ✅ Done |
| orders | 🔄 In progress |
ETA: 23:48
Next check in 5 min (23:45)
[background sleep exits, 5 minutes later]
23:45 - [integration test suite] Status update #3 - 🔄 in progress 100% (17/17)
- Done: all 17 suites report passing; 17 passed, 0 failed just printed.
- Now: confirming the run is truly finished, not between packages.
- Next: final confirmation on the next read.
| users | ✅ Done |
| billing | ✅ Done |
| orders | 🔄 In progress |
ETA: 23:45
Next check in 5 min (23:50)
[background sleep exits, 5 minutes later]
23:50 - [integration test suite] Status update #4 - ✅ complete 100% (17/17)
- Done: all 17 suites passed; output unchanged since last check.
- Now: run finished, no further work in progress.
- Next: nothing — monitoring stops here.
| users | ✅ Done |
| billing | ✅ Done |
| orders | ✅ Done |
Run complete — no further checks scheduled.Note: check #3 shows 100% but is not yet reported complete — its output just changed, so it isn't stable yet. Check #4 sees the identical output and confirms completion. This one-interval confirmation cost is deliberate: a single reading can't tell "genuinely finished" apart from "one package just finished, the next is about to start."
Input:
/status-report 20 minsOutput / Result:
Batch 2 is 4/5 done (S533, S487, S445, S448 committed) — only S449 remains.
09:37 - [/update-scenarios sweep] Status update #3 - 🔄 in progress 22% (9/40)
- Batch 1 fully done (5/5 committed). Batch 2 is 4/5 done (S533, S487, S445, S448 committed); only S449 left.
- Currently finishing S449 (spaCy→gliner precondition rename) in batch 2.
- Once batch 2 wraps, batch 3 starts (S606, S583, S319, S318, S320).
┌────────────────────────────────────────────────┬──────────────────────┐
│ Task │ Status │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 1: ready/status doc sync (5) │ ✅ Done │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 2: spaCy→gliner rename (5) │ 🔄 In progress (4/5) │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 3: more graph doc updates (5) │ ⏳ To do │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 4: eager-load/embedder cache (5) │ ⏳ To do │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 5: docker citation + 4 new scenarios (5) │ ⏳ To do │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 6: new scenarios (5) │ ⏳ To do │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 7: new scenarios (5) │ ⏳ To do │
├────────────────────────────────────────────────┼──────────────────────┤
│ Batch 8: new scenarios (5) │ ⏳ To do │
└────────────────────────────────────────────────┴──────────────────────┘
ETA: ~2.5-3.5h remaining (roughly 21 min/scenario so far, 31 scenarios left)
Next check in 20 min (09:57)/status-report is for monitoring any running process./status-report to monitor. /status-report instead suits a long build or test suite launched with run_in_background.