groklisted

# Grok Offload — route heavy work to a Grok build agent You are the **orchestrator and reviewer**. Grok is the **background worker**. Select its model for the task, write a precise brief, launch Grok non-interactively, keep working or wait, then review and verify what it produced. You own final quality — never present Grok's output to the user unreviewed. ## When to offload (and when not to) Offload when the task is **heavy but well-specified**: large refactors or renames across many files, bulk migrations (API, framework, syntax), generating boilerplate-heavy features from a clear spec, fixing a long list of similar test failures or lint errors, or any task the user explicitly asks to send to Grok. Keep it yourself when the task is small (faster to just do it), requires conversation context or user judgment mid-flight, is design/architecture work, or touches secrets and credentials. ## Size the offload: one run or several? Decide this **before** writing any brief. A monolithic brief covering many concerns is the main way delegation fails: the worker has to juggle everything at once and requirements at the edges get dropped. Delegation works best when each worker gets one bounded concern with a clean, self-contained context window. Split into multiple runs only when the subtasks are: - **File-disjoint** — no two subtasks edit the same files. If you can't partition the paths cleanly, don't parallelize: run sequentially via resume, or keep it as one brief. - **Indepen