Task Extractor

Extract, track, and verify completion of multiple tasks from a single user message. Use when any message contains 3+ actionable items, a prompt dump with mix...

Security Scan

The skill does what it claims (extract and track tasks) but its runtime instructions direct the agent to autonomously execute tasks (including spawning sub-agents and touching external systems) and to avoid asking for confirmation, which can lead to unintended side effects or implicit use of credentials.

Purpose & Capability

Name and description match the SKILL.md: extraction, queueing, and verification of multi-item user messages. Writing TASK_QUEUE.md in a workspace and tracking artifacts is coherent with the stated purpose; no unrelated environment variables, binaries, or installs are requested.

Instruction Scope

The instructions explicitly tell the agent to execute tasks automatically ('Ryan's rule: don't interrogate, just do'), prioritize and run tasks, spawn sub-agents, and verify completion via external checks (file existence, API 200, deploy URL). This gives the skill broad runtime powers (file writes, network calls, potentially destructive operations) without requiring user confirmation and with an activation rule of 'if uncertain, activate', increasing risk of unintended actions.

Install Mechanism

Instruction-only skill with no install spec and no code files — low installation risk (nothing is downloaded or written by an installer).

Credentials

No credentials or env vars are declared (appropriate for an extraction/tracking tool). However, the verification and execution steps imply API calls, deployments, or other actions that may require credentials; the skill neither requests nor documents required credentials and may therefore end up using whatever credentials the agent already has access to — this is a gap and a potential risk.

Persistence & Privilege

The skill writes and updates workspace/TASK_QUEUE.md (expected). It can spawn sub-agents and rely on asynchronous completion events; it is not set to always:true. Combined with the 'do not ask' rule, the ability to autonomously perform and verify tasks increases blast radius, but the skill does not change other skills or system-wide configs.

What to consider before installing

This skill is coherent but potentially dangerous in practice because it instructs the agent to act without asking follow-up confirmation, spawn sub-agents, and perform external checks. Before installing: (1) decide whether you want the agent to automatically perform actions generated from user messages — if not, disable autonomous invocation or modify the skill to require confirmation for anything beyond harmless 'QUICK' reads; (2) run the skill in a sandboxed workspace to contain file writes (TASK_QUEUE.md); (3) ensure credentials your agent has access to are minimised (the skill doesn't declare which creds it needs); (4) consider editing SKILL.md to require explicit user confirmation for destructive or privileged tasks and to enumerate any needed credentials/APIs; (5) monitor sub-agent activity and logs when the skill first runs. If you lack those controls, treat this skill as higher-risk.

Parse multi-task messages → numbered queue → execute sequentially → verify each → report.

Activation

Trigger on ANY user message containing 3+ distinct actionable items. Signs:

• Multiple sentences starting with verbs ("build", "fix", "send", "check", "add", "research")
• Comma-separated or period-separated instructions
• Mixed topics in one paragraph
• "also", "and then", "plus", "oh and", "one more thing"

If uncertain whether to activate: activate. False positives (structuring a 2-item request) cost nothing. False negatives (dropping task #7 of 12) cost trust.

Step 1: EXTRACT (before any execution)

Parse the message into individual tasks. Each task gets:

• Number (sequential)
• Summary (one line, imperative verb)
• Type: BUILD | FIX | RESEARCH | SEND | DEPLOY | CONFIG | OTHER
• Estimated effort: QUICK (< 5 min) | MEDIUM (5-30 min) | HEAVY (30+ min / sub-agent)

Write to workspace/TASK_QUEUE.md:

# TASK_QUEUE — [date] [time]
# Source: [channel]
# Total: [N]
# Status: IN PROGRESS

| # | Task | Type | Effort | Status | Artifact |
|---|------|------|--------|--------|----------|
| 1 | [summary] | BUILD | HEAVY | ⏳ | |
| 2 | [summary] | FIX | QUICK | ⏳ | |
| 3 | [summary] | SEND | QUICK | ⏳ | |
...

Step 2: RECEIPT

Reply to the user with the extracted checklist BEFORE starting work:

📋 Extracted [N] tasks from your message:

1. ⏳ [task summary]
2. ⏳ [task summary]
3. ⏳ [task summary]
...

Starting now. I'll check each off as I go.

Do NOT ask "is this right?" unless genuinely ambiguous. Convert ambiguity into a task and execute. Ryan's rule: don't interrogate, just do.

Step 3: EXECUTE

Work through tasks in dependency order (not necessarily numerical order):

• Independent QUICK tasks first (batch them in parallel tool calls)
• MEDIUM tasks next
• HEAVY tasks: spawn sub-agents with clear scope

For each completed task, update TASK_QUEUE.md:

• ⏳ → ✅ (done) or ❌ (failed) or ⚠️ (partial) or 🔄 (spawned sub-agent)
• Fill in the Artifact column (file path, URL, commit hash, or "n/a")

Step 4: RECONCILE

After all tasks are attempted (or sub-agents spawned), reply with the final checklist:

📋 Task Report ([completed]/[total]):

1. ✅ [task] → [artifact]
2. ✅ [task] → [artifact]
3. 🔄 [task] → sub-agent running, will announce when done
4. ❌ [task] → [reason for failure]
5. ⚠️ [task] → [what was done, what's left]

Step 5: VERIFY (on sub-agent completion)

When a sub-agent announces completion:

• Update TASK_QUEUE.md
• If ALL tasks are now ✅/❌, send final summary
• If tasks remain ⏳, continue working

Rules

1. NEVER skip the extract step. Even if the answer seems obvious. The extract step IS the safety net.
2. NEVER mark a task ✅ without evidence. Evidence = file exists, command succeeded, API returned 200, deploy URL works.
3. If a task fails, say WHY. Not just ❌ — include the error, the blocker, or what's needed.
4. Sub-agent tasks get 🔄 until completion event arrives. Don't mark them ✅ optimistically.
5. TASK_QUEUE.md is the source of truth. If context overflows, re-read it. If a session restarts, re-read it.
6. One TASK_QUEUE at a time. If a new multi-task message arrives while one is active, append to the existing queue (renumber).
7. Checkpoint at 5 completed tasks. Update the user with progress so far.

Edge Cases

"Do X and also Y but wait on Z"

• X and Y get ⏳, Z gets 🕐 (blocked — note the dependency)

Sub-agent timeout

• Mark as ⚠️, note what was attempted, offer to retry or take over manually

User changes mind mid-execution

• Update TASK_QUEUE.md, cross out cancelled tasks with strikethrough, continue with remaining

Overlapping tasks

• If task 3 and task 7 are really the same thing, merge them. Note in Artifact: "merged with #3"

Anti-patterns

• ❌ Reading the message, immediately jumping into task #1 without extracting all tasks
• ❌ Marking a sub-agent task ✅ before the completion event
• ❌ Saying "I'll get to that" and then forgetting
• ❌ Only reporting on the tasks you completed, silently dropping the ones you didn't
• ❌ Asking "which one should I do first?" — just prioritize by dependency + effort and go