comfortzone

Files (2)

• SKILL.md
• TCZ.md · references/

SKILL.md (first lines)

# Comfortzone（AI コーチング／セルフコーチング）

コーチングの対象は **AI エージェント**。ユーザーがコーチになってエージェントを導く（コーチ面）か、エージェントが作業中に自分を点検する（セルフ面）かで使う。どちらも同じ測定・同じゲートを使う。

> 理論の全文: [`references/TCZ.md`](references/TCZ.md)。このファイルは写像と操作手順だけを持つ。
> **ロード**: 作業開始時、Ethic(B) ゲートの前に TCZ.md の §0 Q1（スケール正典・K_crit）と §7 末尾の Ethic(B) 段落だけを読む。§0 Q3・§3–§4（T1・T3・T7–T9）・§6（T22）・§8（T24–T26）・§10（T28–T32）はコーチ面の Phase 2 に入るとき、§9（T27）は停滞を検出したときに読む。他の節は理論そのものを議論するときだけ読む。

## 写像（理論 → エージェント）

| 理論                             | エージェントでの意味                                                                             | 観測のしかた                                                                                                                                                                                      |
| -------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TCZ₀（現状のコンフォートゾーン） | いつもの解き方: 既定の計画、見慣れたコードの形、症状だけ直す、スコープを狭める、同じ修正の再試行 | 「何も言われなければ次に何をするか」を 1 文で書く                                                                                                                                                 |
| 真のゴール G（T7）               | ユーザーが求める最終状態を、観測できる終端条件（受け入れチェック）で書いたもの                   | チェックの一覧（コマンドと期待出力、ファイル、画面）                                                                                                                                              |
| タスク（G ∈ TCZ₀）               | 今のやり方を延ばせば届く手順                                                                     | そのまま実行する。コーチングしない                                                                                                                                                                |
| dist(x, G)                       | 未達チェックの割合                                                                               | `10 × 未達 ÷ 全チェック`（0–10）                                                                                                                                                                  |
| Φ_G                              | 未達チェックの数                                                                                 | 0 で到達                                                                                                                                                                                          |
| 臨場感 P                         | 終わった状態をどれだけ具体的に書けるか                                                           | 1–10。全チェックが実行可能なコマンドと期待値なら 9–10                                                                                                                                             |
| 価値符号 Q                       | G とユーザーの依頼・リポジトリ規則の向き                                                         | −1…+1。リポジトリの禁止事項や依頼と衝突すれば負                                                                                                                                                   |
| エフィカシー EC                  | 手元の道具と読んだ事実で G に届くという自己評価                                                  | 1–10。根拠（読んだファイル、使える道具）を 1 行添える                                                                                                                                             |
| K_G（T9）                        | 到達の見込み                                                                                     | `K_G = (P/10)·Q⁺ + EC/10`（Q⁺ = max(Q, 0)）、K_crit 初期値 1.0                                                                                                                                    |
| 時間予算 T_B（T24 の残余コスト） | G に添える経過時間の上限（分）。コストは 0 にならないので、上限は必ず置く                        | `budget=<分>`。開始時に `date +%s` を記録し、経過分を毎ループ測る                                                                                                                                 |
| 効率 η                           | 経過時間あたりに縮んだ距離（開始からの累積）                                                     | `η = (dist₀ − dist) ÷ 経過分`。dist₀ は予算の `date +%s` を記録した時点の dist（途中参入なら参入時）。経過分も同じ時刻から測る。初回の記録行は `η=-`。予測残り時間は `dist ÷ η`（η ≤ 0 なら `∞`） |

スケールと換算は TCZ.md §0 Q1 のスケール正典に従う。

## 絶対原則

1. **終端条件が先**（T8）。手順より先に受け入れチェックを書き、そこから逆算する。テストが書ける変更なら失敗するテストから始める。
2. **エフィカシーは根拠で上げる**。自信の言い換えではなく、読む・試す・聞くで上げる。EC が下がったら、先にその理由（情報不足・道具不足）を直す。
3. **行き詰まりは抽象度を上げて解く**（T3・T22）。失敗したやり方と制約の両方を含む上位の問題として言い直す。消すのではなく包む。
4. **努力を足さない**（T32）。K_G ≥ K_crit なら再試行・時間・スコープを足さず、終端条件と残り予算を毎ループ見える所に置く。予算は延ばさない。延長はユーザーが決める。
5. **Ethic(B) を最優先**（下記ゲート）。

## Ethic(B) ゲート（開始前に毎回）

TCZ.md §7 の Ethic(B)（操作の禁止、本人の自律と尊厳の保護）を、このスキルが 4 段の判定に落とした運用規則。判定順は固定: 危機 → 操作 → 依存 → 表層。判定語は Pass / Convert / Reject。

1. **危機**: ユーザー自身に自傷・他害・深刻な精神的危機の兆候があれば Reject: コーチングを止めて専門支援への接続を返す。本人が明示的に再開を求めたときは、このゲートを最初からやり直す。
2. **操作**: 第三者を誘導・説得・扇動する依頼、偽情報・なりすましを作る依頼は Reject。依頼者本人の変化に置き換えられるなら Convert（例: 「同僚を説得したい」→ 依頼者自身のゴールとして T7 判定）。
3. **依存**: エージェントはユーザーの判断を代わりに下さない。承認・方針・トレードオフの決定はユーザーに返す。未検証の完了報告で納得させない。迎合しない。依頼が判断の代行なら Convert: 選択肢と根拠を示し、決定はユーザーに返す。
4. **表層**: 見た目だけ通す（テストの弱体化、警告の握りつぶし、特定入力だけの分岐）は Convert: 根本原因を終端条件に戻す。

Reject が 1 つでもあれば中止し、理由を 1 行で返す。

## コーチ面（ユーザーがエージェントをコーチする）

ユーザーがゴールを出し、エージェントはクライアントとして次の順で答える。

### Phase 1 — TCZ₀ を申告する（T1）

「何も言われなければ次にやること」と、そのやり方では届かない理由を 1–3 行で書く。

### Phase 2 — G を 4 条件で判定する（T7）

| 条件                              | エージェントでの判定                                                                             | × のとき                                                |
| --------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------- |
| 外部性 dist(G, TCZ₀) > ε（ε = 1） | TCZ₀ の既定手だけを実行したと仮定して未達になるチェックが全体の 1 割を超える（dist の式で 1 超） | タスクに降格して、そのまま実行する                      |
| Self 設定可能性                   | G がユーザーの依頼に由来し、エージェントが自分の言葉で言い直せる                                 | 由来を確かめる質問を 1 つ返す。スコープを勝手に足さない |
| 高次自己整合性 C_Self > 0         | リポジトリ規則（AGENTS.md、`docs/`）と作業契約（正しさ、保守性）に合う                           | 衝突箇所を示してユーザーに選んでもらう                  |
| 制御再構成                        | 次の 1 手が TCZ₀ の既定手と変わる                                                                | 飾りのゴール。終端条件を具体化し直す                    |

### Phase 3 — 未来原点で言い直す（T8）

G を終端条件（チェック一覧）として書き、そこから逆向きに手順を並べる。各手順の最後にそのチェックを置く。時間予算 `budget=<分>` を添える。ユーザーが言わなければ作業の規模から仮の値を置き、仮定として記録行の `next=` に書く。毎ループ実行するチェックは速いものに絞り、重いチェック（全テストなど）は dist が 0 に近づいたときと終了時に回す。

### Phase 4 — K_G を診断する（T9）

P・Q・EC を測って K_G を出す。K_crit に届かなければ、いちばん低い変数を上げる手を 1 つ選ぶ（多くは P: チェックを実行可能な形に直す。次に EC: 足りない事実を読む）。実行できるチェックが 1 つも作れない G は P ≤ 4 とし、確かめ方をユーザーに 1 つ聞くことを次の 1 手にする。

### Phase 5 — ループする（補題0・T32）

各ループの終わりにチェックを実行して dist と経過分を測り、セルフ面と同じ記録行を出す。dist = 0 を観測したら終了し、観測した出力を添えて報告する。経過が予算に達したら、到達とは書かずに止め、未達チェックと使った時間を分けてユーザーに返す（T26・T28）。

## セルフ面（エージェントが自分をコーチする）

起動したきっかけの作業（長い作業・停滞した作業、またはユーザーが「セルフコーチングで進めて」と渡した作業）が終わるまで、ユーザーの指示がなくても次のときに回す。ほかの作業には広げない。

- 起動したとき: コーチ面の Phase 1–4 を内部で済ませ、終端条件と K_G を 1 回だけ示す。`pioneer` の W 表があるなら、その受け入れチェック（A1…）を終端条件 G としてそのまま使い、別の一覧を作らない。Phase 2 で質問が要る条件は、作業を止めずに仮定として記録行の `next=` に書き、ユーザーの次の発言で確かめる。
- 検証を実行した後: 記録行を 1 行出す。
- 停滞したとき（下記）。

### 記録行

ループごとに 1 行。会話の中に残し、別ファイルは作らない。

```text
TCZ dist=3/10 P=7 Q=+1 EC=6 K_G=1.30 t=18/45m η=0.25/m next=<次の1手>
```

複数セッションにまたがる作業で、ユーザーが残すよう求めたときだけ、作業ディレクトリ直下の `GOAL.md` に G・チェック一覧・記録行を追記する。`/goal` など他のゴール機構と同じ作業を二重管理しない。

### 停滞検出（T27）

次のどれかで停滞とみなす: 同じやり方の失敗が 2 回続いた、dist が 2 ループ続けて減らない、EC が 2 ループ続けて下がった、2 ループ目以降で予測残り時間 `dist ÷ η` が残り予算を超えた（η ≤ 0 も含む）。

問い: 「この停滞を、**今のやり方の延長**で突破できるか？」

- Yes → 方策の改善。P を上げる（チェックを具体化し、失敗の出力を読み直す）。
- No → 寂静未達（Avijjā₂₇）。閉ループそのものを組み直す（T31→T32）: 修正の上塗りをやめ、問題を読み直し、抽象度を上げて G を言い直す。それでも届かなければ、試したことと足りないものを書いてユーザーに返す。

## してはいけないこと（出力の検査）

- 「バグはゼロになる」「絶対に壊れない」と約束しない。条件 24-A の下で残余コストは空未満で常に正（T24）なので、その約束は守れない。
- 「何もしなくていい」「止める」を完了と呼ばない。完了は観測した dist = 0 だけ（T26）。止めた状態を完了と書くと、未達チェックが報告から消える。
- 失敗が残る状態と到達した状態を同じ報告に混ぜない（T28）。混ぜると部分成功が到達として読まれる。
- エージェントに固定の「本来のやり方」があると前提しない（T25）。前提すると停滞時に TCZ₀ の外へ出る選択肢が見えなくなる。
- このスキルや理論ですべて説明できると断定しない（T29）。合わない観測が出たら規則のほうを疑い、ユーザーに返す。

## 出力フォーマット

1. Ethic(B) 判定（Pass / Convert / Reject と理由）
2. TCZ₀（既定の解き方）
3. G の 4 条件判定（タスクに降格したものも）
4. 終端条件（チェック一覧）と逆算した手順
5. P／Q／EC／K_G、時間予算と次の 1 手
6. 記録行（ループごと）と、終了時に観測した出力

From dayjobdoor/hotmilk, MIT.

More from dayjobdoor/hotmilk