torben
6d53c55d0d
Files changed: - CHANGES.md - INSTALL.md - VERSION - instructions/dev/version-parts.md - instructions/gtd-weekly-review/SKILL.md - tools/CONTRACT.md - tools/chemenu/commands/doctor.py - tools/chemenu/commands/version_cmd.py - tools/chemenu/review.py - tools/chemenu/tasks/__init__.py - tools/chemenu/tasks/caldav.py - tools/chemenu/tasks/config.py - tools/chemenu/tests/test_caldav.py - tools/chemenu/tests/test_doctor.py - tools/chemenu/tests/test_review.py - tools/requirements.txt
10 KiB
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
-
Run the review.
tools/wikitool reviewExit 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.
-
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 stalledA tracker project has zero open items and its kb/page isstate: 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 '