Weekly review

Weekly review

Drive the GTD weekly review. The step list lives in CHECKLIST.md — read it when this skill activates and walk it top to bottom. Both files are pure methodology and a base to edit, not dogma; anything said in conversation overrides them.

Task backend

This process is backend-agnostic. It reads widely and writes once, so it needs to:

• list the inbox, the projects, and the tasks under any given project
• find tasks by state: no next action, waiting-for, someday/maybe, completed this week
• find tasks by date: overdue, deferred, due in the coming week
• re-parent, rename, and complete tasks; set defer and due dates; assign contexts from the existing set
• read and write a durable note on a task — the item's trail

If your task backend supplies a binding — an MCP server's connection-time instructions, a skill, or a doc — follow it. It owns the mapping and the write discipline (batching, id freshness).

What persists

Three places, decided in this order:

• about one item → its trail: a block at the end of that item's note, fenced between <!-- gtd:trail --> and <!-- /gtd:trail -->. Write only inside the fence — everything outside it is the user's and is never edited. This is where a keep decision and its reason go, and where you read last week's.
• about how the user works → the profile at ~/.gtd/PROFILE.md (GTD_PROFILE overrides). Policy only. Read it first; where it and the Defaults below disagree, the profile wins. If it doesn't exist, create it seeded from those Defaults.
• answerable by asking the backend → store nothing. Project state, dates and the context set are all queries; never keep a copy.

Write to both without asking, and name what you wrote in the wrap-up.

Defaults (edit these)

• Next-action policy: every active project should have at least one concrete, verb-first next action. <!-- e.g. change to: exactly one *starred* next action per project -->
• Stale threshold: flag anything dated more than 30 days in the past and projects with no open next action.
• Standing decisions: when the user consciously keeps a stale item, write the decision and its reason to the item's trail and don't raise it for the next two reviews. After that, surface it again carrying the count — "kept four times, last because you were waiting on the lease." Repeated keeps are exactly the avoidance this review exists to catch, so memory here is for saying something new, not for going quiet.
• Review log: none. <!-- alternative: append a dated summary line to a "Weekly Review" item's note -->
• Sections: run all three (clear / current / creative). Skip a section only if the user asks or time-boxes the review.

Process

1. Read the profile, then read CHECKLIST.md and walk it. For each step: gather what the step asks for — including the trails on anything you're about to raise — report it in plain language (lead with what needs a decision, not raw listings), and ask the decisions that are the user's to make.
2. Do not change the system mid-review. Accumulate every agreed fix, present the combined plan at the end, then apply it in one pass.
3. Finish with a short wrap-up: state of the system, decisions made, what the user chose as the week's priorities, a learned this run line naming what went into the profile and which trails you wrote, and (per Defaults) the review log entry.