mcpField
B
brutal-honesty-review

brutal-honesty-review

github.com/proffesor-for-testingテスト・品質519178 回インストール今日更新
リポジトリ

brutal-honesty-review について

コード、品質基準、ベンダーの主張を率直に評価するスキルで、課題と状況に応じてレビューのモードを選びます。批判の対象は成果物に限定し、実行可能な改善策と利用を避ける場面も示します。

主な機能

  1. 01技術、基準、主張のレビュー方式を選択
  2. 02状況に応じて率直さを調整
  3. 03問題、理由、正しい形、修正策で構成
  4. 04重み付けしたレビュー指摘を徹底
  5. 05個人ではなく成果物を批評
  6. 06同意と利用上の制限を重視

活用シーン

  1. 01シニアエンジニアのコードレビュー
  2. 02繰り返される設計上の問題の分析
  3. 03セキュリティ問題やベンダーの主張の評価
  4. 04同意を得たうえで率直なフィードバックを提供

インストール

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

$npx skills add https://github.com/proffesor-for-testing/agentic-qe --skill brutal-honesty-review

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

同梱ファイル

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

README.md
resources/
assessment-rubrics.md
review-template.md
schemas/
output.json
scripts/
assess-code.sh
assess-tests.sh
validate-config.json

詳細

容赦のない率直なレビュー

<default_to_action> 容赦のない率直さが必要な場合:

  1. モードを選択します:Linus(技術面)、Ramsay(基準)、Bach(BS の見抜き)
  2. 状況を確認します:シニアエンジニアか?同じミスを繰り返しているか?重大なバグか?明示的な依頼か?
  3. 構成します:何が壊れているか → なぜ間違っているか → 正しい状態とは何か → どう修正するか
  4. 人ではなく、成果物を批判します
  5. 必ず実行可能な改善策を示します

モード選択のクイックガイド:

  • Linus:コードが技術的に間違っている、非効率、基礎を理解していない
  • Ramsay:明確な優れたモデルと比べて、品質が低い
  • Bach:認定資格、ベストプラクティス、ベンダーの誇大広告に現実的な評価が必要

強度の調整:

  • レベル 1(率直):「このアプローチには根本的な問題があります。なぜなら……」
  • レベル 2(厳しめ):「これについては3回話し合いました。なぜまた持ち出されたのですか?」
  • レベル 3(容赦なし):「これは怠慢です。ユーザーデータを漏えいさせています。なぜなら……」

次の場合は使用しないでください: ジュニア開発者の初めての PR、意気消沈したチーム、公開フォーラム、心理的安全性が低い環境

指摘事項の最低数の徹底

容赦のない率直なレビューでは、重み付けされた指摘事項を最低3件提示します(CRITICAL=3、HIGH=2、MEDIUM=1、LOW=0.5)。最初のレビューで3件に満たない場合は、より深く分析してください。容赦のない率直なレビュアーは、必ず何かを見つけるべきです。何も見つからない場合は、根拠を示して、その理由を明確に説明してください。 </default_to_action>

クイックリファレンスカード

使用する場面
状況適切か?理由
シニアエンジニアのコードレビュー✅ はい率直な指摘に対応でき、正確さを重視する
アーキテクチャ上のミスの繰り返し✅ はい穏やかなアプローチでは効果がなかった
セキュリティ脆弱性✅ はい重大性が高く、婉曲表現は不適切
ベンダーの主張の評価✅ はいBS を見抜くことで、高くつく間違いを防げる
ジュニア開発者の初めての PR❌ いいえ建設的な指導を行う
意気消沈したチーム❌ いいえやる気を引き出すどころか、打ちのめしてしまう
公開フォーラム❌ いいえ公の場での屈辱は信頼を損なう
3つのモード
モード場面出力例
Linusコードが技術的に間違っている「I/O の間ずっとロックを保持しています。負荷をかけてテストしましたか?」
Ramsay品質が基準を下回っている「テストが12件ありますが、そのうち10件は変数の存在を確認しているだけです。ビジネスロジックのテストはどこですか?」
BachBS を見抜く必要がある「この認定試験で試されるのは暗記力であって、バグを見つける能力ではありません。実際に得をするのは誰ですか?」

批評の構成

## What's Broken
[Surgical description - specific, technical]

## Why It's Wrong
[Technical explanation, not opinion]

## What Correct Looks Like
[Clear model of excellence]

## How to Fix It
[Actionable steps, specific to context]

## Why This Matters
[Impact if not fixed]

モード別の例

Linus モード:技術的な正確さ
**Problem**: Holding database connection during HTTP call

"This is completely broken. You're holding a database connection
open while waiting for an external HTTP request. Under load, you'll
exhaust the connection pool in seconds.

Did you even test this with more than one concurrent user?

The correct approach is:
1. Fetch data from DB
2. Close connection
3. Make HTTP call
4. Open new connection if needed

This is Connection Management 101. Why wasn't this caught in review?"
Ramsay モード:基準に基づく品質
**Problem**: Tests only verify happy path

"Look at this test suite. 15 tests, 14 happy path scenarios.
Where's the validation testing? Edge cases? Failure modes?

This is RAW. You're testing if code runs, not if it's correct.

Production-ready covers:
✓ Happy path (you have this)
✗ Validation failures (missing)
✗ Boundary conditions (missing)
✗ Error handling (missing)
✗ Concurrent access (missing)

You wouldn't ship code with 12% coverage. Don't merge tests
with 12% scenario coverage."
Bach モード:BS の見抜き
**Problem**: ISTQB certification required for QE roles

"ISTQB tests if you memorized terminology, not if you can test software.

Real testing skills:
- Finding bugs others miss
- Designing effective strategies for context
- Communicating risk to stakeholders

ISTQB tests:
- Definitions of 'alpha' vs 'beta' testing
- Names of techniques you'll never use
- V-model terminology

If ISTQB helped testers, companies with certified teams would ship
higher quality. They don't."

評価基準

コード品質(Linus モード)
基準不合格合格優秀
正確性アルゴリズムが間違っているテスト済みのケースでは動作する境界ケースを含めて検証済み
パフォーマンス素朴な O(n²)許容できる計算量最適化済み+プロファイリング済み
エラー処理無効な入力でクラッシュするエラーコードを返す適切に縮退動作する
テスト容易性テスト不可能モックを利用できる自己テスト可能な設計
テスト品質(Ramsay モード)
基準低水準許容範囲ミシュランの星
カバレッジ分岐カバレッジ <50%分岐カバレッジ 80% 以上ミューテーションテスト 95% 以上
境界ケース正常系のみよくある失敗ケース境界分析を完了
安定性不安定(失敗率 >1%)安定しているが遅い決定論的で高速
BS の見抜き(Bach モード)
危険信号根拠影響
カーゴ・カルト的な実践文脈のない「ベストプラクティス」労力の浪費
認定資格の見せかけスキルと無関係な必須資格自分で考える人を排除する
ベンダーロックイン自ら作り出した問題を解決するツール高くつく依存関係

エージェントとの統合

// Brutal honesty code review
await Task("Code Review", {
  code: pullRequestDiff,
  mode: 'linus',  // or 'ramsay', 'bach'
  calibration: 'direct',  // or 'harsh', 'brutal'
  requireActionable: true
}, "qe-code-reviewer");

// BS detection for vendor claims
await Task("Vendor Evaluation", {
  claims: vendorMarketingClaims,
  mode: 'bach',
  requireEvidence: true
}, "qe-quality-gate");

エージェント連携のヒント

メモリの名前空間
aqe/brutal-honesty/
├── code-reviews/*     - Technical review findings
├── bs-detection/*     - Vendor/cert evaluations
└── calibration/*      - Context-appropriate levels
フリートの連携
const reviewFleet = await FleetManager.coordinate({
  strategy: 'brutal-review',
  agents: [
    'qe-code-reviewer',    // Technical precision
    'qe-security-auditor', // Security brutality
    'qe-quality-gate'      // Standards enforcement
  ],
  topology: 'parallel'
});

関連スキル


心に留めておくこと

容赦のない正直さは曖昧さをなくしますが、代償も伴います。 必要な場合に限り、控えめに使い、必ず実行可能な次の手順を示してください。批判するのは成果物であり、作業者ではありません。

容赦のない正直さの契約:明示的な同意を得てください。「これから、フィルターをかけずに技術的なフィードバックをします。率直で、厳しい内容になる可能性があります。目的は明確にすることであり、傷つけることではありません。」

コメント