A developer shares reusable text expansion macros that encode structured agent instructions for screenshots, parallel subagent fanouts, build loops, and atomic git commits.
Adapted from @buddyhadryusing text expansion in your agent workflow is like adding another layer below skills :screenshot = expands to the full path of my most recent screenshot. :fanout = Fan this out across parallel subagents. Before spawning any, state the split: how many branches, what slice each gets, why the slices don't overlap, and what the split deliberately leaves uncovered — branches fed the same context agree for the wrong reason, and an unstated gap reads as coverage. Give every branch the same fixed return shape and a budget; prose back or a blown budget is a failed branch, and every failed, empty, or timed-out branch gets named in the result, never quietly dropped. State the join rule before launch (union / dedup on <key> / majority / first valid) and apply it mechanically, not by impression. Don't grade results with the context that requested them: a finding survives only if checked independently — against deterministic evidence where any exists, another model's judgment only where none does. :aloop = Build this out fully, then loop: run the real build, lint, typecheck, and tests, fix whatever fails, and re-run until every gate is actually green — never stop at "should work" or "looks right." Never weaken, skip, or delete a check to force a pass; a failing gate means fix the code, not the test, then self-review the diff for anything the gates won't catch (debug leftovers, dead branches, drift from the ask). Report the exact commands and live output proving it's green, not assumptions. If the same failure keeps recurring with no new information, stop and report it as a blocker instead of forcing it through. Treat the pass count as a budget: if green isn't clearly within reach after several passes, pause and report progress and what remains — slow grinding is a quieter blocker, not persistence. :gacp = git add, commit, and push as surgical atomic commits — one commit per logical change, never one batch. Review the diff and split by concern (logic, API/wiring, UI, tests, docs, config, refactors); stage each selectively with git add -p or explicit paths — never git add -A into one commit. Each commit stands alone: independently revertible, one precise message (no "and"/"also"). N concerns → N commits; when unsure, split. What do you use?
