moyu-ko

moyu-ko skill の概要

moyu-ko は何のための skill か

moyu-ko は、過剰設計が始まる前に止めるためのコード編集 skill です。AI に対して、最小限で正しい変更だけを行わせ、ユーザーが求めた範囲の中に収め、追加の抽象化・テスト・ドキュメント・依存関係を、明示的に求められていない限り増やさないようにします。

どんな人がインストールすべきか

既存コードのパッチ適用、狭い範囲のバグ修正、リライトなしの最小変更を AI に任せたいことが多いなら、moyu-ko skill の導入に向いています。正確な diff、レビューの速さ、実装の変更量を抑えることを重視するチームには特に相性が良いです。

何が違うのか

「簡潔にして」とだけ伝える一般的なプロンプトと違い、moyu-ko は明確なガードレールを組み込みます。つまり、要求されたファイルだけを編集し、実装は最もシンプルなものを優先し、依頼内容が曖昧なときは止まって確認する、という振る舞いです。スコープの制御が広いリファクタリングより重要な moyu-ko for Code Editing で特に役立ちます。

moyu-ko skill の使い方

インストールして有効化する

まずディレクトリ標準のインストール手順で moyu-ko install を実行し、その後、明確にコード編集を求めるタスクで skill を呼び出します。たとえば、「src/auth.ts のこのバグを直すのに必要な最小変更だけを、moyu-ko で行って」といったプロンプトがよい起点になります。

範囲が限られたタスクを渡す

moyu-ko usage のパターンが最も効くのは、次の点をはっきり指定したときです。

• 触るべき正確なファイル、またはパス
• 期待する動作の変更
• 変えてほしくない箇所
• 「新しい依存関係は追加しない」「テストは追加しない」などの既知の制約

より強い入力例:

src/cart.ts を更新して、割引がログイン済みユーザーにだけ適用されるようにしてください。ほかの価格計算ロジックは変更せず、新しいファイルも作らないでください。

弱い入力例:

チェックアウトの流れを改善して。

先に読むべきファイルを見極める

最速の moyu-ko guide ワークフローでは、まず SKILL.md を読み、その後、リポジトリ内で変更対象の面を定義しているファイルを確認します。この skill リポジトリは意図的に小さいため、価値があるのは追加のサポートフォルダを探すことではなく、振る舞いのルールを理解することです。

最小 diff を明示して依頼する

skill をうまく機能させたいなら、可能な限り小さい編集だけを求め、必要な制約をはっきり伝えてください。たとえば:

api.ts を moyu-ko でパッチしてください。変更は validation branch のみに限定し、新しい helper は追加せず、他のファイルに触る前に確認してください。

moyu-ko skill の FAQ

moyu-ko はコード編集専用ですか？

はい、それが想定用途です。moyu-ko skill は、広い意味での計画立案やアーキテクチャ作業、ゼロからの足場作りではなく、規律ある編集のためのものです。設計変更が必要なら、通常のプロンプトのほうが適している場合があります。

どんなときに moyu-ko を使わないべきですか？

複数のアプローチを比較したい、補助テストを追加したい、隣接コードまでまとめて整理したい、という場面では moyu-ko は使わないほうがよいです。価値の中心はスコープ管理にあるため、自由度の高いリファクタリングとは相性が悪いことがあります。

初心者にも使いやすいですか？

変更内容を明確に説明できるなら、使いやすいです。skill のルール自体はシンプルですが、依頼に最初から境界があるほど性能を発揮します。初心者が最良の結果を得やすいのは、ファイル名、期待する動作、そして「触らないでほしい範囲」を明示したときです。

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

通常のプロンプトでも最小変更は依頼できますが、moyu-ko はそれを標準の動作モードにします。その結果、集中した編集だけを望んでいたのに、誤って書き換えが広がったり、抽象化が増えたり、余計なファイルが追加されたりするリスクを下げられます。

moyu-ko skill を改善するには

スコープ指示をさらに絞る

品質が最も大きく上がるのは、編集対象を狭めたときです。正確なファイル、変更する最小範囲、期待する結果を伝えてください。依頼が具体的であるほど、moyu-ko が確認待ちで止まりにくくなり、過剰編集もしにくくなります。

明確な境界条件を入れる

触ってほしくないものがあるなら、はっきり書いてください。役立つ境界条件の例は次のとおりです。

• 「新しい helper 関数は追加しない」
• 「新しい依存関係は追加しない」
• 「public API は変更しない」
• 「可能なら diff は 10 行未満にする」

こうした制約は、moyu-ko for Code Editing がレビューしやすい出力を作る助けになります。

タスクが曖昧なら質問が返ると想定する

よくある失敗は、対象を十分に指定せず、残りはモデルが推測してくれると期待してしまうことです。依頼が他のファイルに影響する可能性がある、または新しい抽象化が必要になるなら、moyu-ko は止まって質問するべきです。それは不具合ではなく、むしろ仕様です。

全体設計ではなく、最初のパッチを詰める

最初の出力が広すぎるなら、タスクを広げるのではなく、次の指示をもっと絞り込んでください。たとえば「モジュール全体を整理して」ではなく、「入力を解析する行だけにして」と依頼します。そうすることで moyu-ko usage を、その最小変更設計にきちんと沿わせられます。