poteto 的 pstack 指南第二篇讲 agent 工作流的前半段：研究、规划、原型与架构。她认为 agent 的两类常见失败来自意图表述不足与上下文缺失，因此先用「间接提示」让 agent 用自己的话复述问题，再用 /how、/why、/recall、/teach 补齐运行时机制与历史动机。规划环节她反对写抽象计划文档，改为 README 先行、写教程倒推 API，并用 /prototype 在真实代码里跑多套方案、截图对比。/architect 会并行启动多个模型家族的候选设计，交给异模型交叉评审；实现阶段一旦发现类型需要 any 或强制转换，就推倒重来。适合已让 agent 写生产代码、又被「计划看着厚实却无实质」困扰的工程师。
poteto 把「验证技能」当团队基础设施来维护：agent 能启动应用、截图、读 trace、确认改动真的生效，人才不用当瓶颈。文章给出 /create-verification-skill 的完整路径——先用一个 agent 友好的 CLI（doctor、snapshot、screenshot、wait-settle、feature-flag 等子命令）把启停、点击、性能采样封装成可复现命令，再用 Feature Map 这份 markdown 索引记录每个功能做什么、用户视角怎么进入、有哪些坑。她反对用 git worktree 横向扩容（单机大约 10 个 agent 就到顶），建议改用 Cursor cloud agents，配合 /swarm 批量跑验证；接上定时 routine 后，Slack 里的用户报告可自动复现。文中反复强调 CLI 设计规范（破坏性操作带 --dry-run、错误信息要告诉 agent 下一步、输出 JSON）和每天跑一次维护技能的必要性。适合正在搭 agent harness 的一线工程师；但「2,000 PR/月」「100-1000x」这类数字没有给测量口径，读者需自行打折。
Karpathy 提出一个判断：模型越强，人花在“读懂模型输出”上的时间越多，工作重心会从写代码上移到监督与理解。他给出四条按可读性递进的输出格式建议：一是让模型用 ASD-STE100（源自航空维修文档的受控语言规范）重写解释，约束多但行文干净，嫌太严可要求“80% 接近该规范”；二是让模型画图；三是让它直接输出 HTML，得到可交互网页与动画；四是他最看好的方向——按任意主题定制 3b1b 风格的讲解视频，旁白接 ElevenLabs API key，或用本地算力跑免费替代方案。结论是智能与代码变得廉价后，可以随手生成过去根本不值得做的、用完即弃的定制软件产物。适合关注 LLM 实际用法与输出可读性的一线工程师。