mirror of
https://gitverse.ru/kpa39l/task-list-execution.git
synced 2026-09-28 21:05:03 +00:00
Initial commit: Hermes skill task-list-execution
This commit is contained in:
@@ -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
|
||||
@@ -0,0 +1,24 @@
|
||||
# Example Session: C2 Task Execution
|
||||
|
||||
## Context
|
||||
|
||||
User attached `STATUS.md` from Memory OS project and said:
|
||||
"выбери из файла список задач. и выполни первую незавершенную. Дай мне статус по результату."
|
||||
|
||||
## What I Did Wrong
|
||||
|
||||
1. Read the file → found C2 as first pending task
|
||||
2. Instead of starting immediately, created a `todo` list of 4 sub-steps
|
||||
3. Ran `docker ps`, Qdrant check, `ls wiki-raw`, and `cronjob list` — all as preamble
|
||||
4. User waited silently for 4 tool calls and got no visible progress
|
||||
5. User said "не вижу прогресса" — frustration signal
|
||||
|
||||
## What I Should Have Done
|
||||
|
||||
```
|
||||
Read file → "C2. Начинаю." → tool call (check state) → "Система жива, создаю тест" → tool call → "Ищу в Qdrant" → "✅ C2 done"
|
||||
```
|
||||
|
||||
## Key Lesson
|
||||
|
||||
Investigation is execution. The first tool call of the task IS the progress.
|
||||
Reference in New Issue
Block a user