chemenu/instructions/gtd-weekly-review/SKILL.md

---
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.

**What this skill may write to the tracker, and what it may not.** `wikitool`'s GTD command
surface offers exactly two tracker-side writes - `task new` (create one item) and `task close`
(mark one item done, never delete it) - alongside `review` (read-only) and `new project` (page +
tracker project creation). This skill proposes both writes at the specific findings below, always
after the user confirms the exact call, never on its own initiative - the same posture
`wiki-ingest` takes toward its own commitment question ("propose one and let the user confirm or
correct it"). Everything else a tracker item can need - moving a reminder forward, removing an
item outright - stays the user's own action in their tracker: that is a deliberate line, not a gap
in the command surface waiting to be filled. Do not reach for a tracker-specific tool or API to
"just do it faster" for either half. The reasoning behind keeping the tracker and `kb/gtd/` on
separate write paths, and behind stopping at "create" and "mark done" rather than a fuller CRUD
surface, lives in `docs/knowledge-and-commitment.md`, which this skill does not repeat.

## 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 - propose `tools/wikitool task new --title "<title>" --project "<project>"` with a title the user confirms or corrects, asked as one combined question ("Create '<title>' in project '<project>'?"), then run it once confirmed. (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 - the user's own action, there is no `wikitool` command for it. (b) The commitment is no longer needed - propose `tools/wikitool task close --id "<id>"` (the finding's own `item_id`), asked as one combined question naming the item's title and id, then run it once confirmed | 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 - propose `tools/wikitool task close --id "<id>"` (the finding's own `item_id`), asked as one combined question naming the item's title and id, then run it once confirmed. (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 |
   | `waiting_no_follow_up` | A `WAITING` item carries no `follow_up_at` at all - the provider had nothing to judge staleness against, so `waiting_overdue` could not even ask the question | (a) Set a follow-up date on the item, in the tracker itself - there is no `wikitool` command for this, same as moving a reminder forward. (b) Leave it open-ended deliberately - some commitments genuinely have no date yet | Ask whether there is a date to follow up on at all. If yes, (a); if the item is a genuine "whenever they get back to me", (b) is legitimate, but say so plainly rather than treating the finding as resolved by itself |
   | `project_age_unknown` | A tracker project has no determinable creation date - the provider could not supply one (an empty project, or a server that never reports it), so `unpaged_project` could not judge its age either way | (a) Judge it on its own merits regardless of age - if it clearly deserves a `kb/` page now, `tools/wikitool new project --name "<Name>" --set responsibility=<area>`. (b) Leave it - it becomes ordinary `unpaged_project` material once it does gain a determinable age | There is no date to reason from here, unlike `unpaged_project` - ask the same "would anyone need to know why this exists" question from that row, but without an age argument on either side |

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, 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. Someone who already has a page is the other case,
   and the same section says what it takes: a `[[wikilink]]` on the mention and a participation
   edge on the project page.

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`, `task new`, `task close`, `rename` (via
`instructions/page-lifecycle.md`, only for the rename case), `publish`

**Absent:** moving a reminder forward, and removing an item outright - both stay the user's own
action in their tracker. See "What this skill may write to the tracker, and what it may not"
above for why the line sits exactly there.

## 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?"