Agent Task Tracker

Proactive task state management. Use on EVERY task start, progress update, completion, or failure. Tracks what was requested, what's running (background proc...

Security Scan

The skill's purpose (persisting task state) is plausible, but the instructions ask the agent to persist potentially sensitive runtime details (commands, PIDs, session IDs) and contain metadata inconsistencies; these gaps create privacy and coherence concerns that the user should review before enabling it.

Purpose & Capability

The declared purpose (task-state tracking across sessions) matches the instructions to read/write memory/tasks.md and record task lifecycle events. However the SKILL.md claims it "Triggers automatically — not user-invoked" while registry flags show it is user-invocable and not forced-always; the package metadata in _meta.json (ownerId, slug, version, publishedAt) also disagrees with the registry metadata. These metadata mismatches reduce trust and coherence.

Instruction Scope

Instructions require writing persistent state for every task and explicitly instruct recording background session IDs, PIDs, server names, and the exact command. They also mandate 'write-first' (update the persistent file before reporting to the user). That behavior increases risk of persisting sensitive data (credentials, tokens, or confidential outputs) and creates a privacy/exfiltration surface even though no external network endpoints are used.

Install Mechanism

This is an instruction-only skill with no install spec and no code files — lowest-risk in terms of code being written to disk or arbitrary downloads.

Credentials

The skill requests no environment variables, binaries, or config paths, which is proportionate to a purely in-memory or agent-memory file writer. That said, the instructions expect the agent to capture runtime process/session details (PID, server, command) without declaring what permissions or APIs are used to obtain those — a minor mismatch to clarify.

Persistence & Privilege

The skill asks for persistent storage of task state that 'survives session resets' and to be used on EVERY task. While it is not declared as always:true, autonomous invocation is allowed by default; combined with the 'write-first' rule, this gives it a broad ability to persist content automatically. This creates ongoing privacy and data-retention risk if the stored content can include secrets or sensitive results.

What to consider before installing

Before installing, consider these actions: (1) Confirm the publisher/owner identity — registry metadata and _meta.json disagree. (2) Understand exactly what will be written to memory/tasks.md and where that file is stored and who can read it; avoid storing outputs that may contain secrets. (3) Ask the author to add sanitization (filtering/redaction), configurable retention, and an opt-in toggle so it isn't automatically invoked for every task. (4) If you enable it, review the first few entries of memory/tasks.md to verify no sensitive data is being persisted and set pruning/rotation limits. (5) If you need stronger guarantees, require encryption or tie storage to a controlled vault. If the developer can provide clearer metadata, explicit sanitization rules, and opt-in triggers (instead of unconditional write-first), my confidence in this skill would increase.

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

# 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