All experiments

Experiment

Project management for AI dev

Part one gave your agent a process. This one gives it a backlog: grill the idea, write the spec, slice it into tickets, and sort them so the agent always knows what to grab next.

This is the companion to the episode. The series promise stays the same: we help you get started developing with agents, step by step. Part one installed superpowers, the process your agent follows to build one feature well. This part adds the layer that decides what it builds. You end with a written plan and a sorted backlog, made with Matt Pocock's skills, and your agent works from that instead of from vibes.

Why your agent needs a manager

In part one you watched an agent build a feature with real discipline. It still only builds what you tell it, one conversation at a time. Ask it to "make the app better" and you get vibes back, disciplined vibes now, but vibes. The fix is old and boring: write down what you want, cut it into small pieces, and keep the pieces in order. The skills in this episode make the agent do that writing with you.

Meet the skills

  • Matt Pocock is a developer educator, best known for teaching TypeScript. He publishes the actual skills folder from his own machine as an open repo. A skill, same as in part one, is a single readable markdown file that teaches the agent one process.
  • There is nothing to buy and no service to sign up for. You copy the skills you want into your agent's skills folder; the repo includes a setup skill that wires them for you.
  • These skills change like any software. Between our prep and this recording he shipped v1.1, which renamed two of them: to-prd became to-spec, and to-issues became to-tickets. We reviewed the full diff and upgraded before filming, so the names you learn here are the names in his repo today.

The chain

Five steps, left to right. Each section below walks through one of them.

Grill the idea

Everything starts with an idea too vague to build. The grilling skill interviews you about it, one question at a time, and recommends an answer for every question so you are never staring at a blank. Facts it can find in your codebase it looks up itself. The decisions stay yours. You stop when both of you can say what you are building in one sentence.

Write the spec

A spec is the written answer to "what are we building, and how will we know it works". If you have heard the word PRD before, it is the same document. to-spec takes the grilling conversation you just had and writes the spec from it, with no second interview. It records the user stories (each one reads "as a player, I want X, so that Y"), the implementation decisions you made, what gets tested, and what is out of scope. Write that last list every time; it is what keeps the feature small.

Slice into tickets

A ticket is one piece of work small enough for an agent to finish in a single sitting. to-tickets cuts the spec into them. Each ticket is a tracer bullet: a thin path through the whole app (data, logic, screen, test) that runs end to end on its own, instead of building one layer at a time and having nothing to show. Each ticket also declares its blocking edges, meaning the tickets that must finish before it can start. Whatever has no blockers left is called the frontier, and the frontier is what your agent grabs next. In our setup the tickets are markdown files in the repo's issues folder, so there is no tracker account to create and no new tool to learn.

Sort the backlog

Triage means sorting incoming work, the way an emergency room sorts patients. The triage skill moves each ticket through plain states: needs-triage (just arrived), needs-info (a question is still open), ready-for-agent (an agent can take it), ready-for-human (a person should do this one), and wontfix (rejected, with the reason kept). When a ticket reaches ready-for-agent, triage writes an agent brief on it. The brief is the contract the agent implements from, with acceptance criteria you can check line by line. That brief is what makes AFK work possible: away from keyboard, the agent builds while you do something else, and the brief is what it follows.

Hand it to the engine

The last step of this episode is the first step of part one. superpowers picks the frontier ticket and runs its five stages on it, the same machine you already watched for a whole episode. One habit to add between tickets: start a fresh conversation for each one. Agents work best with a clean context window (their working memory), and the handoff skill writes the short note that carries what the next session needs to know.

What you walk away with

  • A repeatable path from a fuzzy idea to work your agent can pick up on its own.
  • You can name every artifact in the chain, from the spec down to the agent brief, and naming them is what lets you steer the work instead of watching it.

Where to go next

  • The links below are Matt's repo, part one of the series, and the community behind the work.
  • Part three connects the process and the backlog into one system. Subscribe if you want it when it lands.

Resources