task

Task

Manage one outcome through the host Agent. Use the host's existing file, shell, research, and subagent capabilities; never launch nested codex exec, pi --print, a worker daemon, or an unattended supervisor.

Required Runtime Protocol

Resolve the collection root as the parent of this skill directory. Before forming, presenting, or accepting a Task Target, read <collection-root>/csl-tasks/shared/protocols/task-target-alignment.md in full and treat it as the authoritative detailed alignment contract. Read it again after resume or compaction when it is no longer present in context. If it is unavailable, stop before substantive work and report the missing runtime dependency.

This skill owns task activation, the single-outcome Target meaning, permitted lifecycle writes, and the post-alignment task workflow. The shared protocol owns all Task Target alignment semantics.

Storage and Core

• tasks/tasks.md is the newest-first index. It contains only title, current status, and a tasks/<slug>.md link.
• tasks/tasks/<slug>.md is the canonical record and is authoritative when the index disagrees.
• Use node <collection-root>/csl-tasks/shared/scripts/csl-tasks.js --workspace <workspace> ... for creation, state, parent-child, evidence, verification, completion, and index checks.
• Do not hand-edit status or index lines. After direct edits to Scope, Target, Plan, Decisions, or Block, run sync <id> and check <id>.
• Modify only the owning task and its exact index entry. Preserve unrelated task state and untouched history.

Activation and Ownership

• Create, resume, or reopen the owning record as soon as the request either asks to create, modify, move, rename, or delete any file, or establishes a concrete, non-trivial, independently acceptable outcome.
• Activate it before substantive discussion, repository exploration, research, planning, delegation, implementation, or any focused target-forming clarification performed after the outcome exists. For a requested file mutation, activation and—when the host provides one—an actually emitted task_focus(<id>) call must also precede the first requested deliverable edit. Before activation, allow only Project Core loading, the minimal index and candidate-record lookup needed to resolve ownership, and the one focused question permitted by the shared protocol when no honest Target yet exists.
• The lifecycle writes needed to create, resume, reopen, focus, sync, check, and align the owning task are the bootstrap exception to the first-edit rule; they do not authorize editing the requested deliverable.
• Start a new task for every independently acceptable user outcome.
• Reopen an existing task only when the request directly corrects, completes, or re-verifies the same outcome and leaving its Target or Result unchanged would be misleading.
• Component, file, topic, or implementation overlap alone does not establish ownership. Create a new task when ownership is ambiguous.
• Skip records only for simple factual answers and open-ended conversation that request no file mutation and establish no concrete outcome, read-only trivial deterministic operations, and routine Context or Lessons maintenance that is not itself the requested deliverable.