task

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
• "capture <text>" -> capture "<text>" --format telegram
• "mark <title> done" -> done "<title>"
• "show config" -> config show