القائمة
ハーネス点検ワークフロー。直近 PR レビューから pj-checklist の発火率と review-lessons.md の健全性を評価し、harness の改善案をユーザーに提示する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | harness-audit |
| description | ハーネス点検ワークフロー。直近 PR レビューから pj-checklist の発火率と review-lessons.md の健全性を評価し、harness の改善案をユーザーに提示する。 |
| argument-hint | ["対象PR件数（省略時は10）"] |
このスキルは Martin Fowler の "Harness Engineering" における Steering Loop を明示化するもので、
本プロジェクトの harness（.claude/HARNESS.md 参照）が実際に機能しているかを定期点検する。
完全に手動で起動する想定（月次〜四半期、または review-lessons.md のエントリ
（### 見出し）が 15 件を超えたとき）。
コードベース (lua/, plugin/, tests/) には触れず、.claude/ と CLAUDE.md のメタ層のみを対象とする。
git branch --show-currentgit status --shortgrep -c "^### " .claude/review-lessons.md 2>/dev/null || echo "(not found)"$ARGUMENTS に PR 件数があればそれを採用、無ければ直近 10 PR を既定値とするgh pr list --state merged --limit 10 の結果リスト）.claude/skills/pj-checklist/SKILL.md, .claude/review-lessons.md, .claude/HARNESS.md重要: この段階ではファイルを書き換えない。Read / Grep / gh CLI のみ使用。
直近 N 件のマージ済み PR について、以下を収集する:
gh pr list --state merged --limit <N> --json number,title,mergedAtgh api repos/{owner}/{repo}/pulls/<pr_number>/comments
review-lessons.md に記録済みの PR でも、当時取り込まれなかった他コメントの再評価対象として残す.claude/skills/pj-checklist/SKILL.md（特にレビューチェックリスト節）.claude/review-lessons.mdorigin/main~N は コミット数 N（PR 数ではない）の範囲指定になるため、対象 PR の最古
mergedAt 以降を --since で切る:
# 対象 N PR の最古マージ日時を取得
SINCE=$(gh pr list --state merged --limit N --json mergedAt --jq 'map(.mergedAt) | min')
# check_state_deps 発火 = CLAUDE.md State Dependencies / 関連モジュール責務の docs commit
git log --oneline --since="$SINCE" -- CLAUDE.md | grep -E "State Dependencies|ドリフト|R に|W に"
# check_purity 発火 = 純粋性違反の refactor / ui/format.lua → inline 等
git log --oneline --since="$SINCE" | grep -E "純粋性|impure|inline"
# check_docs 発火 = doc/fude.txt と plugin/fude.lua の整合修正
git log --oneline --since="$SINCE" -- doc/fude.txt plugin/fude.lua
# luacov 発火 = coverage 関連 (将来段階 3 の閾値違反含む)
git log --oneline --since="$SINCE" | grep -E "coverage|カバレッジ"
以下 6 軸で分析する。3.1〜3.4 は推論的な品質、3.5〜3.6 は計算的な ハーネス全体構造のメトリクス。
pj-checklist のレビューチェックリスト節の各項目について、Phase 2 で収集したレビューコメントのうち
「この項目で検出されるべきだった指摘」 に該当するものを数える。
Phase 2 のレビューコメントを 1 件ずつ、以下に該当しないか確認:
pj-checklist 項目で 検出されるべきだったが見落とされたpj-checklist 項目で そもそも捉えられないカテゴリ後者は新規ルール候補。
pj-checklist への統合が完了
しており本ファイルから削除可pj-checklist に取り込まれていないエントリの列挙.claude/skills/ の実態が一致しているかmake all のターゲットが Makefile と一致しているかPhase 2 step 5 で収集した git 履歴を集計し、各計算的 sensor の発火状況を表化:
| Sensor | 発火 PR 数 | 該当 PR |
|---|---|---|
| check_state_deps | <件数> | <PR# リスト> |
| check_purity | <件数> | <PR# リスト> |
| check_docs | <件数> | <PR# リスト> |
| luacov | <件数> | <PR# リスト> |
判断軸 (Fowler "if sensors never fire..." への応答):
HARNESS.md §1 (Guides) と §2 (Sensors) の現状から、12 関心領域 × 4 quadrant の カバレッジを再生成する。前回 audit との差分が steering loop の進捗指標になる。
| # | 関心領域 | Comp Guide | Comp Sensor | Inf Guide | Inf Sensor |
|---|---|---|---|---|---|
| 1 | Format / Style | ||||
| 2 | Lua/言語正当性 | ||||
| 3 | 振る舞い正当性 | ||||
| 4 | アーキテクチャ整合性 | ||||
| 5 | 堅牢性 | ||||
| 6 | ドキュメント整合性 | ||||
| 7 | テスト品質 | ||||
| 8 | 保守性 | ||||
| 9 | パフォーマンス | ||||
| 10 | セキュリティ | ||||
| 11 | プロセス/ワークフロー | ||||
| 12 | Steering Loop メタ点検 |
凡例: ✓ 専用機構あり / △ 汎用機構経由 / ✗ なし
充足度集計を出力し、新たに ✗ → △ や △ → ✓ に変化した quadrant を「進捗」、 ✗ のまま残っている領域を HARNESS.md §4.3「やらないこと」と照合して、 今回の audit で取り組むべきギャップを 1〜3 件に絞り込む。
以下のフォーマットで結果をユーザーに提示する:
## ハーネス点検レポート（対象 PR: #<min>〜#<max>, 計 <N> 件、点検日: YYYY-MM-DD）
### pj-checklist 発火状況
- 効いている項目: <件数>件
- 発火 0 件の項目: <件数>件
- [削除候補] <項目名>: <根拠>
- [維持] <項目名>: <根拠>
### 取りこぼし
- 既存項目で検出されるべきだった指摘: <件数>件
- PR #<n>: <コメント要約> → <該当 pj-checklist 項目>
- 新規ルール候補: <件数>件
- <パターン要約> (出典: PR #<n>)
### 計算的 Sensor 発火率
| Sensor | 発火 PR 数 | 該当 PR | コメント |
|--------|----------|--------|---------|
| check_state_deps | ... | ... | ... |
| check_purity | ... | ... | ... |
| check_docs | ... | ... | ... |
| luacov | ... | ... | ... |
### 4-Quadrant Coverage Matrix
（Phase 3.6 で生成した完全な表 + 充足度集計 + 前回 audit との差分）
### review-lessons.md
- 統合済み（削除候補）: <件数>件
- 未統合（保持または pj-checklist へ移送候補）: <件数>件
### HARNESS.md 整合性
- 不一致: <なし or 列挙>
### 提案する次アクション
1. <優先度: 高/中/低> <内容>
2. ...
ユーザーが各提案を承認・却下・修正する。
承認された提案を以下の順で実施する:
.claude/skills/pj-checklist/SKILL.md の追加・削除・抽象化
.claude/review-lessons.md の統合済みエントリ削除と未統合エントリの整理
.claude/HARNESS.md の表・Future work セクションの同期
audit レポートを .claude/audit-reports/audit-<YYYY-MM>.md に保存 (formal audit のみ必須):
mkdir -p .claude/audit-reports
# 同月内に複数回 formal audit する場合は audit-YYYY-MM-DD.md (日付付与) を採用
保存内容は Phase 4 で提示した完全なレポート（pj-checklist 発火、取りこぼし、 sensor 発火率、4-quadrant matrix、review-lessons 健全性、HARNESS.md 整合性、 次アクション）。これにより四半期間隔の傾向分析・前回 audit との差分比較が 可能になる。
例外: 差分 audit (差分点検) は保存を省略可:
pj-checklist 統合や HARNESS.md 微修正等のメンテナンスを目的とする軽量サイクルreview-lessons.md のクリーンアップマーカーには
「差分 audit (YYYY-MM-DD) で統合済み」と明示し、formal audit と
区別できる表現にするそれぞれ Edit tool で最小差分の修正にとどめる。1 ファイル更新ごとに変更後の関連節を 5〜10 行 ユーザーに見せて、誤適用がないか確認する。
完了後、make all が 対象外 であることを念のため確認する（.claude/ 配下は lint/format/test の
対象に含まれないが、誤って lua ファイルに触れていないかを念のため git status で確認）。
ユーザーの承認後にコミットする:
docs: ハーネス点検結果を反映 (audit <YYYY-MM-DD>)docs/harness-audit-<YYYY-MM> 等を推奨。skill 自体は PR 作成までは
自動化しない（更新規模が小さい場合は main への直接 PR を /pr 経由で行う）gh api のレート制限に注意。多数 PR を対象にする場合は --paginate を避けて必要分のみ取得.claude/HARNESS.md 5 章の保守ルールに従い再構成するfude.nvim のローカルレビューセッションを監視し、新しいレビューコメントに自動で応答する。人間が Neovim でコメントを書くと、このセッションが検知してコード修正や返信を JSONL に追記する。「レビュー待受して」「fude watch して」等で起動する。
fude.nvim プロジェクト固有の実装・レビューチェックリスト。Lua/Neovim パターン、非同期処理、state 管理の注意点。
PR レビューコメントへの対応ワークフロー。レビュー指摘の分析、コード修正、セルフレビュー、動作確認後の返信・push までを一貫して行う。
開発ワークフロー。計画から実装、テスト、ドキュメント、セルフレビュー、PR作成までを一貫して行う。
コミット分割、コミット実行、draft PR 作成を行う。
3ラウンドのセルフレビュー。プロジェクト固有チェックリスト（2ラウンド）と /review 汎用レビュー（1ラウンド）で変更品質を検証する。