I came across a video by Matt Pocock where he described a skill he calls “grill me” — a simple but powerful concept: interview me relentlessly about every aspect of this plan until we reach a shared understanding. I found it immediately compelling.
In the video, Matt mentions Fred Brooks’ The Design of Design as the inspiration. I hadn’t read it, so I asked Claude to summarise the key concepts and show me how they could apply to building better skills. The two things collided, and I ended up spending an evening turning that seed into something more structured. This is a writeup of what came out of that conversation and why I think this pattern is worth stealing.
What Fred Brooks Gets Right
Brooks’ book isn’t a recipe book. It’s a collection of essays grounded in his experience leading IBM’s System/360 — and it’s surprisingly opinionated. A few things stuck with me:
Constraints are a gift. Brooks argues that reducing the design space actually makes problems easier to solve. A problem with no constraints has no criteria for excellence. When you’re designing something, state the properties you need — not how to achieve them.
Conceptual integrity is everything. A system should look like one mind designed it. The challenge of team design is maintaining that integrity. This is why the chief-architect model works, and why committees usually produce monstrosities.
Brainstorming is overrated. Brooks cites a controlled experiment at Sandia Labs where individuals significantly outperformed groups across originality, feasibility, and effectiveness. Groups generate more quantity. Not better quality.
Study exemplars, not just principles. The biggest obstacle to educating great designers is the absence of continued practice and critique. Build a personal library of designs you admire. Study them.
Reading this book alongside Matt’s “grill me” skill made me realize: a well-structured interrogation is exactly what Brooks is advocating for. It forces constraint-setting. It surfaces assumptions. It tests conceptual integrity before you’re three months into building.
The Original Seed
Matt’s original skill is terse — deliberately so. Here’s the gist:
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. If a question can be answered by exploring the codebase, explore the codebase instead.
It’s a great starting point. But it lacks structure around how to conduct the interview, when to go deeper versus move on, and what the output should be. It also treats all designers the same, which they aren’t.
Product vs Architecture: Two Different Interrogations
The first thing I realised is that a product person and an engineer need to be grilled on fundamentally different things.
- A product person needs to be interrogated on why and for whom. What’s the actual problem? Who has it badly enough to change their behaviour? Would anyone pay for this?
- An engineer needs to be interrogated on how and what breaks. Where are the boundaries? Which decisions are reversible? What are the failure modes?
The design tree structure is the same, but the questions diverge completely. This became two separate skills: Grill Me: Product and Grill Me: Architecture.
Drawing from Other Books
The one book in this list I’ve actually read is A Philosophy of Software Design. For the rest, I asked Claude: what books have extractable interrogation frameworks — not just good ideas, but principles that could translate into structured questions? It gave me a shortlist with explanations, and I folded the ones that clicked into the skills.
“A Philosophy of Software Design” by John Ousterhout — complexity is the root of all evil, creeping in through shallow modules, information leakage, and temporal decomposition. This translates directly into questions: Is this module deep or shallow? Where is information leaking between layers? Are you decomposing by time or by knowledge?
“Thinking in Bets” by Annie Duke — separating decision quality from outcome quality. Assign confidence levels to your assumptions. Identify what information would change your mind. Distinguish between reversible and irreversible bets. This is exactly what a good design review does.
“The Mom Test” by Rob Fitzpatrick — almost entirely a book about asking better questions and refusing to accept flattering answers. Don’t pitch. Ask about past behaviour, not future intentions. Find the scary question and ask it first.
“Are Your Lights On?” by Gause & Weinberg — about problem definition. The key move: keep asking “whose problem is this?” and “what is the problem, really?” before anyone touches solutions.
On the architecture side, “How Buildings Learn” by Stewart Brand maps beautifully to software via his shearing layers concept — site, structure, skin, services, space plan, stuff. Each layer changes at a different rate. The question it inspires: Are you coupling things that change at different rates? And “Systemantics” by John Gall is perfect stress-test material: a complex system that works is invariably found to have evolved from a simple system that worked.
The “Nudge Your Human” Principle
Here’s the insight I’m most proud of from this conversation: the skills shouldn’t just be good at asking questions — they should be good at teaching the user how to feed the agent.
Most people underestimate how much context an AI agent needs. They have all the context in their head and forget the agent doesn’t. You can ask brilliant questions, but if the answers are vague because the human didn’t think to bring the right material, you’re interrogating shadows.
Both skills now open with Phase 0: Help Me Help You. Before the interrogation starts, the skill coaches the user on what to share.
For product people, that means:
- Similar features or products the team has already shipped, including post-mortems
- Raw user research — even informal stuff like Slack complaints or support tickets
- Competitive products they’ve personally used
- Stakeholder expectations and promises that constrain the design space
For engineers, it means:
- Adjacent codebases and services (critical in microservice architectures)
- API contracts, schemas, or docs for the other side of service boundaries
- Incident history and post-mortems
- Traffic patterns, scale numbers, and performance characteristics
- Prior design docs, RFCs, or ADRs
The framing I landed on: “Think of me as a senior hire on your team — what would you show me on my first day to get me up to speed?”
Adaptive Outputs: Matching the Deliverable to the Stage
The final piece: the output should match where you are in your journey. A grilling session that produces a great conversation but no artifact is a waste.
The skills ask one routing question before producing output: “What happens next?”
For product work:
| Stage | Output |
|---|---|
| Still exploring | One-pager to take to a stakeholder meeting |
| Ready to spec | Full PRD with success criteria, scope, and risks |
| Ready to build | PRD + dependency-ordered GitHub issues |
For architecture work:
| Stage | Output |
|---|---|
| Investigating | ADR with confidence map and open questions |
| Ready for review | Full technical design doc |
| Ready to build | Design doc + GitHub issues, spikes separated from implementation |
The principle for any backlog output: every issue includes a verification criterion (not just “implement X” but how you know it’s done), spikes are separated from implementation tasks, and the first issue targets the riskiest or most uncertain piece.
The Broader Philosophy
This exercise surfaced something I’ve been thinking about more generally: the best agent skills target forever-foundational aspects of software development. Code review, planning, security audits, design interrogation — these problems existed before AI agents and will exist after whatever model comes next. The agent just makes it cheaper to apply rigour consistently.
There’s a trap in building “AI space factories” — over-engineered, model-specific tooling that will be obsolete in months. The best skills are simple, durable, and teach good practice rather than enforcing a specific workflow.
And here’s the compounding return: every new model will get better at following good instructions. Investing in well-structured skills is investing in something that appreciates in value as models improve, rather than depreciating like specific tooling integrations.
The Skills
Both skills are available in my dot-files repository, and were directly inspired by Matt Pocock’s original “grill me” skill.
Each follows the same structure:
- Phase 0: Help Me Help You — coach the user on what context to share
- Phases 1–3: Rigorous interrogation — phased questioning drawing from Brooks, Ousterhout, Fitzpatrick, Duke, Singer, Brand, and Gall
- Phase 4/5: Adaptive output — deliverable matched to the user’s stage
If you’re using Claude Code, you can drop them straight into your .claude/skills directory and invoke them with /grill-me-product or /grill-me-architecture. Point the skill at your plan, your RFC, your Notion doc — and let it find the holes before your stakeholders do.
These skills were built during a single conversation with Claude on mobile. If you’re interested in the methodology for building skills like this — or want to share what you’ve come up with — reach out on Twitter.