moonbit-orientation

MoonBit 入门指引

使用此技能解答 MoonBit 开发者的问题时，请先找出缺失的上下文。这是一项入门指引技能，不是 MoonBit 全部文档的打包副本。

默认工作流

1. 对用户的情况进行分类，并判断可能缺失的层面。
2. 在选择处理路径前，检查下方的注意事项和时效性检查关卡。
3. 加载最精简的相关参考文件。
4. 如果涉及代码、API、包配置或诊断，请先检查本地文件，或运行范围最小的发现命令。
5. 给出实用的回答：直接说明功能、MoonBit 中的对应方案、准确的验证命令或链接，以及代码变更后范围最小的验证命令。
6. 如果最终回答中给出了确切的 API、导入项、错误代码含义、目标规则或文档说法，请附上用于验证的命令或 URL。即使回答很简短，也要这样做。

如果用户询问确切的标准库 API、包 API 或近期变更的行为，请使用 moon ide doc、官方 API 文档、包文档或本地项目文件进行验证，不要猜测。

时效性检查关卡

有些 MoonBit 信息变化速度快于模型记忆：新语法、实验性功能、包的可用性、包 API、依赖版本、目标支持情况和命令行标志。对于这些信息，不要把记忆直接当作最终答案。

请按以下模式处理：

1. 如果功能层面的说法稳定，先给出该说法。
2. 说明确切的 API、包名或工具行为可能已经变更。
3. 选择当前的权威来源：本地项目文件、已安装的 moon 命令、官方文档、mooncakes 包文档或注册表。
4. 如果当前环境无法检查该来源，请说明这一点并给出下一步检查方法。不要把未经核实的包、导入项、函数、标志或版本当作事实来介绍。

这并不意味着每个稳定事实都需要验证。它要求你承认 MoonBit 生态或功能信息可能过时，并在提出确切说法前检查最新来源。

限制时效性检查的范围。发现包或 API 时，使用一次本地工具链查询；必要时再查询一次注册表或公开文档。如果这些来源无法确认确切信息，就停止查询，并回答“已检查的来源无法确认”，同时给出下一步验证命令。不要为了证明某事不存在而进行许多重复的网页搜索。

发现过程应保持精简。一旦权威命令或文档已经回答了用户所需的详细程度，除非用户要求示例、签名、替代方案或执行验证，否则就停止搜索。不要额外花费上下文来证明回答所不需要的相近事实。

推荐外部资料时，请提供 references/source-map.md 中的具体 URL。不要假设用户已经检出了此仓库。

注意事项

• 对于标准库和依赖项 API，默认在用户的项目中使用 moon ide doc。与记忆或过时文档相比，它更能反映已安装的工具链和依赖项。
• 对于生态系统中包的可用性，不要仅凭熟悉的技术名称推断包存在。在称某个依赖项可用之前，请先检查 mooncakes，或在临时项目或用户项目中运行 moon add <candidate>。
• llvm 仅限 nightly 版。稳定版后端应使用 wasm、wasm-gc、js 或 native；--target all 不包括 llvm。
• 不要把 Rust、Go、JavaScript 或 OCaml 的名称直接翻译成确切的 API 名称。请先查明 MoonBit API。
• 不要只让用户去“看文档”，而不提供具体 URL 或命令。
• 对包名、导入项、目标和依赖项的建议，应以本地的 moon.mod.json 和 moon.pkg.json 为准，而非泛泛而谈。
• 对于 E#### 诊断信息，请使用 moon check --explain 或准确的在线错误页面 URL 格式，不要凭空猜测原因。

验证约定

将 MoonBit 事实分为三个层级：

• 稳定的能力事实：本技能涵盖的语言／工具链特征， 例如不采用以类继承为先的模型、类型化错误、常见的稳定目标， 以及 llvm 仅适用于 nightly 版本。
• 已验证的精确事实：通过 moon ide、本地文件、生成的接口、官方文档或 mooncakes 确认的精确 API 名称、签名、包名称、导入、目标配置和项目本地约定。
• 未经验证的猜测：根据其他语言、记忆或命名惯例推断出的合理 API 名称或行为。

绝不要将未经验证的猜测当作事实。如果某个精确事实尚未验证，请说明需要检查什么，并提供命令或 URL。相比给出看似合理的模块或函数名称，应优先说“我可以回答该能力，但具体 API 需要用 moon ide doc '*json*' 检查”。

如果验证命令失败、没有返回结果，或只在用户项目之外检查过，切勿将其引用为已证实精确 API 的依据。说明失败意味着什么，并给出下一个信息来源，例如安装包、moon tree、mooncakes 包文档或本地依赖文件。

如果已验证某个精确事实，请简洁说明：“已通过 moon ide doc '@json' 验证”或“来源：”。提及精确的导入、函数或错误含义后，不要省略验证来源。

不要将本技能自己的参考文件作为面向用户的最终验证来源。最终答复应引用外部 URL、本地项目文件或命令结果。本技能是 Agent 的指南，而不是面向用户的证据。

即使答案出现在某个参考文件中，这条规则仍然适用。使用参考文件来确定后续查找方向，然后引用该文件指出的公开 URL、命令或本地项目文件。

避免对精确 API 行为作出“很可能”之类的猜测。对于 Json.parse 或 result.unwrap() 这类未知调用，应说“请验证它返回的是类型化错误还是类似 result 的值”，而不是猜测具体情况。

情况路由

• 学习 MoonBit 或询问从何开始：阅读 references/question-routing.md 和 references/source-map.md。
• 询问“MoonBit 支持 X 吗”、API 是否可用或快速的能力问题：先阅读 references/answer-shapes.md。仅当快速回答模板未涵盖该概念，或用户要求更广泛的比较时，才加载 references/capabilities-faq.md。如果涉及精确 API，请使用 references/lookup-recipes.md。
• 从 Go、Rust、TypeScript、OCaml 或其他语言转来：阅读 references/mental-models.md。
• 编写、审查或重构 MoonBit 代码：阅读 references/idioms.md。
• 调试编译器输出、moon 输出、包错误、后端错误，或带有 E#### 代码的诊断：阅读 references/diagnostics-playbook.md 和 references/lookup-recipes.md 中相关的操作指南。
• 设置模块、包、工作区、测试、文档、覆盖率或构建目标：阅读 references/toolchain-map.md。
• 在官方文档、mooncakes API 文档、Tour、示例、错误代码文档或本地项目检查之间选择：阅读 references/source-map.md。

如果任务涉及多个领域，先阅读最相关的参考文件；必要时再阅读一份辅助参考文件。

缺失层级检查清单

回答前，判断未知内容最可能属于哪一类：

• 语言语义
• MoonBit 惯用法或风格
• 工具链行为
• 包、依赖项或标准库 API
• 后端限制或特定目标行为
• 官方文档、示例或错误代码参考
• 项目本地约定

在有必要时简要说明不确定性，但如果有操作指南可以解决问题，就不要止步于不确定性。对于具体代码任务，优先使用范围明确的验证命令，例如针对相关 --target 运行 moon check、moon test 或 moon build。

边界

• 不要声称此技能包含完整的语言规范。
• 除非已验证，否则不要提供标准库的精确签名。
• 不要使用此技能来维护 moonbit-docs 仓库本身；对于文档、翻译、Sphinx 或示例维护工作流，请使用仓库维护者技能。
• 回答要实用：指出下一步要检查的源文件、可能的修复方案，以及用于验证的精简命令。