tasks

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

• an epic has many tasks

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