ClawHub

Openclaw Quire Skill

Security

Read and modify Quire tasks, projects, comments, statuses, and tags via the quire CLI — list, search, get, create, update, complete/uncomplete, set dates, comment.

Install

openclaw skills install quire

Quire

Access to a user's Quire workspace via the quire CLI. Reads cover tasks (list, get, search, subtasks, tree), task comments, projects, project statuses and tags, and URL resolution. Writes cover creating tasks, updating task fields, setting/clearing task dates, marking complete/uncomplete, and posting comments. Use this skill when the user asks about their Quire tasks, projects, or comments, wants to act on a Quire URL they've pasted, or wants to mutate a task or post a comment.

Authentication is handled by the CLI's own token store (quire login runs an OAuth loopback flow once per machine). No environment variables or API keys are needed from the user.

All commands emit raw API JSON when invoked with --json. Shape is stable across CLI versions — safe to depend on.

When to use this skill

Invoke when the user asks anything along the lines of:

  • "What's on my plate today?" / "What am I assigned to?"
  • "What tasks are open in project X?"
  • "Find tasks tagged Y in org Z that are blocked."
  • "Show me the subtree of task #408."
  • "Summarize this Quire URL: …"
  • "Who's on the Marketing project?"

When NOT to use this skill

  • Questions about Notion, Asana, Linear, Jira, Todoist, or any tracker other than Quire — even if the phrasing is similar. Pick the skill that matches the user's tool, not this one.
  • Writes outside the supported set. Supported writes: create_task, update_task, set_task_dates, complete_task, uncomplete_task, add_comment. Everything else is deferred — including deleting tasks or comments, attaching files, moving or transferring tasks across projects, editing comments, managing tags/statuses/sublists, and approval workflows. If asked for an unsupported write, decline politely and tell the user it isn't in this skill's surface yet.
  • General productivity advice, planning, or coaching with no concrete need to read live Quire data.

Tool: whoami

Use for: identity grounding — who am I logged in as, and which orgs do I belong to? Cheap to call; useful at the start of a session to know which org's projects are reachable.

Command:

quire whoami --json

Output: a single user object plus an organizations array.

{
  "oid": "0e…",
  "id": 12345,
  "name": "Jane Doe",
  "nameText": "Jane Doe",
  "email": "jane@example.com",
  "organizations": [
    { "oid": "0e…", "id": "acme", "name": "Acme Inc.", "nameText": "Acme Inc." }
  ]
}

Tool: list_my_tasks

Use for: "what's on my plate" — tasks assigned to the signed-in user. Exactly one scope flag is required.

Command:

quire mine [--project <id> | --inbox | --org <id> | --all-orgs] [--skip-inbox] [--limit <n>] --json

Scope flags (pick one):

  • --project <id> — one project (slug or OID).
  • --inbox — the user's private Inbox.
  • --org <id> — one organization.
  • --all-orgs — every org the user belongs to. Includes Inbox by default; add --skip-inbox to exclude it.

Other flags:

  • --limit <n> — positive integer or no for unlimited. Default is paged.

Output: array of task objects (oid, id, name, status, priority, due, assignees, tags, project, …).

Examples:

quire mine --all-orgs --json                       # Everything assigned to me
quire mine --project marketing-launch --json       # Just my tasks in one project
quire mine --org acme --limit 50 --json            # First 50 in Acme org

Tool: list_project_tasks

Use for: all tasks in a specific project (regardless of assignee). Use this when the user names a project; use list_my_tasks --project when they want only their own tasks in that project.

Command:

quire task list <project-id> [--limit <n>] [--cursor <token>] --json

Args:

  • <project-id> — project slug, numeric ID, or OID.

Flags:

  • --limit <n> — positive integer or no for unlimited.
  • --cursor <token> — pass the cursor from a previous page to continue.

Output: array of task objects.

Example:

quire task list marketing-launch --json

Tool: get_task

Use for: full detail on one task — description, custom fields, recurrence, dates, assignees. Always use this before suggesting a write that the user has to confirm (e.g. "should I close #408?") so the suggestion is grounded.

Command:

quire task get <id> --json

Args:

  • <id> — accepts #408 (short id, within current project context), a full OID, or a full Quire task URL. If the user pasted a URL, quire resolve is often cleaner — it returns a typed {kind, resource} envelope.

Output: single task object (raw API shape).

Tool: create_task

Use for: creating a new task inside a project (or as a subtask of an existing task). The user must have named a destination — don't guess a project. If they only said "add a task to remind me…", ask which project or offer to put it in their Inbox.

This is a write. Restate the task you're about to create — name, project (or parent task), assignee, due date, priority — and wait for the user's explicit confirmation before invoking.

Command:

quire task create <project> --name <name> [--description <text>] [--priority <p>] [--due <date>] [--start <date>] [--assignee <user>] [--tag <tag>] [--parent <id>] [--sibling <id>] [--position <before|after>] [--recurrence-freq <freq>] [--recurrence-interval <n>] [--recurrence-byweekday <days>] [--recurrence-until <date>] --json

Args:

  • <project> — project OID, slug, or URL. Required even when creating a subtask via --parent (the parent's project must match).

Required flag:

  • --name <name> — the task name. The only mandatory field.

Common flags:

  • --description <text> — task body.
  • --priority <low|medium|high|urgent>.
  • --due <date>, --start <date> — YYYY-MM-DD or ISO 8601.
  • --assignee <user> — OID, numeric id, or email. Repeat for multiple.
  • --tag <tag> — tag name. Repeat for multiple.

Positioning flags:

  • --parent <id> — create as a subtask of this parent task.
  • --sibling <id> plus --position before|after — place the new task adjacent to an existing sibling. Use one positioning approach, not both.

Recurrence flags: same as update_task (--recurrence-freq, --recurrence-interval, --recurrence-byweekday, --recurrence-until).

Output: the new task object (same shape as get_task).

Examples:

quire task create marketing-launch --name "Draft Q3 announcement" --due 2026-06-01 --assignee jane@acme.com --json
quire task create marketing-launch --name "Write social copy" --parent marketing/#408 --json
quire task create marketing-launch --name "Daily standup notes" --recurrence-freq daily --recurrence-interval 1 --json

Tool: update_task

Use for: modifying fields on an existing task — renaming, editing description, changing status or priority, setting/clearing dates, adding or removing tags, reassigning, managing successors, setting custom-field values, or configuring recurrence. Pass only the flags the user asked to change; omitted flags leave existing values alone.

This is a write. Before invoking, restate the change in plain language ("Change priority of #408 Launch site from high to urgent — confirm?") and wait for the user's explicit go-ahead. If you fetched the task with get_task first to ground the diff, mention what's changing from/to. Do not chain multiple updates in a single turn without re-confirming.

Command:

quire task update <id> [--name <name>] [--description <text>] [--status <0-100>] [--priority <p>] [--due <date>] [--start <date>] [--add-tag <tag>] [--remove-tag <tag>] [--add-assignee <user>] [--remove-assignee <user>] [--add-successor <id>] [--remove-successor <id>] [--custom-field key=value] [--recurrence-freq <freq>] [--recurrence-interval <n>] [--recurrence-byweekday <days>] [--recurrence-until <date>] --json

Args:

  • <id> — task OID, project-slug/#408, or full Quire task URL.

Field flags (pass only what you're changing):

  • --name <name> — new task name. Replaces outright.
  • --description <text> — new description body. Replaces outright.
  • --status <0-100> — numeric workflow status. 0 = active, 100 = complete; projects can define custom statuses in between. If the user names a status ("blocked", "in review"), call list_statuses first to resolve the numeric value. To mark a task complete, prefer complete_task over --status 100 — same effect, clearer intent. Same for "add a tag" — call list_tags first if the user names a tag you haven't seen, so you spell it the way the project does.
  • --priority <low|medium|high|urgent>.
  • --due <date>, --start <date> — ISO 8601 / YYYY-MM-DD. Pass the literal string null to clear a date.
  • --add-tag <tag> / --remove-tag <tag> — repeat for multiple. Tags are matched by name within the task's project.
  • --add-assignee <user> / --remove-assignee <user> — accepts OID, numeric id, or email. Repeat for multiple users.
  • --add-successor <id> / --remove-successor <id> — manage cross-task dependencies (this task blocks <id>).
  • --custom-field key=value — repeat for multiple. key matches the custom field's name in the task's project.

Recurrence flags (set together when adding/changing recurrence):

  • --recurrence-freq <daily|weekly|monthly|yearly>
  • --recurrence-interval <n> — positive integer, every N freq-units.
  • --recurrence-byweekday <days> — comma-separated day numbers 0–6 (0 = Sunday). Only meaningful with --recurrence-freq weekly.
  • --recurrence-until <date> — end date for the recurrence.

Output: the updated task object (same shape as get_task).

Examples:

quire task update marketing/#408 --priority urgent --add-assignee jane@acme.com --json
quire task update marketing/#408 --due null --remove-tag backlog --json
quire task update 0e0123abc --status 30 --due 2026-06-01 --json

If the user is only changing dates, set_task_dates (below) is a smaller-surface alternative — same effect for dates, narrower diff. To mark a task done, use complete_task (below) rather than --status 100.

Tool: set_task_dates

Use for: setting or clearing only a task's start or due date. Prefer this over update_task when dates are the only change — the diff is smaller, the safety conversation is shorter, and there's no risk of accidentally touching other fields.

This is a write. Restate the change ("Set due of #408 Launch site to 2026-06-01 — confirm?") and wait for explicit confirmation. Clearing a date is also a real change worth confirming.

Command:

quire task dates <id> [--start <date>] [--due <date>] --json

Args:

  • <id> — task OID, project-slug/#408, or full Quire task URL.

Flags (pass at least one):

  • --start <date> — ISO 8601 / YYYY-MM-DD, or the literal string null to clear the start date.
  • --due <date> — same shape; pass null to clear.

Output: the updated task object (same shape as get_task).

Examples:

quire task dates marketing/#408 --due 2026-06-01 --json
quire task dates marketing/#408 --start null --due null --json

Tool: complete_task

Use for: marking a task complete. Prefer this over update_task --status 100 — same effect, clearer intent.

This is a write. Restate the task ("Mark #408 Launch site complete — confirm?") and wait for explicit confirmation. If the user says something ambiguous like "wrap that up," confirm before assuming they mean "complete."

Command:

quire task complete <id> --json

Args:

  • <id> — task OID, project-slug/#408, or full Quire task URL.

Output: the updated task object (status now reflects the project's "complete" state).

Example:

quire task complete marketing/#408 --json

To re-open a completed task, use uncomplete_task (below) — the natural pair with complete_task.

Tool: uncomplete_task

Use for: re-opening a task that was previously completed. Resets the task's status to 0 (active). Natural pair with complete_task.

This is a write. Restate the task ("Re-open #408 Launch site — confirm?") and wait for explicit confirmation. Re-opening is a real state change others can see on the task; don't do it silently.

Command:

quire task uncomplete <id> --json

Args:

  • <id> — task OID, project-slug/#408, or full Quire task URL.

Output: the updated task object (status now 0).

Example:

quire task uncomplete marketing/#408 --json

Tool: add_comment

Use for: posting a comment on a task. Comments are visible to everyone with access to the task — treat them as you would a public Slack message.

This is a write. Restate the task and the exact comment text — quote it verbatim — and wait for explicit confirmation. Don't paraphrase: the user is on the hook for the wording. If they gave you a summary ("tell the team the deploy slipped"), draft the comment, show it back, and ask them to approve or edit before sending.

Command:

quire comment add <task-id> --text <text> --json

Args:

  • <task-id> — task OID, project-slug/#408, or full Quire task URL.

Flag:

  • --text <text> — the comment body. Plain string works for short content. For long content, --text @/path/to/file.md reads from disk and --text - reads from stdin. Newlines and Markdown are preserved.

Output: the new comment object (oid, text, author, created, task, …).

Example:

quire comment add marketing/#408 --text "Pushing the launch to Monday — Jane is OOO Friday." --json

Comment editing (quire comment update <oid> --text …) and deletion (quire comment delete <oid>) are not exposed by this skill. If asked, decline and point the user at the CLI directly.

Tool: list_task_comments

Use for: "what's been said about this task?" Pulls every comment on a task in chronological order. Use this before drafting a reply with add_comment so the comment lands in context.

Command:

quire comment list <task-id> --json

Args:

  • <task-id> — task OID, project-slug/#408, or full Quire task URL.

Output: array of comment objects (oid, text, author, created, pinned, task, …). Author is a full user object — refer to people by nameText, not by OID.

Example:

quire comment list marketing/#408 --json

Tool: search_tasks

Use for: filtered queries — "blocked tasks tagged backend in Acme org", "high-priority items due this week in project X". Must scope with one of --project, --org, or --folder.

Command:

quire task search <query> ( --project <id> | --org <id> | --folder <id> ) \
  [--mine] [--assignee <user>] [--tag <tag>] [--status <s>] \
  [--priority <p>] [--limit <n>] --json

Args:

  • <query> — free-text search string. Pass "" (empty) if you only want to filter, not text-search.

Scope flags (pick one — required):

  • --project <id>
  • --org <id>
  • --folder <id> — a folder OID.

Filter flags:

  • --mine — restrict to tasks assigned to the signed-in user.
  • --assignee <user> — OID, numeric id, or email.
  • --tag <tag> — tag name.
  • --status <s> — active, completed, or numeric 0–100.
  • --priority <p> — low, medium, high, urgent, or -1/0/1/2.
  • --limit <n> — page size.

Output: array of task objects.

Example:

quire task search "deploy" --org acme --priority high --status active --json

There is no --due filter. If the user asks for "tasks due this week", fetch with the available filters and then filter by due field in your own logic (or just summarize what came back).

Tool: get_task_tree

Use for: the full subtree under one task — useful when summarizing an epic or when the user asks about subtasks of subtasks.

Command:

quire task tree <id> [--depth <n>] --json

Flags:

  • --depth <n> — positive integer (default 3) or full for unbounded. Prefer a small depth (1–3) for chat responses; only ask for full if the user explicitly wants everything.

Output: array of nested tree nodes. Each node has oid, id, name, a tasks array of children, and an optional cropped: true flag when the depth cut off further children.

For just one level of children (no grandchildren), list_subtasks is cheaper and easier to summarize.

Tool: list_subtasks

Use for: direct children of a task only — one level deep, no grandchildren. Use this when the user asks "what's under #408?" and doesn't need the recursive tree. Cheaper and easier to summarize than get_task_tree for narrow questions.

Command:

quire task subtasks <id> [--limit <n>] [--cursor <token>] --json

Args:

  • <id> — task OID, project-slug/#408, or full Quire task URL.

Flags:

  • --limit <n> — page size.
  • --cursor <token> — pass the cursor from a previous page to continue.

Output: array of task objects (same shape as list_project_tasks).

Example:

quire task subtasks marketing/#408 --json

Tool: list_projects

Use for: discovery — "what projects do I have access to?" Filter to one org when the user has named one.

Command:

quire project list [--org <id>] --json

Output: array of project objects (oid, id, name, nameText, organization, archived, …).

Tool: get_project

Use for: project-level metadata — owner, description, dates, archived status, custom-field schema.

Command:

quire project get <id> --json

Output: single project object.

Tool: list_statuses

Use for: resolving a status the user named ("blocked", "in review") to the numeric value that update_task --status accepts. Each project defines its own workflow statuses between 0 (active) and 100 (complete) — the numbers aren't standardized across projects, so always look them up for the specific project before passing a number.

Command:

quire status list <project> --json

Args:

  • <project> — project OID, slug, or URL.

Output: array of status objects (oid, name, value, color, …). Match by case-insensitive name; pass the value to update_task.

Example:

quire status list marketing-launch --json

Tool: list_tags

Use for: discovering the tag vocabulary on a project before passing --add-tag / --remove-tag (in update_task) or --tag (in create_task). Tags are matched by exact name, so the user's casual spelling ("backend") may not match the project's actual tag ("Backend" or "back-end"). Look up first, spell it the way the project does.

Command:

quire tag list <project> --json

Args:

  • <project> — project OID, slug, or URL.

Output: array of tag objects (oid, name, color, …).

Example:

quire tag list marketing-launch --json

Tool: resolve_url

Use for: turning a Quire URL the user pasted into a typed resource without having to guess what kind of thing it points to. Handles project, task, chat, document, organization, and user URLs uniformly.

Command:

quire resolve <url> --json

Output: { "kind": "task" | "project" | "chat" | "document" | "organization" | "user", "resource": { … } }.

After resolving, you typically already have the full object — no follow-up get call needed.

Common pitfalls

  1. Singular subcommands. The CLI uses quire task … and quire project … (singular), not tasks/projects. The mine, whoami, and resolve commands sit at the top level, not under task.

  2. task list requires a project argument. It is not a global "list every task I can see" command. For "my tasks across everything", use quire mine --all-orgs --json.

  3. task search requires a scope flag (--project / --org / --folder). Searching with no scope is rejected with a validation error.

  4. No --due filter on search. Fetch then filter the due field yourself.

  5. IDs come in three shapes. Project IDs accept slug, numeric id, or OID. Task IDs accept short id (#408 or 408), full OID, or full Quire URL. When a Quire URL is in hand, prefer quire resolve over guessing.

  6. Do not surface opaque OIDs (the 0e… strings) in user-facing replies. They are internal handles. Refer to tasks by name + short id (#408) and to projects by name. Use OIDs only when piping back into another CLI call.

  7. One scope at a time on mine. --project, --inbox, --org, and --all-orgs are mutually exclusive; pick one.

  8. Rate limits exist. Avoid fan-out loops that call get_task over hundreds of tasks in a single turn. Prefer task tree or task list to pull many tasks in one request.

  9. Free Quire plans restrict org-wide scope. quire mine --all-orgs, quire mine --org, quire task search --org, and quire task search --folder return error 469 ("Quire quota exceeded … isn't supported on the free plan") when the signed-in user is on a free plan. Recovery — fan out per project, which IS allowed on free:

    1. Call list_projects (no scope) to enumerate every project the user can see. This works on free.
    2. If the project count is ≤ 10, call list_my_tasks --project <id> for each project and concatenate the results. Mention to the user that you fanned out because cross-org scope isn't available on their plan.
    3. If the project count is > 10, do not fan out blindly — ask the user which subset of projects (or which org) to check. Blanket fan-out across many projects risks API rate limits.

    Same pattern applies to task search: if --org / --folder is blocked, loop the search over --project <id> for the projects you care about.

Authentication failures

If a command exits with an authentication error, tell the user to run quire login once in their terminal — the skill cannot drive that flow itself (it opens a browser for OAuth). After that completes, retry.

Reference

More in Security