A 660-Token AI Coding Workflow That Grills Your Requirements Before Writing a Line of Code
Hello, I'm Wai Wai.
This article shares a set of skills I've been using recently.
This set of skills is about how to better implement an idea through AI Coding.
This set of skills has already gained 176k stars on GitHub, making it a market-validated star product:
This repository was created by a guy named mattpocock.
When I saw his photo, I felt a strong aura of expertise:
This guy has his own video channel on YouTube:
He has also recorded many videos around this repository.
Many of his videos have been reposted to Bilibili.
A couple of days ago, he also recorded a video specifically titled "mattpocock/skills: A complete AI Coding workflow, end-to-end" to introduce this repository.
This video was uploaded on July 16th. At the time of introduction, it had 7.5 million downloads on skills.sh:
When I wrote this article, it was July 18th.
The download count had already reached 9.6 million:
Maybe by the time you see this article, it will have already surpassed 10 million.
Installation
How to obtain and install this skills repository is clearly stated on GitHub, so I won't elaborate.
I mainly want to remind you of a few things mentioned in the video but not on GitHub.
For example, when you install these skills via the npx command, you will encounter a situation:
npx skills add mattpocock/skills
In addition to the main Mattpocock Skills, you will see an 'other' group:
This 'other' group contains skills the author is experimenting with and may be removed in the future, so you can ignore this group for now:
After installation, this set of skills only occupies 660 tokens in the context.
This proportion is super small compared to other skills:
Judging from the guy's proud little expression in the video, he's quite proud of this.
Finally, don't forget this last step: /setup-matt-pocock-skills
This step allows you to do some development-related settings, such as how to track issues and which keywords can trigger related skills.
This step needs to be executed within a specific project.
For example, if I execute it in an empty directory, it will generate these files for me:
The Combo
This repository contains many skills, among which these are user-triggered:
Each of these skills can be used individually.
But when these skills form a set of AI Coding combos, they become even more powerful.
The combo routine given by the author is as follows:
This combo set is actually version v1.1.
You can see the v1.0 version of the combo was like this:
I started using it from the v1.0 stage and already found it very useful then.
The v1.1 version was released in early July.
After using it for two weeks, I think this version is indeed more powerful and smoother to use.
Next, I will introduce the function of each skill in this combo set.
grill-with-docs
Using this skill involves multiple rounds of dialogue with the AI, where the AI clarifies the requirements thoroughly through a "grilling" approach.
At the same time, the meanings of various terms can be further clarified during this process and then updated to CONTEXT.md in a timely manner.
If there are discussions involving architectural decisions during the process, they will also be recorded.
The formal term is Architecture Decision Record, or ADR for short.
If you want to use AI Coding in an engineering manner, ADR is a very important part because before writing code, the AI also needs to grasp historical decisions, design reasons, constraints that cannot be changed arbitrarily, and some business backgrounds that cannot be inferred from the code.
The predecessor of grill-with-docs was called grill-me.
When I first encountered grill-me and saw its full content, I was completely stunned.
The degree of shock was such that I even wanted to write a separate article for it.
In the current version, the entire content of this skill is only eight sentences in total:
https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md
When I first used this skill, about two or three months ago, at that time, this skill only had three sentences in total:
Among the many particularly "bloated" skills at the time, it was a breath of fresh air.
While being extremely minimalist, it was also quite useful. It could indeed help you sort out problems or requirements through a step-by-step questioning approach.
What is this called?
This is called "Great truths are simple."
Let me show you a real usage scenario.
I'll use the music festival case from when I wrote about openSpec before for demonstration.
First, I directly copied the previous question:
/grill-with-docs I want to make a website that can generate a poster of "bands I've seen perform." On the website, you can input the specific music festival name, time, and which bands performed, and then generate a poster with a sense of design. For example, I watched the Strawberry Music Festival in May 2026, with these bands: Prism, Mosaic, Summer Invasion Project, DOUDOU, Meccadell, Sound Fragment, Escape Plan, Tong Yang.
One of the core working principles of grill-with-docs or grill-me is that it only asks one question at a time.
For each question asked, it also provides its own recommended answer and the reason for the recommendation.
For example, the first question it asked was like this:
Actually, my original intention was to choose the option to display multiple bands at once, but I also remembered that I had seen some bands' solo concerts, so I chose "support both."
Then the second question was like this:
It asked me about the user scope, whether it was single-user or multi-user.
It recommended choosing single-user and gave three reasons.
So I chose the single-user option.
The third question was: How is the poster "generated"?
Following its suggestion, I chose plan C.
Then, it prompted me that a conflict had arisen:
You just chose "zero backend," but plan C's "AI generates the main visual" usually requires calling an external image API (like DALL-E, Flux)
It needed my decision to resolve the conflict.
Here I chose the "template-based + AI optional (bring your own key)" method.
Then came the fourth question, confirming the fields displayed on the poster:
Following the questions it raised, I answered in sequence:
performers have an order, support custom mood color palettes, only record the bands from "the day I went," users can upload a photo they took at the venue
I won't show the subsequent questions one by one.
I'll only show some questions that I think are worth highlighting.
For example, the eighth question, it wanted to clarify the vague term "AI main visual."
It needed to understand exactly which parts of the poster the AI would be responsible for:
The 15th question asked me about "date format + time precision":
When it asked me what to name this product, I wrote "Wai Wai and Max's Music Memories."
At this point, it keenly detected that this was two people, conflicting with the initial single-user choice.
So it asked me to resolve the conflict again:
Finally, after being "grilled" with 20 questions, we completed the requirement confirmation:
This is the functional demonstration of /grill-with-docs.
After all the questions are asked, if you look at the files in the project, you will find some changes.
For example, the CONTEXT.md file now has "Term" explanations:
The ADR directory also has several more "Architecture Decisions":
/to-spec
Next up is the performance time for the second move of the combo, "to-spec."
Directly calling the /to-spec skill, it will automatically organize a structured Spec document based on the requirements we discussed earlier.
The specification document is placed under this path: .scratch\music-poster\spec.md
The entire document is several hundred lines long, divided into these chapters:
The content of these chapters can be summarized as follows:
- Problem Statement: Describes the problem to be solved and why this feature is needed.
- Solution: Describes the overall solution and functional flow.
- User Stories: Uses the form of user stories to clarify specific requirements, allowing the AI to understand "who, what to do, and why."
- Implementation Decisions: Records technical implementation plans, including architecture design, technology selection, data models, and key design constraints.
- Testing Decisions: Clarifies the testing scope, testing strategy, and core testing boundaries.
- Out of Scope: Clarifies what the current version will not do, preventing the AI from expanding requirements on its own.
- Further Notes: Supplements priorities, risks, and future evolution directions.
Simply put, what /to-spec does is convert the already discussed and clarified requirements into a structured, executable software development specification.
Subsequently, code implementation can be carried out based on this Spec.
Now that we have a clear plan, the next step is /to-tickets, which splits the plan into detailed tasks.
/to-tickets
Directly calling /to-tickets can split our spec.md into specific tasks one by one.
It was split into a total of 12 small tasks:
Each task contains multiple sub-tasks:
/to-tickets also thoughtfully tells you the dependencies between these tasks and which tasks can be started in parallel:
After splitting the tasks, it's time for the code implementation phase.
That is, it's time for /implement to take the stage.
/implement
Before executing /implement, there's a little trick.
I also learned this from this guy's video:
When you have detailed tasks, before entering the coding implementation, you can do a /clear operation to clear the current context, leaving enough context for the subsequent coding implementation phase.
After executing the /clear operation, you can use /implement to implement each issue one by one:
You can also give them all to /implement at once and let it implement them one by one:
The rest is just letting it run slowly.
From GitHub, /implement is actually a combination skill:
It uses /tdd for code implementation and /code-review for code review.
That means after /implement is done, you don't need to actively call /code-review for code review.
After it worked silently for over an hour, the core function of the final product looked like this:
If I want to modify it, for example, if I want to support batch input in the performer input field, separated by commas.
Just start again from /grill-with-docs:
During this process, if there are any technical decisions worth recording, it will also proactively remind you to document them:
Eventually, a new directory will be generated under the .scratch directory, containing a new set of spec and issues:
/wayfinder
If the previous /grill-with-docs is an upgraded version of /grill-me.
Then /wayfinder is a further upgraded version.
The author himself also really likes this command, even recording a separate video for it:
So what is the difference between /wayfinder and /grill-with-docs?
According to what the author expressed, /wayfinder helps you find the right path; it's an act of exploration and planning.
/grill-with-docs interrogates the plan you already have, ensuring it aligns with existing project knowledge; it belongs to verification and documentation.
Moreover, a sentence from the author in the video reminded me. He roughly meant that he also uses this command in some non-technical scenarios to explore implementation paths.
Based on his reminder, I also planned to use it to explore something unrelated to technology: running.
/wayfinder I can currently run 10km in 45 minutes, and I want to run it in under 40 minutes in 3 months. What should I do?
First, it asked me some basic questions, such as my current running volume and experience, to let it know if I'm a beginner or an experienced runner.
It also asked how many days a week I can run, to facilitate making a specific plan:
Additionally, you can see the grill keyword in the output content.
After collecting this basic information, it provided an "Overall Path" roadmap:
Let's first look at the output it gave us now.
This is the content of map.md:
There is a chapter inside called "not yet specified," which refers to content that hasn't been clarified yet.
The 7 sub-tasks generated revolve around these unspecified contents:
From the previous roadmap, we know that 01 and 04 are the starting points of the entire task.
So we can look at these two sub-tasks separately.
01 is a further inquiry into some basic user information:
04 is about what model to use to derive pace zones:
From my years of running experience, there is indeed no direct correlation between 01 and 04.
Next, I continued /wayfinder starting from 01, and it continued to ask me a series of questions:
It even went into the detail of the mileage on running shoes:
After the inquiry for 01 was completed, it also proactively updated the corresponding md:
Based on the previous question about running shoes, I chose "greater than 600km," so it added a task for me to change shoes:
When using /wayfinder to execute the "change shoes" task, based on my choices, it recommended several pairs of running shoes to me.
It also advised me not to buy carbon-plated racing shoes.
Finally, after round after round of dialogue, continuously deepening its grasp of my current situation and clarifying the ultimate goal, after 31 questions:
It provided a complete 12-week training plan for these three months:
And the corresponding recovery plan and nutrition arrangement:
In addition, there are many other key outputs, such as pace zones, progress observation, etc. Due to space constraints, I won't screenshot them all.
At this point, if we look at map.md again, you will see:
All the previously pending points have been completed:
And all the documents generated above started from this vague question:
/wayfinder I can currently run 10km in 45 minutes, and I want to run it in under 40 minutes in 3 months. What should I do?
So, open your mind. When in doubt, use /wayfinder to help you sort out your thoughts.
It can be for technical thoughts.
But it's not limited to technical thoughts.
What it solves is not "where is the answer," but "how should I find the answer step by step."
I hope this case can also open your mind.
If you're interested, why not find a small requirement and practice this combo set.
Alright, that's a wrap.
Top 1 from juejin.cn, machine-translated. The original thread is authoritative.
Very detailed explanation. I've been using this recently too.