mcpField
U
unslop-review

unslop-review

github.com/mohamedabdallah-14テスト・品質16598 回インストール2 日前に更新
リポジトリ

unslop-review について

Pull Requestのレビューコメントを、直接的で実行可能な形で作成・書き直すスキルです。任意の重要度ラベルを使え、行番号や識別子、具体的な修正案や質問を保ちます。

主な機能

  1. 01直接的で実行可能なレビューコメント
  2. 02任意の重要度プレフィックス
  3. 03行番号と範囲の参照
  4. 04具体的な修正案や質問
  5. 05コメントのみを扱う範囲設定

活用シーン

  1. 01コード差分への要点を絞ったフィードバック
  2. 02バグ・リスク・スタイル上の問題の分類
  3. 03変更に関する具体的な質問

インストール

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

$npx skills add https://github.com/mohamedabdallah-14/unslop --skill unslop-review

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

詳細

Unslop Review

目的

丁寧さを演出するのではなく、チームメイトらしいPRレビューコメントを書き直す、または作成します。問題点は率直に、修正方法は具体的に、人には思いやりを持って伝えます。

トリガー

/unslop-review、/review、「このPRをレビューして」、「コードレビュー」、「レビューを人間らしい表現にする」、「このコメントの不自然な表現を直す」、「このフィードバックを人間らしい表現にする」。プルリクエストのレビュー時に自動で実行します。

形式

標準の形式:L<line>: <severity prefix> <observation>. <fix>.

重要度の接頭辞(任意ですが、重要度を示す必要がある場合は使用してください):

  • bug: — コードが壊れている、または壊れる
  • risk: — 現時点では動作するものの、将来的に脆くなる(パフォーマンス、競合状態、テスト不足)
  • nit: — スタイル、命名、デッドコード、「ついでに直すとよい点」
  • q: — 隠れた苦情ではなく、純粋な質問

複数ファイル:<file>:L<line>: <severity> <observation>. <fix>.

範囲:問題が複数行にわたる場合は L88-140: ...。

ルール

削る
  • 前置き:「気づいたのですが……」、「~のようです……」、「私には~に見えます……」
  • ためらいの重ねがけ:「もしかすると、おそらく、場合によっては、~したほうがよいのではないかと思ったのですが……」
  • 過剰な丁寧表現:「謹んで提案させていただきます……」、「ほんの小さな提案ですが……」
  • コメントごとの称賛:「この関数はいいですね。でも……」、「素晴らしいパターンですね。ただ……」
  • 差分の言い直し:「42行目に、getUser という関数があり、これは~を返していますが……」
  • 修正案のない単なる意見:「これはよくありません」だけで提案がない
残す
  • 正確な行番号と範囲
  • バッククォートで囲んだ識別子:findUser、req.body.id
  • 具体的な修正案、または具体的な質問
  • 修正が明らかでない場合に限り、「なぜ」を説明する
トーン

企業的ではなく、人間らしく。「X の場合、これは例外を投げます」と書き、「特定の状況下で例外を投げる可能性があり得ることを考慮する価値があるかもしれません」とは書きません。「と思います」、「おそらく」のように確度を調整する表現は問題ありませんが、わざとらしく柔らげる必要はありません。

自動で明確化するケース(ひと言ではなく、文章で書く)
  • セキュリティ上の指摘(CVE クラス、認証情報、シークレット)
  • 実質的な議論が必要なアーキテクチャ上の意見の相違
  • 新しいコントリビューター向けのオンボーディング情報
  • 本当に「問題ありません」と答えるケース

こうした場合は短い段落を使い、その後は簡潔な形式に戻します。

例

悪い例 → 良い例
  • 悪い例:この箇所に null チェックを追加することを検討してもよいかもしれないと、謹んで提案させていただきます。状況によっては何らかの問題につながる可能性があるためです。

  • 良い例:L42: bug: \findUser` は一致するものがない場合に undefined を返します。`user.email` にアクセスする前にガードするか、早期に 404 を返してください。`

  • 悪い例:素晴らしい実装ですね!ただ、関数をリファクタリングすると、可読性を高められる可能性があると思います。

  • 良い例:L88-140: nit: この関数は検証、I/O、マッピングを行っています。分割すると、正常系の流れを追いやすくなります。必要なら分割を一緒に進めます。

  • 悪い例:ここにリトライ処理がないことに気づきました。問題になる可能性があります。

  • 良い例:L23: risk: 429 の場合にリトライしません。正当なリクエストを取りこぼさないよう、呼び出しを \withBackoff(3)` で囲んでください。`

  • 悪い例:この実装では、堅牢なキャッシュ戦略を採用しています。

  • 良い例:(削除 — 中身のない称賛です。キャッシュに本当に注目すべき点があるなら、具体的な理由を説明してください。)

承認

変更に問題がなく、具体的な指摘がない場合は、単独の行に LGTM と記載します。定型文は不要です。

範囲

  • コメントのみ。コミット、git push、自動承認、リンターの実行は禁止です。
  • 出力はそのまま貼り付けられる形式にします。1行につきコメント1件、または各項目が明確に分かれたリストにしてください。
  • 重要度は正直に示してください。表現を和らげるために bug を nit に格下げしないでください。

コメント