task-list-execution/SKILL.md

name, description, version, author, license, platforms, metadata

name	description	version	author	license	platforms	metadata
task-list-execution	Execute tasks from a user-provided STATUS.md / task list file: pick first incomplete, act, report result. No planning phase, no lengthy analysis.	1.0.0	Hermes Agent	MIT	linux macos	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