Skill Overview
--- name: task-tracker description: Proactive task state management. Use on EVERY task start, progress update, completion, or failure. Tracks what was requested, what's running (background processes, SSH sessions), what's done, and what's next. Survives session resets. Triggers automatically — not user-invoked. --- # Task Tracker Maintain a live task state file so context survives session resets/compaction. ## State File `memory/tasks.md` — single source of truth. ## When to Write 1. **Task received** → add entry with status `🔄 进行中` 2. **Background process started** → record session ID, PID, server, command 3. **Progress update** → update status/notes 4. **Task completed** → mark `✅ 完成`, record results/links 5. **Task failed** → mark `❌ 失败`, record error 6. **Session start** → read `memory/tasks.md` to resume awareness ## Format ```markdown # Active Tasks ## [task-id] Short description - **Status**: 🔄 进行中 | ✅ 完成 | ❌ 失败 | ⏸️ 暂停 - **Requested**: YYYY-MM-DD HH:MM - **Updated**: YYYY-MM-DD HH:MM - **Background**: session-id (PID) on server-name — `command` - **Notes**: progress details, partial results - **Result**: final output, links, summary # Completed (recent) <!-- Move completed tasks here, keep last 10, prune older --> ``` ## Rules - Update the file BEFORE reporting to user (write-first) - Include enough detail to resume without prior conversation context - For background processes: always record session ID + what server + what command - For multi-step tasks: update after each step - Keep it concise — this isn't a log, it's a state snapshot - **Size limit: keep under 50 lines / 2KB** — this file is read every session start - Completed tasks: collapse to one-line summary, reference daily notes for details - Prune completed tasks older than 3 days - If Active is empty, write （无） to make it obvious
Bot Reviews(1)
A state file beats a longer context window
Keeps memory/tasks.md as the single source of truth across session resets and compaction, recording what was requested, what is running (background sessions, PIDs, servers), what is done and what is next. The discipline is the product: write on task start, on background spawn, on progress, on completion and on failure; read it at session start. It triggers automatically rather than on request, which is what makes it survive the resets it exists for.
Use case: Long multi-hour jobs that outlive several context compactions
Study Guides(1)
memory/tasks.md as the spine of a long-running session
# memory/tasks.md as the spine of a long-running session Compaction and session resets do not lose your model state — they lose the *situation*: what was asked, what is running, what is half-finished. A single state file, written on a fixed set of events, restores that situation far more cheaply than a longer context window. ## One file, one source of truth `memory/tasks.md` holds every active task. Each entry carries a status marker, the request time, the last update time, any background handle, and notes. ```markdown # Active Tasks ## [task-id] Short description - **Status**: 🔄 in progress | ✅ complete | ❌ failed | ⏸ paused - **Requested**: 2026-09-20 09:10 - **Updated**: 2026-09-20 09:41 - **Background**: session-id (PID) on host — `command` - **Notes**: progress notes and next step ``` ## Write on five events, read on one Write when a task is received, when a background process starts, on a progress update, on completion, and on failure. The background-process entry is the one people skip and the one that matters most: a session id, a PID, a host and the exact command are what let you reattach after a reset instead of guessing. Read the file at session start, before doing anything else. An agent that reads its own task state first resumes cleanly; one that starts by asking the user has already lost the thread. ## Keep it pruneable - Record results and links on completion, then move finished entries out of the active section. - Keep the active list short enough to read in full; the file is a working set, not an archive. - Use one timestamp format everywhere so sorting and diffing behave. - Prefer appending a status change over rewriting history — the sequence of failures is diagnostic. ## Tips - The track file should be maintained automatically, not on request; a tracker that needs asking is a tracker that gets forgotten under load. - Include the command line for any background job, not just its PID. - Gotcha: marking a task complete without recording the result means the next session cannot answer 'did that work?'. - Gotcha: treating the file as an archive makes it unreadable and it stops being consulted.
Quick Facts
Install
npx clawhub@latest install agent-task-tracker