---
id: sm-do-work
name: "do-work"
url: https://skills.yangsir.net/skill/sm-do-work
author: bladnman
domain: automation
tags: ["task-automation", "workflow-management", "productivity-tools", "project-execution", "process-optimization"]
install_count: 293
rating: 4.10 (20 reviews)
github: https://github.com/bladnman/do-work
---

# do-work

> 统一的任务捕获和处理入口，用于记录新任务/请求，并创建相应的文件进行追踪。

**Stats**: 293 installs · 4.1/5 (20 reviews)

## Before / After 对比

### 任务捕获与处理流程对比

## Readme

# do-work

# Do-Work Skill

A unified entry point for task capture and processing.

**Actions:**

- **do**: Capture new tasks/requests → creates UR folder (verbatim input) + REQ files (queue items), always paired, then verifies coverage

- **work**: Process pending requests → plans (with plan verification), explores, builds, tests

- **verify**: Evaluate captured REQs against original input → coverage check with auto-fix (also runs automatically after capture)

- **cleanup**: Consolidate archive → moves loose REQs into UR folders, closes completed URs

**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_request` frontmatter. 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.

## Routing Decision

### Step 1: Parse the Input

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

### Step 2: Preserve Payload

**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."

- **Matches a keyword** in the routing table (e.g., "version", "verify", "cleanup") → route to that action directly.

- **Doesn't match any keyword** (e.g., "refactor", "optimize") → ambiguous. Ask: "Do you want to add '`{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:

- Default to **do** (adding a task)

- Hold onto $ARGUMENTS

- If truly ambiguous, ask: "Add this as a request, or start the work loop?"

- User replies with just "add" or "work" → proceed with original content

### Action Verbs (→ Work)

These signal "process the queue":
run, go, start, begin, work, process, execute, build, continue, resume

### Verify Verbs (→ Verify)

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).

### Cleanup Verbs (→ Cleanup)

These signal "consolidate the archive":
cleanup, clean up, tidy, consolidate, organize archive, fix archive

### Changelog Verbs (→ Version)

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.

### Content Signals (→ Do)

These signal "add a new task":

- Descriptive text beyond a single verb

- Feature requests, bug reports, ideas

- Screenshots or context

- "add", "create", "I need", "we should"

## Examples

### Routes to Work

- `do work` → "Ready to process the queue?" (confirmation)

- `do work run` → Starts work action immediately

- `do work go` → Starts work action immediately

### Routes to Verify

- `do work verify` → Evaluates most recent UR's REQs

- `do work verify UR-003` → Evaluates specific UR

- `do work check REQ-018` → Evaluates the UR that REQ-018 belongs to

- `do work evaluate` → Evaluates most recent UR's REQs

- `do work review requests` → Evaluates most recent UR's REQs

### Routes to Cleanup

- `do work cleanup` → Consolidates archive, closes completed URs

- `do work tidy` → Same as cleanup

- `do work consolidate` → Same as cleanup

### Routes to Changelog (via Version)

- `do work changelog` → Displays changelog (newest at bottom)

- `do work release notes` → Same as changelog

- `do work what's new` → Same as changelog

- `do work updates` → Same as changelog

- `do work history` → Same as changelog

### Routes to Do

- `do work add dark mode` → Creates REQ file + UR folder

- `do work the button is broken` → Creates REQ file + UR folder

- `do work [400 words]` → Creates REQ files + UR folder with full verbatim input

## Payload Preservation Rules

When clarification is needed but content was provided:

- **Do not lose $ARGUMENTS** - keep the full payload in context

- **Ask a simple question**: "Add this as a request, or start the work loop?"

- **Accept minimal replies**: User says just "add" or "work"

- **Proceed with original content**: Apply the chosen action to the stored arguments

- **Never ask the user to re-paste content**

This enables a two-phase commit pattern:

- Capture intent payload

- Confirm action

## Action References

Follow the detailed instructions in:

- [do action](https://github.com/bladnman/do-work/blob/HEAD/./actions/do.md) - Request capture

- [work action](https://github.com/bladnman/do-work/blob/HEAD/./actions/work.md) - Queue processing

- [verify-request action](https://github.com/bladnman/do-work/blob/HEAD/./actions/verify-request.md) - Coverage verification of captured requests (runs after capture, or manually)

- [verify-plan action](https://github.com/bladnman/do-work/blob/HEAD/./actions/verify-plan.md) - Plan coverage verification (runs after planning in the work action)

- [cleanup action](https://github.com/bladnman/do-work/blob/HEAD/./actions/cleanup.md) - Archive consolidation and UR closure

- [version action](https://github.com/bladnman/do-work/blob/HEAD/./actions/version.md) - Version, updates & changelog

Weekly Installs245Repository[bladnman/do-work](https://github.com/bladnman/do-work)GitHub Stars89First SeenJan 27, 2026Security Audits[Gen Agent Trust HubPass](/bladnman/do-work/do-work/security/agent-trust-hub)[SocketPass](/bladnman/do-work/do-work/security/socket)[SnykFail](/bladnman/do-work/do-work/security/snyk)Installed onclaude-code214opencode179codex170gemini-cli166github-copilot131kimi-cli103

---
*Source: https://skills.yangsir.net/skill/sm-do-work*
*Markdown mirror: https://skills.yangsir.net/api/skill/sm-do-work/markdown*