在 Agent 工作流中使用文本展开

在 Agent 工作流中使用文本展开，就像在技能层之下再添加一层。

:screenshot = 展开为我最近截图的完整路径。

:fanout = 将此任务分发给并行子 Agent。在派生任何子 Agent 之前，先声明拆分方案：分支数量、每个分支负责哪一片段、各片段为何不重叠，以及此次拆分刻意留下了哪些未覆盖的部分——被喂给相同上下文的分支会因错误原因而达成一致，而未声明的空白会被误读为已覆盖。为每个分支提供相同的固定返回结构和预算；返回散文或超出预算即视为失败分支，每个失败、空结果或超时的分支都必须在结果中明确列出，绝不悄悄丢弃。在启动前声明合并规则（取并集 / 按 <key> 去重 / 多数决 / 首个有效结果），并机械地执行，而非凭印象判断。不得用请求结果时的上下文来评判结果：只有经过独立核查的发现才能保留——在存在确定性证据的地方以证据为准，只有在没有确定性证据时才以另一个模型的判断为准。

:aloop = 完整构建，然后循环：运行真实的构建、lint、类型检查和测试，修复所有失败项，再重新运行，直到每一个门控实际通过——永远不要停在"应该能跑"或"看起来没问题"。永远不要为了强行通过而削弱、跳过或删除检查；门控失败意味着修复代码，而不是修改测试，然后对 diff 进行自审，检查门控不会捕获的问题（调试遗留物、死代码分支、与需求的偏差）。报告确切的命令和实时输出以证明通过，而非依赖假设。如果同一个失败反复出现且没有新信息，停下来将其作为阻塞项上报，而不是强行推进。将通过次数视为预算：如果经过几轮后仍无法清晰地看到绿灯，暂停并报告进度和剩余问题——缓慢的消耗是更隐蔽的阻塞，而非坚持。

:gacp = git add、commit 并 push，以外科手术式的原子提交进行——每次逻辑变更一个提交，绝不批量打包。审查 diff 并按关注点拆分（逻辑、API/接口、UI、测试、文档、配置、重构）；使用 git add -p 或显式路径选择性地暂存——永远不要用 git add -A 合成一个提交。每个提交独立存在：可独立回滚，一条精确的提交信息（不含"and"/"also"）。N 个关注点 → N 个提交；拿不准时，拆分。

你用什么？