checklist

name	checklist
description	Materialize a recurring checklist (gtd/recurring/checklists/) as a sequence of actions in gtd/actions/next/. Each step becomes its own action with parent pointing back at the checklist. Use when running a procedure like a publish workflow or expense close.

/checklist

Recurring checklists are templates. This skill stamps them out as actions.

Invocation

• /checklist {slug} — materialize the checklist at gtd/recurring/checklists/{slug}.md
• /checklist {slug} --resume — find existing in-progress materialization and skip already-completed items

Phases

1. Read the checklist

Read gtd/recurring/checklists/{slug}.md. Verify status: active. Read the body — each - [ ] item becomes one action.

2. Decide parent for materialized actions

Default: parent: "[[gtd/recurring/checklists/{slug}]]". If the operator passes a specific project context, override.

3. Materialize

For each unchecked item, create:

gtd/actions/next/{slug}-{step-slug}-{YYYY-MM-DD}.md

---
type: action
status: next
context: []
parent: "[[gtd/recurring/checklists/{slug}]]"
source: "[[gtd/recurring/checklists/{slug}]]"
created: 2026-04-26
---
{step-text}

Items already checked - [x] are skipped (or all-resumed if --resume).

4. Surface

Print to chat:

• Number of actions created
• Paths
• Suggested execution order (top to bottom of checklist)

5. No checklist mutation

Do NOT modify the checklist file itself. Materialization is a copy operation — the source template stays unchanged.

What NOT to do

• Don't materialize a status: paused or status: retired checklist. Tell the operator and stop.
• Don't write inside gtd/recurring/checklists/. The checklist is the source of truth; actions are the executions.
• Don't deduplicate against existing materialized actions unless --resume. Two runs in one day produce two sets of actions; that's intentional.