workctllisted

# Workctl Use `workctl` as the task-level control plane when a conversation may move between coding CLIs. Repository phase artifacts remain canonical for specification and gates; `.workctl/tasks/<task-id>/` is canonical for task identity, current execution state, and runtime provenance. A reusable model session is an optional cache resource, never the source of truth. ## Session entry A fresh CLI/chat session does not automatically load any workctl task. Inside an existing agent session, the user should name the task explicitly: `Continue workctl task <task-id>`. Read that task's durable state and report Done/Now/Next before acting. From a normal terminal, use `workctl continue <task-id> --runtime <runtime>`. Calling workctl without an ID is safe only when `WORKCTL_TASK` is set, exactly one task is bound to the current Git branch, or the repository contains exactly one task. Otherwise stop and require the task ID; never infer it from recency or chat history. ## Conversational contract Do not make the human operate workctl for normal project orientation. If they ask where the project is or what comes next, use `pipeline-status`. Use workctl only when one concrete task must survive a CLI/session/provider switch, when several tasks coexist, or when the user names a task to resume. ### Choosing workctl versus planning-with-files These tools intentionally overlap on durable context, but they operate at different levels: | Situation | Use | Why | |---|---|---| | One agent