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 stated purpose (task-state tracking) is plausible, but its instructions ask the agent to persist potentially sensitive runtime details and claim automatic triggering while the registry metadata does not — these mismatches and privacy risks merit caution.

Purpose & Capability

The name/description (task state tracking across session resets) matches the SKILL.md guidance to keep a single state file. However the SKILL.md claims the tracker 'Triggers automatically — not user-invoked' while the registry flags do not set always:true and still mark it user-invocable, which is an inconsistency about how and when the skill runs.

Instruction Scope

Instructions direct the agent to read/write a persistent file memory/tasks.md and to record session IDs, PIDs, server names and full commands for background/SSH sessions. Recording full commands risks capturing secrets (passwords, tokens, sensitive CLI args). The rules also instruct updating the file BEFORE reporting to the user (write-first), which can cause unreviewed sensitive content to be persisted.

Install Mechanism

No install spec and no code files are present (instruction-only). This minimizes code-execution/install risk — the skill won't pull external binaries or archives during install.

Credentials

No environment variables or external credentials are required, which is consistent with a simple tracker, but the instructions still require capturing runtime context (servers, PIDs, commands) that can include sensitive data. The skill does not document sanitization, access controls, or who can read memory/tasks.md — so requested persistence of sensitive context is disproportionate without mitigation.

Persistence & Privilege

The skill requires persistent state across sessions (memory/tasks.md) which is reasonable for a tracker, but the SKILL.md's claim that it 'Triggers automatically — not user-invoked' conflicts with registry metadata (always:false). If the skill were to run automatically for every task, that would increase blast radius because it records potentially sensitive context. The write-first rule and retention policy (prune after 3 days) are noted, but there is no guidance on storage access controls or redaction.

What to consider before installing

This skill generally does what it says (maintains a persistent task-state file), but it instructs the agent to persist session IDs, PIDs, server names and the exact commands for background/SSH work — these can contain secrets. Before installing, consider: - Confirm whether the skill will actually run automatically; if automatic invocation is intended, the registry should set always:true or otherwise document how auto-triggering is enforced. If not intended, update SKILL.md to avoid surprise behavior. - Ask where memory/tasks.md is stored, who can read it, and whether it is synced off-device. Ensure appropriate access controls and encryption are in place. - Require the skill to redact or avoid storing command-line arguments that may contain credentials (e.g., mask tokens/ passwords) or record only sanitized metadata (e.g., command name, not full args). - Prefer prompting the user for explicit consent before recording SSH/server details or before the first automatic write. - If you cannot verify storage protections or sanitization, treat this skill as higher risk and avoid installing it in environments that handle secrets or sensitive infrastructure. If the author can provide: where the file is stored, assurance of access controls/encryption, and a change to the SKILL.md that either removes automatic-trigger language or the registry is updated to reflect true automatic behavior, this would reduce concern.

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