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 を調べる際は、ローカルのツールチェーンへの問い合わせを 1 回行い、必要であればレジストリまたは公開ドキュメントを 1 回確認します。それでも正確な情報を確認できない場合は、調査を打ち切り、「確認した情報源では確認できませんでした」と回答し、次に実行すべき確認コマンドを示します。不在を証明するために、ほぼ同じウェブ検索を何度も実行してはいけません。

調査範囲は絞ります。情報源となるコマンドやドキュメントで、ユーザーが求める詳細度の回答が得られたら、ユーザーから例、シグネチャ、代替案、または実行による検証を求められていない限り、追加の検索はやめます。回答に不要な周辺情報を確認するために、コンテキストを余分に費やしてはいけません。

外部資料を案内する際は、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 または対応するオンラインエラーページを確認します。

検証に関する方針

MoonBit に関する情報を、次の 3 つの階層として扱います。

• 安定した機能に関する事実：このスキルで扱う言語やツールチェーンの特徴です。 たとえば、クラス継承を第一とするモデルではないこと、型付きエラー、 一般的に安定しているターゲット、llvm が nightly 限定であることなどです。
• 検証済みの正確な情報：正確な API 名、シグネチャ、パッケージ名、インポート、 ターゲット設定、ローカルプロジェクトの規約などを、moon ide、ローカル ファイル、生成されたインターフェース、公式ドキュメント、または mooncakes で確認したものです。
• 未検証の推測：他の言語からの類推、記憶、命名規則から推測した、 もっともらしい API 名や動作です。

未検証の推測を事実として提示してはいけません。正確な情報が未検証の場合は、 何を確認する必要があるかを伝え、コマンドまたは URL を示してください。 もっともらしいモジュール名や関数名を挙げるよりも、「機能の概要については回答できますが、正確な API は moon ide doc '*json*' で確認する必要があります」と伝えてください。

検証コマンドが失敗した場合、結果が返されない場合、またはユーザーのプロジェクト外でしか確認していない場合は、 その結果が正確な API の根拠であるかのように引用しないでください。その失敗が何を意味するかを伝え、 次の確認先として、たとえばパッケージのインストール、moon tree、mooncakes のパッケージドキュメント、 ローカルの依存関係ファイルなどを案内してください。

正確な情報を確認した場合は、「moon ide doc '@json' で確認済みです」または「出典：」のように簡潔に伝えてください。 正確なインポート、関数、エラーの意味を挙げるときは、検証元を省略しないでください。

最終回答の検証元として、このスキル自体の参照ファイルを引用してはいけません。最終回答には、 外部 URL、ローカルプロジェクトのファイル、またはコマンドの実行結果を示してください。このスキルは エージェント向けのガイダンスであり、ユーザー向けの根拠ではありません。

参照ファイルに答えが含まれていた場合も、このルールは適用されます。参照ファイルを手がかりに作業し、 その参照ファイルが示す公開 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 を読んでください。

複数の領域にまたがるタスクでは、まず最も具体的な参照先を読み、必要に応じて次に関連する参照先を 1 つ読んでください。

不明点の確認リスト

回答する前に、不明点が主に次のどれに該当するかを判断してください。

• 言語のセマンティクス
• MoonBit のイディオムやスタイル
• ツールチェーンの動作
• パッケージ、依存関係、または標準ライブラリの API
• バックエンドの制限またはターゲット固有の動作
• 公式ドキュメント、サンプル、またはエラーコードの参照先
• プロジェクト固有の規約

重要な場合は不確実性を簡潔に伝えてください。ただし、確認手順がある場合は、不確実性を示すだけで終わらせないでください。 具体的なコード作業では、該当する --target を指定した moon check、moon test、moon build など、 対象を絞った検証コマンドを優先してください。

境界

• このスキルに言語仕様の全文が含まれているかのように扱わないでください。
• 検証済みでない限り、標準ライブラリのシグネチャを正確に示さないでください。
• moonbit-docs リポジトリ自体の保守にこのスキルを使用しないでください。ドキュメント、翻訳、Sphinx、サンプルの保守ワークフローには、リポジトリメンテナー用のスキルを使用してください。
• 回答は実用的な内容にしてください。次に確認すべきソース、考えられる修正方法、検証に使う最小限のコマンドを示してください。