Have you ever tried to build something with AI and it just never builds what you actually want? Part of that reason is because AI doesn’t have the full context, the full story of what you’re trying to create. If you could somehow embed everything you want to build, typographies, colors, functionalities, directly into the AI’s brain, there’s no way it would build applications with the lowest accuracy. But the process of collecting that context is really challenging because the AI doesn’t know what context to collect. Luckily, there’s actually a skill for that. It’s called the grooming skill, and currently that skill is the second most downloaded of all time on the skill leaderboard. Essentially, what the skill does is interview you relentlessly to collect that context for you and embed it into the AI’s brain so it can build applications with the highest accuracy.
That skill was created by a person named Matt PCOG, who’s an expert in the web development application space. Most people know him because of the grooming skill, but he’s actually created tons and tons of skills, over 51 skills with more than 13 million downloads across everything he’s built. So let’s go over exactly what those skills are, how to use them to build applications with the highest accuracy, how they work behind the scenes, and how they’re different compared to skills we’ve already talked about like GStack, Sue Howowers, and GSD.
Why Matt PCOG Built His Skills Differently
First, let’s talk about why he actually built these skills. What’s the motivation? Matt thinks that yes, AI can build things really fast nowadays, but the accuracy it generates is really random. He sees AI as kind of a black box where you give it a prompt, give it instructions, let’s say “build me a checkout page”, and sometimes it gives you what you want, sometimes it doesn’t. Often it gives you different styles, different functionalities than what you initially imagined. That’s why he builds skills like the grooming skill, two specs, or two tickets: to control that AI randomness, to harness the agent for that output randomness.
Obviously, he’s not the first one building these skills. We already have skills like GStack, Sue Powers, and GSD that are really popular in the AI space. But here’s the thing Matt doesn’t really like about those skills: they kind of take over the entire pipeline and every one of them wants you to follow the whole process start to finish. For example, GStack has a brainstorming session, an auto plan skill, an office hour skill, and GSD has a skill where you break things into different phases. Every skill is chained to each other. There’s a dependency. So if you trigger skill number two and it goes wrong, and you realize maybe you need to adjust at skill number six, and then you want to maneuver the direction of the project development, you have to rerun the entire pipeline again. There’s no way to just trigger step two and rerun the process. The whole process is chained together and you can’t break it.
Matt’s approach is completely different. He thinks we should break skills into very modular pieces that we can trigger in any order we want. Rather than one big framework where changing one thing breaks the entire process, we build smaller skills that are modular and reusable. If you finish the implementation skill, you can still trigger the two spec skill, and after you’re done with that, you can still trigger the real skill, and the order you trigger those skills can be anything. That’s why Matt PCOG’s skills are really different compared to a lot of those traditional spec-driven development frameworks.
The Groom Me Skill: Five Rules That Interview You Relentlessly
Now let’s look at the most popular skill he created: the groom me skill. Like I said, it’s the second most downloaded skill ever from the skill leaderboard. And to put it in perspective, the skill itself is very, very short, only a couple of lines. I’ve summarized the entire skill into five rules.
Rule one: Relentlessly. Until the AI agent and yourself reach a shared understanding, it’s going to relentlessly, continuously, ask more questions until both of you reach that shared understanding.
Rule two: The decision tree. Every time it asks a question, it only tackles one branch at a time. It’s not going to ask you one question about the checkout page, one question about the about page, and one question about the dashboard page all over the place. It focuses on one branch, one decision at a time, checkout page. Once that’s fully cleared out, then it moves on to another page or another decision.
Rule three: One at a time. It waits for your answers before it asks you another question.
Rule four: Recommend one. It never hands you a blank question. It gives you recommendations and options you can choose from.
Rule five: Do not act. It has to wait for confirmation before it can act.
That whole process is kind of like a decision machine. The model supplies you with options, you decide, and the decisions stack on top of each other. Every decision it makes just continues to ask more questions until there are no more questions left in the decision tree itself. That’s pretty much the grooming skill.
The Two Spec Skill: Freezing Your Decisions Without Code
After you build a consensus between the agent and yourself, the next thing you need to do is write it down. If you just close the conversation, everything you talked about, all 18 questions, all the grilling sessions, is gone. That’s why the two spec skill freezes that, or converts it into a spec, an overall design plan on exactly how you’re going to implement things.
What makes this skill really different compared to other two spec skills from spec-driven development frameworks is that Matt enforces this skill to never put any code block in the MD file itself. There could be really highly technical stuff, but he never wants to put any code in the spec. Why? Because if you put code in the spec, the agent is going to follow that code. But what if that code is outdated when you actually start building? The spec without code is a lot cleaner, and it forces the AI agent to look at the code, cross-reference it, and make better decisions on what’s right. It doesn’t make sense to put code in the spec.
The Two Tickets Skill: Slicing by Feature, Not by Layer
The two ticket skill is exactly what the name says: converting what’s in the spec into actual tickets the agent can perform. But the way it groups those tickets, or breaks the spec into different tickets, is also very different compared to any other spec-driven frameworks.
Instead of grouping by layer, which is what most traditional approaches do, for example, one ticket for UI, one for API, one for the database, Matt proposes grouping by feature. With the layer approach, after one ticket is finished, you only have one thing (like the database), and you have to wait until all tickets are complete before you can test the application. But with feature-based slicing, you can have ticket one just building out the login page. You can test the entire feature end to end because the full feature is fully functional. This makes it easier to test and really makes the application very modular. You can change requirements or do anything going forward. Slice by feature, not by layer.
The Implementation Skill and Test-Driven Development
Once you’ve converted your spec into different tickets, the next step is implementation. Matt created a skill called the slash implement skill, which helps you write the code. If you look at the implementation skill, it’s also very short. Essentially, what it does is trigger TDD, test-driven development, whenever possible.
TDD means you write the test first, then you write the code to pass that test. This approach ensures that the code you write is actually necessary and functional. The implementation skill guides the AI through this process, keeping things lean and focused.
The Architecture Skill: Deleting Dead Code and Improving Structure
Matt also introduced a skill focused on improving codebase architecture. This skill scans the entire git log, walks through the hot files, and runs what’s called a deletion test. The idea behind the deletion test is simple: let’s say you have a main program that calls a module or function in question. The deletion test tries to see if that function is really necessary to exist. If the function has no use, maybe you should remove it. If you try to remove it, do all the tests pass? Does all the functionality hold up? If the tests don’t pass because that function is deleted, then you should keep it, it’s a dependency of the main program. But if you delete the function and the whole program works the same, there’s no point in keeping it. Delete it.
This skill gives you an architecture review page that tells you exactly what to delete or improve. For example, in one project I ran it on, the render HTML function had no caller, no function called it. Those were stale references, redundant code that should be deleted. Another example: two shallow modules where two functions were being called by two different functions, but those two functions were identical. That means they were created twice. If you refactor, you can unify them into one, making everything cleaner and more token efficient.
The whole point is that AI wastes a lot of time and tokens going back and forth between functions, trying to understand how they call each other. This skill reduces that waste by identifying what’s unnecessary and what can be streamlined.
Why Modular Skills Are the Way Forward
After studying all the skills Matt PCOG created, I realized something important. The reason he built these skills is because all those other frameworks try to enforce you to follow their entire process start to finish, with no way to maneuver in the middle. That’s what he’s solving with his own skills: reducing that dependency, making skills modular.
I think this mindset is the way to go. Nowadays, models like GPT-5, Claude Opus 5, or Gemini 2.5 are really, really smart. You don’t have to make skills that are tied together. For weaker models like Sonnet or DeepSeek, models that aren’t frontier, you can probably use something like Super Powers because those models don’t have that kind of knowledge embedded in them. They’re lightweight and don’t have this framework in place, so using Super Powers is probably ideal. But for frontier models, the approach should be similar to Matt’s: make skills modular, mostly rely on AI to make the best decisions, and use the skill really just to harness, to guard the AI as minimally as possible and guide it in the right direction.
This reminds me of a trend I’ve been seeing. As models get smarter and cheaper, you can see it with Opus 5 versus Opus 4.8, companies like Anthropic themselves are deleting over 80% of their system prompts for newer models. The models are getting stronger and don’t need that much hand-holding because those guardrails or skills are embedded into the model by itself. If you have outdated skills that really hand-hold the model and don’t let it think creatively, it’s actually going to hold back the results you get.
So after studying all of Matt’s skills, I realized we shouldn’t put too many guards on skills, too many instructions that hold back model performance. We should write skills similar to what Matt created: using vocabularies and architectures that prune the skill but don’t guard the AI from thinking creatively for any kind of problem. That’s what I truly believe is going to be the trend going forward. Before, we had so many instructions in skills. Now we don’t need too many because the models are getting smarter.
Points clés à retenir
- AI builds things fast but with random accuracy because it lacks full context, skills like grooming solve this by interviewing you relentlessly until a shared understanding is reached
- Matt PCOG’s skills are modular and can be triggered in any order, unlike traditional frameworks like GStack or GSD that chain everything together and force you to follow the entire pipeline
- The groom me skill runs on five rules: relentlessly question, follow one decision tree branch at a time, ask one question at a time, always recommend options, and never act without confirmation
- The two spec skill converts conversations into a design plan but intentionally excludes code blocks to keep the spec clean and force the AI to cross-reference actual code
- The two tickets skill slices work by feature, not by layer, so each ticket delivers a fully functional feature that can be tested end to end immediately
- The architecture skill scans git logs and runs deletion tests to identify dead code, duplicate functions, and stale references that waste tokens and slow down the AI
- As frontier models get smarter, skills should provide minimal guardrails and let the AI think creatively, heavy-handed instructions actually hold back performance on strong models
The whole shift here is about trusting the model more while giving it just enough structure to stay on track. Matt’s skills don’t try to control every step. They set up a lightweight framework, ask the right questions, and then get out of the way. That’s a fundamentally different philosophy from the all-in-one pipelines we’ve seen before, and for the current generation of models, it just makes more sense.