moyu-lite

moyu-lite スキルの概要

moyu-lite でできること

moyu-lite は、コード編集のための軽量なガードレールスキルです。余計なリファクタリング、新しい抽象化、大規模な書き換え、そして「親切すぎる」副次的な変更を避けることで、エージェントがユーザーの正確な依頼の範囲内にとどまるのを助けます。Code Editing で、賢さよりも最小差分を優先する moyu-lite スキルを探しているなら、これはかなり相性のよい選択です。

どんな人に向いているか

moyu-lite は、過剰編集が主なリスクになる場面で使います。たとえば、1つの問題を直したのに、関係のないファイル、アーキテクチャ、挙動まで変えてしまうケースです。保守作業、小規模なバグ修正、部分的なファイル編集、そしてユーザーが「X だけ変えて」「シンプルなままで」「リファクタリングしないで」と言っている依頼に特に向いています。

何を最適化するのか

このスキルは 3 つのルールを軸にしています。依頼されたことだけを変えること、まずは最も単純な解決策を選ぶこと、そして迷ったら確認することです。そのため moyu-lite は、正確さが発想力ではなく「抑制」によって決まる場面で力を発揮します。大きなコード解決策を生み出すことよりも、スコープを制御することに重点があり、コード編集ワークフローで本当に詰まりやすいのはそこだ、という状況で役立ちます。

moyu-lite スキルの使い方

moyu-lite をインストールして有効化する

moyu-lite install では、環境内でリポジトリのパスからスキルを追加し、編集前にエージェントがスキルファイルを読んでいることを確認してください。ソースに示されている典型的なインストールコマンドは次のとおりです。
npx skills add uucz/moyu --skill moyu-lite

変更依頼は狭く具体的に出す

moyu-lite usage が最も効果を発揮するのは、対象、期待する結果、境界をきちんと名指しした依頼です。強い入力の例は、「src/auth.ts を更新して、ログイン時に email alias を受け付けるようにして。他の auth ロジックやファイル構成は変えないで」です。弱い入力は「auth を改善して」のようなものです。これではスコープが広がりやすく、スキル側が推測せざるを得ません。

まず読むべきファイルを押さえる

最初に SKILL.md を読み、その後で README.md、AGENTS.md、metadata.json、あるいは rules/、references/、resources/、scripts/ といった関連ガイドがあれば確認してください。このリポジトリは意図的にシグナルがコンパクトなので、余計な補助ファイルを探し回るより、スキル本文を丁寧に読むほうが重要です。

書き換え指示ではなく編集ポリシーとして使う

moyu-lite は、モデルがコードを書き始める前に適用するのが最適です。現在の構造を維持し、差分を最小限に抑え、依頼が膨らんだら確認のために止まるように指示してください。既存コードのパッチ作業では、正解はしばしば「よりよいアーキテクチャ」ではなく「最小限で安全な変更」です。moyu-lite はその判断に向いています。

moyu-lite スキル FAQ

moyu-lite は小さな変更だけのためのものですか？

いいえ。ユーザーが狭く नियंत्रされた変更を重視する Code Editing タスクなら、規模に関係なく使えます。大きな機能追加でも、差分を最小限にし、依頼されていないリファクタリングを避ける指示であれば moyu-lite は有効です。

通常のプロンプトと何が違いますか？

通常のプロンプトはタスクを説明するだけで、モデルがコードを「改善」する余地を残すことがあります。moyu-lite は、そこに明確な抑制レイヤーを加えます。依頼が変更を許可していないなら、その変更は範囲外として扱います。これにより、再設計アシスタントではなく、慎重な編集者のように振る舞わせたいときに、より信頼しやすくなります。

moyu-lite を使わないほうがいいのはどんなときですか？

探索、再設計、大規模な整理を本当にしたいときは使わないでください。アーキテクチャを組み替えたい、パターンを標準化したい、あるいは周辺コードの改善まで含めてタスクを進めたいなら、moyu-lite は保守的すぎる場合があります。

moyu-lite は初心者向けですか？

はい。ルールが簡単で、「変える量を減らす」「早めに確認する」「最小で正しい修正を選ぶ」だけで運用できます。初心者が特に意識すべきなのは、「役に立ちそうな余計な作業」こそが、このスキルが防ごうとしている失敗パターンだという点です。

moyu-lite スキルを改善するには

編集境界を明確にする

moyu-lite guide で最も強い入力は、正確なファイル、範囲、許容スコープを名指しします。「テストは変更しない」「新しい依存関係は追加しない」「現在の API は維持する」といった、触ってはいけないものも明記してください。これで曖昧さが減り、スキルは意図を推測するのではなく抑制を効かせやすくなります。

最低限の達成条件をはっきり書く

ユーザーが本当に気にするのは、見た目の美しさより出力の安全性です。「失敗している分岐を直す」「ハードコードされたパスを置き換える」「呼び出し元を変えずにこの 1 つの関数だけ調整する」のように、最小の成功条件を明示してください。moyu-lite for Code Editing をうまく機能させたいなら、1 回の制約された差分で満たせる目標を与えるのが重要です。

失敗しやすいパターンを把握する

プロンプトが曖昧なとき、コードベースが散らかっているとき、あるいは周辺コードの改善を促しているように見えるタスクでは、スキルが脱線しやすくなります。最初の結果で抽象化が増えた、関係のないファイルに触れた、必要以上に書き換えた、という場合は、指示を絞り込み、境界を言い直してから 2 回目を依頼してください。

追加ではなく絞り込みで反復する

初回の結果が広すぎるなら、依頼を小さくすることで修正します。たとえば、残したい正確な行、ファイル、挙動を指定して、足りない編集だけを求めてください。moyu-lite では、よりよい結果はたいてい「より多くの文脈」ではなく「より強い制約」から生まれます。