构建与测试步骤可能执行项目仓库中的任意脚本
原文依据:1 处Skill 指示代理在修改后运行可用的 build、typecheck 和 tests,但没有要求先检查这些命令实际会执行什么。项目清单或测试配置可以把这些常规命令映射到任意本地程序。
如果被处理的仓库不可信,脚本可能读取代理可访问的凭据或文件、修改工作区之外的数据,或发起网络操作;实际影响取决于执行环境授予的权限。
该 Skill 确实要求在修改后运行相关构建、类型检查和测试;这些命令在某些仓库中可能触发项目自定义脚本。但提供的源码没有命令、清单或测试配置,无法证明会执行任意程序。这也是实现 UI 后的常规验证。用户可要求先展示并检查将运行的命令及其脚本定义,或仅允许已审核的检查。
这项判断针对展示的代码和适用条件,不表示风险已经实际发生。3. For greenfield screens, major redesigns, or vague direction, consider a visual reference pass *if an image-generation tool is available* (skip otherwise — it's a companion, never the deliverable). Four modes: **direction board** (2–3 abstract mood/material/color explorations before code — no real UI), **UI reference** (medium-fidelity composition for a chosen direction), **paintover** (a stronger version of an existing screenshot), **raster asset** (empty-state art, textures — never icons/logos/charts). Always reject generic SaaS, illegible text, off-domain palettes; extract palette/density/proportions/signature, then build it in real code and verify in the browser.4. Patch the implementation, then run the relevant build/typecheck/tests when available.5. Verify visually for non-trivial UI. Use the inline render tool, a local browser, or screenshots at desktop and mobile widths; fix overlap, broken spacing, blank states, unreadable text, missing assets, and generic composition before presenting.