Why Matt Pocock's /grill-me Beats Superpowers Skills

A five-line AI skill became one of the most talked-about tools in software development. It came from Matt Pocock, a well-known TypeScript educator, and formed part of an open-source collection that attracted enormous attention from developers. At first, the popularity of such a tiny file seems difficult to explain. But its value does not come from the number of words it contains. It comes from the software engineering experience compressed into those words. Matt's project is not merely a collection of prompts. It is a modular workflow designed to control the ways AI commonly fails while building software. The central idea is simple. Generating code is no longer the hardest part. Modern AI can produce code extremely quickly. The real challenge is keeping it aligned with the goal, preventing it from making hidden decisions, and ensuring that the resulting software remains testable and maintainable. AI does not always stop when a request is unclear. It often fills in the missing details itself. But even a simple feature contains dozens of decisions involving validation, permissions, loading states, error handling, unusual inputs, and user behavior. When the human does not make those decisions explicitly, the AI makes them silently. That leads to the first problem Matt wanted to solve. How do you stop AI from guessing what you want? His answer is a skill called grill-me. Instead of allowing the AI to begin coding, grill-me reverses the interaction. The AI questions the human, identifies unclear areas, and follows each decision into its consequences. It asks one focused question at a time and may suggest possible answers, but the final decision remains with the human. The AI is not being asked to become the architect. It is being used to expose all the places where the architecture has not yet been decided. This keeps the developer in control while taking advantage of AI's ability to generate options, identify edge cases, and uncover missing requirements. But clarifying the idea is only the first step, because the next problem is preserving what was decided. A long discussion may produce a clear shared understanding, but that understanding can disappear when the conversation ends. Matt's to-spec skill converts the discussion into a durable specification. The specification records the intended behavior, goals, requirements, and constraints. However, it deliberately avoids including implementation code. That distinction matters because code changes much faster than product intent. If a specification contains detailed code examples, those examples can become outdated and later confuse the AI. The specification should preserve what the system must accomplish, not permanently attach that intent to one temporary implementation. Once the intent has been captured, the next question is how to turn it into manageable work. That is the purpose of to-tickets. AI often divides a project according to technical layers. It might create separate tasks for the database, backend, and frontend. This appears organized, but it means nothing can be properly tested until all three layers are finished. If the database design is wrong, the problem may not become visible until the interface is finally connected. By then, much of the project may depend on the original mistake. Matt instead divides work into vertical slices based on user-facing functionality. One ticket might implement user login from beginning to end. It includes only the database changes, backend behavior, and interface required for that feature. Once complete, login can immediately be tested. The next ticket might implement adding a product to a shopping cart in the same end-to-end way. Each completed ticket produces something usable. Problems appear sooner, progress becomes easier to evaluate, and independent features may be developed in parallel. With the requirements clarified and the work divided, the workflow can finally move into implementation. Matt's implement skill uses test-driven development, or TDD. The key rule is that expected behavior must be defined before the implementation is written. Imagine a checkout rule stating that a customer receives a $100 discount when the cart reaches $1,000. If the AI writes the implementation first and accidentally subtracts $200, it may later create a test that expects the same incorrect result. The code is wrong, but the test agrees with it, so everything appears to pass. The AI has effectively validated its own mistake. Writing the test first prevents this. Before the feature exists, the test establishes that a $1,000 cart must receive exactly a $100 discount. The test initially fails because the implementation has not yet been written. The AI must then create code that satisfies an expectation that was fixed in advance. TDD gives the AI a finish line it cannot conveniently move. Passing tests, however, does not guarantee that the code is well-designed, which leads to the next stage, independent review. After implementation, Matt's workflow starts a code review in a fresh session. This reduces the chance that the reviewing AI will simply defend the assumptions made while writing the code. The review also goes beyond a vague instruction, such as, look for bugs. Matt directs the AI toward recognized software engineering problems. These include shotgun surgery, where one small change requires edits across many files, feature envy, where logic appears to belong in another module, and data clumps, where the same collection of values repeatedly moves through the system and should probably become a single object. These established terms function as compressed instructions. Each one activates a larger body of engineering knowledge without requiring a long explanation. And that same principle explains why Matt's skills can remain so small. His approach emphasizes pruning. Unnecessary sentences are removed, obvious instructions are not repeated, and information-dense terminology is preferred over lengthy descriptions. A strong skill contains clear constraints, useful specialist language, and an explicit definition of completion. The goal is not to write the longest prompt possible. It is to use the smallest amount of language that reliably produces the desired behavior. Even with clearer requirements, tests, and reviews, another problem appears as the project grows. AI-generated systems can become fragmented. AI naturally concentrates on the files immediately in front of it. It may create many small modules that look tidy individually, but force the rest of the application to understand too many internal details. Matt describes these as shallow modules. Consider a checkout process separated into discount calculation, payment validation, order creation, inventory updates, and confirmation email. Those pieces may each be reasonable, but if the main application must coordinate all five operations, the complexity has not truly been hidden. It has only been distributed across more files. A deep module provides one simple interface while hiding substantial complexity behind it. Instead of requiring the application to coordinate every checkout step, the system could expose a single operation, such as process checkout. The internal module still performs all the necessary work, but the rest of the application does not need to understand how. This is particularly helpful for AI because its working context is limited. When related logic is concentrated behind a clear boundary, the model can understand and modify that area without jumping across a large number of files. To support this, Matt includes an architecture improvement skill that looks for opportunities to create deeper modules and improve locality. One useful test is to imagine removing a module. If removing it causes important hidden complexity to spill into the rest of the application, the module is probably valuable. If removing it makes the system simpler, the module may only be an unnecessary layer. By this point, the individual skills begin to form a complete system. grill-me exposes missing decisions. to-spec preserves the agreed intent. to-tickets converts it into testable vertical slices. Implement uses TDD to produce the code. CodeReview checks for established engineering problems. Architecture Improvement keeps the system understandable as it grows. But Matt does not force every project through one rigid sequence. This is a major difference between his approach and more structured frameworks such as superpowers. A fixed workflow can provide useful guardrails, especially when a model needs close supervision. But it can also become restrictive when specifications, tickets, or existing processes are already available. Matt's skills work more like modular building blocks. A developer can use only the parts that are needed. If a specification already exists, the earlier steps can be skipped. If only a code review is required, that skill can be used independently. The workflow supports the developer without taking control away from the developer. And that leads to the broader lesson behind the entire project. Matt Pocock did not make AI coding more reliable by replacing software engineering expertise. He made it more reliable by encoding that expertise into reusable instructions. The skills are effective because they are built on proven ideas about requirements, vertical slicing, testing, refactoring, modularity, and architecture. The files may be small, but the knowledge behind them is substantial. AI can now generate code faster than ever. But someone must still define the goal and make the important decisions. Matt's workflow is not a system for removing the engineer from development. It is a system for keeping the engineer in the driver's seat.