Post-Workshop Handout

Matt Pocock's Agent Workflow

Skills for Claude Code — from a problem to a finished solution
Workshop taught 26 July 2026 For students who want to go back over the live lesson slowly

If the live session moved too quickly, this is the version you can read at your own pace. Nothing new has been added; it is the same lesson written down, together with a glossary of every term that went past quickly on the day.

The main takeaway

This is not a workflow for writing code. It is a way of getting from a problem to a solution, and it can be applied to every aspect of life.

Understand the requirement → break it into manageable tasks → work through the tasks. Regardless of what we want to achieve, if we understand our requirements and break them down into manageable tasks, it becomes much easier to manage our goals. Whether it is writing a Facebook article, handling marketing, conducting a literature review, writing a paper, preparing a slide deck, or buying and selling second-hand items online, I believe it must go through this process. That is why this specific workflow was chosen for the workshop, rather than a set of coding techniques.

Why AI agents are not only for writing code

When we use this process, incorporating AI agents is not strictly for writing code. Agents are there to carry out the individual tasks, and whether an agent can genuinely help us comes down to two conditions:

  1. How well we have broken the task down. A task an agent can finish is a task we have already understood ourselves.
  2. Whether the agent is connected to the tools it needs in order to perform the work, such as our files, an API, the browser, or the machine itself.

Neither of those two conditions has anything to do with programming, and that is the whole reason this workflow applies just as well to work that contains no code at all.

Point A → Point B

Point A is the problem and Point B is the solution. There are often multiple ways to solve a problem, and our initial ideas might not be the most efficient. This is precisely the situation grilling exists to address, because it asks us to look at the other routes before we spend our effort walking one of them.

A B the problem the solution the route grilling finds your first idea the route you never considered
Figure 1. Getting from Point A to Point B. Several routes usually exist, and the most obvious one is not necessarily the best. Drawn for this handout as an inline SVG.

Essential keywords

Every term that went past quickly on the day is explained here in plain language. If a sentence in this handout stops making sense, the term you are missing is very likely to be in this list.

LLM (Large Language Model)This is the model itself, the component that produces text. Claude, GPT and Gemini are all LLMs. On its own an LLM can only converse, and it needs tools before it can actually carry out work.
AI agentAn LLM that has been given tools and a goal, so that it can take actions in a loop rather than simply replying. It reads files, runs commands and checks the results until the piece of work is finished.
CLI / TerminalThe Terminal is the text window in which we type commands to the computer, and a CLI (Command Line Interface) is any program driven that way rather than by clicking. This workflow lives here, because the Terminal is where an agent can reach everything else.
ShellThe program running inside the Terminal that interprets what we type, usually zsh or bash. Put loosely, the Terminal is the window and the shell is the program listening inside it.
PipingSending the output of one command straight into the next, written with the | character. It is how small tools are chained into a larger one, and it is also how we connect other tools and data to an agent.
APIA defined way for one program to ask another for data or for an action, which is how software communicates with software. Asking whether an agent can help with a task often amounts to asking whether the thing we need it to touch has an API.
MCP (Model Context Protocol)A standard way of plugging tools and data sources into an agent so that it can use them without custom glue being written for each one. It is the tidy answer to the second condition, which is connecting the agent to what it needs.
Local modelAn LLM that runs on our own machine rather than on a company's servers. It matters here because a workflow that lives in the Terminal can be pointed at a local model later without our having to learn anything new.
Claude CodeThe agent we drove through the Terminal during the workshop. It is the program that reads our skills, asks us the grilling questions, and carries out the work.
SkillA reusable instruction pack that we install once and that teaches the agent a particular procedure. Everything in this workflow, including Grilling, Wayfinder and To Spec, is a skill.
Slash commandThe way we invoke a skill: we type /name, and the agent loads those instructions and follows them. /grilling is the slash command, and grilling is the skill behind it.
Repository (repo)A folder that holds one project together with its history. It does not have to contain code, because a repository can just as easily hold a marketing plan and its documents. It is simply the container our project lives in.
IssueOne written, self-contained piece of work, rather like a ticket, sized so that a single agent session can genuinely finish it. Issues are the manageable tasks of the central idea, made concrete.
Issue trackerThe board or list where issues live and where their status is visible, whether to do, doing or done. It is how we and the agent agree on what is still outstanding.
GrillingAn interview process between us and the AI agent, run one question at a time, until both parties have a profound understanding of the problem. It concludes with a summary written into a central document.
WayfinderGrilling applied across all categories of a project, so that no area is left unexamined. Grilling is suitable for less complex projects, whereas Wayfinder is better for projects with higher complexity.
CONTEXT.md / AGENT.mdThe central document that grilling writes to, a plain text file in our project holding the understanding we have agreed on. Every step after this point reads from it, and its quality determines the quality of what we produce.
SOP (Standard Operating Procedure)The written way in which something is done, set out so that anyone can pick it up and follow it. Once grilling has filled in our central document, that document serves as our SOP, both for ourselves and for every agent that comes after us.
PRD / specA specification of what is to be built or produced, stated concretely enough to act on. A PRD (Product Requirements Document) is the same idea expressed in product language. It is the step between understanding the problem and having a list of tasks.
/to-specThe skill that turns the SOP into an actionable specification, so that our understanding becomes a list of things which must be true once the work is done.
/to-issueThe skill that breaks the spec into individual issues, each one sized so that a single agent can finish it.
/implementWe hand the agent one issue and it performs the work. This is the most visible step, although it can only be as good as the document that stands behind it.
/goA command that works through the queue rather than a single issue, so that the agent takes the next piece of work and continues without our choosing each one.
LoopRepeating a step automatically until the work runs out, taking an issue, completing it, and then moving on to the next. This is what turns a set of issues into progress that continues without supervision.
AFK (Away From Keyboard)The collective name for /go and loops, meaning agents working through issues while we are not sitting at the keyboard. It is only advisable once the tasks have been defined properly.
Setup skill/setup-matt-pocock-skills installs the skills and establishes shared concepts such as Issues. It is run once per project, and it can be skipped on a repository that has already been configured.
Point A → Point BA is the problem we have and B is the solution we want. Framing work in this way makes it clear that several routes exist and that one of them has to be chosen deliberately.

About Matt Pocock

Matt Pocock is a TypeScript educator and engineer, the creator of Total TypeScript and co-author, with Taylor Bell, of the book Total TypeScript. He publishes the agent skills this workflow is based on openly in his mattpocock/skills repository on GitHub. We are borrowing his workflow rather than his subject matter, and nothing we did in the workshop required TypeScript.

The workflow, step by step

There are six steps. Each one takes something in and hands something out, and what it hands out becomes the input to the step that follows. That chain is the method in its entirety.

/setup → /grilling → /wayfinder → SOP → /to-spec → /to-issue → /implement → /go
0 · SETUP /setup-matt-pocock-skills once per project — then skip 1 · UNDERSTAND /grilling one question at a time 2 · CHART THE ROUTE /wayfinder high complexity only 3 · YOU NOW HOLD AN SOP CONTEXT.md / AGENT.md — the agreed understanding. Everything downstream reads from this document. 4 · TURN INTO WORK /to-spec → /to-issue spec, then separate issues 5 · EXECUTE /implement one issue, done properly 6 · SCALE UP · AFK /go — or a loop many issues, unattended
Figure 2. The six steps, and the document that sits in the middle of them. Drawn for this handout as an inline SVG.

The worked example we will carry through all six steps

There is not a line of code in it. The sentence we begin with is "I want to grow my Facebook page." It is worth watching what happens to that sentence as it passes through the pipeline, because by step 6 it has become five finished pieces of work and it no longer contains the word "grow".

0Setup — /setup-matt-pocock-skills

This installs the skills and establishes shared concepts such as Issues, so that the later steps have somewhere to put work. It is typically a one-time process, and if you are working on an existing repository that has already been configured you may not need to perform it again.

In — a project folder, set up on one occasion.
Out — the skills installed, and an agreed place for issues to live.
Facebook example: we create a folder for the page project and configure it once, after which it does not need to be touched again.

1Understand the problem — /grilling

We are at Point A and we want to reach Point B, and our initial idea for getting there might not be the most efficient one. Grilling involves an interview process between you and the AI agent, one question at a time, until both parties have a profound understanding of the problem. It concludes with a summary in a central document, such as CONTEXT.md or AGENT.md.

In — a problem that is still vague, described in your own words.
Out — a central document that states what the problem actually is.
Facebook example: the phrase "grow my Facebook page" does not survive the questions. Grow by what measure, followers or revenue? What happens after somebody follows the page? The interview arrives at the real requirement, which is 30 course leads a month. Followers were never the goal, because they were only a guess at the route.

2Chart the route — /wayfinder

Wayfinder involves grilling across all categories of the project, so that we understand every aspect of it and no area is left unexamined. As a rule of thumb, grilling alone is suitable for less complex projects, while Wayfinder is better for projects with higher complexity.

In — the central document from grilling, together with the areas nobody has examined yet.
Out — the same document, with no unexamined areas remaining.
Facebook example: one page with one offer is not especially complex, so grilling was sufficient and Wayfinder was skipped. If this were a launch across four channels with a budget and a deadline, that is the point at which we would reach for Wayfinder.

3You now hold an SOP

Once Wayfinder and Grilling are complete, we hold a central document that acts like a company SOP: the understanding we have agreed on, written down, which everything downstream reads from. This step is not a command but a change in what we are holding. We began with an idea in our head, and we now have a document that somebody else could execute.

In — the honest answers we gave during grilling.
Out — CONTEXT.md, which is the standard operating procedure for this piece of work.
Facebook example: the document now states who the audience is, what the offer is, what counts as a lead, and that the monthly target is 30. Anyone, or any agent, can pick it up and act on it.

4Turn the SOP into work — /to-spec, then /to-issue

We turn this SOP into actionable tasks using /to-spec, and then break those down into specific issues using /to-issue. Each issue is sized so that one agent can genuinely finish it.

In — the SOP.
Out — a specification, and then a set of separate issues that can each be finished.
Facebook example — the five-item spec: (1) who the audience is and what the offer is; (2) the content pillars and the posting cadence; (3) the path from a post to a captured lead; (4) how a lead is counted; (5) a weekly review.
These become five issues: write the audience-and-offer one-pager; draft twelve posts against the three pillars; build the signup page the posts point at; set up lead counting; and schedule the posts and book the weekly review.

5Execute — /implement

Once we have these sub-tasks, we can instruct the AI to execute them. You use the /implement command to have the agent perform the work on one issue, from beginning to end.

In — one issue.
Out — that issue, completed.
Facebook example: we hand over the issue "draft twelve posts against the three pillars", and twelve drafts come back written for the right audience, because the document had already told the agent who that audience is.

6Scale up — AFK mode

If you want the agent to handle multiple tasks at once, you can use commands like /go or a loop, which are collectively known as Away From Keyboard mode.

In — the issues that remain.
Out — those issues, completed while we were doing something else.
Facebook example: the remaining four issues go through /go. We began with "I want to grow my Facebook page" and we end with five finished pieces of work aimed at 30 leads a month.
A whiteboard with To Do, Doing and Done columns and sticky notes
Figure 3. An issue is a task small enough to be written on a single sticky note and actually finished. Steps 4 to 6 amount to this board being emptied, with an agent doing the work instead of us. Photo: Jeff.lasovski, "Simple kanban board", Wikimedia Commons, CC BY-SA 3.0.

Two points I would like to repeat

Grilling is the least expensive place to catch a misunderstanding. Grilling can feel slow while we are in the middle of it, and it is nonetheless the least expensive part of the whole process. A misunderstanding we catch during grilling can usually be corrected with a single sentence, whereas the same misunderstanding discovered during /implement means the work has to be done again. I would therefore ask you to treat the interview as part of the work rather than as a formality that precedes it.

The quality of the result is set by the central document. Because /implement is the step where output appears, it is easy to assume that it is the step which matters most. In practice the quality of the result is set by the quality of the central document, and the quality of that document is set by how honestly we answered the questions during grilling. If the SOP is unclear, the issues derived from it will be unclear as well, and the agent will carry that lack of clarity straight through into the output.

Why the Terminal

That is exactly why I chose to teach everyone how to use the Terminal, rather than keeping us in Claude Chat or Claude Artifacts. It was not a preference for appearing technical. Each of the four points below is a capability we would lose in a chat window.

1. Piping and APIs

The Terminal allows us to easily pipe or connect various APIs to the AI agents, which is the second of the two conditions from the first page and the point at which work that is not code becomes possible. Piping, written with the | character, means that the output of one thing becomes the input of the next, so anything with an API can be chained into the agent's reach. A chat interface gives us only the tools that the interface decided to provide, whereas the Terminal does not restrict us in that way.

2. Portability across providers

Model providers will keep changing. If our workflow lives in a CLI, it gives us the freedom to switch to different LLM agents more easily in the future, including local models running on our own machine, and that switch is a matter of changing configuration rather than something we have to learn again. Our skills, our CONTEXT.md and our issues all survive it. Anything we build inside one company's chat product, by contrast, goes wherever that product goes.

3. It is the foundation

As I demonstrated in class, connecting to mobile devices and other machines is also much simpler through the Terminal, as it is the core foundation of computer usage. Computer use, meaning an agent that operates a machine rather than only describing it, is built on this same layer. If we start one layer above it, in a chat box, every one of those connections has to be handed to us by somebody else.

4. The old objection no longer applies

The reason people used to avoid the Terminal was that it required memorising commands, and that reason has expired. Nowadays, using the CLI is much easier because these AI agents can help control the Terminal for us, allowing for a smoother workflow without the need to memorise complex commands like before. We describe the outcome we want and the agent produces the command. I would encourage everyone to become familiar with these tools now, while they are easier to pick up than they have been at any point before.

A terminal window showing a shell session with several commands and their output
Figure 4. A shell session, in which commands are typed, output is returned, and each command is able to feed the next. This is the surface the agent drives on our behalf, and none of it has to be remembered. Screenshot: The GNOME Project, "Linux command-line. Bash. GNOME Terminal.", Wikimedia Commons, GNU General Public License.

Wrap-up — and what to do next

A short recap. We understand the requirement, we break it into manageable tasks, and we work through the tasks. The tasks are issues and the understanding is a document, and it is that document rather than /implement which decides how good the result will be. Grilling is the point at which being wrong is inexpensive, and the Terminal is what keeps the agent connected to everything else while leaving us free to move between providers.

Your next actions

  1. Run the setup skill once. Type /setup-matt-pocock-skills in a fresh folder. There is no need to read ahead, so simply get it installed.
  2. Choose one small real problem of your own. Not a practice exercise, but something you actually want completed this week, and deliberately something with no code in it, such as a post, a listing, a section of a paper, or a slide deck.
  3. Let the agent grill you, and answer honestly. Allow it to ask one question at a time and resist summarising ahead of it. When your original phrasing changes under questioning, that is the process working rather than a detour.
  4. Read your own CONTEXT.md. Would somebody who knows nothing about the project get the right result from it? That is the only quality check worth making before you move on.
  5. Take it all the way through. Run /to-spec, then /to-issue, then /implement on a single issue. Finish one loop from beginning to end before you try /go, because AFK is only advisable once your tasks have been defined properly.
  6. Skip Wayfinder on this first attempt, unless your problem is genuinely large. Save it for the point at which grilling alone leaves parts of the project unexamined.

The aim of that first run is not an excellent result. It is to give you a feel for the difference between the sentence you started with and the document you ended up with.

Where to get help

Resource room — I have posted most of the relevant information from the workshop there, so that is the place to start if you want to watch or read something again.

Discord channel — If I missed anything in this handout, or if you have additional insights, please feel free to share them there. What you work out on your own problem is worth more to the group than the worked example above.