---
name: gtd-weekly-review
description: Turns the findings from `wikitool review` into decisions and page updates - the GTD Weekly Review, with a machine that prepares the list instead of a human reconstructing it from memory. Use when the user asks for "the weekly review", "review my projects", "what's stalled", or after `wikitool review` has findings nobody has acted on yet.
---

# GTD Weekly Review

**Purpose:** A finding from `wikitool review` is not an action by itself - "this initiative looks
stalled" can mean a next action is missing, the initiative was deliberately paused, or it is
actually finished. Which one is true is a human judgment. This skill runs the conversation that
collects that judgment and carries it out.

**Trigger:** The user asks for a weekly review, or `wikitool review` has findings nobody has
looked at yet.

**Before the first `wikitool` call:** `instructions/session-setup.md`.

**Provider-neutral by design.** Nothing below names a task-tracker provider, a file format or an
API - only the tracker's generic role. That is deliberate: this skill is the one document that
must read identically in every instance, whichever tracker it runs against. Anything the tracker
itself must do - add a task, reschedule a reminder, remove an item - is described as an action the
user takes in their tracker: a deliberate choice, not a gap in `wikitool`'s GTD command surface,
which also carries `task new` (tracker item only, no page) alongside `review` (read-only) and
`new project` (page + tracker project creation) - this skill simply does not call it. The
reasoning behind keeping the tracker and `kb/gtd/` on separate write paths lives in
`docs/knowledge-and-commitment.md`, which this skill does not repeat - do not reach for a
tracker-specific tool or API to "just do it faster".

## Steps

1. **Run the review.**

   ```bash
   tools/wikitool review
   ```

   Exit 0 with no findings means a quiet week - say so and stop. A non-zero exit means the report
   is **incomplete**: one or more checks could not run because a provider call failed. Read the
   printed "INCOMPLETE" block, tell the user which checks were skipped and why, and be explicit
   that the *absence* of a finding under a skipped check means nothing - it was never asked. Do
   not re-run the command hoping for a different result; a failing provider is not fixed by
   retrying.

2. **Walk the findings by check, one at a time.** Each finding names a `kb/gtd/` project (or, for
   the two checks anchored on the tracker side, a tracker project) and the condition that fired.
   For every finding, present the options below, ask which applies, and act on the answer -
   never pick one yourself. A finding is a question, not an instruction.

   | Check | What fired | Options | How to tell them apart |
   |---|---|---|---|
   | `stalled` | A tracker project has zero open items and its `kb/` page is `state: active` | (a) A next action is genuinely missing - add one in the tracker. (b) The initiative is deliberately paused - `tools/wikitool touch --page "<Title>" --set state=dormant`. (c) It is actually finished or given up on - `--set state=completed` or `--set state=abandoned` | Read the page's `## Ziel` and `## Status` sections and ask the user directly: is there still a next step toward that goal, or did this stop for a reason? A pause that was never decided is (a); a pause that *was* decided is (b), never left as `active` with nothing moving |
   | `waiting_overdue` | A `WAITING` item's `follow_up_at` is older than the threshold | (a) Follow up now, then move the reminder forward in the tracker. (b) The commitment is no longer needed - remove or close it in the tracker | Did the person the item names actually come through, and is the ask still relevant? If yes but late, (a); if the need has passed, (b) - never leave the same stale date standing unexamined |
   | `unpaged_project` | A tracker project has no `kb/` page, past the age threshold | (a) It has grown a memory worth keeping (participants, decisions, context) - `tools/wikitool new project --name "<Name>" --set responsibility=<area>`. (b) It genuinely never needs one - confirm and leave it tracker-only | Ask: would anyone, including the operator in six months, need to know *why* this exists or who is in it? If yes, (a); a project that is fully explained by its own title and task list stays (b) |
   | `no_open_loop` | A `kb/` page is `state: active` but its tracker project is missing or empty | (a) Same three options as `stalled` above. (b) The name diverged - a rename happened on one side only | Before assuming a stall, check whether a *similarly* named tracker project exists. If it does, this is `instructions/page-lifecycle.md`'s rename case (`tools/wikitool rename` for the page, plus renaming the tracker project to match), not a state change - the review reports both directions of a rename so it never has to be inferred silently |
   | `someday_stale` | A someday/maybe item has not been touched past the threshold | (a) Activate it - give it a page with `tools/wikitool new project` if it is ready to become a committed initiative. (b) Strike it - remove it from the tracker. (c) Leave it - still genuinely "maybe" | Would the user commit to starting this today? If yes, (a). If it no longer belongs on the list at all, (b). If it is still worth keeping but not yet, (c) is a legitimate answer, not inaction - do not force a decision the user is not ready to make |

3. **Record what was decided or learned on the page - never the task list.** A decision made this
   week (a scope cut, a direction change) goes under `## Entscheidungen`; something that showed
   itself in the course of the work goes under `## Gelerntes`. Use `tools/wikitool touch` for the
   frontmatter fields it owns (`state`, `summary`, `provenance`) and edit the body directly for
   prose, the same as any other page update (`instructions/wiki-manage/SKILL.md` § Updating a
   page). **The page never summarizes the open-items list** - that is `kb/gtd/COLLECTION.md`'s
   own rule (its momentary state lives in the tracker, joined to the page only by name), and this
   skill exists precisely because that join is not automatic.

4. **Mentions of people stay mentions.** A person named in `## Beteiligte` while working through a
   finding does **not** get a page or a `[[wikilink]]`, however much this pass is about them - a
   page is earned only once they matter for the knowledge independent of this one initiative
   (`types/project.md` § Authoring guidance). Creating one here, out of the habit of linking what
   gets mentioned, is the mistake this step exists to head off.

5. **Close out.** If any page changed, `instructions/publish-cycle.md`. A pass that only changed
   tracker state (the user acted on option (a)/(b) above without touching `kb/`) publishes
   nothing - there is no page diff to carry.

## Decision points

- **A finding's `project` name does not match any page you can find?** That is very likely the
  `no_open_loop`/`unpaged_project` rename case in step 2's table, not a data error - check there
  before assuming the join is broken.
- **The user wants to skip a finding without deciding?** That is a legitimate outcome for
  `someday_stale` (option (c)) and, less often, for a genuinely undecided `stalled` case - leave
  it and say so plainly in your summary, rather than silently omitting it. It will resurface next
  week.
- **The report was incomplete (step 1)?** Work through whatever findings did arrive; do not treat
  a skipped check as reassurance that nothing is wrong there.

## wikitool commands used

`review`, `touch`, `new project`, `rename` (via `instructions/page-lifecycle.md`, only for the
rename case), `publish`

**Deliberately absent:** anything that reaches into the task tracker directly. `wikitool`'s GTD
surface also includes `task new` (tracker item only, no page -
`docs/knowledge-and-commitment.md`), but this skill does not use it: every tracker-side action in
the table above - adding a next action, moving a reminder, removing an item - is something the
user does in their tracker, not something this skill automates.

## Output

Tracker-side changes the user made themselves, plus whichever `kb/gtd/` pages actually changed,
published to `origin/main`.

**Example triggers:**

- "Let's do the weekly review"
- "What's stalled right now?"