mcpField
N
navvy

navvy

github.com/andrewgleave開発3447 回インストール27 週間前に更新
リポジトリ

navvy について

navvyは、Gitの履歴からコードベースを評価するスキルです。保守リスクやプロジェクトの動向を把握したい開発者向けに、5種類の分析を行い、簡潔な診断レポートにまとめます。

主な機能

  1. 01変更頻度の高いファイルの特定
  2. 02コントリビューターのコミット数集計
  3. 03不具合関連ファイルの特定
  4. 04月ごとのコミット推移の追跡
  5. 05リバートとホットフィックスの検出

活用シーン

  1. 01変更と不具合が集中するファイルの発見
  2. 02プロジェクトの知識が少数の人に偏っているか確認
  3. 03開発ペースの変化の確認

インストール

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

$npx skills add https://github.com/andrewgleave/skills --skill navvy

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

同梱ファイルREADME.md

詳細

Navvy

1 分以内に実行できる 5 つの Git コマンドで、1 時間コードを読むよりも多くのことがわかります。コミット履歴は診断データです。チームの力学、リスクの集中、メンテナンスのパターンを明らかにしますが、これらはコードそのものからはわかりません。

5 つのコマンドをすべて実行し、結果を統合して診断レポートを作成します。

コマンド

可能な場合は、これらのコマンドを並列で実行してください。プロジェクトの期間に合わせて --since を調整します。活発なプロジェクトには 1 year ago を使い、更新頻度の低いプロジェクトでは期間を延ばしてください。

1. 変更頻度の高い箇所
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

過去 1 年間に最も多く変更された 20 ファイルです。オーナーが不在のファイルで変更頻度が高い場合、コードベースの足かせになっていることを示す最も明確な兆候です。こうしたファイルは影響範囲が予測しにくく、見積もりを膨らませます。

2. コントリビューターの状況
git shortlog -sn --no-merges

コミット数の多い順にコントリビューターを並べます。バス係数のリスクに注目してください。1 人がコミットの 60％以上を占めている場合、知識が危険なほど集中しています。主要なコントリビューターが今も活動しているかどうかも確認してください。

3. バグの集中箇所
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

バグ関連のコミットで最も頻繁に変更されたファイルです。このリストと変更頻度の高い箇所の両方に含まれるファイルは、最もリスクの高いコードです。繰り返し壊れ、そのたびにパッチが当てられています。

4. 開発速度の推移
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

全履歴を対象に、月ごとのコミット数を表示します。一定のペースは健全です。急激な減少は、人員の離脱や勢いの低下を示している可能性があります。不定期な急増は、継続的デリバリーではなく、リリースをまとめて行っていることを示唆します。

5. 火消しの兆候
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

リバートとホットフィックスを確認します。頻繁に発生している場合、チームがデプロイプロセスを信頼していない兆候です。これは、テストやデプロイの信頼性に、より深い問題があることを示しています。

レポートのまとめ方

5 つのコマンドをすべて実行した後、短い診断レポートを作成します。コマンドごとではなく、データからわかることを軸に構成してください。

注目点
  • 変更頻度の高い箇所とバグの重複。 両方のリストに含まれるファイルは、リファクタリングやテストカバレッジの改善で最も大きな効果が見込める対象です。
  • バス係数。 圧倒的な貢献をしていた人が活動を停止している場合、リスクがあります。コントリビューターが広く分散していれば健全です。
  • 開発速度の変化。 減少や急増を、チームの変更、書き直し、ローンチなど、プロジェクトについて把握している情報と照らし合わせてください。
  • 火消しの頻度。 年に数回のリバートは正常です。毎月ホットフィックスが必要なら、システム上の問題が疑われます。
レポートの形式
# Codebase Diagnostic: [repo name]

## Key Findings
[2-4 bullet points: the most important things to know before touching this code]

## Churn Hotspots
[Top files, what they are, whether they overlap with bug clusters]

## Team & Ownership
[Bus factor assessment, active vs inactive contributors]

## Health Signals
[Velocity trend interpretation, firefighting frequency]

## Recommendations
[Where to focus attention, what to investigate further]

簡潔にまとめてください。目的は全体像を把握することであり、網羅的な分析ではありません。レポートを読み終えた人が、問題の所在と慎重に扱うべき箇所を把握できるようにしてください。

コメント

Markdown 対応