用途：把已确认的理解转化为一份简短的书面计划，用户批准后才开始构建。
使用时机：/fstack-nail 确认摘要之后；用户索要计划且想法已清晰时；/fstack 因尚无计划而路由到此。
步骤：若 /fstack-nail 已产出确认摘要，以其为基础，除非新证据冲突，否则不重开已定问题；在项目根目录写入或更新 PLAN.md；严格使用四个小节，不添加其他标题；把计划展示给用户；停下并请求批准，未获批准不得实施；若某步过大，拆分或删除，不嵌套子步骤。
PLAN.md 格式：What we're doing（2–4 句，平实语言，说明做什么与为什么）；Steps（编号列表，最多 7 步，每步应能一次完成并验证）；What we're NOT doing（必填，不得留空，列出诱人但超出范围的附加项）；How we'll know it works（1–3 条可实际尝试的检查，如“切换开关、刷新、主题保持”）。
禁止：超过一页，超长则拆成多份计划；添加四节之外的标题；开始实施——计划以批准为终点。
示例交互：Agent 写入并展示 PLAN.md，说明四节内容并询问是否批准；用户回复“Approved.”后 Agent 停止，用户可接着调用 /fstack-build。
限制：资料未提供收费、平台、安装命令等信息。