| name | tasks |
| description | This skill handles issues, tasks, todos, epics, etc in a way the user likes. It can advise on what should be written, to which local files, when, as well as how to read such files. it can help synchronise such local issues with remote issue trackers |
| triggers | [{"phrase":"what should I do next?"},{"phrase":"tados in this project"},{"phrase":"tasks in any project"},{"phrase":"epics in all projects"},{"phrase":"current issues"},{"phrase":"new issue"},{"phrase":"new feature"},{"phrase":"new bug"}] |
tasks
A skill for helping user decide what to do next
What a skill is
It's actually a docstring with executable side-effects, and should be written with the same rigour.
Description
This skill handles issues, tasks, todos, epics, etc in a way the user likes.
It can advise on what should be written, to which local files, when, as well as how to read such files.
It can help synchronise such local issues with remote issue trackers.
Local naming
Given the scope of the terms we order them like this:
Epic > Task > Issue > To Do
We do not use "issues" locally, just epics, tasks, and todos.
An "Epic" is at same level as a "Project", and can even concern many projects
A "Task" is roughly at level of a "Feature", and concerns a significant chunk of the project
- a task is in one epic, but can link to others
- a task has many todos
A "ToDo" (aka "to do") is at a low level, may concern just a few lines of code
- a todo is in one task, but can link to others
A new, small, project may not even have any todos yet, just tasks
Local Files
ToDos should be stored in files called "TODO.md"
Tasks should be stored in files called "TASKS.md"
Epics should be stored in files called "PLAN.md", in a section called "Epics"
Note:
- we think of TODO.md and TASKS.md as "belonging to" this skill
- and we think of PLAN.md as belonging to many skills, or other Claude process
So we respect the formatting we find in PLAN.md
- but can impose a format on TODO.md and TASKS.md
Local Formats
For the preferred formats wehen writing local files see
- ../docs/todo-format.md
- ../docs/task-format.md
- ../docs/epic-format.md
A good SKILL.md has:
- tight description (third-person, trigger conditions explicit)
- SKILL.md as table-of-contents only
- logic in referenced files
- at least concrete test cases you can run to verify
- it fires correctly
- it does (at least some of) what it is supposed to
Or: a good skill should succinctly and precisely tell Claude how it can help.
Testing
We encourage testing by dogfooding.
In this document, from here on, we use "issues" to mean "epics, tasks, or todos"
When using this skill to propose new issues to user, or changes to issues:
- always be explicit about prposals for priority, classification, and so on
- and ask user to explictly approve them each individually
- a simple diff between 2 versions of a file, which can show changes to many issues, is not sufficient
- present each proposed issue change as a mutiple choice :
- yes
- chat
- no
- if user chooses
- yes: then write the proposed change
- chat: then chat with user about how that change could be improved, and done better next time
- no: then chat with user about why that change should be dropped, and how to avoid similar changes next time
Every issue the user does not approve should trigger a review of this skill
- debug why the proposed values were wrong
- improve the skill
