mcpField
R
review-writing

review-writing

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

review-writing について

review-writing は、指定された文章を適用される文章規範に照らして確認するスキルです。ドキュメントと人間の声を重視する文章を区別し、根拠のある指摘を報告します。編集するかどうかは執筆者が決めます。

主な機能

  1. 01ファイル、ディレクトリ、glob、貼り付け文の確認
  2. 02ドキュメントまたは文体規範の選択
  3. 03共通の文章要件の確認
  4. 04影響に基づく指摘の評価
  5. 05根拠と具体的な修正案の報告

活用シーン

  1. 01技術ドキュメントのレビュー
  2. 02記事やマーケティング文の確認
  3. 03指定ポリシーに照らした文章評価

インストール

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

$npx skills add https://github.com/doodledood/manifest-dev --skill review-writing

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

同梱ファイル

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

references/
DOCS-STYLE-REFERENCE.md
PROSE-FLOOR-REFERENCE.md
WRITING-REFERENCE.md

詳細

review-writing — 独自の文体で文章をレビューする

文章が、それを規定するライティング基準から逸脱している箇所を報告します。レビューのみを行います。問題を見つけて説明するのはあなたの役割で、修正するかどうかは作者が決めます。

入力

$ARGUMENTS にはレビュー対象を指定します。ファイルパス、ディレクトリ、glob、または貼り付けたテキストを指定できます。また、文体を明示的に指定して検出結果を上書きすることもできます(register=docs、register=voice)。マニフェストゲートの Evidence は、実行で選択された評価者のもとで文体を指定し、このスキルを有効にします。ゲートには文体と、呼び出し側が選択した合格基準が示されます。

引数がない場合は、作業ツリー内で最も最近更新された文章ファイルをレビューし、どのファイルを選んだかを伝えます。対象を一意に決められない場合や、文章らしいファイルに変更がない場合は、推測せず、レビュー対象を尋ねます。尋ねる相手がいない場合は、Evidence が最も強く裏付ける候補をレビューし、その前提をレポートの冒頭で明示します。候補がまったくない場合は、不足しているものを明記して BLOCKED と報告します。

文体と評価

文体は2種類あり、それぞれ独自のルールがあります。指摘は影響の大きさで分類します。合格基準は呼び出し側が提示します。

文体対象ルール
docs仕様書、提案書、レポート、正式および技術的なドキュメント、README、参考資料、API ドキュメントreferences/DOCS-STYLE-REFERENCE.md
voice記事、ブログ投稿、マーケティングやソーシャルメディア向けの文章、ニュースレター、物語、創作references/WRITING-REFERENCE.md

各文体には、共通の最低基準も適用されます。references/PROSE-FLOOR-REFERENCE.md には、アクセシビリティとインクルーシブな言葉遣いの最低基準を含め、両方に共通するルールが記載されています。この最低基準に関する指摘も、文体固有の指摘と同じ基準で評価し、報告します。最低基準だけを対象にした個別の実行方法はありません。

各指摘は、読み込んだ文体の深刻度尺度で評価します。どちらの尺度も影響の大きさに基づき、Low はどのような種類の指摘であっても、表現を磨く程度のもの、または軽微なものを示します。読み込んだ文体の基準は、読者に生じる具体的な不利益を定めています。明示された要件は引き続き拘束力を持ちます。正確性や安全性の不備、または明示された約束の不履行が Low と評価された場合は、呼び出し側の基準を適用する前に、Evidence に基づいて再評価します。

合格主張と、意図的に要求する深刻度またはカテゴリの基準は、呼び出し側が提示します。主張に基づくゲートでは、失敗とされる各項目について、想定読者、意味または効果とのつながりを示し、具体的な不利益を説明します。深刻度の評価だけでは、その主張を否定できません。提示された明示的な閾値は維持します。ゲートの指定がない場合は、結論を出さずに分類を返します。復元可能な主張や基準がないまま結論を求められた場合は、質問するか BLOCKED と報告します。必要な Evidence が不足している場合は未解決のままとします。また、指摘が空であることだけでは、品質が高いとは証明されません。

読み込む参照ファイルは正確に2つにしてください。共通の最低基準と、選択した文体の参照ファイルです。1つのテキストに対して、両方の文体のファイルを読み込んではいけません。両者のルールは意図的に相反しており、誤った文体に基づく指摘はノイズになります。

文体の判定

テキストの目的を判断できるだけの範囲を読みます。ドキュメントは説明や仕様を示します。つまり、何かの仕組みや手順を読者に伝え、その価値は読者が内容に従うことで発揮されます。人間の声で書かれた文章は、説得、物語、娯楽を目的とします。視点を伝え、その価値は読者が読むことで発揮されます。

テキストに両方の要素が実際に混在する場合(物語から始まるチュートリアルや、途中から参考資料のようになるリリース告知など)は、本文の大部分を占める文体を選び、その理由を1行で伝えます。また、もう一方の文体のルールは適用していないことを明記します。

どちらの文体か本当に判断がつかない場合は、その旨を伝えて質問し、黙って一方を選んではいけません。尋ねる相手がいない場合は、より近い文体を選び、その前提をレポートの冒頭で明示します。register= が明示されている場合は常にそれを優先し、説明は不要です。

優先順位

プロジェクト独自のスタイルシートや AUTHOR_VOICE.md、およびセッション中にユーザーが示したルールやコンテキストファイル内のルールは、どの文体でも、同梱の参考資料より優先されます。レビューの前に、それらがないか確認してください。参考資料と異なるルールが定められている場合は、そのルールが適用され、参考資料の記述については指摘しません。ただし、適用される文体基準で重大(CRITICAL)に該当する指摘は引き続き報告し、そのルールを明記してください。適用したスタイルの参照元をレポートに記載してください。

報告

各指摘には、以下を含めてください。

  • 重大度とルールの領域
  • 場所を添えた、該当する文章の正確な引用
  • ルールが求める内容と、この箇所がそれを満たしていない理由
  • 具体的な修正案。1行で足りる場合は書き換えた行を、そうでない場合は変更の概要を示してください

指摘は、重大度の高い順、次に本文内の位置順に並べてください。

問題のない文章も、きちんとした結果です。その旨を明確に伝え、適用した文体と参照資料を示して、そこで終えてください。徹底しているように見せるため、些細な指摘を付け足してはいけません。捏造された指摘は、著者が得るものよりも多くの注意を奪います。同じパターンが文章内に多くある場合は、1件の指摘で代表例を2、3件と件数を示してください。1件ずつ個別に指摘する必要はありません。

ルールをこの文章に適用するかどうかが判断の分かれるところであれば、欠陥と断定するのではなく、その指摘の中で判断の余地があると述べてください。

対象範囲と、このスキルの対象外

このスキルは、ユーザーがレビュー対象として指定した文章を、依頼に応じて、どの文体でもレビューします。文章全体を読み、スタイル基準に照らして評価します。コード変更内のコメントやドキュメントの段落がそもそも必要かどうかは別の問題であり、このスキルでは扱いません。

レポートを受け取った後に修正の適用を依頼された場合、それは別の依頼であり、通常の編集として対応します。

コメント