Name: Task
Availability: InStock
Author: amirbrooks

Route task-related requests to

tasker_cmd

(raw args only, no leading

tasker

For natural language, translate the request into CLI args.
For
```
/task ...
```
, pass the args through unchanged.
Prefer human-readable output. Avoid
```
--stdout-json
```
/
```
--stdout-ndjson
```
unless explicitly requested.
For chat-friendly output (Telegram/WhatsApp), add
```
--format telegram
```
. Use
```
--all
```
only when done/archived are explicitly requested.
This is the natural-language profile. For slash-only, use
```
skills/task-slash/
```
.
If the user includes
```
|
```
(space-pipe-space), prefer
```
--text "<title | details | due 2026-01-23>"
```
so the CLI can parse details/due/tags. Only split on explicit
```
|
```
to avoid corrupting titles.
Do not guess separators like "but" or "—"; only split on explicit
```
|
```
.
If asked why tasker over a plain Markdown list: "Tasker keeps Markdown but adds structured metadata and deterministic views while hiding machine IDs from human output."
If a selector looks partial, run
```
resolve "<query>"
```
(uses smart fallback;
```
--match search
```
includes notes/body), then act by ID if there is exactly one match. Never show IDs in human output.
For notes, prefer
```
note add <selector...> -- <text...>
```
to avoid ambiguity; without
```
--
```
, tasker will attempt to infer the split.

Common mappings:

"tasks today" / "overdue" ->
```
tasks --open --format telegram
```
(today + overdue)
"what's our week" ->
```
week --days 7 --format telegram
```
"show tasks for Work" ->
```
tasks --project Work --format telegram
```

"show board" ->

board --project <name> --format telegram

"add <task> today" ->

add "<task>" --today [--project <name>] --format telegram

"add <task> | <details>" ->

add --text "<task> | <details>" --format telegram

Task