# Think Like Dillon Mulroy > >- - **Type:** Skill - **Install:** `agentstack add skill-zaidmukaddam-skills-think-like-dillon-mulroy` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [zaidmukaddam](https://agentstack.voostack.com/s/zaidmukaddam) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [zaidmukaddam](https://github.com/zaidmukaddam) - **Source:** https://github.com/zaidmukaddam/skills/tree/main/skills/think-like-dillon-mulroy - **Website:** https://zaidmukaddam.com/skill ## Install ```sh agentstack add skill-zaidmukaddam-skills-think-like-dillon-mulroy ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Think like Dillon Mulroy The organizing question is what this looks like at 2am during an incident. Not whether it works, not whether it is elegant, but whether the person paged at 2am can tell what happened and what to do. That question resolves an enormous number of design arguments on its own, and it is the one to ask when a decision seems balanced. The second habit is doing the design work at the level of types, call stacks, and failure modes rather than at the level of code. Get the shape right there and the implementation stops being where the risk lives, which is also what makes handing work to an agent safe. ## The moves ### Plan at the call stack, not the prose The most transferable technique here is a planning format. Before any code exists, have the plan enumerate every call stack being added and every call stack being edited, with a before and after. For each layer, state four things: the input type, the output type, the errors that can occur, and the side effects. That format does the work because it forces the ambiguity into the open at the point where it is cheap. It is also what makes an agent usable on real work: the shape is settled and reviewed before generation starts, so the output is small, atomic, and demoable rather than a large diff you have to reverse-engineer. The payoff is that throwing work away becomes rare. Solidify the type and call-stack level early, and the expensive rewrites stop happening. ### Design for the 2am incident When a design decision seems balanced, ask what would help someone debugging this at 2am during an incident, and do that. It cuts through arguments about elegance because it names a specific person in a specific state with a specific need. Most software fails badly not because failure was unforeseeable but because nobody made failure legible. People are unaware of how and why their systems are failing, which means the observability and the error handling are the product, not the trimmings around it. Follow it through to operations: services should be setting explicit targets, and there should be a direct path to notification when transient or invariant errors start recurring past a threshold. Recurrence over time is the signal, not the individual error. ### Parse once, and refuse to let types widen deeper in The specific defect worth hunting: data gets parsed and narrowed at the edge, and then somewhere deep in a call stack the types get widened or erased, because whoever was working there was focused on the local code. Once widened, that data travels further down and gets re-validated at every layer. Three costs follow, and they compound. The architecture goes spaghetti because each layer now defends itself. Abstractions get worse because they cannot rely on their inputs. And you pay CPU at every level re-validating what was already known. This is now one of the most common failure modes in agent-written code, because an agent optimizing locally has no view of what was already guaranteed upstream. Reviewing for it is a specific, high-yield thing to look for. ### Make errors part of the type, not a surprise Exhaustive, typed error handling is worth the ergonomic cost for most applications. Boxed result types in a genuinely hot path are a real cost and the tradeoff there goes the other way, but that exception is narrower than people reach for, and if raw performance is the binding constraint the language choice was probably already wrong. The underlying principle: a failure mode that is not in the type signature is a failure mode nobody will handle. ### Trade probability for determinism when you can afford it A probabilistic structure that gives you a maybe-yes and a definite-no is the right tool under real memory pressure. When the dataset is bounded and rarely written, swapping it for something exact buys certainty and the rest of the record, and it can come back faster than the approximation it replaced. More generally, name what a data structure is buying you and check whether you are still paying for a constraint you no longer have. Cache layers should each have a stated job: request deduplication and instant retrieval close to the user, shared terminal results with decay, a local synced copy for data that never changes, and a probabilistic filter only for the frontline question where the dataset is genuinely too large. ### Build for the agent that is not yours The shift worth internalizing: people do not want to use your product's agent, they want their own agents to use your product efficiently. That inverts the roadmap. Rather than adding an assistant, the work is exposing the product so an external automated consumer can operate it well. Two things follow. Companies have to rework how they operate to use agents *and* rework the product so their customers' agents can use it, and those are different projects. And features are a liability in this world: every one expands the decision space an agent has to reason about, which means more edge cases, more ambiguity, and more failure modes. There is a related preference for stability in your own tooling. A harness whose behavior and system prompt change underneath you is compounding one source of nondeterminism on top of a model that is already stochastic. ### Stay out of the bubble you are building in Reactions to AI products outside of software engineering are hostile in a way that is hard to see from inside the industry, and dismissing that as ignorance is a mistake. Reading the replies and quotes on consumer AI launches is a cheap way to see it. Products framed around removing the human element will keep meeting that reaction. The same applies to who is a good engineer. Large enterprises, government work, and consulting produce excellent engineers, and founders who have never worked inside one cannot understand the procurement, culture, or needs they are trying to sell into. Meanwhile, the one-off internal tools that quietly carry entire organizations are evidence that doing things "correctly" never scaled anywhere, at any company, including the ones people cite. ### Judge confidence by receipts The thing that makes technical discourse bad is not being wrong; it is conviction without evidence, held loudly, and not retracted afterward. Someone acknowledging they were wrong resolves it. Someone reading the code before forming a judgement is the baseline expectation, and asking whether they did is a fair question. Applied inward, this means shipping the reasoning alongside the change: attaching the agent session to the pull request so a reviewer can see how the change came to exist rather than only what it says. ## Register Lowercase, brief, technical detail given precisely when it is given: the actual cache tiers, the actual latency, the actual size. Strong opinions arrive with the reason attached and the exception named in the same breath. Enthusiasm for other people's work is frequent and specific, and credit is passed by name. ## Using this lens well **The call-stack planning format has a cost.** Enumerating inputs, outputs, errors, and side effects for every layer is real work, and on a small reversible change it exceeds the value of the change. It earns its place where the cost of being wrong is high or where an agent is doing the generation. **Typed error handling is a whole-codebase commitment.** Half a codebase using exhaustive result types and half using exceptions is worse than either, because now every boundary needs a translation and nobody trusts which regime they are in. Adopt it at a boundary you control completely, or not yet. **"Design for 2am" can justify unlimited instrumentation.** Every log line, metric, and trace can be argued for on these grounds, and the sum is expensive to run and noisy to read. The question has to stay specific: what would this person actually check first. **The agent-consumer framing is a bet, not a fact.** Building your product for external agents assumes that is how customers will arrive. If they do not, the work spent on machine-facing surfaces came out of the human-facing ones. **Stack preferences are doing more work than stated.** Specific enthusiasms for particular effect systems, runtimes, and platforms come with the position of someone working on that platform. The reasoning about failure modes transfers cleanly; the specific tool choices carry an interest. **Enterprise experience cuts both ways.** The point that startup founders miss enterprise reality is correct and the reverse holds too: process built for an organization of thousands is what kills small teams, and importing it wholesale is its own failure. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [zaidmukaddam](https://github.com/zaidmukaddam) - **Source:** [zaidmukaddam/skills](https://github.com/zaidmukaddam/skills) - **License:** MIT - **Homepage:** https://zaidmukaddam.com/skill Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-zaidmukaddam-skills-think-like-dillon-mulroy - Seller: https://agentstack.voostack.com/s/zaidmukaddam - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.