Judgment Harness

---
user-invocable: true
description: "プロジェクト固有の「何を良しとするか（判断軸）」を、ベース層の上にレイヤーで積み上げて育てるための方法論。色・トーン・体験・表現の方針をどう構造化し、どう発酵させ、どこに昇格させるかの段取りを持つ。プロジェクト立ち上げ時の判断軸づくり、デザイン/体験設計の方針を立てる前段、判断軸スキルをどこに足すか迷ったときに使う。"
---

# judgment-harness — 判断軸ハーネスの組み立て方（方法論）

「**このプロジェクトで何を良しとするか**」を、行き当たりばったりで決めず、
**レイヤーで構造化し → 対話で発酵させ → skill/SSOTへ昇格**する段取りを持つ判断軸。
個別の「何を決めたか（what/why）」は各プロジェクト層スキルに書く。ここは **how to build** だけを持つ。

## 発火条件

- プロジェクト立ち上げ時に「テイスト・体験・表現の方針」を立てるとき
- デザイン/UI/モーション/コピーの**方針を構造化**したいとき
- 学びや決定を**どのレイヤー（CLAUDE.md / rule / どのskill）に置くか**迷ったとき
- 判断軸が散らかってきた／同じことを何度も決め直していると感じたとき

---

## レイヤー構造（どこに何を置くか）

判断軸は4層で積む。**下の層ほど普遍（how）、上の層ほど固有（what/why）**。

| 層 | 実体 | 性質 | 例 |
|---|---|---|---|
| **ベース層**（普遍） | `CLAUDE.md` ＋ `.claude/rules/*` ＋ 汎用スキル群 | how・判断ロジック | TDD、命名規約、レビュー手順 |
| **プロジェクト層** | プロジェクト固有スキル1枚 | what / why | このプロダクトの存在設計・体験原則 |
| **ドメイン/演出層** | 視覚・モーション・音 等の演出原理スキル | 演出原理 | 視線誘導・線・色の作法 |
| **機能単位** | 認証/決済/管理画面 等の局所ルール | 局所制約 | 後で必要になったら |

- **重複して書かない**: how はベース層・汎用スキルへ委譲。プロジェクト層は「結局どう決めたか」だけを持つ。
- ベース層は ai-template / 知識リポジトリから同期される前提（普遍ルールは個別プロジェクトで抱え込まない）。

### 立ち上げの順序

1. **プロジェクト層スキルを最初に作る**（＝「このプロジェクトで何を良しとするか」のSSOT）。
   穴埋め雛形 `project-design-language` をコピーして埋める。空でよい、TBDでよい。
2. 視覚/モーション等で固有の作法が要るなら**演出層スキル**を足す。
3. 機能固有の制約は、その機能に着手するときに**機能単位ルール**として足す。

---

## 発酵ループ（design TDD）

判断軸とデザインは、仕様を最初に固めず **RED→GREEN→REFACTOR のリズム**で育てる。

```
言語化（壁打ちメモに書く）
  → ドラフトskill化（プロジェクト層/演出層に薄く落とす）
  → 動くドラフト画面を作る
  → 触って「違う」を出す（Vibe Coding）
  → skill / コンテンツを修正
  → 反復 → 固まったら skill/SSOT へ正式昇格
```

- **完璧主義で止めない**。まず動かして発酵させる（着手時点では人間も答えを持っていないことが多い）。
- 「壁打ちメモ（発酵場所）」と「確定skill（SSOT）」を**分ける**。メモは考える場所、skillは決まった場所。
- 確定ログはメモ側に時系列で残し、結論はskillへ移す。

---

## "らしさ"の作り方（判断の核）

- **差別化＝規範/逸脱のペア**: "らしさ"は「**ベストプラクティスをどこで意図的に外すか**」から生まれる。
  規範（守る）と逸脱（破る）を**対で設計**し、逸脱は必ず意図を明示する（なんとなく外さない）。
- **格（レジスタ）を揃える**: 混ぜる要素はフォーマル度を揃える。フォーマルとカジュアルを無造作に混ぜるとチグハグになる。
  構造は精密に、遊び・有機性は"点"で効かせる。

---

## 昇格の判断（どこに書くか迷ったら）

| 学びの性質 | 置き場所 |
|---|---|
| 全プロジェクトで普遍に効く手順・判断ロジック | ベース層（`CLAUDE.md` / `rules`）→ さらに ai-template へ送り状（`doc/output/to-template.md`） |
| このプロジェクトの存在設計・体験の決定 | プロジェクト層スキル |
| 視覚/モーション等の固有の作法 | 演出層スキル |
| まだ揺れている・検証中 | 壁打ちメモ（発酵場所）にドラフトで置く |

> 汎用化できる学びは、区切りで `doc/output/to-template.md`（送り状）に記録し、ai-template 側で取り込む（プロジェクトは ai-template を直接編集しない＝競合回避。取り込み手順は `template-feedback` スキル）。

---

## 進め方（最初に問う）

- この決定は**どの層**のものか（普遍 / プロジェクト / 演出 / 機能）？
- いま**固める段階**か、まだ**発酵させる段階**か（メモ止まり or skill昇格）？
- ここで守る規範は何か、意図的に外す逸脱はどこか？
- 汎用化できる学びはあるか（あれば送り状へ）？