Tasks

Tasks let you capture project work, hand it to the AI agent for implementation, and track what’s done. Each task can link to a thread where the agent works and you steer the result. You can also automate tasks with one-shot or repeating schedules, a generic webhook event, or a project tag.

How tasks work

The activity bar lists two entries for the selected project: Tasks and Automations. Each opens the Tasks dock window in that view. The Tasks view lists tasks that have no trigger. The Automations view lists the tasks that do. Automation-only actions, such as Run History, live in the Automations view.

The Tasks view is a flat list, not a board. It shows only tasks that are not Done; done tasks are filtered out of the list entirely.

Indicator	Meaning
Spinner	A working task shows a spinner on its actions button.
Status chip	Once the agent sets a status, a chip shows the raw value: Plan, Build, Test, or Review.

Tasks carry a status field with six values (Ready, Plan, Build, Test, Review, Done) and a working flag. The agent tool can set any status directly.

Adding tasks

1. Click the + button in the bottom-right corner of the Tasks view.
2. Write a description of what needs to happen.
3. Click Add or press Ctrl+Enter (Cmd+Enter on Mac).

The system generates a title from your description. You can’t set the title manually when creating a task.

The dialog in the Tasks view has no trigger editor. To give a task a schedule, event, or tag trigger, create it from the Automations view instead: that dialog is titled Add Automation and opens with the Trigger editor expanded. If you collapse the trigger, the Add automation button appears.

Descriptions that work well:

• State the specific change you want, not a vague category.
• Include acceptance criteria or the expected outcome.
• Mention constraints, file paths, or relevant context.

Example:

Add user authentication with email/password login.
Validate email format, require 8+ character passwords,
show specific error messages for failures,
save session tokens securely.

Editing and deleting tasks

• Click a task to open the edit dialog.
• Change the description, tags, or automation trigger and click Save, or click Delete to remove it.
• If you save changes, Tarsk links the task to the selected thread, if any. If you save without changes, Tarsk leaves the task unchanged.

The edit dialog supports manual, scheduled, event, and Has Tag triggers. A task created on the Tasks view starts with manual-only execution; the trigger is chosen when the dialog’s trigger section is expanded.

Tags

Tasks can carry colored tags for grouping and filtering.

• The Add and edit dialogs include a tag field. Pick an existing tag. Create new tags in the Manage Tags dialog.
• The Tags menu in the Tasks view header lists every tag with a filter checkbox. Check one or more to show only tasks carrying those tags.
• Choose Edit Tags in that menu to create, rename, or delete tags. Tarsk assigns each tag’s color automatically; you cannot change it.

Task actions

Each task has a dropdown menu with contextual actions:

Start in a new workspace

Creates a new workspace, links the task to it, sets the task to Build + working, and sends the task description as the first message to the agent. The new chat appears in the side panel and opens so you can watch the run. The task’s actions button shows a spinner as the working indicator.

Run Now

Available for automated tasks: scheduled, event-triggered, and Has Tag. This launches the task immediately in a new thread using the same execution path as automation. For one-shot schedules, the schedule is cleared when it fires, including when you use Run Now.

Mark as Done

Sets the task status to Done and clears the working flag. Done tasks are filtered out of the list entirely.

These actions don’t appear for every task. Run Now shows for automations that aren’t done, including while another run is still in progress. Start in a new workspace shows when the task isn’t done and isn’t already working. Mark as Done is hidden once the task is Done, and hidden for tasks that have a trigger. Run History appears only in the Automations view.

Run History

Opens a dialog that lists the past runs of the task.

Scheduled tasks

You can schedule tasks from the Automations view or from chat. The dialog that opens there is titled Add Automation, with the Trigger editor already expanded.

Add/Edit dialog

Under Trigger, choose:

• Once — run at a specific date and time.
• Interval — run every set number of minutes.
• Hourly — run every hour at the minute you pick.
• Daily — run once a day at the time you pick.
• Weekdays — run on weekdays at the time you pick.
• Weekly — run on the day and time you pick.
• Event — run when an event with a matching event key arrives, either a built-in task event or a webhook your service sends.
• Has Tag — run when a project tag is applied to a task, then remove the tag. See Has Tag-triggered tasks.

Schedules use your browser timezone at save time. Check Paused to disable the trigger without deleting it.

Chat and agent tool

You can also schedule from chat by asking the agent to create or update a task with a specific time, for example:

• Schedule this task for tonight at 9pm
• Create a task to regenerate the changelog tomorrow at 8am

The agent converts that request into canonical schedule fields on the task.

Behavior:

• Scheduled tasks show an automation label in the Tasks view, including the next run for recurring schedules.
• The scheduler scans for due tasks periodically.
• When the scheduled time arrives, Tarsk creates a new thread and sends the task description through the normal chat execution path using the Default model alias.
• Saving a scheduled task requires a Default model alias. Set one under Settings → Default Models.
• Each scheduled fire writes a task.scheduler entry to Logs (Triggered scheduled task on success, Failed to run scheduled task on error).
• Workspace clone, branch checkout, and setup-script failures after a trigger are also written to Logs (task.execution and features.threads.threads.manager).
• One-shot schedules clear after they fire. Repeating schedules stay active and fire again on the next due time.
• Run Now bypasses pause and launches immediately. For one-shot schedules, Run Now also clears the schedule.
• lastRunStatus updates to indicate whether the launch request succeeded or failed.

Event-triggered tasks

Tasks can also run from an event. Event-triggered tasks store an eventKey, such as door.opened or deploy.finished.

Under Event, the Event type list offers two built-in keys that Tarsk fires for project tasks:

• Task Added (task.added) — a task was saved in the project.
• Task Changed (task.changed) — a saved task’s description or tags were changed.

Choose Custom event key to type any other key, such as one your own webhook sends. Both triggers receive the task as event context:

{ "task": { "id": "...", "title": "...", "status": "...", "tags": [] } }

A Task Changed event also carries the field names the change touched: { "task": { ... }, "changes": ["description"] }.

Task events fire from wherever the task was saved: the Tasks and Automations views, chat, or the agent’s tasks tool. An update that changes no stored value does not fire the event, and neither do changes Tarsk makes while running an automation (claiming the task, attaching its thread, recording the run result, or the tool’s implement action).

A Task Changed event fires only when the description or the tags changed. A status, title, schedule, or enabled edit fires no event, so updating task bookkeeping cannot re-trigger watchers.

Task events also fire for changes an automation makes. A task that reacts to task.changed and then changes tasks can therefore trigger itself again. Keep reacting automations from editing the tasks they watch, or pause them while that work is in flight.

Webhook endpoint

POST /api/projects/:projectId/events
Authorization: Bearer <project-event-token>
Content-Type: application/json

{ "eventKey": "door.opened", "payload": { "doorId": "front" } }

Behavior:

• Tarsk verifies the bearer token for the project.
• It finds tasks with triggerType = "event" and the matching eventKey.
• For each matching task, Tarsk launches a new thread and sends the task description plus the inbound event payload context. A task that is already running still launches; each run gets its own thread.
• The response includes accepted, matched, launched, and skipped counts.

For v1, any external service can call this endpoint as long as it knows the project ID, event key, and bearer token.

Testing with /send-event

From chat in a project thread, you can manually fire an event trigger:

/send-event door.opened
/send-event door.opened {"doorId":"front"}

This uses the same matching and launch path as the webhook, respects Paused tasks, and does not start an agent turn for the command itself.

Has Tag-triggered tasks

A task can also run when a tag is applied to a task in the project. Choose Has Tag under Trigger, then pick one of the project tags from the Tag list. The tag must already exist: an automation never creates one, because a trigger watching a tag nothing applies would never fire.

Behavior:

• Applying the tag starts every enabled automation watching it, each in its own thread. The run is told the tag name, the tagged task, and that the tag was removed before the run started.
• The tag is then removed from the tagged task. One application buys one run per watcher, so re-applying the tag is a second request; the dialog says so next to the selector.
• The removal is bookkeeping. It raises no Has Tag trigger and no task.changed event, so a run that edits the tagged task cannot re-arm itself that way.
• An automation whose own task was tagged does not run for itself. Automation rows are ordinary tasks, so they carry tags too.
• A paused automation never matches, so it neither runs nor consumes the tag.
• A Done task is not exempt: a watched tag applied to it fires and is consumed like any other, and the task stays Done.
• Two automations on the same tag both run for one application, and neither sees the tag afterwards.
• Deleting the watched tag keeps the trigger and clears only its tag reference, so the automation keeps showing Has Tag in the Automations view instead of quietly becoming a plain task. It runs nothing, and the trigger editor asks for a tag the next time you open it; you can still pause it or delete it.
• Run History records the trigger as Has Tag with the tag name at launch time, so a later rename or delete leaves history readable.

. ”## Working state”

When a task’s working flag is set:

• The spinner on the task’s actions button is the working indicator.
• The app polls the server every 2 seconds to pick up status changes.
• When a run finishes, the server clears that run. The working flag stays set until every in-flight run for that task has finished. The status stays where it was.
• If the linked thread gets deleted, the task automatically moves to Done next time the task list loads.

Plan status

The agent tool can set a task to Plan status. When the linked thread finishes, the server looks for a file named {task-id}-plan.md in the thread directory. If found, it replaces the task description with the plan content and deletes the file. This is a backend behavior the agent can use; the UI doesn’t have a dedicated “Plan” button.

Agent tasks tool

The AI agent manages tasks programmatically with the tasks tool. From chat, you can ask the agent to:

• Add tasks (created in Ready status; the agent must supply a title).
• List tasks to see the current board.
• Update tasks (change status, title, description, or automation trigger). Updating a description does not regenerate the title — the agent must set title explicitly to change it. Title auto-generation is UI-only.
• Delete tasks.
• Implement a task in the current conversation.
• RunNow for an automated task.
• Tag triggers: pass triggerType: "tag" with a tagName naming an existing project tag. The tool resolves the name and refuses a tag the project does not have.

The agent can set any valid status (Ready, Plan, Build, Test, Review, Done) through the tool. The UI has no Ready or Working labels: it shows a status chip for Plan through Review and a spinner for working tasks.

Skill on automated tasks

The add and update actions accept a skillRef, written as //bundled-skill-name for a bundled skill or /skill-name for a project or global skill. When an automated run launches the task, Tarsk prepends the skill invocation to the prompt it sends to the agent, unless the description already invokes that skill. The Tasks UI does not expose this field; ask the agent to attach or clear it.

Last run status

Automated tasks record:

• lastTriggeredAt — the last time automation launched the task
• lastRunStatus — one of succeeded or failed for the latest launch attempt

These fields hold summary state, so the task keeps only the latest run. For the full set of runs, open Run History from the task menu in the Automations view. The dialog lists each run with a trigger badge (Schedule, Event, Has Tag, or Manual), a timestamp, and a link to that run’s conversation. When the task has not run yet, the dialog shows “No runs yet. Runs appear here after the task is triggered by its schedule, an event, a tag, or Run Now.”

Tips

• An automation can have several runs in progress at once. Each run ties up its own thread, and the task spinner stays on until the last one finishes.
• Check the linked thread if you want to redirect the agent mid-task.
• Descriptions are the agent’s instructions. The more specific the description, the less you need to steer in the thread.
• If a task’s thread disappears, Tarsk marks it Done when the Tasks view loads. To resume the work, ask the agent to set the task to Ready and implement it in the current conversation, which links it to the current thread.
• Scheduled one-shot tasks clear after they fire. Re-schedule or switch to a repeating preset if you want them to run again.
• Paused tasks do not fire from the scheduler, webhook, /send-event, or a tag application, and a paused Has Tag automation does not consume its tag. Use Run Now to launch manually.