Initial commit: Hermes skill task-list-execution

SKILL.md

@@ -0,0 +1,90 @@
+---
+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