---
name: task-list-execution
description: "Execute tasks from a user-provided STATUS.md / task list file: pick first incomplete, act, report result. No planning phase, no lengthy analysis."
version: 1.0.0
author: Hermes Agent
license: MIT
platforms: [linux, macos]
metadata:
  hermes:
    tags: [workflow, task-list, execution, productivity]
---

# Task List Execution from File

## When to Use

The user attaches or references a file containing a structured task list (STATUS.md, README.md, TODO.md, or similar) and says something like:

- "выбери из файла список задач и выполни первую незавершенную"
- "pick the first incomplete task from this file and do it"
- "что там по задачам? сделай что-нибудь"
- "take the next pending task and execute it"

## Core Rules

### 1. Read once, act immediately

Read the file. Identify the first task with status `⏸️ Pending`, `⏳ In Progress`, or `⚠️` (not `✅ DONE`, not `❌ CANCELLED`). Then **start executing it**. Do not:

- ❌ Spend time verifying every component of the system first
- ❌ Create a todo list with sub-steps before doing anything
- ❌ Present a multi-step plan for approval
- ❌ Give a status report of every component before acting

✅ Instead: "Task X found. Starting. [do the thing]"

### 2. Investigation is part of execution, not preparation

If the task needs state checks (docker ps, Qdrant health, file existence, cron status), do those checks as **the first action of the task itself**. Frame them as progress, not setup:

- ✅ "C2: проверяю состояние Docker и Qdrant..." → *tool call*
- ❌ "Let me first check the overall system health before I start..." → *tool calls* → "Here's the status" → *then start*

### 3. Report the result, not the journey

After completing, report:

- **What was done** (1 sentence)
- **Result** (✅ done / ⚠️ partial / ❌ blocked)
- **What's next** (optional, 1 line)

Do not report every tool call or intermediate state unless the user asks.

### 4. Handle blockers

If the task is blocked:
- Say why in one sentence
- Offer to skip to the next task or fix the blocker
- Do not get stuck in a debugging rabbit hole without user input

### 5. Clean up after yourself

- Remove test artifacts you created
- Update the STATUS.md file to reflect the new status
- Remove TODO items if you created them

## Common Pitfalls

| Pitfall | Fix |
|---------|-----|
| Analyzing the full system before starting the task | The analysis IS the task's first step, not a preamble |
| Writing a todo list for the user to approve | Just execute the task directly |
| Calling the user's frustration "impatience" | They're right — move faster |
| Explaining what you're about to do instead of doing it | Say "Начинаю" and call tools |
| Writing long status updates mid-task | Save the full report for the end |

## Example

**User:** [attaches STATUS.md] выбери из файла список задач. и выполни первую незавершенную.

**Bad:** "Let me read the file. I see tasks A1-A7 done, B1-B2 done, C1 done, C2 pending. Let me check the current state of the system first — docker ps, Qdrant health, search-api, cron status..." (3 tool calls of analysis) → "Here's the system status" → "Now I'll start C2"

**Good:** "Читаю файл. Первая незавершённая — C2 Verify end-to-end pipeline. Начинаю." (tool call to check state AS PART of the task) → "Система жива. Создаю тестовую заметку..." → "✅ C2 done. Пайплайн работает."

## Verification

After completing:
- [ ] Task status updated in the source file
- [ ] Test artifacts cleaned up
- [ ] Result reported concisely