mint-threejs-skills

Mint Three.js 技能

Mint 的浏览器端 Three.js 工作技能套件。它整合并改编了开源的 Three.js 游戏、应用和图形 Agent 工作流，适用于各类 3D 应用，同时保留深入的游戏工作流。

选择路线

• 新请求的主要交付物是一个生成的模型、一个动画模型、一套协调的模型资源、一个材质、一套材质，或一个明确要求的 Mint 世界：先阅读 references/asset-viewer.md，然后使用应用总监。资源本身就是产品；查看器是用于检查和下载资源的外壳。
• 通用 3D 应用、查看器、配置器、模拟、漫游、编辑器或交互体验：阅读 skills/threejs-app-director/SKILL.md。
• 带有目标、挑战、计分、失败、进度或游戏感的游戏或类游戏请求：阅读 skills/threejs-game-director/SKILL.md。
• 混合体验：从应用总监开始，然后只加入相关的游戏专家技能。

两条路线共用视觉系统、交互、调试、QA 和 references/mint-mcp-assets.md。在为某个代码库首次调用 Mint MCP 写入前，阅读 references/mint-project-workspaces.md，为此项工作确定一个 Mint Project。使用 Mint 资源的项目还需采用 references/asset-pipeline.md 中的持久化注册表。

现有应用或游戏的上下文优先于资源交付。应在该项目中生成并集成用户要求的资源，而不是搭建独立查看器。

不变原则

• 现有项目架构优先。对于从零开始的项目，默认使用 TypeScript、Vite 和 Three.js 模块。
• 默认使用原生 Three.js；如果项目或用户选择 React Three Fiber 或其他基于 Three.js 的技术栈，则予以支持。
• Mint MCP 是唯一的生成资源生产流程。不要在浏览器运行时代码中调用 MCP。
• 区分本地代码项目（正在编辑的文件夹或仓库）和 Mint Project（拥有 Mint 聊天和资源的远程工作区）。确定或创建 Mint Project 一次，将其写入 mint-assets.json 并持久保存；该代码库启动的每项独立生成都应复用它。
• 对于导入 Mint 文件或远程世界配置的每个项目，都要通过 scripts/sync-mint-assets.mjs 维护项目根目录下的 mint-assets.json。复用稳定的逻辑键，并遵循现有项目的资源根目录约定。
• 对于每条加载 Mint 生成的 GLB 的 Three.js 路径，都要阅读 references/gltf-runtime-compatibility.md，并使用支持 Draco 的共享加载器。Mint 优化后的 GLB 与基础版 GLTFLoader 不兼容。
• 优先生成独立模型并在 Three.js 中组合。只有在用户明确选择生成环境时才生成 Mint 世界；此时阅读 references/mint-world-splats.md。
• 如果程序化资源或用户提供的资源更符合设计需求，或者 Mint MCP 不具备所需能力，则使用这些资源。绝不要为 Mint 已成功生成的对象另行创建与之竞争的程序化版本。
• 验证前，阅读 references/verification-policy.md。执行其中规定的自动化最低要求；进行扩展的桌面端/浏览器 QA 前先征求同意；移动端 QA 则必须另行获得批准。其审批边界优先于更宽泛的专家技能完成要求。
• 不要将目标、压力、奖励或失败等游戏概念强加到通用 3D 应用中。

用户所有的 UI

• 将交付的应用视为用户的产品，而不是资产生成流程的演示。
• 除非用户明确要求，否则不要在运行时 UI 中显示提供方名称、品牌标识、徽章、生成链接、资产 ID 和来源信息。
• 仅在最终回复或开发者文档中提及生成来源和交付链接。
• 默认只提供体验所需的最精简 UI：加载和错误状态、必要控件，以及用户明确要求的操作。
• 除非用户提出要求，否则不要添加标题、标题栏、导航、营销文案、署名或装饰性应用外框。
• 对于规范的资产查看器，画布应占据主导位置，并在信息按钮的触发下打开居中的紧凑详情对话框，同时在底部居中放置检查控件。不要预留固定侧边栏空间。对于其他简单查看器和分步演示，使用底部居中的紧凑控件组。加载、就绪或错误状态应直接显示在控件组上方，并采用相同的紧凑视觉风格。

当用户要求可复用的提示词时，请使用 references/request-templates.md。