mcpField
P
prose-editing

prose-editing

github.com/redhat-developerドキュメント1942 回インストール1 日前に更新
リポジトリ

prose-editing について

prose-editingは、主張や条件、適用範囲を保ちながら既存の文章を編集するスキルです。文書の目的や指示に応じて文体を選び、書き換えと変更なしの監査を区別します。

主な機能

  1. 01主張を変えずに文章を編集
  2. 02目的や指示に応じた文体選択
  3. 03書き換えと監査の両モード
  4. 04意味と範囲の保持を確認
  5. 05コードなど指定箇所を保護

活用シーン

  1. 01技術文書の簡潔化
  2. 02意味を保った告知文の書き換え
  3. 03文章を変更せず問題点を監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/redhat-developer/rhdh-skills --skill prose-editing

インストール後、Claude Code で/prose-editingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
compression.md
mechanical.md
voice.md
scripts/
lint.py
NOTICE

詳細

散文の編集

主張を変えずに既存の草稿を編集します。呼び出し元は散文を提示し、分かる場合は文体も指定します。このスキルを別のスキルが呼び出した場合は、散文のみを返します。

操作を選ぶ

明示された編集の意図を優先します。書き直し、簡潔化、または自然な表現への変更を求める依頼は、指摘やスコアも求めている場合でも編集として扱います。

変更しないこと、監査、または書き直しを伴わない指摘を明示的に求められた場合に限り、audit を使用します。別の人が書いた文章だからといって、自動的に編集不可になるわけではありません。第三者からの引用部分は保護しますが、周囲の草稿について書き直しを求められた場合は、その提案または実行を行います。

主な文体を選ぶ

呼び出し元が文体を指定している場合は、それを優先します。それ以外の場合は、文書の主な用途に基づいて選びます。

文体主な用途読み込む参照資料
strict手順書、運用手順、安全に関するテキスト、オペレーター向けエラーmechanical と compression の全体
flavoredREADME、技術文書、PR または MR の本文、Jira の文章、コードコメントmechanical と compression の共通部分
voicedお知らせ、コミュニティ向けメッセージ、ブログ記事、個人的な文章mechanical と voice
audit明示的な変更なしの確認3 つすべての参照資料。提案は文書の主な用途に従う

著者名よりも用途を優先します。著者名が記載された技術 README も flavored です。用途が本当に曖昧で、選択を誤ると書き直しに大きく影響する場合は、要点を絞って 1 つ質問します。それ以外の場合は、構成を最も変えない voiced を使用します。

主スコアには数値を 1 つだけ使用します。文体の対応表を独自に作成してはいけません。複数の文体が混在する文書では、主な文体を維持し、手順や安全に関するセクションには strict のルールを手作業で適用します。この局所的な上書きによって、スコアを追加してはいけません。

ユーザーが自分の文章のサンプルを提示した場合は、草稿を読む前にそのサンプルを読みます。安定した文のリズム、語彙、句読点、つなぎ表現、癖を、voiced の編集に反映します。サンプルに基づいて、ダッシュ、カール引用符、繰り返される書き出しなど、それ単独では意図的な習慣を示す根拠として不十分な特徴を採用してもかまいません。

安全な作業用コピーを用意する

インストール済みのこのスキルの隣には、決してファイルを書き込まないでください。システムの一時ディレクトリ API を使って、一意のディレクトリを作成します。以下のパスはすべて、そのディレクトリ内に置きます。

  • source.md:意味の確認に使う、変更していないスナップショット。
  • rewrite.md:編集前後のスコアリング対象となる唯一のファイル。このファイルを編集します。
  • before.json:正規化された rewrite.md の正確なパスに対するベースラインレポート。
  • voice.md:ユーザーが文章サンプルを提示した場合に、その変更していないスナップショットを保存するファイル。

テキストが貼り付けられた場合は、提示されたバイト列を source.md に書き込み、それを rewrite.md にコピーします。ユーザーファイルの場合は、そのファイルを両方のパスにコピーし、書き直しがすべてのガードを通過するまで元ファイルに触れないでください。ホストが対応している場合は、プロセス引数配列を使用します。シェルが不可避な場合は、信頼されたスキルディレクトリとすべての一時パスを含め、すべてのパスを引用符で囲みます。ユーザーが指定したパスを、引用符で囲まずにコマンドへ貼り付けてはいけません。

ユーザーが文章サンプルを提示した場合は、その正確なバイト列を voice.md にコピーし、両方のリンター実行時に --voice-sample "<unique-temp-dir>/voice.md" を指定します。サンプルがない場合は、両方の実行でこのオプションを省略します。異なるサンプル、または変更されたサンプルを使う場合、ベースラインとの互換性はありません。

この SKILL.md を基準に scripts/lint.py の場所を解決します。文章サンプルがない場合、同等のシェル形式は次のとおりです。

python "<skill-dir>/scripts/lint.py" --json --register <register> \
  "<unique-temp-dir>/rewrite.md" > "<unique-temp-dir>/before.json"

サンプルがある場合は、文体の引数の後に --voice-sample "<unique-temp-dir>/voice.md" を挿入します。

ホストの UTF-8 ファイル API、または一時ディレクトリ内へのリダイレクトを使用します。固定名の before.json は使用しないでください。引き渡し後、一意のディレクトリを削除します。

編集ループ

audit を行う場合は、監査に進んでください。編集する場合:

  1. レジスターで指定された参照資料を読み込みます。適用されるルールをすべて確認してください。

  2. rewrite.md を採点し、完全な JSON を before.json として保存します。

  3. すべての violations、samples、markers、手動チェックを確認します。スコアがゼロでも、マーカーや判断が必要なルールがクリアされたことにはなりません。

  4. 非公開のソース目録を作成します。すべての命題、条件、例外、適用範囲の限定、法的効力、名前、数値、バージョン、日付、引用、出典、識別子、安全上の影響を記録します。

  5. rewrite.md を書き直します。複数のパターンが1つの段落に集中している場合を除き、役立つ最小限の範囲を変更します。その場合は、具体的な要点を中心に段落を書き直してください。

  6. 同じ正規化済みの rewrite.md パスを、before.json に対して採点します。

    python "<skill-dir>/scripts/lint.py" --json --register <register> \
      --baseline "<unique-temp-dir>/before.json" \
      "<unique-temp-dir>/rewrite.md"
    

    ベースラインで文体サンプルを使用した場合は、レジスターの後に同じ --voice-sample "<unique-temp-dir>/voice.md" 引数を追加します。

    ベースラインのメタデータまたはパスが一致しない場合、検証は失敗であり、スコアとして扱いません。呼び出しを修正して再実行してください。別のレジスター、引用ポリシー、ファイル、リンターのスコアバージョンからのレポートを再利用してはいけません。

  7. 書き直しと採点のパスは、さらに1回まで実行できます。

  8. source.md と rewrite.md を双方向に比較します。ソースの命題と限定事項はすべて維持され、出力の命題はすべてソースまたは明示的なユーザー指示に由来している必要があります。ソース自体が変更を認めていない限り、must、should、may、can、不確実性、否定、例外を維持してください。

  9. 手動チェックリストと敵対的な最終確認を行います。「まだ生成文のように聞こえる箇所はないか?」「消えてしまった事実や制限はないか?」「この書き直しで何を追加したか?」と自問してください。これらの質問で見つかった欠陥を修正します。

  10. 最終文を、ここで初めて指定された保存先にコピーします。ユーザーファイルの場合は、保護対象の箇所を維持しながら本文を置き換えます。貼り付けられたテキストの場合は、書き直した内容を返します。

Python を実行できない場合は、同じ参照確認、目録作成、敵対的な確認を目視で行います。lint 未実施と明記し、推定値は報告しないでください。

監査

書き直しや出力ドキュメントの作成は行わないでください。

  1. 3つの参照資料をすべて読み込み、指定された作業コピーを --register audit で1回採点します。
  2. ドキュメントの目的から主要なレジスターを推定します。各検出箇所を、適用対象、レジスター対象外、誤検出に分類します。
  3. 主張の維持、文体サンプルとの競合、名前や書き出しの繰り返し、冠詞の使用、段落の焦点、内容を繰り返す見出し、内容の薄い段落など、すべてのマーカーと手動ルールを確認します。
  4. 単一のスコア、ソースの主張・条件・適用範囲の目録、簡潔な検出結果の表を返します。表には、ルール、ソース内の該当箇所、分類、編集案を記載します。変更は加えないでください。

保護対象の箇所と Markdown

コードフェンス内またはインラインのコード、コマンド、識別子、部品番号、単位、検索に使われるエラー文字列、YAML フロントマター、データ、リンク先は決して変更しないでください。リンクテキストは本文として扱います。文脈から引用、タイトル、検討対象の例、または外部所有のテキストだと特定できる場合は、引用された第三者の文言を維持してください。

引用ブロック、コールアウト、表のセルは、それだけで引用とは限りません。第一者の本文はリンターで確認し、編集してください。実行中の本文が、除外する必要のある例または第三者からの引用だと依頼者が明示した場合に限り、--quote-safe を使用します。このオプションは、保護された領域内の検出結果のみを抑制します。ドキュメントの他の部分にある通常の第一者の本文を隠してはいけません。

レポートを読む

JSON オブジェクト全体を確認してください。終了コードだけで判断しないでください。

キー意味
violations と samplesスコアに加算される信頼度の高い件数と、その例
markers状況に応じた判断が必要で、スコアには加算されない可能性のある問題
by_layerスコア対象の各カテゴリを管理する参照レイヤー
manual_checksリンターでは認定できないルール
file_identity、voice_sample_identityベースライン比較の安全性を確保する正規入力
delta互換性のあるベースラインの before、after、improved の値
total_per100w品質の判定ではなく、主要な密度スコアの 1 つ
fail_over、over_fail_over呼び出し側が任意で指定する有限かつ非負の CI 閾値とその結果。--fail-over N が指定されていない場合は含まれません

単独での語調の変化、曲線引用符、全角ダッシュ、短い強調文、意図的な反復は、機械生成された文章の証拠ではなく、マーカーです。参照資料に記載された反復パターンまたは集中パターンを形成している場合にのみ、スコアに加算してください。voiced では、提示された文体サンプルがこれらのスタイル既定値より優先されます。

提出

呼び出し元返す内容
最終的に外部へ送る文章を編集する別のスキル最終文章のみ。文体とスコアのメタデータはトランスクリプトに残します
文章を貼り付けた人最終的なリライト、文体、スコアの差分、未解決の指摘
ファイルを提供した人ファイルを編集してから、文体、スコアの差分、未解決の指摘を報告します
明示的な audit指摘事項とスコア 1 つ。リライトはしません

別のスキルがこのパスを呼び出すのは、自由形式の文章をすべて作成した後、その文章を表示、判定、投稿する前の 1 回だけです。転送レイヤーから呼び出してはいけません。構造化ペイロード、コマンド、チェックサム、生成レポート、ADR、AGENTS ファイル、スキル、PRD、または他の執筆スキルが管理するローカル文書には、自動的に適用しないでください。ユーザーが明示的に依頼した場合は、どのような文章ドキュメントでも編集できます。

完了条件

次のすべてを満たした場合にのみ、作業は完了です。

  • 操作と主要な文体が、呼び出し元の意図に合っている。
  • 変更前と変更後のレポートが、同一の正規 rewrite.md、文体サンプル、スコアのバージョン、文体、引用符ポリシーに基づいている。そうでない場合は、応答に 未 lint と記載する。
  • スコア対象の違反、マーカー、該当する手動ルールのすべてが修正されている、具体的な誤検知の理由を添えて却下されている、監査で対象外と分類されている、または未解決として報告されている。
  • 双方向の項目照合により、原文の主張、適用範囲の制限、条件、法的効力の強さが失われておらず、裏付けのない主張が追加されていないことを確認できている。
  • 保護対象のバイト列が変更されていない。
  • 敵対的な視点で最終確認を行い、未報告の欠陥が残っていない。
  • 提出内容が上の表に従っている。
  • 一意な一時ディレクトリが削除されている。

コメント