> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automate.it.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Worker mode (bring your own agent)

> Generate the content yourself; use Automate It as the review gate and publisher

In worker mode your agent produces the content, and Automate It provides what it can't: a human approval checkpoint and credentialed publishing to the connected platforms. Commands below use the [`ait` CLI](/guides/cli); every one maps 1:1 to an MCP tool.

## Claiming means owning

Claiming a task assigns it to you. That has three consequences worth internalizing:

* The **built-in worker never touches it** — not at claim time, and not after a rejection returns it to `todo`.
* The **dead-task sweep leaves it alone** — that sweep only recovers the built-in worker's own crashed runs. Take as long as the content needs.
* Don't abandon a claimed task: nothing times it out, so it sits in `working` until you complete it or a human deletes it.

## The loop

**If your content is already finished**, one call does everything — the task is created with content attached and lands directly in the review queue:

```sh theme={null}
ait task submit --title "Post about the v2.0 launch" --type x \
  --body "Acme v2.0 is live — new API, faster everything."
```

(One-shot submit needs the `content:write` scope in addition to `tasks:write`.)

**If you're generating as you go**, claim first, then attach and complete:

```sh theme={null}
ait task create --claim --title "Post about the v2.0 launch" --output-types x
ait task add-content <taskId> --type x --body "Acme v2.0 is live — …"
ait task complete <taskId>       # → human review queue
```

**Working a queue someone else fills** (automations, teammates, tasks assigned to you):

```sh theme={null}
ait task claim-next                   # atomically claims the oldest unassigned todo task
ait task list --mine --status todo    # tasks assigned specifically to you
```

Prefer `claim-next` over `list` + `claim`: it's one atomic step, so two agents can never grab the same task. It never hands you a task assigned to someone else.

## When a human rejects your work

The task returns to `todo` with `revisionCount` incremented — still assigned to you. Read the feedback, reclaim, and revise **in place**:

```sh theme={null}
ait task get <taskId>        # newest `comments` entry is the reviewer's note
ait task claim <taskId>      # back to "working" — complete only accepts working
ait task update-content <taskId> <contentItemId> --body "<revised copy>"
ait task complete <taskId>
```

`add-content` *appends* — using it to revise leaves the rejected draft attached alongside the fix. Use `update-content`, or `clear-content` to start a thread over. If the reviewer's note was ambiguous, answer it:

```sh theme={null}
ait task comment <taskId> --comment "Kept the link — removing it drops the CTA."
```

## Write to the workspace's standard

Skills are the workspace's reusable instructions — brand voice, formatting rules — plus bundled reference files. Nothing is injected for you in worker mode, so read them yourself before writing:

```sh theme={null}
ait skills list                      # id, name, description
ait skills get <skillId>             # full instructions + bundled file ids
ait files download-url <fileId>      # presigned URL — curl it yourself
```

Attach skills at creation (`--skills "brand voice"`, names or ids) so the content records what it was written against.

## Linking a social post to its article

A task that outputs both `rss` and a social platform can put `{articleUrl}` in the social post body — it's replaced with the article's real URL at publish time. If there's no `rss` output, the token (and the space before it) is stripped rather than leaking.

## Ground rules

* Humans approve, reject, and publish. **Never review your own output** — even if your key's role technically allows it.
* One task per distinct piece of content; don't resubmit because review is slow. Humans are slow — a few status checks an hour is plenty once a task is in `review`.
* If a task comes back `failed` or rejected twice, surface the reviewer's comment and the task id to your operator rather than retrying silently.