第10話 スキル物語 「リポジトリレビューして」と言ったら品質を点数で出してくれる話

いつ困る？

作ったリポジトリが他人に見せられる品質か不安になる。コミット履歴が整理されず・README が古い・テストがない・依存ライブラリは古いまま・CIは通っていないか赤のまま——自覚はあるが、どこから手を付けるべきか分からない。自信を持って公開できない・面談で提出できない・人に渡せない状態が、作ったプロジェクトを長く棚上げしてしまう。

こう言うと起こること

「リポジトリレビューして」「コード品質を評価して」「アーキテクチャ評価して」を CC に投げる。裏側の repo-review スキルは、種別（アプリ/ライブラリ/運用スクリプト/コンテンツ）を判定し、各言語用の品質評価軸（Python は AST 詳細・他言語は近似）を「実測ベース」で走査する。テストケース数・コード行数・commit hash まで、推測ではなく計測値を返す。優先度付き改善案が「最重要3点」に絞って並び、根拠は出力ログと行番号で示される。

flowchart TB
    A["🔍「リポジトリレビューして」"] --> B["どんなソフトか自動判定"]
    B --> C["あてはまる評価軸で点検"]
    C --> D["嘘のない数値で点数化"]
    D --> E["点数と改善案を出力 📊"]

何が変わるか

「見せる前にどこを直すべきか」で迷う時間が消える。計測値を根拠に直されるので「直した感」のための手戻りではなく、本当の品質が上がる。「点数（N/100）・fail 条件・観測出力」の3点セットで判定するので、改善が前に進んだかも自分で確認できる。定期的にリポジトリをレビュー運用に組み込めば、面談提出物がいつも1週間以内に整う——前向きに公開できる習慣が回る。

<details><summary>▶ 技術的にどうなってるか</summary>

仕組み

• 種別判定 → 種別ごと評価軸選択（アプリ=テスト/Lint/CI連動、ライブラリ=公開API/バージョン、運用スクリプト=冪等/監視、コンテンツ=リンク切れ/鮮度）
• 計測値ベース: コード行数・テスト数・commit hash はツール出力で実測・推測禁止
• fail条件: 「検証した範囲」内の最悪ケースを再現可能にする
• 言語別: Python は AST 詳細解析・他言語は近似カウントで算出（誤差は明示）

注意点

• 改善案は「重要3点」に絞る（幅広浅バイアスを構造的に封じる）
• 「修正しました」の報告にはコミットハッシュ等を添えて再現可能にする
• 検証網羅性ゲート:「exit code N=合格」のみならず「fail 条件ケース」の検証有無も明示

由来情報

• 設計正典: SSOTの~/.claude/skills/repo-review/SKILL.md
• 関連スキル:なし（単独で品質を上げる入口）

</details>