torben/chemenu
1
1 Fork 0
Code Issues 35 Pull Requests Actions Packages Releases 37 Activity

task: Weekly review proposes task new/task close; tracker gains a closing write path
CI / verify (push) Successful in 54s
Details
Release / release (push) Successful in 36s
Details

Browse Source 
Files changed:
- CHANGES.md
- INSTALL.md
- README.md
- VERSION
- docs/knowledge-and-commitment.md
- instructions/gtd-weekly-review/SKILL.md
- instructions/ingest-large-tree.md
- instructions/wiki-ingest/SKILL.md
- tools/CONTRACT.md
- tools/chemenu/commands/review_cmd.py
- tools/chemenu/commands/task_cmd.py
- tools/chemenu/review.py
- tools/chemenu/tasks/protocol.py
- tools/chemenu/tasks/superproductivity.py
- tools/chemenu/tests/test_review.py
- tools/chemenu/tests/test_superproductivity.py
- tools/chemenu/tests/test_task_cmd.py
This commit is contained in:
torben committed 2026-09-22 21:46:09 +02:00
1 parent 8b535b4016
commit 62d1c5e636
17 files changed
+563 -87
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

instructions/gtd-weekly-review/SKILL.md
+22 -18
View File
@@ -17,14 +17,20 @@ looked at yet.
**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".
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
@@ -48,11 +54,11 @@ tracker-specific tool or API to "just do it faster".
| 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 |
| `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 - 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 |
| `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 |
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
@@ -87,14 +93,12 @@ tracker-specific tool or API to "just do it faster".
## wikitool commands used
`review`, `touch`, `new project`, `rename` (via `instructions/page-lifecycle.md`, only for the
rename case), `publish`
`review`, `touch`, `new project`, `task new`, `task close`, `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.
**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
instructions/ingest-large-tree.md
+7
View File
@@ -153,6 +153,13 @@ session.
already under `raw/` (§ [When to run](#when-to-run) named the volume/breadth trigger that
put it there). Fill `## Not Extracted` from b.
This includes step 4's commitment question, asked once **per unit** rather than once for
the whole tree: a unit is a subject the same way a single-file `wiki-ingest` source is one,
and whether *this* subject opens or closes a loop is only visible while its own extract is
in front of you - not at the end of the run, once several subjects' worth of content has
gone by. A unit that carries no commitment simply skips the question, the same as any other
source (`wiki-ingest` step 4's own "No commitment either way in this source?").
e. **Publish** this unit alone, then tick its checklist line. One unit, one commit.
Do not start unit *N+1* before *N* is published: later units must be able to see the pages
instructions/wiki-ingest/SKILL.md
+40 -15
View File
@@ -84,19 +84,21 @@ validator complains - and the ticked list is the only record that they happened.
4. **Discuss with the user.** Present the key takeaways and ask: which points matter most,
which entities/concepts to create or update, any specific emphasis - **and whether this
source also carries a commitment**, something to follow up on rather than only record. A
customer complaint, a meeting note with an action item, an offer awaiting a reply: the
knowledge side (steps 6-9 below) and the commitment side are not exclusive, and most
external sources that are not pure reading material carry both.
source also carries a commitment**, in either direction: something to follow up on (it opens
a loop) or evidence that an existing commitment is done (it closes one) - "das Angebot wurde
angenommen", "der Termin hat stattgefunden". A customer complaint, a meeting note with an
action item, an offer awaiting a reply, a confirmation email: the knowledge side (steps 6-9
below) and the commitment side are not exclusive, and most external sources that are not pure
reading material carry one or the other, occasionally both.
Whether a source is actionable at all, and what its next step is, is the user's call - GTD's
own *Clarify* - never a guess from the source's wording alone. Do not create an item on your
own initiative; propose one and let the user confirm or correct it.
own *Clarify* - never a guess from the source's wording alone. Do not create or close an item
on your own initiative; propose one and let the user confirm or correct it.
**If a commitment is confirmed, resolve its project and create the item before continuing to
step 5** - the tracker side settles first, the same order `new project` already holds between
a tracker project and its page, so a failure creating the item leaves nothing promoted and no
page behind it. Search for a likely project rather than asking cold:
**If the source opens a commitment, resolve its project and create the item before continuing
to step 5** - the tracker side settles first, the same order `new project` already holds
between a tracker project and its page, so a failure creating the item leaves nothing promoted
and no page behind it. Search for a likely project rather than asking cold:
```bash
tools/wikitool search "<likely project name>"
@@ -128,8 +130,26 @@ validator complains - and the ticked list is the only record that they happened.
does not exist yet at this moment - it is freetext, never resolved or validated against an
actual page.
No commitment in this source? Skip straight to step 5 - the knowledge side runs on its own
exactly as before.
**If the source instead closes a commitment**, resolve which open item it is and mark it done
before continuing to step 5 - same order, tracker side first. Search for the likely project,
then list its open items to find the one the source closes:
```bash
tools/wikitool search "<likely project name>"
tools/wikitool task list --project "<confirmed project>"
```
Put title and id to the user as **one** combined question - "Close '<title>' (id `<id>`) as
done?" - never a foregone conclusion, the same posture as the opening question above. If
nothing in the list obviously matches what the source describes, say so and leave it open
rather than guessing at an id. Once confirmed:
```bash
tools/wikitool task close --id "<confirmed id>"
```
No commitment either way in this source? Skip straight to step 5 - the knowledge side runs on
its own exactly as before.
5. **Promote from `incoming/` if that is where the file sits.** Read
`raw/CONTRACT.md` "Getting a file in" and "Capture fields" if you have
@@ -304,6 +324,11 @@ validator complains - and the ticked list is the only record that they happened.
- **No project fits the commitment, and none should be created either?** File it into the
tracker's inbox rather than forcing a project choice - see step 4's own three-way choice. Name
the cost (invisible to `wikitool review`) before the user picks it.
- **A source seems to close a commitment, but `task list` shows nothing that obviously matches?**
Leave it - the item may already be closed, may live under a different project name, or the
source may be less conclusive than it first reads. A wrongly closed item is worse than one left
open one more week: it disappears from every later review with nothing to show it was ever
there.
- **One source names far more subjects than usual?** That is breadth, not volume. It is not
split into several sources - it cannot be - and it does not get a page per name either:
`instructions/ingest-large-tree.md` § A broad source is not cut.
@@ -319,9 +344,9 @@ validator complains - and the ticked list is the only record that they happened.
## wikitool commands used
`raw accept`, `search`, `types describe`, `task new`, `new project`, `new source`, `new entity`,
`new concept`, `touch`, `cite add`, `xref add`, `xref link-source`, `sources coverage`,
`sources rebuild-index`, `index rebuild`, `log append`, `log status`, `publish`
`raw accept`, `search`, `types describe`, `task new`, `task list`, `task close`, `new project`,
`new source`, `new entity`, `new concept`, `touch`, `cite add`, `xref add`, `xref link-source`,
`sources coverage`, `sources rebuild-index`, `index rebuild`, `log append`, `log status`, `publish`
## Output