Let a task run itself when a tag or an event arrives

You file a task, apply a tag, and keep working. A minute later a new chat is reading that task and starting on it. The tag is already gone from the card.

That is a Has Tag automation. It sits next to the two triggers that wait for something to happen: a tag you apply, and an event that arrives while you work.

Two ways to arm a task

A task with a trigger is an automation. Open the Automations tab, choose Add Automation, and the trigger editor is already open. Under Trigger you get the schedule choices, then Event and Has Tag at the end of the list:

• Event runs the task when an event with a matching key arrives.
• Has Tag runs the task when a chosen project tag is applied to a task, then removes the tag.

The list row tells you what the automation waits for. A tag trigger reads Has Tag: needs-review. An event trigger reads Event: task.added. A paused row starts with Paused ·.

A tag that asks for work

Most tags describe a task. A watched tag asks for work.

Apply needs-review to a task, and every enabled automation watching that tag starts, each in its own thread. Tarsk hands each run the tag name, the tagged task, and a line saying the tag was removed before the run began. The agent reads the task next, so without that line it would find the tag missing and stop to ask.

The trigger fires when you apply the tag. A tag that already sits on a task does nothing on its own. Re-saving a task with the same tags does nothing. Removing a tag does nothing. One application buys one run per watcher, so applying the tag a second time is a second request.

The tag comes off

Tarsk removes the tag before the run gets a workspace. The delete is also the claim on the application: a second watcher finds nothing left to remove and starts nothing, so two automations on one tag never race for the same tag.

The removal is bookkeeping. It raises no tag trigger and no task change, so a run that edits the tagged task cannot re-arm itself that way.

An automation does not fire for itself. Automation rows are ordinary tasks, so they carry tags like any other, and tagging one of them starts nothing.

A paused automation does not match, so it neither runs nor takes the tag. A Done task is not exempt: a watched tag on it fires and is consumed, and the task stays Done.

A failed launch still leaves the tag gone, and the run is recorded as failed. One application buys one run either way, so a lingering tag cannot re-arm a trigger.

If you delete the watched tag, the trigger stays and loses only its tag. The row still says Has Tag, nothing runs, and the editor asks for a tag the next time you open it. You can still pause or delete the automation.

Events Tarsk fires for you

Two event keys are built in. Under Event type you can pick Task Added or Task Changed, or choose Custom event key and type your own.

• Task Added fires when a task is saved in the project, from the Tasks view, the Automations view, chat, or a request from the agent.
• Task Changed fires when a saved task’s description or tags change.

Both hand the run the task as context:

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

Task Changed adds the field names the change touched: { "task": { ... }, "changes": ["description"] }. That list is a real before-and-after comparison of stored values, not the fields that came in the request. A save that changes nothing fires nothing.

Status, title, schedule and enabled edits stay quiet. Tarsk’s own bookkeeping does too: claiming a task for a run, attaching its thread, recording the result, and starting a task from the agent.

Reactions can chain. An automation that watches task.changed and then edits tasks will fire again on its own edits. Keep a reacting automation from touching the tasks it watches, or pause it while that work runs.

Events from outside

A custom key takes whatever your own systems send. Post to the project’s event address with the project’s event token and a body of { "eventKey": "door.opened", "payload": { "doorId": "front" } }. Tarsk reports how many automations matched, launched, and were skipped.

You can try a key without leaving the chat:

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

That path matches and launches the same way the webhook does, respects a paused automation, and starts no agent turn for the command itself.

Run now, and what a run leaves behind

Run Now starts an automation immediately, even while it is paused. For a one-shot schedule it also clears the schedule.

Every run opens a conversation. Run History on the Automations tab lists those conversations newest first, each with a trigger badge and a time. The badge reads Has Tag with the tag name as it was at launch, so renaming or deleting the tag later leaves the history readable. Click a row to reopen that run and read what the agent did.

The task records whether the launch succeeded. A tag that is already gone, or an event that matched nothing, leaves no run to show.

Limits

• A tag trigger watches one tag. Two automations on the same tag both run for one application.
• A custom event key allows letters, numbers, dots, colons, underscores and hyphens, up to 100 characters.
• An automation never creates a tag. The Tag list offers tags the project already has.
• A task that is already running still launches when its trigger fires again. Each run gets its own thread.

Try it

1. Add the tag needs-review to a task, so the project has it.
2. Open the Automations tab and choose Add Automation.
3. Give it a description such as “Review the tagged task and post a summary as a comment”, then pick Has Tag and needs-review.
4. Save, then apply needs-review to any other task.
5. Watch the tag disappear and a new conversation appear in Run History.

For an event, make a second automation with Task Added and a description like “Read the new task and add the labels it needs”. Every task you save after that starts a run.

Keep three things in mind:

• A watched tag is a one-shot request. Applying it again asks again.
• Tarsk fires Task Added and Task Changed itself, and a custom key brings events from your own services.
• Every run leaves a conversation you can reopen from Run History.