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.