You hire someone, hand them a client presentation, tell them they are not allowed to ask a single question, and promise to fire them if the first draft is bad. Nobody runs a team that way, yet it is roughly how a lot of us hand work to Claude and ChatGPT, then forward whatever comes back to a customer. This one is for anyone whose company is starting to drown in AI output nobody checked, and for the leaders tempted to ban the tool because of it.

The problem starts before the prompt. Most knowledge work is tacit: you know how to do it until you have to explain it, which is the illusion of explanatory depth, so the ask stays vague and the model fills the gap. Chris shows what that looks like with one plain Opus 5.5 prompt for the Said and Unsaid newsletter, which came back with placeholders and a guessed format, then walks through /saidandunsaid, an orchestrator skill with no logic of its own. It calls research, outline, draft, a fresh-subagent cold read, image and render subskills, and a human picks the story at the start and reads the draft at the end.

Then it moves into the enterprise: where organizational skills live in Claude under Customize, why a skill your company already published beats one you build yourself, and why banning AI after a bad draft pushes the work into shadow AI, which IBM's 2026 breach report ties to 43% of breaches. Sash adds the recipe-book view: you never have to write a skill file by hand. Have Claude interview you with the skill creator, or take a plugin someone else built and customize it.

Key takeaways:

• Make your AI ask you questions before it builds anything - say so in the prompt, or use a brainstorming or grill-me style skill that does it for you.
• Turn any task you repeat into a skill: the instructions, the rules, and two or three examples of output you consider good.
• Keep the orchestrator free of logic: one top-level skill that only calls subskills, so you can change or reuse one step without breaking the rest.
• Before you build a skill at work, open Customize, then Skills, and check the Organization section - a team may already have built it.
• Don't ban AI after one bad draft. Make a named person accountable for what ships, and give them skills that make good output the default.

Watch the video version on YouTube · Full show notes, transcript + takeaways

You have wanted to try Linux for years, and you quit in the same place every time: the install, the hotkeys, and all the ways to break the thing before you have done anything with it. After 20 years deep in Windows internals and three on a Mac, Sash hit exactly that wall, then installed Omarchy, DHH's Arch and Hyprland desktop, on a dusty Lenovo ThinkCentre off the SD card in his Sony a6000, because no USB stick in the house held six gigs. It installed in under five minutes. The first thing he did was open Codex inside it.

Omarchy ships nine agent CLIs pre-wired, Claude Code, Codex and Hermes among them, and a hotkey that launches whichever one you make the default. From there every change started as a sentence. Codex taught him the tiling hotkeys in about 20 minutes by moving the windows itself, built an app launcher bar in five, named his workspaces (Build, Comms, Studio, OS, Flex), and embedded a four-time-zone world clock in the bar. Asked what it knew about the system, it surfaced the agent skills Omarchy installs on disk: manuals for building plugins and widgets, for updating, and a crash flow where a pop-up hands the failed process straight to your default agent to read the logs and debug. When an OS update threatened 48 hours of customization, Codex built a private Git repo of the config and an update hook that backs up, updates, reviews what landed, and reloads.

The bigger point is DHH's "malleable OS": the agent is not an app running on the operating system, it can reach the source, so your Omarchy and someone else's end up genuinely different machines. It also runs on hardware the big vendors have stopped supporting, including M1 and M2 Macs, at a moment when a Mac mini has a 12-week wait. It is not set-and-forget computing - this is for people who want the customization and will own it. Sash is buying a KVM switch to make it his daily driver.

Key takeaways:

• Check the closet before you buy an agent machine. Omarchy installed in under five minutes on an old i7 ThinkCentre with 16 GB of RAM, and it runs on M1 and M2 Macs that can no longer take the latest macOS.
• Use the agent as a tutor before you use it as a builder. Ask it to walk you through the hotkeys and let it move the windows while you watch - that is how Sash learned tiling in 20 minutes.
• Ask the agent what skills and context it has on the system before you ask it to change anything. On Omarchy that question surfaced the built-in manuals for plugins, widgets, updates and crash diagnosis.
• Have the agent build its own safety net before you customize heavily: a private Git repo of your config and an update hook that backs it up, updates, and reloads what the update touched.
• Find a USB stick with at least six gigs before you start, or an SD card adapter. Sash lost 90 minutes to that alone.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Your shipping carrier sends a bill. Your invoicing system sends invoices. Nobody has ever compared the two, because the systems were never connected and the reconciliation was a spreadsheet import somebody did by hand. Drummond's CIO pointed an MCP at both sides, extrapolated a year out, and found more than $600,000 in shipping charges the company had absorbed and never passed on to its clients. The same tooling caught carrier overcharges worth filing claims against.

Chris Brock runs IT for a 90-year-old family-owned commercial print and fulfillment company in Atlanta and Jacksonville, just under $100 million in revenue, where the industry-standard ERP has atrocious reporting and a lot of the data going in is hand-typed. The working pattern is specific and repeatable: build an MCP over whatever legacy API or Postgres connection exists, plan on a frontier model, then hand that written blueprint to a cheaper model to execute inside explicit "only work in these lanes" guardrails. In CI/CD, agents security-check and end-to-end test other agents before a developer signs off. Licensing is centralized and allocated mainly to IT and some management, less for cost than for the MSA problem: a CSR dragging a customer-address CSV into an open model is a real contractual exposure. Nothing runs lights-out. Every process still has a human on green light, red light.

The part that answers the budget question is what happens after the win. A hard-dollar number converts the next AI request from a forecast into a case study, and it changes how you can approach a department. Lead with evidence of what a prior automation actually recovered and people stop hearing "we are automating you out of a job." The distinction Brock draws is between busy and strategic, not between human and machine.

Key takeaways:

• Reconcile two systems nobody has ever compared, such as a carrier bill against your own invoices, and extrapolate a year out before you ask for any AI budget. That is where the hard-dollar number comes from.
• Plan on a frontier model, then hand the written blueprint to a cheaper model to execute. Put the "only work in these lanes" constraints in writing first, because an unconstrained agent gets a mile down the road before you catch it.
• Put an agent on your agent. Security-check and end-to-end test the output in CI/CD before a developer ever sees it for sign-off.
• Build the MCP over the legacy system rather than waiting for better reporting. Most old software still exposes an API or direct Postgres, which is enough.
• Lead a funding ask with money you already recovered, not a productivity estimate, and open the same way when you go hunting for automatable work so the department does not get defensive.

Watch the video version on YouTube · Full show notes, transcript + takeaways