WEBVTT

1
00:00:00.600 --> 00:00:02.759
Here's a plan an agent just wrote for you.

2
00:00:02.779 --> 00:00:07.112
Forty steps, tidy headings, every edge case
considered.

3
00:00:07.550 --> 00:00:08.989
It feels like progress.

4
00:00:09.009 --> 00:00:12.871
But look closer: not a single line of it has
actually run.

5
00:00:13.350 --> 00:00:17.932
This lesson is about a different way to
plan, where the plan is built out of

6
00:00:17.952 --> 00:00:19.826
evidence instead of prose.

7
00:00:21.350 --> 00:00:27.171
This lesson teaches The Complete Guide to
pstack, Part Two, by Lauren, who posts as

8
00:00:27.191 --> 00:00:33.083
poteto. pstack is her personal set of agent
skills, behind a workflow she says ships

9
00:00:33.103 --> 00:00:35.162
thousands of PRs a month.

10
00:00:35.550 --> 00:00:39.100
Part One argued that verification comes
first.

11
00:00:39.120 --> 00:00:43.972
If an agent can't check its own work, you
remain the bottleneck, babysitting it all

12
00:00:43.992 --> 00:00:44.526
day.

13
00:00:44.983 --> 00:00:46.977
Part Two asks the next question.

14
00:00:46.997 --> 00:00:50.375
Once verification works, how do you figure
out what to build?

15
00:00:51.933 --> 00:00:54.825
We'll move through four stages.

16
00:00:55.283 --> 00:00:57.159
First, understand the problem.

17
00:00:57.179 --> 00:00:59.413
Then, specify the outcome.

18
00:00:59.883 --> 00:01:02.585
Next, explore the options with prototypes.

19
00:01:02.605 --> 00:01:06.749
And finally, execute, with proof at every
step.

20
00:01:07.217 --> 00:01:10.000
Underneath all four sits verification.

21
00:01:10.020 --> 00:01:13.575
Keep it in mind as the floor everything else
stands on.

22
00:01:15.133 --> 00:01:18.082
Frontier models are very capable coders.

23
00:01:18.102 --> 00:01:22.258
Even so, poteto keeps seeing two failure
modes.

24
00:01:22.717 --> 00:01:28.741
First, the agent can't fully understand your
intent, because the task is under-specified,

25
00:01:28.761 --> 00:01:30.419
or poorly specified.

26
00:01:30.883 --> 00:01:34.824
Second, it doesn't have enough context on
how to do the work correctly.

27
00:01:35.283 --> 00:01:40.853
The two are related, and they share one fix:
prime the agent's context window with high

28
00:01:40.873 --> 00:01:43.293
quality context before it starts.

29
00:01:44.867 --> 00:01:50.024
Before agents, changing a system meant
reading enough of it to build a mental model

30
00:01:50.044 --> 00:01:50.398
first.

31
00:01:50.418 --> 00:01:52.792
For a small fix, maybe hours.

32
00:01:52.812 --> 00:01:56.036
For refactoring the core, it could take
months.

33
00:01:56.483 --> 00:01:58.371
Agents remove that barrier.

34
00:01:58.391 --> 00:02:01.213
They'll change code whether or not you
understand it.

35
00:02:01.233 --> 00:02:05.306
What stays hard is keeping the code and the
user experience high quality.

36
00:02:05.783 --> 00:02:07.812
So the skill becomes supervision.

37
00:02:07.832 --> 00:02:12.153
Tell the agent what you want to achieve, but
leave it free to solve the problem in ways

38
00:02:12.173 --> 00:02:13.970
you might not have thought of.

39
00:02:15.533 --> 00:02:18.895
One of poteto's favorite techniques is the
indirect prompt.

40
00:02:18.915 --> 00:02:23.925
Instead of telling the agent what you think
is wrong, draw the problem out of it, in its

41
00:02:23.945 --> 00:02:24.816
own words.

42
00:02:25.283 --> 00:02:29.980
When someone reports an issue in Slack,
she'll often write something like this: read

43
00:02:30.000 --> 00:02:34.810
this Slack thread, and restate in your own
words, in plain English, what you think the

44
00:02:34.830 --> 00:02:36.253
underlying issue is.

45
00:02:36.717 --> 00:02:38.345
That does three things.

46
00:02:38.365 --> 00:02:44.184
First, it compresses a noisy conversation
into a structured problem statement.

47
00:02:44.650 --> 00:02:48.947
Second, it lets you catch a
misunderstanding, like a fixation on a red

48
00:02:48.967 --> 00:02:51.858
herring, before the agent writes any code.

49
00:02:52.317 --> 00:02:57.011
And third, you haven't led it down the wrong
path with your own assumptions, which could

50
00:02:57.031 --> 00:02:59.795
be wrong, or could limit what the agent
finds.

51
00:03:01.367 --> 00:03:03.738
Next, build a mental model you can trust.

52
00:03:03.758 --> 00:03:06.204
Two pstack skills do the digging.

53
00:03:06.683 --> 00:03:09.137
/how traces runtime mechanics.

54
00:03:09.157 --> 00:03:14.576
It first sizes up the subsystem, and if it
spans multiple directories or services, it

55
00:03:14.596 --> 00:03:18.608
spawns parallel explorer agents on fast,
efficient models.

56
00:03:19.083 --> 00:03:22.056
/why investigates motivation and intent.

57
00:03:22.076 --> 00:03:23.742
Code tells you what happens.

58
00:03:23.762 --> 00:03:26.468
It rarely tells you why someone wrote it
that way.

59
00:03:26.950 --> 00:03:32.147
So /why queries historical evidence in
parallel: git history and PR review

60
00:03:32.167 --> 00:03:37.575
comments, Linear tickets, Notion design
docs, Slack, Datadog monitors, Sentry

61
00:03:37.595 --> 00:03:40.926
errors, code lineage, and analytics events.

62
00:03:42.467 --> 00:03:44.201
/teach builds on both.

63
00:03:44.221 --> 00:03:50.794
It calls /how and /why, then explains the
result to you in an intuitive way.

64
00:03:51.250 --> 00:03:54.270
Use it whenever you need the agent's work to
make sense to you.

65
00:03:54.290 --> 00:03:58.421
For example: teach me why you implemented it
this way and not another way.

66
00:03:58.441 --> 00:04:00.285
What were the tradeoffs, and why?

67
00:04:00.717 --> 00:04:01.791
There's a bonus.

68
00:04:01.811 --> 00:04:05.647
Models often state things confidently
without reading the code.

69
00:04:05.667 --> 00:04:11.214
Having to teach makes the agent gather the
evidence first, so it helps the agent too.

70
00:04:11.650 --> 00:04:14.104
/recall solves a different problem.

71
00:04:14.124 --> 00:04:18.632
Long projects span many chats, and each new
chat starts from zero.

72
00:04:18.652 --> 00:04:24.023
Your past transcripts are a gold mine of
context, and /recall pulls them back in.

73
00:04:25.600 --> 00:04:29.223
Once you understand the problem, how do you
specify the solution?

74
00:04:29.683 --> 00:04:35.279
In poteto's opinion, most plan modes
over-specify implementation details, and

75
00:04:35.299 --> 00:04:37.787
under-specify everything else.

76
00:04:38.250 --> 00:04:42.697
That's why the pstack readme cheekily says,
I don't believe in planning.

77
00:04:42.717 --> 00:04:43.722
She does plan.

78
00:04:43.742 --> 00:04:45.646
She just plans through code.

79
00:04:46.117 --> 00:04:50.268
For shared code and packages, that means
readme-driven development.

80
00:04:50.288 --> 00:04:55.101
Write the docs a user would read first,
describe the API to a hypothetical user,

81
00:04:55.121 --> 00:04:57.959
then work backwards to the implementation.

82
00:04:58.417 --> 00:05:02.523
When she built Dune, her team's in-house
client framework for desktop apps, she

83
00:05:02.543 --> 00:05:06.859
started by writing a tutorial for it, to
feel what building an app with it would be

84
00:05:06.879 --> 00:05:07.440
like.

85
00:05:09.000 --> 00:05:11.866
Her first agent-written draft was painful to
read.

86
00:05:11.886 --> 00:05:17.582
It tried to be a tutorial, a how-to guide,
an architectural explanation, and an API

87
00:05:17.602 --> 00:05:19.486
reference, all at once.

88
00:05:19.950 --> 00:05:25.188
So she sharpened her knife first, by writing
a /technical-writing skill.

89
00:05:25.650 --> 00:05:31.950
It uses the Diátaxis framework, which splits
documentation into four distinct modes.

90
00:05:32.417 --> 00:05:37.342
A tutorial teaches by doing: it leads a
newcomer through steps to build something

91
00:05:37.362 --> 00:05:38.150
visible.

92
00:05:38.617 --> 00:05:44.503
A how-to guide gives an experienced user the
steps to solve a specific, real problem.

93
00:05:44.900 --> 00:05:48.673
Reference is dry, complete and
authoritative:

94
00:05:48.693 --> 00:05:52.112
APIs, machinery, configuration flags.

95
00:05:52.517 --> 00:05:57.142
And explanation discusses background, design
choices, and tradeoffs.

96
00:05:57.617 --> 00:06:01.238
Together with /unslop, the docs come out
readable.

97
00:06:01.258 --> 00:06:06.390
And a plan written this way gives the agent
a concrete target to check its own work

98
00:06:06.410 --> 00:06:07.206
against.

99
00:06:08.767 --> 00:06:11.491
pstack's skills compound in the design
phase.

100
00:06:11.511 --> 00:06:14.064
Here's a three-part prompt from the article.

101
00:06:14.517 --> 00:06:19.520
Part one recalls the past week of
virtualization work, and uses /how and /why

102
00:06:19.540 --> 00:06:22.514
to understand the current implementation.

103
00:06:22.950 --> 00:06:27.991
Part two uses that context, including the
bugs it already fixed, to design a new

104
00:06:28.011 --> 00:06:31.217
engine that eliminates flicker and jitter
entirely.

105
00:06:31.237 --> 00:06:35.240
And it starts by writing a tutorial for
using it in a React app.

106
00:06:35.683 --> 00:06:39.953
Part three asks the agent to teach the
design, and prove it's superior.

107
00:06:39.973 --> 00:06:43.455
That's where the verification skills from
Part One earn their keep.

108
00:06:43.475 --> 00:06:49.082
The agent now sees the whole problem the way
you do, not just a small slice.

109
00:06:50.633 --> 00:06:53.537
When planning, two mistakes are the most
common.

110
00:06:53.983 --> 00:06:57.052
One: accepting the agent's first design.

111
00:06:57.517 --> 00:07:01.941
Two: overcooking the plan without any
empirical evidence.

112
00:07:02.383 --> 00:07:06.075
Human teams iterated on design docs through
several drafts.

113
00:07:06.095 --> 00:07:11.696
With agents you can skip that ceremony, and
take measure twice, cut once to its limit,

114
00:07:11.716 --> 00:07:13.388
with parallel agents.

115
00:07:14.967 --> 00:07:17.267
That's the job of the prototyping playbook.

116
00:07:17.287 --> 00:07:19.096
But first, what's a playbook?

117
00:07:19.550 --> 00:07:21.897
In pstack, playbooks aren't skills.

118
00:07:21.917 --> 00:07:27.794
They're reference files inside /poteto-mode,
and each one captures a workflow she uses.

119
00:07:27.814 --> 00:07:31.532
They load only when the task needs them, to
save tokens.

120
00:07:31.552 --> 00:07:35.107
As of version 0.15.0, there are
twenty-three.

121
00:07:35.550 --> 00:07:36.942
You don't call them yourself.

122
00:07:36.962 --> 00:07:41.989
/poteto-mode uses them automatically,
depending on the task: prototype a few

123
00:07:42.009 --> 00:07:45.364
options, fix this bug, eval this skill
change.

124
00:07:46.933 --> 00:07:51.819
Here's a prompt that triggers it: prototype
a few options for a feature request, use

125
00:07:51.839 --> 00:07:56.051
/control-app, and take videos or screenshots
for me to choose from.

126
00:07:56.517 --> 00:08:01.910
For visual changes, the agent builds
throwaway sketches, in your app or a scratch

127
00:08:01.930 --> 00:08:02.579
directory.

128
00:08:02.599 --> 00:08:07.376
When it's testing an interaction, it puts
two or three variations behind a simple

129
00:08:07.396 --> 00:08:08.229
switcher.

130
00:08:08.683 --> 00:08:13.778
Then it drives each one with /control-app,
the verification skill from Part One.

131
00:08:13.798 --> 00:08:19.252
It takes screenshots of each variant, and
measures the actual timing or layout.

132
00:08:19.717 --> 00:08:22.406
Prototyping is planning, but with code.

133
00:08:22.426 --> 00:08:26.686
The agent answers its own questions with
evidence instead of waiting for you, and it

134
00:08:26.706 --> 00:08:30.828
gets the chance to surprise you with an
option you'd never have considered.

135
00:08:32.400 --> 00:08:37.645
For bigger changes, poteto spends her own
time on architecture and data structures,

136
00:08:37.665 --> 00:08:40.372
and lets agents fill in the implementation.

137
00:08:40.392 --> 00:08:44.867
The /architect skill gives that work five
disciplined phases.

138
00:08:45.317 --> 00:08:46.237
Ground the problem.

139
00:08:46.257 --> 00:08:51.828
The agent runs /how and /why over the
affected systems, to learn existing

140
00:08:51.848 --> 00:08:54.140
ownership and constraints.

141
00:08:54.617 --> 00:08:55.419
Sketch.

142
00:08:55.439 --> 00:08:59.780
In an architecture arena, independent
runners, often from different model

143
00:08:59.800 --> 00:09:04.738
families, each draft a complete design
package: how a caller would use it, the core

144
00:09:04.758 --> 00:09:08.463
types, public function signatures, and a
short rationale.

145
00:09:08.917 --> 00:09:10.946
Cross-judge and synthesize.

146
00:09:10.966 --> 00:09:15.976
A judge running a different model from the
main agent evaluates the candidates against

147
00:09:15.996 --> 00:09:20.098
a strict rubric, and the best ideas are
combined into one design.

148
00:09:20.550 --> 00:09:22.438
Implement against the sketch.

149
00:09:22.458 --> 00:09:27.535
The agent replaces placeholder bodies with
real logic, and if a function needs

150
00:09:27.555 --> 00:09:32.168
unexpected parameters or extra state, it
surfaces the discrepancy.

151
00:09:32.617 --> 00:09:34.481
And scrap it when the design is wrong.

152
00:09:34.501 --> 00:09:39.749
If implementation proves the sketch was
wrong, the agent throws it away and starts

153
00:09:39.769 --> 00:09:40.390
over.

154
00:09:41.967 --> 00:09:43.748
How do you know an architecture is wrong?

155
00:09:43.768 --> 00:09:46.391
Look for empirical proof in the code.

156
00:09:46.850 --> 00:09:51.805
One signal: the same workaround appearing
across unrelated call sites.

157
00:09:52.283 --> 00:09:57.073
Another: types that need escape hatches,
like any, or forced casts.

158
00:09:57.550 --> 00:10:02.563
Notice what poteto doesn't do: adversarially
review abstract plans.

159
00:10:02.583 --> 00:10:07.466
Agents start hallucinating theoretical
risks, and inventing complex edge cases to

160
00:10:07.486 --> 00:10:10.571
guard against problems that will never
happen.

161
00:10:11.017 --> 00:10:13.848
So don't overcook plans while they're still
abstract.

162
00:10:13.868 --> 00:10:20.253
Let the agent answer open questions itself,
by prototyping and verifying its own work.

163
00:10:21.750 --> 00:10:27.238
pstack has no planning skill, but it does
ship a multi-phase planning playbook. poteto

164
00:10:27.258 --> 00:10:32.874
uses it after she's happy with a design, to
turn it into a tactical execution plan.

165
00:10:33.283 --> 00:10:36.362
Every task in the plan is structured around
proof.

166
00:10:36.382 --> 00:10:41.522
Tests alone aren't enough: a step counts as
verified only when the agent has actually

167
00:10:41.542 --> 00:10:43.663
run the code and seen it work.

168
00:10:44.117 --> 00:10:47.148
A script validates the plan's structure and
formatting.

169
00:10:47.168 --> 00:10:54.013
Once approved, it executes item by item, as
small, self-contained, easily reviewed PRs.

170
00:10:54.450 --> 00:10:59.661
For really large projects, she may commit
the plan temporarily so other agents know

171
00:10:59.681 --> 00:11:02.623
the work in progress, then delete it when
done.

172
00:11:02.643 --> 00:11:05.018
Plans aren't worth keeping forever.

173
00:11:06.567 --> 00:11:10.331
Here's how the pieces fit together, in four
prompts from the article.

174
00:11:10.783 --> 00:11:16.128
An ambiguous bug in production: investigate,
and give me what we know, what data you

175
00:11:16.148 --> 00:11:18.427
used, and your best hypotheses.

176
00:11:18.833 --> 00:11:22.421
A new service boundary, like rate limiting
for webhooks:

177
00:11:22.441 --> 00:11:27.889
/architect it first, answer open questions
with prototypes, and let me review before

178
00:11:27.909 --> 00:11:28.925
proceeding.

179
00:11:29.317 --> 00:11:34.467
A big migration to StyleX: break it into
small, verifiable PRs, each with visual

180
00:11:34.487 --> 00:11:40.026
regression tests and live verification, so
the result is one hundred percent identical

181
00:11:40.046 --> 00:11:42.350
to the original, bugs included.

182
00:11:42.817 --> 00:11:46.898
And a bug reported on Slack: reproduce it
with /control-app.

183
00:11:46.918 --> 00:11:51.663
If it reproduces on main, fix it, and show
me a video as proof.

184
00:11:52.067 --> 00:11:57.456
Because /poteto-mode already pulls in most
of these skills, much of the time you can

185
00:11:57.476 --> 00:11:58.164
simply say:

186
00:11:58.184 --> 00:11:59.759
/poteto-mode, do it.

187
00:12:01.267 --> 00:12:02.576
Let's check your understanding.

188
00:12:02.596 --> 00:12:06.564
After each question, pause the video if you
want to answer before I do.

189
00:12:07.017 --> 00:12:07.902
Question one.

190
00:12:07.922 --> 00:12:13.346
Why ask the agent to restate a bug report in
its own words, instead of giving it your

191
00:12:13.366 --> 00:12:14.307
diagnosis?

192
00:12:17.783 --> 00:12:22.825
Because it compresses the noise into a clear
problem, exposes misunderstandings early,

193
00:12:22.845 --> 00:12:26.618
and doesn't steer the agent with guesses
that may be wrong.

194
00:12:27.083 --> 00:12:28.075
Question two.

195
00:12:28.095 --> 00:12:31.178
What's wrong with accepting the agent's
first design?

196
00:12:34.650 --> 00:12:36.349
You never see the alternatives.

197
00:12:36.369 --> 00:12:40.950
Prototype several options, and let real
evidence choose between them.

198
00:12:41.417 --> 00:12:42.585
Question three.

199
00:12:42.605 --> 00:12:46.513
In a pstack plan, when does a step count as
verified?

200
00:12:49.950 --> 00:12:53.088
Only when the agent has actually run the
code and seen it work.

201
00:12:53.108 --> 00:12:55.790
Passing tests alone isn't enough.

202
00:12:57.333 --> 00:13:01.886
Plan mode is often a way to convince
yourself the agent will do the right thing.

203
00:13:01.906 --> 00:13:06.522
But a long, abstract plan only gives you the
illusion of progress.

204
00:13:06.983 --> 00:13:11.661
pstack instead combines thorough
investigation, empirical evidence, and

205
00:13:11.681 --> 00:13:13.436
rigorous verification.

206
00:13:13.883 --> 00:13:18.306
Plan that way, and engineering with agents
stops feeling like a gamble.

207
00:13:18.326 --> 00:13:21.056
It becomes predictable and repeatable.

208
00:13:21.517 --> 00:13:26.164
This lesson adapted Lauren's article, The
Complete Guide to pstack, Part Two.

209
00:13:26.184 --> 00:13:28.958
Read the original for links to every skill.

210
00:13:28.978 --> 00:13:30.352
Thanks for watching.