meaning-preserving-rewrite

意味を保った書き換え

成果

方針、計画、標準、メモ、レポート、テンプレートを、ルールや決定を削除したり、弱めたり、適用範囲を広げたり、隠したりせず、明確な文章に書き換えます。

適用条件と範囲

ユーザーから方針や計画の文言を簡潔にするよう求められた場合、管理対象の成果物に定められた文体が必要な場合、すべての条項を維持したまま短縮する必要がある場合、またはパッケージにベースライン、台帳、書き換え、証明が必要な場合に使用します。

通常のコードリファクタリング、詳細を省略してよい通常の要約、単発のクリエイティブコピーには使用しないでください。

必須の構成

リソースゲート：ここで指定するパッケージファイルを使用する前に、mise run validate を実行してください。

スキルパッケージも変更する作業、またはホストの執筆方針に依存する作業に着手する前に、依存関係の調整を読んでください。このスキルは、条項レベルの意味と文体を扱います。同じパッケージに簡略化を担当するピアがインストールされている場合、そのピアがパッケージのモードと分解を担当します。

同等の担当がない場合は、パッケージの境界を変更しないでください。不足している依存関係をでっち上げたり、それを避けるために分岐を弱めたりしないでください。

執筆標準

リソースゲート：ここで指定するパッケージファイルを使用する前に、mise run validate を実行してください。

• 結果またはルールから書き始めます。
• 一般的な言葉、能動態、自然な短縮形を使います。
• 可能な場合、箇条書き1つにつきルールを1つにします。
• 担当者、ファイル、コマンド、数、チェックを明記します。
• 技術用語は初出時に定義します。
• 正確なパス、コマンド、ハッシュ、設定名、引用元の文、バックアップ、生の出力を保持します。
• must、must not、may、prefer を使って、要件の強さを明確に保ちます。
• 例外の範囲は、その根拠となる情報源と同じく限定します。
• 以前の会話の文脈に依存しないでください。
• em ダッシュと en ダッシュ、埋め草、曖昧な表現、整えすぎた締めくくりは避けます。
• 見出し、段落、リストの間に読みやすい間隔を保ちます。
• 常に必要なルールは親ファイルに記載します。分岐ごとの詳細は、親へのリンクを戻す適切な担当のファイルにのみ移動します。
• 管理対象の各 Markdown ファイルを、ホスト側の制限サイズ未満に保ちます。サイズ制限を満たすためだけに読みやすい間隔を削除しないでください。

最終的な文章の確認を行う前に、文体チェックを読んでください。

手順

1. ベースラインを記録する

リソースゲート：ここで指定するパッケージファイルを使用する前に、mise run validate を実行してください。

1. 記憶から再構成するのではなく、現在の情報源を読みます。
2. 現在存在する情報源ごとに、パス、ハッシュ、バイト数、行数、見出し、モードを記録します。
3. 将来のパスは、ハッシュをでっち上げずに不在として記録します。
4. 現在の各ターゲットを担当者専用のバックアップにコピーし、バイト単位で同一であることを証明します。
5. 書き換えの動作に影響する場合は、情報源とリポジトリの状態を記録します。
6. 説明のつかない情報源の変化があれば、作業を停止します。

項目とチェックについては、ベースラインと台帳の契約を使用してください。

2. 意味の台帳を作成する

情報源の各条項に、固定のIDを割り当てます。複数のルールを含む段落は分割します。

各条項について、情報源、正確なテキスト、意味、要件の強さ、移動先、置き換え後の文、アクション、レビュー状態を記録します。使用できるアクションは keep、split、move、clarify です。drop は決して使用しないでください。

新しい文体ルールと、計画されたすべての成果物に同じ文体を適用するルールを追加します。生成する台帳では、マップとタプルの形状を一貫させます。

3. 現在の情報源を確認する

リソースゲート：ここで指定するパッケージファイルを使用する前に、mise run validate を実行してください。

書き換えが公式ドキュメント全体またはプリミティブ全体を網羅すると主張する場合、書き始める前に現在の公式情報源一式を一覧化します。古いスナップショットを信用したり、存在しないページをでっち上げたりしないでください。ドキュメント一覧の契約に従ってください。

4. 書き換える

1. 受け入れられたすべての意味と要件の強さを維持します。
2. 常に必要なルールは親成果物に記載します。
3. 分岐ごとの詳細は、適切な担当のリンク先ファイルにのみ移動します。
4. 各手順の正規の担当を1つにします。
5. 文言やセクションを変更するたびに、台帳のターゲットを更新します。
6. 現在のファイルとバックアップを差分比較し、実質的な各ブロックを台帳のIDに結び付けます。

5. 検証

リソースゲート：ここに記載されたパッケージファイルを使用する前に、mise run validate を実行してください。

次のすべてを確認します。

• 台帳の完全な網羅、一意の ID、許可されたアクション、承認済みのレビュー状態、指定されたターゲットの存在。
• 行数と文字数の上限、リンク、コンテキストの読み込み、ハッシュ、モード、シークレットの安全性。
• 文章部分のみの文体。正確さを保つ必要がある引用、バックアップ、生の出力、インラインコード、コードフェンスは対象外にします。
• 全文を読み返した際の明確な文法。
• 人間による報告と機械による報告の一致。
• コンポーネントの結果と変更全体のステータスの区別。

文章とコードが混在する内容全体に対して、短縮形や句読点を一括置換しないでください。該当する文章だけを修正し、近くのコードと構文を再確認してください。

一時的な検証ツールは OS の一時ディレクトリに置き、使用後に削除してください。対象を絞った検証は、テストスイートが成功した結果ではなく、臨時の検証であると明記してください。

レビュー用パケットと完了処理には、検証契約を使用してください。別のレビュアーを待つと許可済みの主要作業が止まり、外部ルールでレビュアーが必須とされていない場合は、メインワーカーで同じ確認を行い、独立したレビューではないことを明記してください。

証明の基準

次のすべてを満たす場合に限り、PASS を返してください。

• すべてのソース条項に承認済みの対応付けがあり、アクションに drop がない。
• すべての置換で、ソースの意味、範囲、例外、強さが維持されている。
• ベースラインとバックアップのハッシュが引き続き一致している。
• すべてのリンク先が存在し、台帳と一致している。
• 文体、文法、セキュリティ、パッケージの各チェックに合格している。
• コンポーネントの結果を、変更全体の証明として提示していない。
• 一時的な検証ファイルが残っていない。

範囲を限定したコンポーネントの証明には合格しているものの、全体の基準を満たしていない場合は PARTIAL を使用してください。ソースの変更、権限の不足、証拠へのアクセス不能、または未解決の依存関係により、安全な書き換えができない場合は BLOCKED を使用してください。

よくある失敗

• まだ存在しないパスのハッシュを計算する。
• ソースの箇条書きや限定的な例外を省略する。
• 正確なルールを曖昧な要約に置き換える。
• 文言の修正後に古い台帳の記述を残す。
• チェッカーデータやインラインコードを文章としてスキャンする。
• ファイル全体のクリーンアップでコード例を壊す。
• コンポーネントの PASS を変更全体の PASS として報告する。
• メインワーカーがレビューを行ったのに、独立したレビューと主張する。
• 一時的なビルダーや古いレビュー用パケットを残す。

パッケージのリソース

フィールドテンプレートとして assets/meaning-ledger-template.json を使用してください。実行例については、examples/policy-rewrite.md、examples/blocked-drift.md、または examples/package-reconciliation.md を参照してください。パッケージのメンテナーは references/、mise run test、evals/ を使用し、その後 mise run ci を実行します。通常の書き換えでは、これらのパスを読み込みません。

ファクトリー実行契約

受け入れられる成果は、平易な言葉で文章を書き換えながら、名前付きの意味上の不変条件をすべて保持し、意味の損失を確認した記録を残すことです。変更する対象のオーナーを最小限にしながら、現在の意味上の不変条件の動作を維持してください。

1. mise run ci で現在のパッケージを凍結し、そのダイジェストを記録します。
2. mise run domain-research-policy を実行し、現在の意味上の不変条件のソースと反証材料を判断します。
3. 指定された意味上の不変条件の操作について、mise run agentic-request を実行します。意味に関する選択はモデルに委ねてください。
4. mise run decision-policy、mise run ci、動作評価を実行します。失敗した場合は、最も下位のオーナーに戻ってください。
5. mise run invocation-policy -- <receipt> を実行し、すべてのタスク、またはドメイン固有の不使用理由を説明します。
6. 任意で mise run improvement-policy を実行します。保護対象の次元が後退しない場合に限り、変更する次元は1つだけにします。

各契約が必要な場合に限り、assets/use-case-contract.json を mise run use-case-policy で、evals/evals.json を mise run evals で読み込みます。

再現可能な処理、順序、実行記録、チェックは Mise が担います。解釈、因果関係の判断、創造的な作業、コードでは得られない直接的な認識はモデルが担います。権限の不足、古い証拠、またはゲートの失敗があれば中止してください。