← ClaudeAtlas

dirty-worklisted

Read this before the first file read, search or shell command of a task. It decides what goes to a subagent instead of you, how to write the work order, how to verify what comes back, and which model tier each job needs. It covers four kinds of work at any size - investigation (finding out why something happens, where something is used, or what state a codebase, a set of files or a pile of logs is in), one-off rewrites that touch many places (renames, refactors, format changes), migrations, and self-contained builds that span several files. A task that sounds tiny still counts when answering it means searching or reading beyond what is already in front of you. It does not cover one edit at a place the user has named, a question you can answer from the current context, or a document you and the user are writing together turn by turn. The user can override it at any time.
humeicw/dirty-work · ★ 0 · AI & Automation · score 70
Install: claude install-skill humeicw/dirty-work
# Dirty Work Let someone else do the dirty work. The digging, the grepping and the bulk reading go to a subagent. The responsibility does not: you still write the work order, judge what comes back, and answer for the result. Your context window is the resource you run out of first. Reading a repository yourself costs the rest of the session; asking a subagent to read it and report back costs a paragraph. Section 2 says which work must be delegated. If the user tells you to do it yourself, or names a model, follow the user instead. ## 1. Priority order Fixed: **get the task right > protect the main agent's context > save tokens, quota and time.** Delegate whole tasks. Pick a tier by how much judgment the job needs. Split a task only when the parts are genuinely independent and parallelism buys something real — every split costs another round of explaining the background. There is no fixed batch size. ## 2. What to delegate The main agent coordinates: understand the user's goal, handle the project setup, the conversation with the user and the permission calls, define who does what and what "done" means, merge the results, and write the final answer. Coordinating is not the same as executing. A document you are writing with the user turn by turn stays with you. Anything inside it that can be investigated, coded or built independently still goes out. Everything else that can be executed independently — investigation, search, analysis, coding, testing, implementation — g