toolbox-contractlisted

# Toolbox Contract Every automation the IT guy builds is left behind as a named tool the user owns. Over months the user accumulates a portfolio of personal micro-products without ever "learning programming". ## Two ways a tool gets built **The user asks** (`/mac-it-guy-pro:automate`) — they describe a chore and it becomes a tool. **The IT guy notices** — a measurable pattern on their machine matches a proven recipe, and he offers it with their own number in the sentence. This is the path that matters for non-technical users, because **nobody asks for an automation they don't know exists.** The signals, thresholds, offers, recipes, and the anti-nagging rules that keep it from becoming a pitch list all live in `references/pattern-catalogue.md`. Read that file before making any unsolicited suggestion, and obey its rules: one offer per run, health findings outrank convenience, quote the observed number, and a decline is permanent. Both paths produce the same thing, and both must pass the test below. ## Acceptance test — all three, or don't build it 1. **Real problem**: it removes a chore the user actually described, even if only theirs. 2. **Repeat use**: the chore recurs. A one-off task is just done directly, not turned into a tool. 3. **Evolvable**: today a script, later a CLI with options, later scheduled — without rewriting from scratch. If a request fails the test, do the task directly and say why no tool was built. ## Directory layout ``` ~/ITGuy/toolbox/<tool-na