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 mostly matches its stated purpose (maintaining a small persistent task state), but there are metadata and instruction mismatches and privacy‑relevant details (writing PIDs, server names, commands) that make it worth careful review before installing.

Purpose & Capability

Name/description (task tracker that persists state) align with the SKILL.md instructions to read/write a single state file. However the package metadata and included _meta.json disagree (different ownerId and version) and the SKILL.md asserts it “Triggers automatically — not user-invoked” while the registry flags show normal user-invocable/autonomous behavior (always: false). These inconsistencies around provenance and invocation model are unexpected.

Instruction Scope

Instructions explicitly instruct the agent to write/read memory/tasks.md and to record session IDs, PIDs, server names, and full commands. That is coherent with a task tracker, but these fields can contain sensitive data (server identifiers, command-line arguments that may include secrets). The SKILL.md also mandates 'Update the file BEFORE reporting to user (write-first)', which increases the chance of persisting transient or sensitive state. The document does not reference any other files or env vars, which is consistent, but it does not declare the memory/tasks.md path in the skill metadata (no required config paths), so there's a minor mismatch between declared requirements and runtime instructions.

Install Mechanism

Instruction-only skill with no install spec and no code files — low install risk because nothing will be downloaded or written by an installer. The runtime behavior is limited to read/write of a small state file.

Credentials

The skill requests no environment variables or external credentials. That is proportionate to its stated purpose. However, the data it instructs the agent to capture (commands, PIDs, server names) can contain secrets; absence of declared secrets is appropriate but the skill should document redaction rules.

Persistence & Privilege

The skill expects to persist state across sessions (survive resets), which fits its purpose. It does not request 'always: true' or system-wide privileges. The main concern is that the SKILL.md claims automatic triggering (runs on EVERY task event) while registry flags do not indicate forced inclusion — a mismatch that affects how broadly this skill will act in practice.

What to consider before installing

This skill appears to be what it says (a small persistent task-state tracker) but there are a few things to check before installing: 1) Provenance: the included _meta.json ownerId/version differ from the registry metadata—verify the publisher and source. 2) Invocation: the doc says it should 'trigger automatically' but the registry metadata doesn't force always-on; decide whether you want automatic triggering. 3) Privacy: it records session IDs, PIDs, server names and full commands — avoid storing commands or arguments that contain secrets, and confirm the memory/tasks.md location is access-controlled. 4) Redaction: ask for or add a rule to redact sensitive fields before writing (tokens, passwords, private keys, secret-bearing args). 5) Minimality: consider making it user-invoked or limiting fields recorded to reduce leakage. If you cannot verify the owner or you are uncomfortable with persistent recording of process/host/command details, do not install or only enable it in a constrained/testing environment.

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