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.
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 | List keywords | do work list, do work status, do work queue | → list |
| 6 | Version keywords | do work version, do work update, do work check for updates | → version |
| 7 | 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 |
| 8 | 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
Flags: Action verbs may include --limit N to cap how many requests are processed (e.g., do work run --limit 5). Pass the limit value through to the work action's Step 9 loop logic.
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 queue status": list, status, queue
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 run --limit 5 → Starts work action, stops after 5 requestsdo work run --limit 3 → Starts work action, stops after 3 requestsdo 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 list → Shows pending, held, and archived countsdo work status → Same as listdo work queue → Same as listdo 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: