Asana

This skill provides a dependency-free Node.js CLI that calls the Asana REST API (v1) using a Personal Access Token (PAT).

Script: {baseDir}/scripts/asana.mjs
Auth: ASANA_PAT (preferred) or ASANA_TOKEN
Output: JSON only (stdout), suitable for agents and automation

Setup

Create an Asana PAT in your Asana account (Developer Console is not required for PAT usage).
Provide the token to OpenClaw/Clawdbot as ASANA_PAT.

Common injection patterns

Shell env (local testing):

export ASANA_PAT="..."

OpenClaw config (recommended): set skills.entries.asana.apiKey (or env.ASANA_PAT) so the secret is injected only for the agent run.

Configure via OpenClaw CLI (recommended)

This is the safest way to set the PAT because it keeps secrets out of prompts and ad-hoc shell history.

Recommended (apiKey → ASANA_PAT):

openclaw config set skills.entries.asana.enabled true
openclaw config set skills.entries.asana.apiKey "ASANA_PAT_HERE"

skills.entries.asana.apiKey is a convenience field: for skills that declare metadata.openclaw.primaryEnv, OpenClaw injects apiKey into that env var for the agent run (this skill’s primary env is ASANA_PAT).

Alternative (explicit env):

openclaw config set skills.entries.asana.enabled true
openclaw config set skills.entries.asana.env.ASANA_PAT "ASANA_PAT_HERE"

Verify what is stored:

openclaw config get skills.entries.asana
openclaw config get skills.entries.asana.enabled
openclaw config get skills.entries.asana.apiKey

Remove a stored token:

openclaw config unset skills.entries.asana.apiKey
# or
openclaw config unset skills.entries.asana.env.ASANA_PAT

Important: sandboxed runs

When a session is sandboxed, skill processes run inside Docker and do not inherit the host environment. In that case, skills.entries.*.env/apiKey applies to host runs only.

Set Docker env via:

agents.defaults.sandbox.docker.env (or per-agent agents.list[].sandbox.docker.env)
or bake the env into your sandbox image

First calls (sanity + discovery)

Who am I:

node {baseDir}/scripts/asana.mjs me

List workspaces:

node {baseDir}/scripts/asana.mjs workspaces

(Recommended) Set a default workspace once:

node {baseDir}/scripts/asana.mjs set-default-workspace --workspace

ID resolution

When the user provides names (project/task/user), resolve to GIDs using one of:

typeahead --workspace --resource_type project|task|user --query "..." (fast, best default)
projects --workspace --all (enumerate)
users --workspace --all (enumerate)

Avoid guessing a GID when multiple matches exist.

Core: tasks

List tasks assigned to a user (personal productivity)

node {baseDir}/scripts/asana.mjs tasks-assigned --assignee me --workspace --all

List tasks in a project

node {baseDir}/scripts/asana.mjs tasks-in-project --project --all

Search tasks (Advanced Search API)

Canonical primitive: search-tasks (supports many filters; preferred over adding narrow “search helper” commands).

One-liner example (search within a project):

node {baseDir}/scripts/asana.mjs search-tasks --workspace --project --text "..." --all

Useful filters:

--assignee me| (maps to assignee.any)
--completed true|false
--created_at.after / --modified_at.after
--due_on.before YYYY-MM-DD / --due_at.before
--is_blocked true|false / --is_blocking true|false

Create / update / complete

Create:

node {baseDir}/scripts/asana.mjs create-task --workspace --name "..." --projects --assignee me

Update:

node {baseDir}/scripts/asana.mjs update-task --name "..." --due_on 2026-02-01

Complete:

node {baseDir}/scripts/asana.mjs complete-task

Project manager workflows

This skill supports the workflows commonly expected from a PM in Asana:

Keep a project brief up to date (upsert-project-brief)
Write status updates (create-status-update)
Work with timelines (start/due dates) and shift schedules safely
Use custom fields as first-class metadata
Interpret blockers and dependency graphs (project-blockers, dependencies, dependents)

Project brief

Read:

node {baseDir}/scripts/asana.mjs project-brief

Upsert (create or update):

node {baseDir}/scripts/asana.mjs upsert-project-brief --title "Project brief" --html_text "..."

Status updates

Create:

node {baseDir}/scripts/asana.mjs create-status-update --parent --status_type on_track --text "Weekly update..."

List:

node {baseDir}/scripts/asana.mjs status-updates --parent --all

Sections and moving tasks

List sections:

node {baseDir}/scripts/asana.mjs sections --project --all

Create section:

node {baseDir}/scripts/asana.mjs create-section --project --name "Blocked"

Add a task to a project

Command: add-task-to-project

Calls POST /tasks/{task_gid}/addProject and supports optional section placement and ordering.

Examples:

node {baseDir}/scripts/asana.mjs add-task-to-project --project

With section + ordering:

node {baseDir}/scripts/asana.mjs add-task-to-project --project --section --insert_before null --insert_after null

(--section, --insert_before, and --insert_after are optional; when provided they are passed through in the request body.)

Remove a task from a project

Command: remove-task-from-project

Calls POST /tasks/{task_gid}/removeProject.

Example:

node {baseDir}/scripts/asana.mjs remove-task-from-project --project

Custom fields

Custom fields are critical for reliable PM automation.

List a project’s custom fields:

node {baseDir}/scripts/asana.mjs project-custom-fields --all

Read a custom field definition:

node {baseDir}/scripts/asana.mjs custom-field

Set task custom fields on create/update:

node {baseDir}/scripts/asana.mjs update-task --custom_fields '{"":""}'

Notes:

For enums, the value is typically the enum option GID.
For numbers, send a JSON number.

Rich text, mentions, and reliability

Asana rich text fields are XML-valid HTML fragments wrapped in a root element. The API rejects invalid XML or unsupported tags.

Key points:

Use html_notes for task descriptions.
Use html_text for comments/stories and status updates.
Avoid unsupported tags like
and ; prefer literal newlines (\n) and
separators.
For mentions/links, use (or a self-closing ).