brutal-honesty-review について
コード、品質基準、ベンダーの主張を率直に評価するスキルで、課題と状況に応じてレビューのモードを選びます。批判の対象は成果物に限定し、実行可能な改善策と利用を避ける場面も示します。
主な機能
- 01技術、基準、主張のレビュー方式を選択
- 02状況に応じて率直さを調整
- 03問題、理由、正しい形、修正策で構成
- 04重み付けしたレビュー指摘を徹底
- 05個人ではなく成果物を批評
- 06同意と利用上の制限を重視
活用シーン
- 01シニアエンジニアのコードレビュー
- 02繰り返される設計上の問題の分析
- 03セキュリティ問題やベンダーの主張の評価
- 04同意を得たうえで率直なフィードバックを提供
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ proffesor-for-testing/ agentic-qe --skill brutal-honesty-reviewインストール後、Claude Code で/brutal-honesty-reviewを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
README.mdresources/assessment-rubrics.mdreview-template.mdschemas/output.jsonscripts/assess-code.shassess-tests.shvalidate-config.json詳細
容赦のない率直なレビュー
<default_to_action> 容赦のない率直さが必要な場合:
- モードを選択します:Linus(技術面)、Ramsay(基準)、Bach(BS の見抜き)
- 状況を確認します:シニアエンジニアか?同じミスを繰り返しているか?重大なバグか?明示的な依頼か?
- 構成します:何が壊れているか → なぜ間違っているか → 正しい状態とは何か → どう修正するか
- 人ではなく、成果物を批判します
- 必ず実行可能な改善策を示します
モード選択のクイックガイド:
- 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件は変数の存在を確認しているだけです。ビジネスロジックのテストはどこですか?」 |
| Bach | BS を見抜く必要がある | 「この認定試験で試されるのは暗記力であって、バグを見つける能力ではありません。実際に得をするのは誰ですか?」 |
批評の構成
## 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'
});
関連スキル
- code-review-quality - 外交的なバージョン
- context-driven-testing - Bach モードの基盤
- sherlock-review - 証拠に基づく調査
心に留めておくこと
容赦のない正直さは曖昧さをなくしますが、代償も伴います。 必要な場合に限り、控えめに使い、必ず実行可能な次の手順を示してください。批判するのは成果物であり、作業者ではありません。
容赦のない正直さの契約:明示的な同意を得てください。「これから、フィルターをかけずに技術的なフィードバックをします。率直で、厳しい内容になる可能性があります。目的は明確にすることであり、傷つけることではありません。」
コメント
Markdown 対応