使い方ガイド

🏠 ダッシュボード 📚 リファレンス 📖 使い方ガイド 🪝 hook パイプライン図

どう品質が積み上がるのか / シーン別・活用方法 / その他のシーンでも / はじめ方

どう品質が積み上がるのか

1回のレビュー指摘が、全チームの資産になるまで
01
レビューで指摘
PR で品質問題が見つかる（人 or AI レビュー）
02
自動でルール化
汎用的な教訓を抽出し、共通ルールへ昇格
03
全チームへ配布
以後、全リポジトリのコーディングに自動注入
04
品質が底上げ
同じ指摘が出なくなる。次の新しい指摘へ
④ の次はまた ① へ — 使うほど賢くなる好循環

シーン別・活用方法

「何を打てばいいか」までそのまま載せています。skill 名を覚える必要はありません。

計画 → 設計 → 実装 → 検証
USE CASE 01

ゼロから新機能を開発する

Before
設計が曖昧なまま実装に入り、後から手戻り。担当者ごとに品質がばらつく。
After
要件→設計→実装→検証を V字で段階的に。各段をゲートで通しながら、コーディング中は全社ルールが自動で効く。要件が曖昧でも、まず設計から固める。
使い方
/vmodel-feature
- repo: <絶対パス>
- 要件: <箇条書き。曖昧でよい>
- 実データサンプル: <あれば。無ければ「なし」>
裏側
PDCA × V字モデルの agent 群がフェーズゲート制で進行。各段の完了を確認してから次へ進むので、品質が段階で担保される。並行して rules-global が repo の技術構成を検出し backend / frontend / testing のルールを注入。
診断 → 再現テスト → 修正
USE CASE 02

バグを修正する

Before
原因を特定しないまま塞ぐ → 別の形で再発。直し方が場当たり的。
After
バグをそのまま貼るだけ。再現テストを先に書く → 診断 → 修正の型に自動で乗る。修正時のレビュー指摘も自動でルール化され、同種バグが再発しない。
使い方 — コツは 3 点セット（原文・再現手順・期待動作）
<エラーメッセージ原文をペースト>
再現手順: <操作>
期待: <本来の動作>
裏側
skill 名を覚える必要なし。この 3 点だけで diagnosing-bugs（診断ループ）に自動ルーティングされ、再現テスト先行で直す。恒久対策になった教訓は pr-lessons が再発防止ルールへ昇格。
実装・単体テスト
USE CASE 03

テストを書く

Before
何を・どこまでテストするか属人的。動くだけの「形だけ」のテストが混ざる。
After
テスト規約が毎セッション自動注入済み。普通に頼むだけで「成功パスも検証」「呼び出し回数でなく動作で検証」「形骸化テスト禁止」等が効く。
使い方
<対象ファイル / 機能> のテスト書いて

# テストファーストで機能ごと作るなら
/tdd <機能>
裏側
テスト規約（rules-global/testing.md）を SessionStart hook が毎回注入するので、明示しなくても効く。/tdd は red-green-refactor で「まず失敗するテスト」から作る。
改善・品質資産化 ⭐ この仕組みの肝
USE CASE 04

コードレビューをする

Before
同じ指摘を毎回繰り返す。指摘が個人の記憶に埋もれ、チームの資産にならない。
After
指摘が自動で共通ルールに昇格 → 次から全員が守る。レビューそのものが品質資産に変わる。冒頭のフライホイールが回り始める起点。
使い方
/review <PR番号>

# 指摘対応が終わったら（週次で自動化もあるが、即固定したいとき）
pr-lessons
裏側
pr-lessons が指摘を「全PJ共通 / repo特有 / 一回性」に仕分け。共通の教訓は rules-global へ昇格、repo特有はレポートへ。毎時・週次の自動ジョブが 15 リポジトリを横断して同じことを継続。
オンボーディング・セットアップ
USE CASE 05

新メンバー参加 / 新リポジトリ作成

Before
立ち上げ時に品質基準が伝わらない。オンボーディングが属人的で時間がかかる。
After
clone するだけで全社ルールが効く。ゼロ設定で品質基準を継承。プロンプトすら不要 — セットアップは 2 コマンド。
使い方 — セットアップ 2 コマンド（初回のみ）
git clone <claude-config> && ./scripts/install.sh
裏側
以降は全セッションでルールが自動注入。新しい repo は clone するだけで①グローバルルールが効き、repo 固有ルールは .claude/rules/ を置いたときだけ増える。

その他のシーンでも

リファクタ

壊さず整える

変更前後でテストを通しながら、依頼に直結する範囲だけを最小限に修正。求められていない“改善”を勝手に足さない。

<対象> をリファクタして
セキュリティ

見落としを防ぐ

認証・個人情報・権限まわりの規約を注入した上で、変更を多観点でレビュー。危ない変更を早期に弾く。

/security-review
リリース判断・検証

“たぶん大丈夫”をなくす

多観点レビュー後、各指摘を別 agent が実コードで反証してから確定。主観でなく検証でゴー判断。

verified-feature-review / /verify

はじめ方

特別な学習は不要です。3 つだけ覚えれば動き出します。

1
セットアップは 1 回だけ
clone して install.sh。以降は全セッションで自動。
2
普段どおり頼む
ルールは裏で自動注入。意識しなくても効く。
3
レビュー後に固定
指摘対応後 pr-lessons。次から全員に効く。
技術者向けメモ — 数字で見る仕組み
17
横断する対象リポジトリ
毎時
マージ PR → ルール化の頻度
週次
ルールの重複自動整理
5層
general / backend / frontend / testing / infra

共通ルールは PR レビュー指摘から自動昇格し、SessionStart hook が repo の技術構成（stack）を検出して該当層だけを注入します（backend の repo に frontend のルールは出しません）。開発フローは PDCA × V字モデルと、Harness Engineering の設計プリミティブの両輪で整理 — その分類はダッシュボードの「V字開発モード分類」「Harness Engineering 分類」パネルで一覧できます。ルールが「書かれても実装時に参照されない」問題を、注入と機械チェック（lint / CI）で仕組みとして塞いでいます。