Grill.me: the skill that changed how I work with AI agents

For a long time I thought productivity with AI agents depended on writing better prompts. Then I realized the problem was not the prompt: it was context. Since I started using Grill.me, I stopped trying to guess everything in the first message and began designing solutions with the agent before writing a single line of code.

Almost two years ago I started bringing AI tools into my daily development workflow. Like many people, I started with Cursor. I watched the editor evolve: first came Rules, then interaction modes like Ask, Agent, and Plan, and later new agent-oriented ways of working.

Other editors appeared in parallel. One that caught my attention was Anti-Gravity, Google's experiment in AI-assisted development. What is interesting is not only the model it uses, but the product philosophy: the editor decides automatically when to plan, when to execute, and when to rethink the strategy. As a user, you practically hand the whole development process to the agent.

Cursor can do some of that too, but its philosophy always felt different to me: it is a much more craft-oriented tool. You feel like you are working side by side with the agent, and you keep making decisions while the AI executes. Personally, I prefer that approach. I do not want to become a vibe coder who accepts every proposal from the model. I want to keep doing engineering.

Over time I discovered that the real bottleneck was never code generation: it was context. When we work with agents we usually do something like this:

• we write a relatively short prompt;
• the agent interprets what it thinks we want;
• it generates a solution;
• gaps appear that it did not account for;
• we correct;
• it regenerates;
• we repeat five or six times.

The loop works, but it consumes a lot of time. And worse, many of those iterations happen because the agent never had enough information to make good decisions from the start.

There is something I have tried to protect since I started working with AI: I do not want to delegate thinking; I want to delegate implementation. The difference seems subtle, but it completely changes how you work. Before asking the agent for something I try to define things like:

• the data model;
• an ERD when it applies;
• business constraints;
• architectural patterns;
• project conventions;
• important technical decisions.

The AI writes the code, but the engineering still sits on the human side. The best solutions appear when the agent works from solid foundations, not from improvised prompts.

Over the last few months we have seen an interesting evolution inside the Cursor ecosystem. First came Rules, which let you define general project conventions. Then came Skills.

Skills matter because they encapsulate reusable knowledge. It is no longer only about telling the model "follow these rules": now we can teach it complete processes. A skill can tell it how to design an API, create migrations, review security, document changes, or reason before implementing. Instead of repeating the same prompt again and again, the knowledge stays versioned inside the project, and that scales much better. Best of all, there are countless official skills built by the creators of the software solutions and tools we use every day. That provides real context on what can be done and how to apply the technology the way it is meant to be applied.

Among all the skills that started circulating, one especially caught my attention: Grill.me, created by Matt Pocock. You can find it in my resources.

Its idea looks extremely simple. When you invoke the skill, the agent does not start coding: it starts asking questions. Lots of questions. And they are not random: each one aims to remove an ambiguity from the problem.

It happened to me today. I came in with a relatively clear idea, wrote an initial prompt, and invoked Grill.me. For about an hour I answered more than thirty questions. Some were simple; others forced me to think through architectural decisions I had not made yet.

What is interesting is that the skill does not only ask: it also proposes alternatives. Something like this: Do you want to solve this with events or synchronous calls? And below that several options appear. Each one explains advantages, trade-offs, impact, and which one it recommends. That completely changes the dynamic: I am no longer filling out a form; I am having a design conversation.

I think that is the real value of Grill.me. It does not only improve context: it forces me to think about aspects I had not even considered. Many times I found myself reading an option and thinking: "I had not contemplated that possibility."

And that is probably the greatest virtue of a good AI tool. Not writing faster, but expanding the space of possible solutions. Because when we only answer our own questions, we stay trapped inside our own mental model. Grill.me breaks that boundary.

After the questioning session ends, something interesting happens. The agent already knows the context, the constraints, the important decisions, the priorities, and the success criteria. Only then does implementation begin. And the difference is huge: the first versions of the code usually get much closer to what I actually wanted to build. Not because the model is smarter, but because it has better information. In engineering that almost always produces better results.

For a long time we thought working with AI meant learning to write prompts. I am no longer so convinced. More and more I believe the future goes somewhere else: not toward better instructions, but toward better conversations.

Skills represent exactly that: reusable processes, ways of thinking, and decision sequences. And Grill.me takes that idea one step further: it turns problem discovery into an explicit part of the workflow.

In my experience, yes. Especially when the problem is complex. It may seem odd to spend an hour answering questions before you start coding, but that hour often replaces several hours of later iterations. And above all, it improves the quality of technical decisions. It does not replace engineering: it amplifies it. And that, for me, is the difference between using AI to generate code and using AI to build software.

When to use Grill.me?

• New features.
• Large refactors.
• Architecture design.
• Systems with many technical decisions.
• Ambiguous requirements.

When you probably do not need it?

• Small bugs.
• Trivial changes.
• UI tweaks.
• Quick fixes.

If you still have not added a discovery stage before asking an agent for code, I think it is worth trying Grill.me, the skill by Matt Pocock. Not because it writes better code, but because it does something much more important: it forces you to formulate a better problem. And in software development, almost always, a good solution starts long before the first line of code.