moyu-fr

moyu-fr skill の概要

moyu-fr は、つい作り込みすぎるエージェント向けのコード編集ガードレール skill です。特に、求められた行だけを編集すれば済む場面で、ファイル全体の書き換えや抽象化の追加、スコープ外の「改善」を避けつつ、最小限かつ正しい変更をしたい人に向いています。

moyu-fr は何のための skill か

moyu-fr skill は、パッチ型の作業に最適です。たとえば、外科的な修正、範囲の狭いリファクタリング、単発のバグ修正、そしてユーザーが明示的に「簡単に」「最小限で」「X だけ変えて」と求めるケースです。エージェントの意識を、本来やるべき仕事である「依頼された変更を入れて、そこで止める」に揃えやすくします。

この skill が他と違う理由

一般的なプロンプトと違い、moyu-fr には明確な過剰設計抑止ルールが組み込まれています。新しいレイヤー、余計な依存関係、起こりえないケースへの防御的コード、無関係なドキュメントやテストを抑制します。そのため、広さではなく抑制が成果物の質を左右する場面で特に有効です。

向いているユーザーと向かないケース

リポジトリやタスクが差分サイズ、アーキテクチャのブレ、不要な整理の影響を受けやすい場合は、Code Editing で moyu-fr を使うのが向いています。一方で、設計変更、機能拡張、テスト作成、広範なモダナイゼーションを本当に求めているなら、相性は強くありません。skill の最適化対象が「変更を最小化すること」だからです。

moyu-fr skill の使い方

インストールして有効化の経路を確認する

moyu-fr のリポジトリにある skill インストール手順を使い、エージェントが編集依頼から skill を検知できることを確認してください。moyu-fr install の判断が特に強いのは、もともと厳密なスコープ管理をワークフローに組み込んでいて、過剰設計の兆候が出たときに skill を自動で効かせたい場合です。

編集依頼は狭く具体的に書く

moyu-fr usage で最も効くのは、境界がはっきりした具体的な依頼です。良い入力では、対象ファイル、正確な振る舞いの変更、そして変えてはいけないものを明示します。

強い依頼例:

• “Edit src/auth.ts to fix the null check in validateSession; do not change error handling or add helpers.”
• “Update only the regex in README.md example; keep the rest of the snippet unchanged.”

弱い入力は広すぎます:

• “Improve the auth flow”
• “Clean up this module”
• “Make it more robust”

こうした依頼は拡張を招きやすく、まさにこの skill が防ぎたい方向です。

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

実用的な moyu-fr の使い方としては、まず SKILL.md を読み、そのうえでリポジトリが参照している関連ノートやタスク固有ファイルを確認します。この skill の現状では、主なシグナルは skill 本体です。そのため、最も有益なのは、指示内容、リポジトリツリー、そして実際に編集する直前のファイルを読む流れです。対象と最小許容差分を正確に言語化できないなら、まだプロンプトが曖昧です。

書き換えエンジンではなく、抑制フィルターとして使う

この skill は、望む結果をすでに把握していて、余計な変更だけを止めたいときに最もよく働きます。エージェントの編集を次の方向に寄せるためのものです:

• 行変更は最小限にする
• 要求がない限り新しい抽象化を追加しない
• 依頼されない限り追加のドキュメント、テスト、コメントを書かない
• パッチで足りるならファイル全体を書き換えない

moyu-fr skill の FAQ

moyu-fr は Code Editing 専用ですか？

はい、最も強くフィットするのは、スコープを厳密に絞った code editing です。オープンエンドな生成、アーキテクチャ設計、あるいは余分な足場が前提になるタスクには、あまり向いていません。

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

普通のプロンプトでも「シンプルに」とは言えますが、moyu-fr はその好みをより強い運用ルールに変えます。隣接する問題まで解決しようとしたり、周辺コードを書き換えたり、依頼されていない見栄えの調整を足したりしがちなエージェントに対して、特に意味があります。

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

はい、単一の具体的な変更を説明できるなら使いやすいです。ファイル名、症状、そして編集の正確な境界を言えるなら、最もスムーズに使えます。初心者がつまずきやすいのは skill が難しいからではなく、依頼が広すぎるときです。

いつ moyu-fr を使うべきではありませんか？

本当にリファクタリング、テスト網の拡充、新しい抽象化、システム強化が必要なときは使わないでください。その場合、skill の抑制が本来の目的とぶつかり、技術的には最小でも、結果として不完全な出力になりえます。

moyu-fr skill の改善方法

最初にもっと厳密な制約を伝える

moyu-fr を改善する最善策は、何を変えずに残すべきかを明示することです。ファイル名、対象行、そして “no new functions,” “no extra comments,” “do not touch formatting outside this block” のような除外条件を含めてください。こうした制約があるほど、推測の余地が減り、skill の最小編集挙動が安定します。

許容できる最小差分を要求する

moyu-fr usage をより良くしたいなら、成功条件を diff ベースで書くのが有効です:

• “Change only one branch condition.”
• “Patch the existing function instead of creating a helper.”
• “Preserve the current public API.”

これで、エージェントに「完了」の形が伝わり、スコープの膨張を防げます。

よくある失敗パターンに注意する

主な失敗は、意図しない拡張です。余計なバリデーション、余計な説明、あるいは親切に見えるが要求以上に変えてしまう整理が入りがちです。もう1つよくあるのは、実際には複数の小変更が必要なのに編集が足りなくなるケースです。その場合は、skill が早く止まりすぎないよう、必要な修正をすべて明示してください。

追補は、より狭くして繰り返す

最初の結果がまだ広すぎるなら、同じ依頼を言い換えるのではなく、次の指示をさらに絞ってください。たとえば “Keep the same logic and only adjust this condition” のほうが、 “make it smaller” よりずっと実行しやすいです。moyu-fr では、より良い入力とは、文脈を増やすことではなく、自由度を減らすことを意味します。