mirror of
https://gitverse.ru/kpa39l/task-list-execution.git
synced 2026-09-28 21:05:03 +00:00
estorozhenko
90 lines
3.7 KiB
Markdown
90 lines
3.7 KiB
Markdown
---
|
|
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 |