Skill: ivangdavila/task-list (version 1.0.0)

--- name: Task List slug: task-list version: 1.0.0 homepage: https://clawic.com/skills/task-list description: Run a conversational task list with Inbox, Today, Upcoming, recurring tasks, waiting items, projects, and review loops that stay trustworthy. changelog: "Initial release with a conversational task-list workspace, stable views, and Things or Todoist-style operating rules." metadata: {"clawdbot":{"emoji":"📋","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/task-list/"]}} --- ## Setup On first use, read `setup.md` for activation boundaries, continuity rules, and how to introduce the system without turning it into a form. ## When to Use User wants to manage a task list by talking naturally instead of filling a UI. The agent should capture tasks, clarify them into clean next actions, and maintain stable views like Inbox, Today, Upcoming, Anytime, Someday, and Waiting. Use this when the user wants Things or Todoist behavior from conversation: quick capture, predictable sorting, recurring work, project structure, and weekly review without silent changes. ## Architecture Memory lives in `~/task-list/`. If the user wants continuity and `~/task-list/` does not exist, run `setup.md`. See `memory-template.md` for the durable context file and `workspace-format.md` for the local file layout. ``` ~/task-list/ ├── memory.md # Durable preferences and activation boundaries ├── inbox.md # Raw captures that still need clarification ├── tasks.md # Active tasks across Today, Upcoming, Anytime, Someday ├── projects.md # Finite outcomes with next actions and deadlines ├── areas.md # Ongoing responsibilities without end dates ├── recurring.md # Recurrence rules and regeneration behavior ├── waiting.md # Delegated or blocked work with chase dates └── log.md # Recently completed, dropped, or major field changes ``` ## Quick Reference | Topic | File | |-------|------| | First-use behavior | `setup.md` | | Durable memory | `memory-template.md` | | Local workspace files | `workspace-format.md` | | Capture and clarification | `capture-and-clarify.md` | | Views and sorting rules | `views-and-sorting.md` | | Dates, recurrence, and waiting | `recurrence-and-waiting.md` | | Daily and weekly review loops | `review-rhythm.md` | ## Core Rules ### 1. Capture first, clarify second - Never block raw capture on missing metadata. - If the user brain-dumps multiple items, capture them all first, then clarify only the fields that materially change execution. - Default ambiguous items to `Inbox` instead of pretending certainty. - Use `capture-and-clarify.md` to decide what to infer versus what to ask. ### 2. Preserve task semantics exactly - Keep due date, start or defer date, recurrence rule, completion time, and waiting state as separate concepts. - "Due Friday" is different from "show me this Friday" and different again from "snooze until Friday." - If a date phrase could change the outcome, ask once and record the clarified meaning. - Use `recurrence-and-waiting.md` for exact date and repeat behavior. ### 3. One task equals one visible next action - Rewrite vague items into a task title that starts with a verb and can be advanced in one focused work block. - If the user names an outcome with multiple steps, create a project plus the next visible action instead of one bloated task. - Preserve important original wording in notes or context when rewriting could hide nuance. - Use `workspace-format.md` for the project and task record shape. ### 4. Keep views stable and predictable - The same task should land in the same view every time given the same fields. - Sort by bucket first, then date, then urgency, then intentional manual order. - `Today` is for work that should be seen now, not for every overdue item in the system. - Use `views-and-sorting.md` whenever listing or re-listing tasks. ### 5. Separate projects, areas, and waiting work - Projects are finite outcomes with a defined done condition. - Areas are ongoing responsibilities such as finance, health, hiring, or household operations. - Waiting work must keep owner, blocker, last follow-up, and next chase date visible so delegated tasks do not disappear. - Never collapse all of this into one flat list. ### 6. Make every structural change explicit - Confirm destructive or high-trust changes: delete, archive, mark done, recur, reschedule, or bulk move. - When you change a task, say what changed in plain language. - Never silently merge duplicates, invent deadlines, or mark something completed without the user's intent. - Use the logging patterns from `workspace-format.md` for meaningful changes only, not noisy chatter. ### 7. Review ruthlessly to keep trust - Run lightweight daily triage to empty `Inbox`, refresh `Today`, and surface real blockers. - Run a weekly reset to prune stale tasks, expose overcommitment, and ensure every active project has a next action. - Suggest defer, drop, delegate, or Someday when the list exceeds realistic capacity. - Use `review-rhythm.md` for the minimum review loop. ## Common Traps - Turning every conversation into a questionnaire -> capture becomes slower than opening a task app. - Mixing due dates and start dates -> tasks appear too early, too late, or in the wrong view. - Treating projects and areas as the same thing -> review quality collapses as the list grows. - Hiding delegated work inside generic blocked tasks -> follow-up risk becomes invisible. - Keeping everything in `Today` -> the user stops trusting the list and avoids it. - Rewriting task meaning too aggressively -> clean titles look nice but destroy intent. - Auto-completing or auto-rescheduling without saying so -> trust is lost immediately. ## Security & Privacy **Data that leaves your machine:** - None by default. **Data that stays local:** - Task records and preferences under `~/task-list/` if the user wants continuity. **This skill does NOT:** - Access files outside `~/task-list/` for storage. - Make undeclared network requests. - Send reminders or run automations without explicit user approval. - Modify its own skill instructions. ## Related Skills Install with `clawhub install <slug>` if user confirms: - `assistant` - Chief-of-staff style execution across tasks, messages, and follow-through. - `daily-planner` - Turn tasks into a realistic day plan with protected focus blocks. - `memory` - Keep durable context when the user wants broader long-term recall. - `plan` - Build structured plans when a task grows into a multi-step initiative. - `projects` - Manage deeper project tracking beyond a simple task list. ## Feedback - If useful: `clawhub star task-list` - Stay updated: `clawhub sync`

path: capture-and-clarify.md
content: # Capture and Clarify — Task List

## Capture defaults

- Accept raw language: "remind me," "I need to," "waiting on," "someday," "not this week."
- If the user gives several items at once, split them into separate task records.
- Keep ambiguous items in `Inbox` unless the bucket is obvious from wording.

## Infer silently when confidence is high

Infer without asking when the meaning is obvious:
- explicit dates
- obvious waiting language
- obvious recurring language
- direct project names already in use
- clear "someday" or "not now" phrasing

## Ask only when ambiguity changes action

Ask one short follow-up when:
- the date phrase could mean due or defer
- the user named an outcome that should become a project
- the item might be waiting on someone else
- deletion, done, or recurrence could change history

Do not ask for tags, colors, labels, or metadata that does not change execution.

## Title hygiene

- Start with a verb whenever possible.
- Remove filler words but keep meaning.
- Preserve sensitive wording in notes when shortening the title would hide nuance.

## Good conversions

- "Need to send Marta the draft by Friday" -> `Send draft to Marta` with due date Friday
- "Waiting on legal before I can ship contract" -> waiting item plus next chase date if known
- "Someday maybe redesign landing page" -> Someday bucket, not Today
- "Every first workday review cash runway" -> recurring rule with explicit regeneration behavior


path: memory-template.md
content: # Memory Template — Task List

Create `~/task-list/memory.md` only if the user wants continuity across sessions.

```markdown
# Task List Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending

## Context
- Activation preference:
- Default buckets:
- Date semantics:
- Review rhythm:
- Project style:
- Area vocabulary:
- Typical overload signals:

## Notes
- Current planning horizon:
- Recurring commitments worth keeping visible:
- Waiting patterns or follow-up rules:
- Durable corrections about sorting, naming, or prioritization:

---
*Updated: YYYY-MM-DD*
```

## Optional Support Files

If the user wants full continuity, create these files too:

- `~/task-list/inbox.md` — unclarified captures
- `~/task-list/tasks.md` — active tasks across Today, Upcoming, Anytime, Someday
- `~/task-list/projects.md` — finite outcomes and next actions
- `~/task-list/areas.md` — ongoing responsibilities
- `~/task-list/recurring.md` — recurrence rules and last completion
- `~/task-list/waiting.md` — delegated or blocked items
- `~/task-list/log.md` — recently completed, dropped, or major changes

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | preferences still evolving | keep learning from normal task-list use |
| `complete` | working model is stable | apply defaults with minimal follow-up |
| `paused` | setup or updates paused | use stored context without pushing for more |
| `never_ask` | user declined setup questions | do not reopen setup unless they ask |

## Integration Values

| Value | Meaning |
|-------|---------|
| `pending` | activation boundary not decided yet |
| `done` | activation preference saved in main memory |
| `declined` | user wants manual invocation only |

## Key Principles

- Keep memory short enough to scan before acting.
- Save user-stated rules and durable patterns, not every daily task.
- Update `last` whenever the local task-list workspace changes.
- Ask before widening storage from lightweight memory into the full task workspace.


path: recurrence-and-waiting.md
content: # Recurrence and Waiting — Task List

## Date semantics

- `Due` means the task becomes painful or late after that date.
- `Start` or `defer` means the task should begin appearing on that date.
- `Completed` records when the user actually finished it.

Never overwrite one field just because another changed.

## Recurrence rules

- Preserve the user's wording if possible: every weekday, every Friday, first business day, every two weeks after completion.
- Regenerate from the correct anchor:
  - calendar-based rules use the calendar date
  - completion-based rules use the completion timestamp
- When a recurring item completes, create the next occurrence and log the regeneration.

## Waiting state

Use `Waiting` when progress depends on another person, team, or external event.

Each waiting item should keep:
- who or what it depends on
- when it entered waiting
- when to follow up next
- what action becomes possible once unblocked

## Rescheduling language

- "Move to Someday" changes bucket, not history.
- "Snooze two weeks" changes start or defer date, not due date unless the user says so.
- "Push deadline" changes due date and should be reflected explicitly.

When the user's phrasing is unclear, ask which field they want changed before editing.


path: review-rhythm.md
content: # Review Rhythm — Task List

## Daily triage

Minimum daily loop:
1. Empty or shrink `Inbox`
2. Confirm what truly belongs in `Today`
3. Surface overdue and waiting risks
4. Make drop, defer, or delegate suggestions when the list exceeds capacity

Keep the result short enough to act on immediately.

## Weekly reset

At least once a week:
- clear stale Inbox items
- archive or log completed work
- scan Waiting for silent blockers
- ensure every active project has a next action
- move low-value backlog into Someday or delete it
- call out overload honestly

## Ruthless pruning

When the user is overloaded, force trade-offs:
- "Do now"
- "Schedule later"
- "Waiting on someone else"
- "Someday or maybe"
- "Drop entirely"

The task list earns trust when it removes noise, not when it stores everything forever.


path: setup.md
content: # Setup — Task List

Read this silently when the user wants task-list help and `~/task-list/` does not exist or is missing the main files. Start naturally and do not mention file names, folders, setup, or configuration.

## Your Attitude

Act like a sharp operator who makes task management feel lighter, clearer, and more trustworthy than a manual app. The user should feel relief quickly: capture chaos, name what matters, and reduce mental load without turning the conversation into data entry.

## Priority Order

### 1. Give immediate value

Solve the current task-list request in the first exchange or two:
- capture a brain dump cleanly
- show a useful `Today` view
- clarify an overloaded project into next actions
- rescue a messy list into Inbox, Waiting, and Someday

Make the first result feel better than a blank task app.

### 2. Learn how this should activate

Early in the conversation, learn when this should show up:
- whenever they talk about tasks, todos, follow-ups, or commitments
- only when they ask explicitly
- only for selected work areas or projects

If they want ongoing help, save that activation preference in their main memory so the skill appears in future sessions when it should.

### 3. Learn operating preferences from real work

Capture only the preferences that change task-list behavior:
- preferred views or buckets
- whether dates mean due, defer, or both
- how aggressive to be about pruning and prioritizing
- whether the user likes project, area, tag, or energy-based grouping
- whether the user wants a lightweight list or full continuity

Learn from what they do and confirm only when it changes outcomes.

### 4. Ask before creating local continuity

This skill works statelessly for one-off help. If the user wants continuity, explain the result in natural language: a small local task-list workspace that keeps Inbox, active tasks, projects, waiting items, and recent changes. Ask before creating anything on disk.

## What to Save Internally

With user consent for continuity, keep only high-signal context:
- activation preference
- preferred task buckets and review rhythm
- naming conventions for projects or areas
- date semantics they care about
- current backlog shape, recurring rules, and open waiting items

Do not store secrets, unrelated personal history, or private data outside task-list operations.


path: views-and-sorting.md
content: # Views and Sorting — Task List

## Core buckets

- `Inbox` — captured but not clarified enough to execute
- `Today` — should be visible now
- `Upcoming` — dated work not ready for Today
- `Anytime` — no current date pressure
- `Someday` — intentionally deferred ideas
- `Waiting` — delegated or blocked on someone else
- `Done` — completed and ready to roll out of the active list

## Deterministic ordering

Within a view, sort in this order:
1. Overdue due dates
2. Due today
3. Start date reached
4. High-priority items
5. Manual or intentional order
6. Everything else by oldest unresolved change

If two tasks tie on all fields, keep their previous visible order.

## Today rules

- `Today` is a focused working set, not the whole backlog.
- Pull in items explicitly scheduled for today, due today, or manually promoted by the user.
- Overdue items do not automatically flood `Today`; surface them as risk, then ask whether to promote, defer, or drop.

## Upcoming rules

- Show dated tasks in chronological order.
- Separate "starts showing" from "due by" when both exist.
- Keep recurring work visible only at its next intended appearance, not every future occurrence.

## Waiting rules

- Keep owner, blocker, and next chase date visible.
- Do not hide waiting items inside generic project notes.
- Surface stale waiting items during review even if they are not due today.


path: workspace-format.md
content: # Workspace Format — Task List

Use simple Markdown files so the task list stays inspectable and easy to repair.
## `inbox.md`
```markdown
# Inbox

- [ ] Send investor update Friday
- [ ] Ask Marta if legal approved the contract
- [ ] Figure out dentist appointment
```

Keep raw wording until clarification is worth the effort.
## `tasks.md`
```markdown
# Tasks

| Task | Bucket | Project | Area | Due | Start | Priority | Next step |
|------|--------|---------|------|-----|-------|----------|-----------|
| Send investor update | Today | Q2 fundraising | Finance | 2026-03-13 | 2026-03-12 | high | Draft bullet outline |
| Book dentist appointment | Anytime | - | Personal admin | - | - | low | Call preferred clinic |
```

Use buckets from `views-and-sorting.md`: Inbox, Today, Upcoming, Anytime, Someday, Waiting, Done.
## `projects.md`
```markdown
# Projects

## Q2 fundraising
- Outcome: close the round with signed docs
- Status: active
- Deadline: 2026-05-30
- Next action: draft investor update
```

Each active project must have one visible next action.
## `areas.md`
```markdown
# Areas

- Finance
- Hiring
- Health
- Household
```

Areas are ongoing responsibilities, not projects with an end date.
## `recurring.md`
```markdown
# Recurring

| Task | Rule | Recreate from | Last done | Next show |
|------|------|---------------|-----------|-----------|
| Review cash runway | every Friday | completion | 2026-03-06 | 2026-03-13 |
```
## `waiting.md`
```markdown
# Waiting

| Task | Waiting for | Since | Chase on | Next visible step |
|------|-------------|-------|----------|-------------------|
| Legal review of contract | Marta | 2026-03-04 | 2026-03-10 | Follow up if silent |
```
## `log.md`
```markdown
# Recent Changes

- 2026-03-06: Moved "Book dentist appointment" from Inbox to Anytime
- 2026-03-06: Marked "Review cash runway" done and regenerated next occurrence
```

Log meaningful state changes, not every casual mention.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)