mirror of
https://gitverse.ru/kpa39l/task-list-execution.git
synced 2026-09-29 09:15:05 +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