guarantee-interview

Files (1)

• SKILL.md

SKILL.md (first lines)

# Guarantee Interview — 裁定インタビュー

保証レコードへ「判断の出来事」を供給する手順である。実装から観測した振る舞いについて人間に一問し、その裁定を文書へ残すことで、保証レコードの出自ルールが要求する根拠を新しく作る。
呼び名は standards DOCS_OPS §3「呼び名」に従う（レコード＝行を足す集合。旧称: 保証台帳）。

## ① 位置づけ — 3段のうち裁定を担う

```
guarantee-ledger ⑩ 突合 ──観測──▶ guarantee-interview ──裁定──▶ 保証レコード
   （実装を読む）                     （人間に聞く）           （宣言する）
```

| 段 | 担当 |
|---|---|
| 観測 | `guarantee-ledger` ⑩ 段階 2 突合 |
| 裁定 | **本スキル** |
| 宣言 | `guarantee-ledger` ①〜⑨ + checker |

本スキルは裁定だけを担う。保証レコードの表書式・出自列の形式・checker の契約は `guarantee-ledger` が正本であり、ここでは重複して定義しない。

本文中の丸数字は、修飾が無ければ本スキルの節番号を指す。他スキルの節はスキル名を冠して書く（`guarantee-ledger` ⑩ 等）。**面**とは外部から観測できる単位（HTTP API・CLI 出力・スケジューラ・Webhook・画面等）であり、保証レコードが整理の単位とするものと同じである。

### 事後棚卸しとの違い

本機構は「実装から保証を起こす」ように見えるため、`guarantee-ledger` ⑧ が禁じた事後棚卸しの復活かという問いに必ず晒される。答えを設計の芯に置く。

> 観測は実装から来てよい。**昇格は今ここでの人間の裁定から来る。**

事後棚卸しが禁じられる理由は「実装が決めた振る舞いが、人間の判断を経ずに契約へ昇格する」ことである。人間の裁定を経る経路はその理由に抵触しない。過去の判断を捏造せず、現在の判断を新しく作る。

### 崩壊モード

本機構の失敗形は**ラバースタンプ**である。「これは意図どおりですね？」に yes を並べるだけの運用に落ちれば、出自の捏造装置となり、禁じたはずの事後棚卸しと同じものへ潰れる。以下の各節はすべてこの崩壊モードへの対策である。

## ② 入口

入口は 2 つ持つが、いずれも ④ の問いカードへ正規化してから同一の裁定ループへ入る。

| 入口 | 種 | 使う場面 |
|---|---|---|
| A（先行） | `guarantee-ledger` ⑩ 突合が出した `unrequested` / `partial` | 保証レコードが既にある面。材料が既に存在する |
| B | 面の walkthrough（形の正本・画面を見ながら順に問う） | 保証レコードがゼロの面。`guarantee-ledger` ⑩ を回す前のブートストラップ |

> **新しいキューを作らない。** 入口 A のキューは突合レポートそのものであり、入口 B は面の一覧がキューである。

入口 B は A との差分だけを持つ。④ 以降の問いカード・裁定ループ・記録・打ち切りは共通であり、B 固有なのは材料の出所だけである。B では形の正本と画面を**面の目次として**使い、そこに並ぶ操作を順に辿って、正本が定めていない振る舞いを拾う（正本が定めている事柄はそのまま ③ の条件 2 で落ちる）。B は A より根拠が薄いため（⑧ 参照）、初回は A で回す。

入口 A は突合レポートが item ごとの識別子を持ってリポジトリ内に残っていることを前提とする。会話の中だけに出力した突合結果はキューにならない。

## ③ 問いの門 — 何を問いにするか

次の 3 条件をすべて満たすものだけを問いにする。

1. **保証レコードがその振る舞いを約束していない**（該当行が無い、または既存行の保証文が当該の振る舞いを覆っていない）
2. **形の正本（OpenAPI・CLI ヘルプ・型定義等）を読んでも分からない**
3. 利用者から観測でき、壊れたら困る

条件 1 が「保証レコードに無い」でないのは、入口 A が `partial`（保証レコードに行はあるが保証文が実装の振る舞いを覆っていない）も材料に含むためである。行の有無で書くと partial が全件落ちる。**問うているのは行の有無ではなく約束の有無である。**

門は機械的であり、基準が明文である。判定に人間を呼ばない。この門を通らないものは問いにしない。条件 3 は、④ が要求する「壊れた場合に利用者へ起きること」を 1 文で書けるかで判定する。書けなければ通さない。

門で落とした item も裁定文書へ 1 行で列挙する（item の識別子と、満たさなかった条件の番号）。節は作らないが、⑦ の再開では決着済みとして扱いキューから外す。**どこにも記録せずに落とさない。**

## ④ 問いカード

エージェントは「実装はこうなっている」という事実だけを提示し、**推奨を述べない。**「意図的に見える」「妥当と思われる」といった評価語を含めない。

| | 内容 |
|---|---|
| 含める | 観測した振る舞い（**利用者から見た形**で書く。内部実装の用語で書かない） |
| 含める | その振る舞いが現れる操作・経路 |
| 含める | **観測の根拠** — 読んだ実装ファイルの該当箇所、または実際に動かした手順。形の正本については読んだ定義の箇所 |
| 含める | 形の正本がその点について何も言っていないことの確認結果 |
| 含める | 壊れた場合に利用者へ起きること |
| 含めない | 実装がそうなっている理由の推測 |
| 含めない | 他の選択肢の評価、エージェントの結論 |

> **技術的必然性の調査（「スキーマ制約上その選択肢しかない」等）を、問う前に行わない。** 人間が「非意図」と裁定すれば、その調査は不要になる。

禁じているのは *なぜそうなっているか* の掘り下げであり、観測の根拠として求める *どこを見てそう言っているか* の開示とは別物である。根拠が無い問いカードでは、人間は提示を信じる以外にできることがない。

## ⑤ 裁定ループ

人間へ問うのは「**意図か否か**」だけである。「保証に値するか」は ③ の門が既に判定しており、裁定の場で再度問わない。

| 裁定 | 意味 | 行き先 |
|---|---|---|
| **意図** | 意図どおり | **保証レコードへ**（`pin確認` は空欄で入る） |
| **非意図** | 意図していない | 修正をそのリポジトリの課題管理（Action・issue 等）へ積む。セキュリティに関わるもの（⑥ の列挙）は公開の課題管理へ再現経路・影響を書かず、⑥ と同じ非公開の追跡先へ積む。**現行挙動を保証レコードに載せない** |
| **保留** | 判断できない | 次回へ持ち越す |

裁定はこの 3 つに固定する。「約束だ」と「意図だが約束ではない」を対等に並べる形は採らない。同じ判断を二度させることになり、人間が「約束と呼ぶほどでは」で流せる逃げ道を作る。門を通った実害ある振る舞いが宙に消える、ラバースタンプの逆向きの失敗（取りこぼし）である。

保証レコードへ反映するときの分岐を 2 つ定める。

- **裏付けテストが無い item は、意図と裁定しても保証レコードへ載せない。** テスト作成を Action へ積み、テストが入ってから載せる（`guarantee-ledger` ⑥）。裁定文書の節は先に残るため、後から同じ出自を指して載せられる。ただし**後から載せるときは、保証レコードへ書く `保証` が裁定節に記録された振る舞いと一致することを確認する。** 実装が変わって一致しなくなっていたら、その節を出自にせず裁定し直す
- **`partial` を意図と裁定した場合は新しい行を起こさない。** 既存行の `保証` を実装の振る舞いへ合わせて正確にし（範囲を広げる、または成り立つ条件を明示する）、`出自` を裁定文書の該当節へ差し替える。非意図と裁定したなら実装を直す Action を積み、`保証` は維持する。**範囲を広げる書き換えでは、広げた部分を既存の `裏付けテスト` が覆っているかを確認する。** 覆っていなければ書き換えず、テスト追加を積んでから書き換える（新規行と同じ扱い）

`partial` で人間へ問う対象は「**実装の現在の振る舞いが意図どおりか**」である。書き換えの制約は 1 つだけ置く。

> **保証の核を弱めない。** 核ごと落とすのは退役であり、`guarantee-ledger` ③ の退役提案として扱う（本スキルの経路ではない）。

### 「非意図」が生命線である

既存アプリの仕様再確認は、保証だけでなく**バグと仕様漏れも掘り出す。** エージェントが指示の隙間を埋めた振る舞いは、正しく動いていても正しいとは限らない。この裁定を持たない機構は現状追認装置であり、誤った実装を契約へ昇格させる。

### 「保留」を正当な出口として置く

`guarantee-ledger` ①「迷ったら載せない」が既にこれを支持している。新ルールの発明ではなく、既存原則の適用である。保留を選びにくい場に作ると、判断できないものが追認へ流れる。

### 理由の一文を必須とする

人間の理由は**逐語で**残す。整形・要約・言い換えをしない。要約すると、後から読んだときに「エージェントが書いた理由」と区別できなくなり、`guarantee-ledger` ⑪ の形骸化判定にそのまま落ちる。

> **裁定者をエージェントで代理しない。** 他のエージェント（司令塔・サブエージェントを含む）の応答を人間の裁定として記録しない。

### 但し書き — 固定したくない場合

「意図どおりだが、近く変える／変える余地を残したい」場合は、意図と裁定したうえで保証レコードへは載せず、そのリポジトリのリスク記録（`risk-registry` 等）へ回す。

From elchika-inc/agent-toolkit, MIT.

More from elchika-inc/agent-toolkit