Task queue - add requests or process pending work
A unified entry point for task capture and processing.
Actions:
Core concept: The do action always produces both a UR folder (preserving the original input) and REQ files (the queue items). Each REQ links back to its UR via
user_requestfrontmatter. This pairing is mandatory for all requests — simple or complex.
Capture ≠ Execute. The do action captures requests. The work action executes them. These are strictly separate operations. After the do action finishes writing files and reporting back, STOP. Do not start processing the queue, do not begin implementation, do not "helpfully" transition into the work action. The user decides when to execute — always. The only exception is if the user explicitly says something like "add this and then run it" or "capture this and start working" in the same invocation.
Examine what follows "do work":
Check these patterns in order — first match wins:
| Priority | Pattern | Example | Route |
|---|---|---|---|
| 1 | Empty or bare invocation | do work |
→ Ask: "Start the work loop?" |
| 2 | Action verbs only | do work run, do work go, do work start |
→ work |
| 3 | Verify keywords | do work verify, do work check, do work evaluate |
→ verify |
| 4 | Cleanup keywords | do work cleanup, do work tidy, do work consolidate |
→ cleanup |
| 5 | Version keywords | do work version, do work update, do work check for updates |
→ version |
| 6 | Changelog keywords | do work changelog, do work release notes, do work what's new, do work what's changed, do work updates, do work history |
→ version |
| 7 | Descriptive content | do work add dark mode, do work [meeting notes] |
→ do |
Critical rule: Never lose the user's content.
Single-word rule: A single word is either a known keyword or ambiguous — it is never "descriptive content."
{word}' as a new request, or did you mean something else?"Only route to do when the input is clearly descriptive — multiple words, a sentence, a feature request, etc.
If routing is genuinely unclear AND multi-word content was provided:
These signal "process the queue": run, go, start, begin, work, process, execute, build, continue, resume
These signal "check request quality": verify, check, evaluate, review requests, review reqs, audit
Note: "check" routes to verify ONLY when used alone or with a target (e.g., "do work check UR-003"). When followed by descriptive content it routes to do (e.g., "do work check if the button works" → do).
These signal "consolidate the archive": cleanup, clean up, tidy, consolidate, organize archive, fix archive
These signal "show release notes": changelog, release notes, what's new, what's changed, updates, history
Note: "updates" (plural) routes to changelog display. "update" (singular) routes to update check. Both are handled by the version action.
These signal "add a new task":
do work → "Ready to process the queue?" (confirmation)do work run → Starts work action immediatelydo work go → Starts work action immediatelydo work verify → Evaluates most recent UR's REQsdo work verify UR-003 → Evaluates specific URdo work check REQ-018 → Evaluates the UR that REQ-018 belongs todo work evaluate → Evaluates most recent UR's REQsdo work review requests → Evaluates most recent UR's REQsdo work cleanup → Consolidates archive, closes completed URsdo work tidy → Same as cleanupdo work consolidate → Same as cleanupdo work changelog → Displays changelog (newest at bottom)do work release notes → Same as changelogdo work what's new → Same as changelogdo work updates → Same as changelogdo work history → Same as changelogdo work add dark mode → Creates REQ file + UR folderdo work the button is broken → Creates REQ file + UR folderdo work [400 words] → Creates REQ files + UR folder with full verbatim inputWhen clarification is needed but content was provided:
This enables a two-phase commit pattern:
Follow the detailed instructions in:
