back
loading skill details...
Create content tasks and automations in Automate It, do the content work yourself or leave it to the built-in worker, poll task status through the human revi...
---
name: automate-it
version: 0.1.1
description: Create content tasks and automations in Automate It, do the content work yourself or leave it to the built-in worker, poll task status through the human review gate, and fetch links to published posts. Use when asked to draft, schedule, or publish social content via Automate It, or to check the status or published results of a submitted task.
homepage: https://automate.it.com/agents
metadata:
openclaw:
emoji: "⚡️"
homepage: https://automate.it.com/agents
primaryEnv: AUTOMATE_IT_API_KEY
requires:
env:
- AUTOMATE_IT_API_KEY
bins:
- node
envVars:
- name: AUTOMATE_IT_API_KEY
required: true
description: Automate It API key (starts with ak_).
- name: AUTOMATE_IT_WORKSPACE
required: false
description: Default workspace id; auto-resolved when the key sees exactly one workspace.
- name: AUTOMATE_IT_API_URL
required: false
description: API base URL; defaults to https://api.automate.it.com.
---
# Automate It
Automate It is a content platform with a human review gate: tasks describe content to create, a worker generates the content, a human reviews and approves it, and it publishes to the connected platforms (X, LinkedIn, Instagram, Threads, Facebook, Discord, Bluesky, articles, and more).
You can participate two ways:
- **Delegate mode** — you submit a task describing the content; Automate It's built-in worker generates it. You poll for the outcome.
- **Worker mode (bring your own agent)** — you generate the content yourself: create the task with `--claim`, attach your content, complete it into the human review queue. Automate It provides the review checkpoint and the credentialed publishing; you provide the brains.
All commands use the bundled CLI: `./ait.mjs` (Node 18+ or Bun; also runs as `node ait.mjs …`). It speaks the same MCP server that human-driven clients (Claude Code, etc.) use, so anything the platform exposes as a tool is available — `./ait.mjs tools` lists everything, and `./ait.mjs call <tool> --args '<json>'` calls any tool the named commands don't wrap. Errors print `{"error": "..."}` to stderr and exit 1.
## Setup
Required environment:
- `AUTOMATE_IT_API_KEY` — an Automate It API key (starts with `ak_`). The human operator creates this in Automate It under **Profile → API keys**.
- `AUTOMATE_IT_WORKSPACE` (optional) — default workspace id. If unset and the key has exactly one workspace, it is auto-resolved. Every command also accepts `--workspace <id>`.
- `AUTOMATE_IT_API_URL` (optional) — defaults to `https://api.automate.it.com`.
Verify access before doing real work:
```sh
./ait.mjs workspaces # workspaces the key can reach
./ait.mjs whoami # the user you act as
```
If a command fails with `MCP HTTP 401`, the key is missing, mistyped, or revoked — stop and tell the operator. If it fails with `missing required scope`, the key lacks a scope (see Permissions) — report which one is missing rather than retrying.
## Worker mode: do the work yourself, use the review gate
Use this when you (or your runtime) already produce the content and Automate It's job is human approval + publishing.
1. **Create the task already claimed.** `--claim` creates it in `working` status, so the built-in worker never touches it — there is no race to lose.
```sh
./ait.mjs task create --claim \
--title "Post about the v2.0 launch" \
--instructions "Context for reviewers: announcing Acme v2.0" \
--output-types x
```
The response includes the task JSON — save the `id`.
Claiming assigns the task to you: the built-in worker never touches it, the platform's dead-task recovery leaves it alone (that sweep is for the built-in worker's own crashed runs), and a later rejection routes back to you. Take as long as the content needs — but don't abandon a claimed task: nothing times it out, so it sits in `working` until you complete it or a human deletes it.
2. **Attach your content.** One call per content item; use `sortOrder` for threads (0 = first post).
```sh
./ait.mjs task add-content <taskId> --type x \
--body "Acme v2.0 is live — new API, faster everything. https://acme.dev/blog/v2"
```
For images/video: get a presigned URL, PUT the file, then reference it:
```sh
./ait.mjs upload-url --filename hero.png --mime-type image/png
# PUT your file to the returned uploadUrl, then:
./ait.mjs task add-content <taskId> --type x --body "..." \
--media '[{"type":"image","url":"<permanentUrl>"}]'
```
3. **Complete it into review.**
```sh
./ait.mjs task complete <taskId>
```
The task lands in the human review queue (`review` status). From here it's the same as delegate mode: poll, and fetch links after publish.
If your content is already finished, skip the three-step loop entirely with the one-shot submit — it creates the task with the content attached and lands it directly in the review queue:
```sh
./ait.mjs task submit --title "Post about the v2.0 launch" --type x \
--body "Acme v2.0 is live — new API, faster everything. https://acme.dev/blog/v2"
```
If a human rejects your content, the task drops back to `todo` and `revisionCount` goes up. It is still assigned to you (claiming assigned it), so the built-in worker can't touch it. **Reclaim it** — `task complete` only accepts a task in `working` — then revise.
Revise in place. `task add-content` *appends* another post — use it again and the task carries both the rejected draft and the fix.
```sh
./ait.mjs task claim <taskId> # back to "working", yours again
./ait.mjs task get <taskId> # newest `comments` entry says why it was rejected
# each contentItems[] entry has the id you need
./ait.mjs task update-content <taskId> <contentItemId> --body "<revised copy>"
./ait.mjs task complete <taskId>
```
To rewrite a multi-post thread from scratch, `./ait.mjs task clear-content <taskId>` first, then add each post again. `task delete-content <taskId> <contentItemId>` drops a single one.
Explain yourself if the reviewer's note was ambiguous, or if you deliberately didn't follow it:
```sh
./ait.mjs task comment <taskId> --comment "Kept the link — removing it drops the CTA."
```
## Delegate mode: let the built-in worker create the content
1. **Create the task without `--claim`.** Describe the content in `--instructions` the way you would brief a copywriter: topic, angle, tone, audience, links to include.
```sh
./ait.mjs task create \
--title "Post about the v2.0 launch" \
--instructions "Write an upbeat announcement of Acme v2.0 for developers. Mention the new API and link to https://acme.dev/blog/v2." \
--output-types x,linkedin
```
2. **Poll until it resolves.** Poll every 60 seconds or so while generating; once it reaches `review`, a few checks an hour is plenty — humans are slow.
```sh
./ait.mjs task get <taskId>
```
| status | meaning | what you do |
|---|---|---|
| `todo` | queued, not started | wait |
| `working` | content is being generated | wait (in worker mode this means *you* owe content) |
| `review` | waiting on a human reviewer | wait (slow — human in the loop) |
| `approved` | human approved, not yet published | wait (or report approval) |
| `published` | live on the destination platforms | fetch links, report success |
| `failed` | generation or publish failed | report failure to the operator |
| `deleted` | task was deleted by a human | stop tracking it, report |
3. **Fetch the published links** once status is `published`:
```sh
./ait.mjs task links <taskId>
```
Returns `{"taskId": "…", "status": "published", "links": [{"platform": "x", "postUrl": "https://…", "postId": "…"}]}` — report the `postUrl` values back to whoever asked.
### Publish modes
- Default (`--publish-mode manual`): after approval, a human also clicks publish. Safest; use unless told otherwise.
- `--publish-mode immediate`: publishes automatically the moment a reviewer approves.
- `--publish-mode scheduled --publish-at 2026-07-10T15:00:00Z`: publishes at the given time after approval.
- `--no-review` skips the human review gate entirely (auto-publish on completion). **Never use this unless the operator has explicitly told you to.**
### Output types
Valid `--output-types` / `--type` values: `x`, `linkedin`, `instagram`, `facebook`, `threads`, `discord`, `bluesky`, `article`, `email`, `carousel`, `podcast`, `rss`, `spreadsheet`, `document`.
Only platforms the workspace has actually connected will publish. Don't guess and don't ask — check:
```sh
./ait.mjs call list_integrations # which platforms are connected
./ait.mjs call get_x_character_limit # 280 or 25000, depending on the plan
```
### Linking a social post to the article it announces
When a task publishes to `rss` **and** to social platforms, put the token `{articleUrl}` in the social post body. At publish time it's replaced with the article's real URL — which doesn't exist until the feed item is created, so you can't write it yourself.
```sh
./ait.mjs task add-content <taskId> --type article --title "Acme v2.0" --body "<the article>"
./ait.mjs task add-content <taskId> --type x --body "Acme v2.0 is live. Read more: {articleUrl}"
```
If the task has no `rss` output (or the feed publish fails), the token and the space before it are stripped, so the post still reads correctly. The token only resolves for `rss` — a `podcast` output does not populate it.
## Skills: how this workspace wants its content written
A skill is reusable instruction — brand voice, formatting rules, house style — plus any reference files bundled with it. Check for skills before you write anything.
```sh
./ait.mjs skills list # id, name, description
./ait.mjs skills get <skillId> # full instructions + bundled file ids
```
Attach them by name (or id) when creating a task:
```sh
./ait.mjs task create --title "Launch post" --skills "brand voice,changelog style" --claim
```
**This is the part agents get wrong.** Attaching a skill only does something when the *built-in worker* runs the task — it injects the instructions and files for you. In worker mode (`--claim`) the worker never runs, so **nothing is injected**. Read the instructions yourself with `skills get` and apply them. Attaching is still worth doing: it records which skills the content was written against.
Bundled files are workspace files. Fetch one by getting a URL and downloading it yourself:
```sh
./ait.mjs files download-url <fileId> # returns a time-limited downloadUrl
curl -o brand.pdf "<downloadUrl>"
```
## Checking on existing work
```sh
./ait.mjs task list --status review # everything waiting on a human
./ait.mjs task list --limit 10 # recent tasks
./ait.mjs task get <taskId> # full detail for one task
./ait.mjs files list --search brand # workspace file browser
```
## Working a queue someone else fills
If tasks arrive from automations or teammates and you're the worker, take them one at a time:
```sh
./ait.mjs task claim-next # atomically claims the oldest todo task
```
Use this rather than `task list --status todo` followed by `task claim <id>`: those are two calls, and another worker can take the task in between. `claim-next` returns nothing when the queue is empty. It never hands you a task assigned to someone else.
### Working tasks assigned to you
Humans (or other agents) can assign tasks to your user instead of the built-in worker. Assigned tasks are invisible to the built-in worker — they wait for you. Check for them periodically, then run the normal work loop:
```sh
./ait.mjs task list --mine --status todo # work waiting on you
./ait.mjs task claim <taskId> # only the assignee can claim an assigned task
# … generate content …
./ait.mjs task add-content <taskId> --type x --body "..."
./ait.mjs task complete <taskId>
```
If a task you worked comes back with a higher `revisionCount` (a reviewer rejected it), you'll find it in `task list --mine --status todo` again — read the rejection comment via `task get`, revise in place with `task update-content`, and `task complete` again. Because it stays assigned to you, the built-in worker can't claim it out from under you while you revise.
You can also assign at creation: `task create --assign <userId|me>`, or `task submit --assign me`.
## Reviewing (only when the operator's key allows it)
If your key belongs to a reviewer/admin and the operator has asked you to help triage, these exist: `task next-review`, `task approve <id>`, `task reject <id> --comment "..."`, `task publish <id>`. **Do not approve or publish content you produced yourself** — the whole point of the review gate is that a different human (or their delegate) signs off.
## Automations (recurring content)
A task is one-off; an automation is a standing brief that spawns tasks on a schedule. Use automations only when asked for recurring content.
```sh
./ait.mjs automation create --name "Weekly changelog roundup" \
--instructions "Summarize this week's merged changes as a friendly post." \
--output-types x --schedule '{"type":"cron","value":"0 9 * * 1"}'
./ait.mjs automation list
./ait.mjs automation get <automationId>
./ait.mjs automation update <automationId> --name "Renamed"
./ait.mjs automation run <automationId> # trigger now; returns the spawned task to poll
```
`automation run` returns a task — poll it with `task get`. If the response includes `"alreadyRunning": true`, an earlier run is still in flight; poll that task instead of triggering again.
## Everything else
`./ait.mjs tools` lists every tool the platform exposes (files, folders, integrations, URL shortening, …); call any of them with `./ait.mjs call <tool> --args '<json>'`. `workspaceId` is injected automatically when omitted.
## Permissions
The API key's scopes bound what you can do (enforced server-side):
- `tasks:read` — `task list / get / links / next-review`
- `tasks:write` — `task create / claim / claim-next / complete / comment / approve / reject / publish / delete`
- `content:write` — `task add-content / update-content / delete-content / clear-content`, and `task submit` (which attaches content, so it needs `tasks:write` **and** `content:write`)
- `files:read` — `files list / download-url`, folder listing
- `files:write` — `upload-url`, folder mutations
- `skills:read` — `skills list / get`
- `automations:read` / `automations:write` — automation commands, including `automation run`
Workspace roles apply on top. Any member — including a viewer — can create and work tasks, but a viewer's tasks always require review (`--no-review` is ignored for them). Creating automations requires an admin; approving and publishing require a reviewer or admin. A `403`/`missing required scope` error names what's missing — report it to the operator; do not retry.
## Ground rules
- In worker mode you create, work, and complete; **humans approve, reject, and publish**. Never review your own output.
- One task per distinct piece of content. Do not resubmit a task because review is slow.
- If a task comes back `failed` or rejected, surface the reviewer's comment and the task id to the operator — do not silently retry more than once.
don't have the plugin yet? install it then click "run inline in claude" again.