--- name: task description: Create, resume, update, cancel, verify, and complete a canonical workspace task for one outcome. Use before every user-requested file creation, modification, move, rename, or deletion, even when trivial, and for any concrete non-trivial outcome. Activate and align its Task Target before substantive work. Skip only no-file simple factual answers and open-ended conversation without a concrete outcome. --- # 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 `/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/.md` link. - `tasks/tasks/.md` is the canonical record and is authoritative when the index disagrees. - Use `node /csl-tasks/shared/scripts/csl-tasks.js --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 ` and `check `. - Modify only the owning task and its exact index entry. Preserve unrelated task state and untouched history. ## Task Artifacts Persist a workspace-local task artifact only when the user requests a durable file or the task needs durable evidence that does not have a more authoritative project location. Use `tasks/artifacts///` with the owning canonical task ID and create only the category that is needed: - `discussions`: user-visible discussion or synthesis; never private reasoning, role exchanges, or hidden state. - `specs`: RFCs, PRDs, ADRs, designs, and separately requested implementation or migration plans. - `reports`: research, analysis, review, and audit reports. - `evidence`: logs, screenshots, benchmarks, and other raw verification material that cannot be represented safely by a concise observation or external link. The category describes the artifact's stable purpose, not its lifecycle state. Draft, accepted, completed, or superseded status never moves the file. Keep source code, configuration, and long-lived authoritative project documentation at their normal project paths. Link an artifact from its task record with `../artifacts///`; do not duplicate its body in the record. Never persist secrets, private data, or unnecessary full logs. ## 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()` 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 in the main session. - A delegated child must use the existing owning task named by the main session's current delegation packet. It must not create another task, present a user-facing checkpoint, or invent broader ownership; missing or out-of-Plan delegation returns to the main session under the shared protocol. - 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. - When the user explicitly asks to execute an implementation-ready plan, resume that plan's exact record; the `task-plan` to `task` phase transition alone does not create new ownership. - 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. ## Start or Resume 1. Load Project Core, then read only the newest index entries and plausible candidate owning records needed to resolve ownership. Do not query task-relevant Context Packs, inspect task-direct sources, or begin substantive discussion yet. 2. For a new task, choose a lowercase kebab-case ID and run: `create --title --kind task --target "T1: <observable condition>"`. Repeat `--target` for additional conditions. If the request cannot support any honest observable Target, ask one focused question; create the record as soon as the answer establishes the outcome. 3. Run `resume <id>` for new, Pending, Blocked, or Cancelled work. Use `reopen <id>` only for the same completed outcome; add the next Target ID before continuing. 4. Immediately after creation, resume, or reopen succeeds, emit the real host tool call itself—for example, `task_focus(<id>)`—in the same reply as the lifecycle command; treat both calls as one atomic batch. Planning or listing `task_focus` without emitting it does not satisfy this step. If binding fails (for example, the record lives outside the session workspace), disclose that failure explicitly instead of silently skipping. 5. Apply the shared Task Target Alignment Protocol to the active record. For this workflow, the conversational Target means the intended outcome and observable completion condition; before alignment, the permitted lifecycle writes are create, resume, reopen, focus, sync, and check. The gate follows activation and precedes task-direct source inspection or substantive preparation; only the protocol's focused target-forming clarification may occur within it. A main session runs the user-facing gate; a delegated child validates the main session's packet and either continues the named task or returns to the main session without prompting the user. When resuming the same implementation-ready plan record, an explicit request to execute is execution authorization, not a new Target by itself; inherit a recoverable, materially equivalent accepted Target without another checkpoint. 6. After the protocol aligns the current Target, query task-relevant Context Packs, read relevant lessons, and inspect task-direct sources. 7. Add or refine only the substantive Scope, Target, and Plan content now supported, then `sync` and `check` before execution continues. ## Record Contract Keep `# Title`, the core-owned `Status:` line, and `Kind:`. New records use these sections as needed: ### Scope Add only when an adjacent boundary is easy to include accidentally, the user excludes work, or expansion materially changes cost or risk. Record included and excluded outcomes without prescribing implementation. ### Target - This is the only checkbox list. Use unique stable IDs (`T1`, `T2`, ...). - Each item is one observable pass-or-fail result, preserved behavior, compatibility boundary, or side-effect boundary. - Do not put implementation steps, commands, workflow gates, or review state here. - Never check a Target manually. Record evidence with `result <id> <Tn> --evidence <one-line evidence>`; the core checks the matching item. ### Plan Use an ordered list without checkboxes. Keep only current result nodes, dependencies, and next actions. Do not prescribe algorithms, files, functions, types, or call paths unless the user requires them. ### Result The core records one evidence line per Target. Evidence must name what was checked, how, and the observed result. Update evidence when it becomes stale; changing a Target or relevant deliverable invalidates verification. Record the review gate through `review <id> ... --evidence ...`: - `skipped` unless the user explicitly asks for adversarial review, a two-Agent Reviewer-Editor loop, or independent Reviewer approval; - `required` when explicitly requested; then move to In Review before invoking that workflow; - `approved` only after that review approves, with its report link or decision evidence. If review changes the deliverable, return to In Progress and replace stale Result and verification evidence before reviewing again. Do not infer review from risk, complexity, verification gaps, another rule, or Agent judgment. Ordinary review, testing, proofreading, and self-review do not request the independent review workflow. ### Verification Run proportionate host-native checks yourself; the core never executes arbitrary commands. Record the current outcome with `verify <id> passed|failed --evidence <one-line observation>`. A failed check blocks completion. Re-run and replace verification after relevant changes. ### Block Add only while Blocked, with `Reason` and observable `Unblock when`. Add the section before `status <id> blocked`. Resuming removes it. Use `cancel <id>` for a reversible soft stop; cancelled work is not completed and can resume. ## Completion 1. Confirm every current Target has Result evidence. 2. Run proportionate verification and record it as passed. 3. Record `skipped` or an actual `approved` review gate. 4. Confirm this session actually bound to the owning record through the host focus mechanism when it provides one; if binding failed or was unavailable, disclose that before completing. 5. Run `complete <id>`. This is the only route to Completed and fails closed on missing Targets, Results, review, verification, Block, or unfinished Queue children. 6. Run `check <id>` and `validate` before delivery. Do not retrofit untouched historical record bodies. All records share the new paths, while the stricter `Kind:` contract applies to new or reopened work. ## Maintainer Validation Keep the routing fixtures in `evals/` aligned, run authorized focused core/task tests, then run the built-in `$skill-quality` gate against this package. Quality failures block completion. Review warnings, but never delete or distort required workflow guidance merely to satisfy the initial-load budget.