moyu-strict

moyu-strict skill の概要

moyu-strict とは

moyu-strict は、コード編集における過剰設計を厳しく防ぐためのガードレール skill です。狙いは、きれいな再設計ではなく、必要最小限で安全な変更にとどめることです。主な役割は、要求を満たしつつも、エージェントが余計なファイルに触れたり、抽象化を増やしたり、無関係なコードを「改善」したりするのを防ぐことにあります。

どんな人に向いているか

この moyu-strict skill は、既存コードベースで範囲の狭い修正に取り組むレビュー担当者、メンテナー、エージェントに特に向いています。最小限の diff、予測しやすいレビュー、偶発的な副作用の回避を重視するなら、moyu-strict for Code Editing はかなり相性が良いです。探索的なリファクタリング、アーキテクチャ作業、広範囲の整理には、それほど向いていません。

何が違うのか

実際の違いは「強制力」にあります。moyu-strict は単なる「より良いコードを書こう」という prompt ではなく、範囲の管理、編集の дисциплина、節度を中心に据えています。特に効くのは、明示的なルール群です。編集前にスコープを確認すること、新しい抽象化レイヤーを増やさないこと、依頼されていない docs/tests/dependencies を追加しないこと、そして変更が依頼内容に対して大きくなりすぎそうなら止めることです。

moyu-strict skill の使い方

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

moyu-strict install に対する repo の skill install フローを使い、コード変更の範囲を狭く保ちたい場面で読み込みます。環境がコマンドベースの installer を使うなら、重要なのは、モデルが編集を始める前に moyu-strict を適用しておくことです。そうすることで、制約がレビューだけでなく最初の下書きから効くようになります。moyu-strict usage としては、設計セッションではなく targeted fix のたびに有効化するのが基本です。

まず正しいファイルを読む

最初に読むべきなのは skills/moyu-strict/SKILL.md です。ここに strict なルールと activation の挙動がまとまっています。この repo には skill ファイルが 1 つしかなく、helper scripts、references、rule folders もないため、隠れた workflow tree を追いかける必要はありません。ユーザーに必要なのは拡張的な repository tour ではなく、ルール本文そのものです。

ざっくりした依頼を strict な prompt に変える

この skill は、依頼の中で target と境界がすでに明確に示されているときに最もよく機能します。強い入力の例は、次のようなものです。「src/parser.ts の null crash を修正し、このファイルだけを編集してください。tests、comments、refactoring は追加しないでください。」弱い入力の例は、「この module を改善して」です。前者なら moyu-strict が制約をかけやすく、後者は scope drift を招きやすくなります。

編集前確認の workflow で使う

良い moyu-strict guide の流れは、影響を受ける file か function を特定し、意図する変更を明示し、他の file は動かさないと確認したうえで編集に入ることです。もし task にもっと広い変更が必要そうなら、そこで止めて、より小さい version でよいかを確認します。これは、この skill が最も重視する価値、つまり diff になる前に過剰な拡張を見える化することに合っています。

moyu-strict skill の FAQ

moyu-strict は普通の prompt と同じですか？

いいえ。通常の prompt は簡潔な code を求めることはありますが、moyu-strict は編集境界の強制そのものを目的にしています。本当に問題になりやすいのが誤ったロジックではなく、不要な追加変更である場面で最も価値があります。

どんなときに使わないほうがいいですか？

本当に coordinated rewrite、新しい abstraction、documentation refresh、test harness creation が必要な task では使わないでください。結果として広めの整理が必要なら、この skill の「minimal PR」寄りの bias が、本来の目的とぶつかることがあります。

初心者にも向いていますか？

はい。ルールがシンプルで具体的だからです。初心者がやりがちな失敗は、曖昧な依頼を出しておいて skill が境界を汲み取ってくれると期待することです。moyu-strict は、何を変えるべきかだけでなく、何を変えてはいけないかまでユーザーが言えると、よりうまく動きます。

一般的な code editing prompt とは何が違いますか？

一般的な prompt は、完了を優先して最適化されがちです。moyu-strict は restraint を優先します。scope creep に異議を唱えること、装飾的な変更を避けること、review しやすい大きさの diff に保つことを agent に求めます。そのため、feature 拡張よりも maintenance work に向いています。

moyu-strict skill を改善するには

編集境界を具体的に指定する

品質が最も上がるのは、最初に file、function、意図する成果をはっきり示すことです。「これをきれいにして」ではなく、「src/auth.ts だけを変更して空トークンを処理し、それ以外は触らない」と書いてください。そうすることで、moyu-strict が可能な限り狭い応答を強制しやすくなります。

何を禁止するかを明示する

moyu-strict は exclusions を軸にしているので、追加してほしくないものも伝えるべきです。たとえば、新しい helper なし、comments なし、tests なし、dependency changes なし、formatting-only edits なし、といった具合です。この skill の価値は、余計な追加を拒むことにあり、より広い解決策を勝手に発明することではありません。

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

最もありがちな失敗は、小さく始まった request が、気づかないうちに redesign に広がることです。その場合、改善すべきなのは「もっと code quality を上げること」ではなく、task を小さくすることです。まずは受け入れ可能な最小パッチを求め、必要ならそこから反復してください。そうすることで、moyu-strict skill は strict な diff 制限と minimal-change の思想にきちんと沿えます。

小さな初回パッチから反復する

最初の出力が広すぎるなら、1 つの症状、1 つの file、1 つの outcome に絞って prompt を詰めてください。逆に、最初の出力が浅すぎるなら、最も重要な不足制約だけを追加します。たとえば「signatures を変えない」「call sites を修正しない」といった具合です。moyu-strict skill のユーザーは、長い instructions よりも、境界を鋭くするほうがたいてい良い結果につながります。