LEAF Work 是 LEAF 工作流中承接 Learn 阶段的技能，核心原则是“先叶后树”：不要一上来就生成完整成品，而是先做出一个廉价、可检查的实例，验证方向正确后再扩展。它按顺序关闭四类不确定性：Learn（判断工作需求）、Example（在扩展前证明一个廉价实例正确）、Architect（把实例泛化为可交付的生成器）、Feedback（确认仍然成立并总结已确立与已学到的内容）。leaf-work 从 leaf-learn 通过①Intent 和②Unknowns & Context 之后开始，携带同一 sprout 从③推进到⑧，在⑨之前把已通过的工作移到 .leaf/02-leaves/，在⑩之后调用 leaf-done。
使用方式上，工作统一放在一个 .leaf/ 项目文件夹中，以 leaf CLI 为执行主体。若没有匹配的 sprout 通过①/②，应调用 leaf-learn，不要自行发挥或创建松散的阶段文件夹。开始时应从 00-status.md 读取①Intent 和②Unknowns & Context，除非下游门禁迫使返回。行为与语气来自 leaf-soul，需在开始时调用并遵循其报告、语言、事实/猜测边界、评审交接和渲染产物展示规则。需要其他 LEAF 技能时（leaf-learn、leaf-clean、leaf-done、leaf-profile）应直接调用，而非仅引用文件。
每个门禁按对应参考执行：识别当前门禁、读取其参考、告知用户门禁，并遵循其通过/返回条件。①/②返回使用 ../leaf-learn/references/gate-01-intent.md 和 ../leaf-learn/references/gate-02-unknowns-context.md；③及以后使用 references/gates.md。评审或批准前，先对每个即将清理的门禁文件运行 leaf checkpoint <slug> --<gate>，再对需要简化处理的文件调用 leaf-clean。状态变化时更新 00-status.md，并保持其 ## Overview 与门禁文件一致。发现事实变化时应尽早返回到最早被推翻的门禁，并记录到 04-Feedback/10-retrospective/mid-process-discoveries.md。阶段边界、高影响门禁以及⑧的开始/通过需要用户明确批准，除非已预先授权。⑧明确通过或交付后，把同一文件夹从 .leaf/01-sprouts/ 移到 .leaf/02-leaves/，更新状态并运行 leaf doctor；⑩通过后调用 leaf-done。写文件前使用 references/layout.md 了解文件夹布局、门禁文件名、状态值和文件与文件夹规则。
③Criteria、④Wireframe、⑤Design 构成“标准→实例→生成器”链条，不应跨生产/消费边界合并，分歧必须保持可见。进入③–⑤时读取 references/engine.md。适用场景包括需要先验证再扩展的工程、文档或设计任务。限制方面，资料未提供具体收费、价格、平台支持或效果数据；该技能依赖 LEAF 体系其他技能与 .leaf/ 项目结构，不能脱离体系单独使用。