semantic-generation

semantic-generation — 語より先に対象を固定する生成手順

対象が曖昧なまま語（しばしばその場の造語）を先に置き、その語を土台に思考を進めると、 指示対象とのずれが訂正されないまま日本語文・設計文・コード識別子へ波及する。 本 skill は「対応表を先に独立提出し、本文はその写しとして書く」順序を強制する。 規律の基準は referent-before-label rule が持つ。

適用判定

次のいずれかに該当する時に使う。判断できない場合は該当扱いにする。

1. 設計資料、要求からの設計、調査報告、原因切り分け案、対策案を書く。
2. 命名する（公開仕様・状態名・条件名・事象名・値や記録の型名・メソッド名・boolean 名）。
3. ユーザーが与えた推論順序を短い作業ラベルへ要約しようとしている。

通常の流れ

1. 対応表を独立成果物として先に保存する（2段階提出）

本文を1文字も書く前に、対応表を独立ファイルとして保存する。

• 保存先: 作業ディレクトリの referent-table-<slug>.md（成果物が output/ 配下なら 同じディレクトリに置く）。
• 保存後に SHA-256 を記録する。Linux では sha256sum <path>、macOS では shasum -a 256 <path> を使う。この記録が「本文より先に対応表を作った」ことの痕跡になる。 完成文書の先頭に表を置くだけでは生成順の証明にならない。

2. 対応表の書式（列順は変更禁止）

出典	目的	具体対象	役割	前後関係	候補語	初出定義

• 候補語は右端に固定。具体対象と役割が埋まるまで候補語欄は空欄のままにする。 語を先に決めて対象を後付けする順序を、書式で不可能にするためである。
• 役割は閉じた選択肢から選ぶ: 開始条件 / 状態 / 事象 / 値 / 記録 / 目的 / 手段。 同一語が複数役割を指す場合は行を分ける。
• 「前後関係」にはユーザーが与えた推論順序（例: 試験 → 切り分け → 対策）を原文の語で 書く。役割列と混ぜない。
• 表は通常1〜6行に制限する。超える場合は意味が変わる境界で表を分割する。
• 完成時に、候補語列を隠しても「具体対象」列だけで意味が通ることを確認する。

3. 候補語を埋める

• ユーザーの用語・確立した用語を最優先で使う。
• それ以外の新語を置く場合は「初出定義」欄に「X とは〜を指す」を書く。定義が 書けない語は導入せず、具体対象の記述をそのまま本文で使う。

4. 本文を対応表の写しとして書く

• 本文の中心語彙は対応表に載った語だけを使う。
• 日本語文・設計要素・コード識別子の三層で同じ対応を保つ（例: 「履歴量が250Kに達する」 = 開始条件 → 条件名 / 「自動要約が始まる」 = 事象 → 事象名・メソッド名 / 「自動要約実行中」 = 状態 → 状態名。別役割は別名にする）。
• 骨組み・見出しに作業ラベル（目的・対象・判断を省いた抽象名詞句）を使わない。 使いたくなったら、その句の指示対象を表に書けるか試し、書けなければ具体文で書く。

問題時の予備動作

• 対応表を提出せず本文を書き始めたことに気づいたら、後付けで表を追記して継続しない。 本文を破棄し、対応表を独立提出し直してから本文を再生成する。
• 表の1行が誤っていた（指示対象や役割の取り違え）と指摘されたら、説明を追加するの ではなく、該当行を書き直してから本文の該当箇所を再生成する。
• 本 skill が読み込めない環境では、最低6列（出典・目的・具体対象・役割・前後関係・ 候補語）の表を独立ファイルとして保存してから本文に着手する。

備考

• 本 skill の本文には検証用の試験入力・期待回答を記載しない（検証の独立性を保つため。 試験は別ディレクトリの fixture で管理する）。
• 誤用語リストとの照合を目的にしない。照合先は「その文書自身が宣言した対応表」である。