task

task

<task_skill>

<when_to_activate> Activate this skill when the user:

• Asks to create, write, capture, file, or add a task / todo / backlog item.
• Asks to list, show, find, or query existing tasks.
• Asks to update, edit, refine, or expand a task.
• Says a task is done, finished, implemented, shipped, or completed: move it to archive with status finished.
• Says a task should be dropped, parked, deferred, or shelved: move it to archive with status deferred.
• Asks to lint, audit, or health-check the tasks directory.
• Mentions the project's tasks, todos, or backlog in any way that implies persisting upcoming work as files rather than chat state. </when_to_activate>

<not_in_scope> The wiki skill captures durable knowledge (concepts, procedures, references). The task skill captures upcoming work on this project. When a user message is about recording what they learned or how something works, route to wiki instead. When they want to track what still needs doing, this skill is right.

A focused sibling serves some of that backlog work better than the hub does. When a request names one task and one lifecycle step (check this task, implement it, audit it, close it out), hand it to the sibling that owns that step, which <family> names alongside every other sibling's role. Broad and multi-task backlog work stays with the hub: listing and querying the tree, triaging or updating several tasks in one round, and mining one source into a set of tasks, except where <family> names a sibling that owns that whole-tree job. The preference routes a request to the narrower surface rather than withholding it, since the hub keeps every capability <family> opens by stating. </not_in_scope>

The filing convention has one canonical split: material directly about the task system lives under tasks/, and project-wide standing material lives at the repo root as optional UPPERCASE.md docs. Two root-doc roles exist there: harness-loaded rule files (CLAUDE.md / AGENTS.md / GEMINI.md and equivalents) provide the project's standing-instruction baseline, while family-consulted guardrail docs (CHARTER.md / ARCHITECTURE.md / FEATURES.md / TESTING.md) add task-family-specific constraints and context. The task tree stays intentionally two layers: tasks/ for live work and tasks/archive/ for closed work. No further task nesting. Scope sits in the filename, not in a folder. A bare project with only tasks/ remains complete.

<standing_doc_consumption> Resolve the project root from the base <discover> step. The project's standing instructions start with the harness-loaded root rule files: CLAUDE.md / AGENTS.md / GEMINI.md and equivalents. When present, the harness loads those files before the skill runs, and the task family follows that baseline at every touchpoint independent of whether any family guardrail doc exists. The task family adds no separate presence-gated read for those harness files because the harness already supplies them.