工具链
AI 技能
插件自带的四个 agent 技能，以及一个编码代理写 DreamFXLang 时那条"必须先读 schema"的循环。
插件在 .skill/ 下带着四个 agent
技能。它们是给编码代理（Claude Code 一类）用的说明书：怎么创作、构建、排错、迁移特效，全程 headless。
| 技能 | 做什么 |
|---|---|
dream-fx-create | 按一句自然语言描述写一个新的 .dfs / .dfe / .dfm，然后构建它以证明它编得过 |
dream-fx-verify | headless 构建或检查：一个文件，或整棵 DFX 树。其他三个技能都调它 |
dream-fx-diagnose | 拿一条 DFXnnnn 查成因、解释、改源码 |
dream-fx-decompile | 把现有 Niagara 系统导出成源码，或回答「这个项目的 VFX 有多少能被表达」 |
那条循环里最容易被跳过的一步
dream-fx-create 的核心是一个五步循环，其中第 2 步是关键：
找模块
dfx.ps1 list 打印搜索路径暴露的每一个模块。
读它们的真实签名
dfx.ps1 schema <Module> —— 每个打算调用的模块都要读一次。
这是所有人（包括模型）都会跳过、然后在上面花掉二十分钟的那一步。模块输入名是从真实资产上读出来的： 带空格的名字、被静态开关揭示出来的输入、只在某个栈里存在的输入 —— 没有人能可靠地猜对它们。
写文件
放到某个 DFX/ 根下。
构建
dfx.ps1 build <file> -Force。
证明这一步不是可选的。 「写出来看着对」在这里没有意义 —— 只有 build 绿了， 才说明模块名、输入名、类型、开关顺序全都对。这也是为什么四个技能里有一个专门是构建门。
给自己的代理接上
技能是纯文本说明加上 dfx.ps1，没有别的依赖。要在自己的项目里用：
- 让代理能跑
pwsh； - 引擎能解析（
UE_ENGINE_ROOT或注册好的EngineAssociation）； - 写包的命令要求编辑器关着 —— 让代理知道这条；
- 把
.skill/下四个SKILL.md接进你的代理技能目录。
为什么这个语言适合代理
不是因为「AI 时代」，而是三件很具体的事：
- 文本是唯一编辑面。 代理写得了文本，点不了 Slate 按钮。
- 诊断带稳定的码和位置。
DFX3003永远是同一个失败模式，行列指到 token 上 —— 这是一条可以被程序消费的反馈通道，而不是一段散文。 - 构建是 headless 且有退出码的。 「对不对」有一个不靠人眼的判据。
同样三件事对人也成立。代理只是把「反馈通道要机器可读」这条要求，逼得更明显一点。