From 62d91e3cb20bfffb79329cb0acd0b913d8a08787 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Thu, 21 May 2026 20:42:56 -0400 Subject: feat(workflows): tag <=30min tasks :quick: during task review I added a per-task effort check to the task-review walk. If a task looks like 30 minutes or less and isn't already tagged, mark it :quick: on the heading. When the heading and body don't make the effort clear, ask instead of guessing. A mislabeled :quick: defeats the point, since the tag exists so Craig can grab a genuinely small task in a spare moment. I edited the canonical claude-templates copy and the synced project mirror together, so the next startup rsync won't revert them. --- .ai/workflows/task-review.org | 9 ++++++++- claude-templates/.ai/workflows/task-review.org | 9 ++++++++- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/.ai/workflows/task-review.org b/.ai/workflows/task-review.org index febb986..6a9a266 100644 --- a/.ai/workflows/task-review.org +++ b/.ai/workflows/task-review.org @@ -55,6 +55,12 @@ Then take the tasks one at a time, in list order. For each, show Craig the headi Keep is the common case — most tasks are still right and just need re-stamping. Be decisive and quick; this is a 5-minute habit, not a planning session. +*** Tagging =:quick:= — small tasks + +While reviewing each task, estimate its effort. If you judge it *30 minutes or less* and it doesn't already carry =:quick:=, add the tag to the heading line. If the heading and body don't tell you how long it'll take, *ask Craig* — don't guess. A wrong =:quick:= is worse than none: the tag exists so Craig can grab a genuinely small task in a spare moment, and a mislabeled one wastes that moment. + +This is orthogonal to the action chosen — a task can be kept (or re-graded, or marked DOING) *and* tagged =:quick:= in the same pass. Skip the assessment on a Kill, since it's leaving the pool. Tags go on the heading line per [[file:../../claude-rules/todo-format.md][todo-format.md]], sharing one =:tag1:tag2:= cluster. + *** Stamping =:LAST_REVIEWED:= Set =:LAST_REVIEWED:= to today's date (from above) in the task's =:PROPERTIES:= drawer: @@ -80,7 +86,7 @@ Follow the completion rules in [[file:../../claude-rules/todo-format.md][todo-fo When the batch is done (or Craig calls it early): -1. Summarize what changed — re-grades, kills, anything marked DOING — in a couple of lines. Don't list the keeps individually; "the rest were confirmed as-is" is enough. +1. Summarize what changed — re-grades, kills, anything marked DOING, anything newly tagged =:quick:= — in a couple of lines. Don't list the keeps individually; "the rest were confirmed as-is" is enough. 2. The edits are already written to =todo.org=. If Craig keeps =todo.org= open in Emacs, remind him to revert the buffer so his editor picks up the changes (and flag that any unsaved edits he had open could collide — re-running picks up whatever's on disk). * Common Mistakes @@ -91,6 +97,7 @@ When the batch is done (or Craig calls it early): 4. *Turning it into planning* — this is hygiene (is each task still right?), not "what should I do today". For that, use =open-tasks.org=. 5. *Drifting the date format* — =:LAST_REVIEWED:= must be =YYYY-MM-DD=, or the staleness script won't read it. 6. *Marking a kill DONE instead of CANCELLED* — DONE means finished, CANCELLED means abandoned. A task review kills tasks that shouldn't be done at all. +7. *Guessing a =:quick:= estimate* — if the heading and body don't make the effort clear, ask Craig instead of tagging on a hunch. A mislabeled =:quick:= defeats the tag's purpose. * Living Document diff --git a/claude-templates/.ai/workflows/task-review.org b/claude-templates/.ai/workflows/task-review.org index febb986..6a9a266 100644 --- a/claude-templates/.ai/workflows/task-review.org +++ b/claude-templates/.ai/workflows/task-review.org @@ -55,6 +55,12 @@ Then take the tasks one at a time, in list order. For each, show Craig the headi Keep is the common case — most tasks are still right and just need re-stamping. Be decisive and quick; this is a 5-minute habit, not a planning session. +*** Tagging =:quick:= — small tasks + +While reviewing each task, estimate its effort. If you judge it *30 minutes or less* and it doesn't already carry =:quick:=, add the tag to the heading line. If the heading and body don't tell you how long it'll take, *ask Craig* — don't guess. A wrong =:quick:= is worse than none: the tag exists so Craig can grab a genuinely small task in a spare moment, and a mislabeled one wastes that moment. + +This is orthogonal to the action chosen — a task can be kept (or re-graded, or marked DOING) *and* tagged =:quick:= in the same pass. Skip the assessment on a Kill, since it's leaving the pool. Tags go on the heading line per [[file:../../claude-rules/todo-format.md][todo-format.md]], sharing one =:tag1:tag2:= cluster. + *** Stamping =:LAST_REVIEWED:= Set =:LAST_REVIEWED:= to today's date (from above) in the task's =:PROPERTIES:= drawer: @@ -80,7 +86,7 @@ Follow the completion rules in [[file:../../claude-rules/todo-format.md][todo-fo When the batch is done (or Craig calls it early): -1. Summarize what changed — re-grades, kills, anything marked DOING — in a couple of lines. Don't list the keeps individually; "the rest were confirmed as-is" is enough. +1. Summarize what changed — re-grades, kills, anything marked DOING, anything newly tagged =:quick:= — in a couple of lines. Don't list the keeps individually; "the rest were confirmed as-is" is enough. 2. The edits are already written to =todo.org=. If Craig keeps =todo.org= open in Emacs, remind him to revert the buffer so his editor picks up the changes (and flag that any unsaved edits he had open could collide — re-running picks up whatever's on disk). * Common Mistakes @@ -91,6 +97,7 @@ When the batch is done (or Craig calls it early): 4. *Turning it into planning* — this is hygiene (is each task still right?), not "what should I do today". For that, use =open-tasks.org=. 5. *Drifting the date format* — =:LAST_REVIEWED:= must be =YYYY-MM-DD=, or the staleness script won't read it. 6. *Marking a kill DONE instead of CANCELLED* — DONE means finished, CANCELLED means abandoned. A task review kills tasks that shouldn't be done at all. +7. *Guessing a =:quick:= estimate* — if the heading and body don't make the effort clear, ask Craig instead of tagging on a hunch. A mislabeled =:quick:= defeats the tag's purpose. * Living Document -- cgit v1.2.3