I sat down to help a teammate fix her workflow. She ended up fixing mine. You've seen the follow-up email skill I built. Last week a sales director reached out to sharpen hers. Generic emails, a few bullets pasted from the call, nothing a busy clinic owner would actually read. But she knew something I'd half-missed: ProShort (call recording tool) pushes all the call data into HubSpot's structured fields. Turns out we were both underusing the same data, from opposite ends. She was pulling a fraction of those fields. I was manually copy-pasting context that was already sitting in them. 95% of my manual step, gone. One conversation. Her output picked up my case study library and copywriting skill. My build dropped the copy-paste it never needed. I was too heads-down in my own version of the problem to see it. Took someone solving it from a different angle to surface the blind spot. ⸻ If you want the build side, here's how it actually works. Two skills, split on purpose. One fetches, one writes. The email skill you saw before is the writer. It takes the deal context and turns it into a case-study-anchored follow-up. But it was only ever as good as what I pasted into it by hand. The new piece I'm sharing below, deal context, is the fetcher. It pulls the call notes straight from the CRM, finds the right one, strips the duplicate copies and the empty stubs, and hands the writer a clean, structured intake. No paste. Why split them instead of one big skill? Leverage. The fetcher is shared infrastructure. The email skill uses it today; re-engagement and day-prep use the same one next. Build the context layer once, every writer on top of it gets smarter. It also makes them easy to fix. Last week I caught a bug in how it resolved "wrap Friday" — it pulled the wrong day. Fixed it in the fetcher alone, never touched the email skill. One job per skill means when something breaks, you know exactly where to look. A fetcher that gets the context right. A writer that does one thing well with it. That's the whole idea.