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

name, description

name	description
gtd-weekly-review	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.

   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 '