/daily-task-manager

name: daily-task-manager
version: 2.0.0
description: |
  Task lifecycle management with stable task IDs. Add, complete, defer, remove,
  and review tasks with deterministic action routing and fail-closed ambiguity
  handling. Maintains a running task list as a brain page.
triggers:
  - "add task"
  - "complete task"
  - "what are my tasks"
  - "task list"
  - "defer task"
tools:
  - search
  - get_page
  - put_page
  - add_timeline_entry
mutating: true
upstream: daily-task-manager@fc834ee

Daily Task Manager

Contract

This skill guarantees:

• Tasks stored as a brain page (slug `ops/tasks`, file `ops/tasks.md`) with structured format and a stable `id` per task
• Task lifecycle: add → in-progress → complete | defer | remove
• Priority levels: P0 (urgent), P1 (today), P2 (this week), P3 (backlog)
• Completed tasks archived with completion date; deferred tasks carry a target date + reason
• Mutations never drop unrelated tasks or unknown sections
• Every action returns the structured result below (Returns)

Returns

After every action, report a structured result so callers (including sub-agents) can chain reliably:

{action, task_id, status: ok|not_found|ambiguous|needs_confirmation, priority, date, page: "ops/tasks", saved: true|false}

For `review`, return the grouped active-task list instead of a single task_id. When invoked with the trigger "task list json", return a JSON array of task objects `{id, description, priority, due, status}` instead of markdown.

Tool Interface

Use ONLY the declared tools. `get_page("ops/tasks")` to read, `put_page("ops/tasks", …)` to write, `add_timeline_entry` for the audit trail, `search` for cross-referencing. Do not shell out to `gbrain` CLI verbs from this skill; the tools are the interface. (When the user runs this manually outside an agent, the CLI equivalents are `gbrain get ops/tasks` / `gbrain put ops/tasks` — equivalents only, not the skill's interface.)

Action Routing

Map user intent deterministically before touching state:

• "add / remind me to / put X on my list" → **add**
• "done with X / finished X / completed X / ✅ X" → **complete**
• "push X / defer X / move X to next week" → **defer**
• "delete X / remove X / kill task X" → **remove** (explicit delete words only — never infer remove)
• "what are my tasks / task list / what's on my plate (today)" → **review** ("today" filters to P0+P1)

Phases

1. **Load.** `get_page("ops/tasks")`. **First run:** if the page does not exist, look for `ops/tasks.md` (where earlier versions of this skill saved tasks): if it exists, create `ops/tasks` with its tasks and leave the old page in place; otherwise create it from the Output Format template. Then proceed. 2. **Validate.** Determine the action via Action Routing. If required fields are missing (see per-action rules), ask ONE concise clarification before mutating state. Never fabricate priorities, due dates, or defer reasons. 3. **Identify the target task** (complete/defer/remove): match by `id` when given; otherwise fuzzy-match description against ACTIVE tasks only. Zero matches → return `not_found`, do not mutate. Multiple matches → list candidates with IDs, return `ambiguous`, do not mutate. 4. **Execute:**

• **Add:** Require a description. Priority: use the user's stated/clearly-implied level; otherwise default to **P3 and say so in the reply + timeline entry**. Due date only if supplied or explicit in the user's words. Mint a new task ID (`t-YYYYMMDD-NN`, NN = next free ordinal that day). Add a timeline entry.
• **Complete:** Mark `[x]`, move to Completed with `(completed: YYYY-MM-DD)`.
• **Defer:** Require a target date/timeframe AND a reason; ask if missing. Move to Deferred preserving original text, ID, and priority unless the user changes them.
• **Remove:** Destructive — require explicit confirmation unless the user's message already contains it. Prefer suggesting complete or defer.
• **Review:** Read-only. Never mutates. Active tasks grouped by priority, IDs shown.

5. **Save.** `put_page("ops/tasks")` after any mutation. Diff-mindset: touch only the affected lines; preserve all other content, including sections this skill doesn't recognize.

Edge Cases

• **First run:** page missing → carry the tasks over from `ops/tasks.md` if that page exists and leave the old page in place, else create from template, before acting; `status: ok`, note "initialized".
• **Malformed page:** if `ops/tasks` exists but doesn't match the schema, do NOT rewrite it wholesale. Append/edit within it minimally, preserve unknown content verbatim, and flag the malformation in the reply.
• **Retry/duplicate add:** if an identical description already exists in active tasks, do not add a duplicate — report the existing task ID instead.
• **Dates:** ISO 8601 (`YYYY-MM-DD`) everywhere. Compute "today"/"next week" with code/clock, never guess.
• **Page identifier:** always the slug `ops/tasks` (no `.md`) in tool calls; this is the single canonical location (`ops/tasks.md` is a different slug and misses it).
• **Single-writer assumption (concurrency limitation).** The task cycle is read-modify-write: `get_page("ops/tasks")` → edit → `put_page("ops/tasks")`. `put_page` replaces the WHOLE page and has no compare-and-swap, so two mutations that interleave are last-writer-wins: the second `put_page` overwrites the first's change (a completed task reappears, an added task vanishes), and the `t-YYYYMMDD-NN` minting can hand the same ordinal to two concurrent adds (duplicate IDs). Serialize task edits — never run parallel task mutations (multiple subagents, concurrent chat turns) against `ops/tasks`. If a mutation might race, re-`get_page` immediately before `put_page` and re-derive the next free ordinal from the freshly-read page.

Output Format

Persisted page format

Each task carries a stable ID so later actions can target it safely:

# Tasks

## P0 — Urgent
- [ ] <!-- id: t-20260115-01 --> {task description}