chemenu/instructions/weekly-review/SKILL.md

name, description

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

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, because wikitool has no command for it: the only two GTD commands that exist are review (read-only) and new project (page + tracker project creation). That narrow command surface is deliberate (see the reasoning in types/project.md and kb/gtd/COLLECTION.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.

   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. review and new project are the only two GTD commands this stack has (types/project.md); every other 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?"