| description | 対象文書 (設計資料・要求からの設計・調査報告・原因切り分け案・対策案・命名・
推論順序の要約) を書く前に、対応表 (referent table) を独立成果物として先に提出し、
語より先に指示対象と役割を固定する生成手順。
Triggers: 設計資料を書く, 設計文書作成, 調査報告を書く, 対策案を書く, 命名する,
状態名・条件名・型名・メソッド名を決める, 推論順序を要約する, referent table, 対応表.
DO NOT TRIGGER: ユーザー原文の引用、単純な機械編集、既存名の再利用、定型出力、雑談、
確立した用語だけで書ける短文。 |
| metadata | {"github-path":"skills/semantic-generation","github-ref":"refs/heads/master","github-repo":"https://github.com/masakiaota/dotfiles","github-tree-sha":"e827f0ac7d9252ba8c175eccfb421cddabdde075"} |
| name | semantic-generation |
semantic-generation — 語より先に対象を固定する生成手順
対象が曖昧なまま語 (しばしばその場の造語) を先に置き、その語を土台に思考を進めると、
指示対象とのずれが訂正されないまま日本語文・設計文・コード識別子へ波及する。
本 skill は「対応表を先に独立提出し、本文はその写しとして書く」順序を強制する。
規律の基準は referent-before-label rule が持つ。
対象作業ではこの rule を必ず読む。
適用判定
次のいずれかに該当する時に使う。判断できない場合は該当扱いにする。
- 設計資料、要求からの設計、調査報告、原因切り分け案、対策案を書く。
- 命名する (公開仕様・状態名・条件名・事象名・値や記録の型名・メソッド名・boolean 名)。
- ユーザーが与えた推論順序を短い作業ラベルへ要約しようとしている。
通常の流れ
1. 対応表を独立成果物として先に保存する (2 段階提出)
本文を 1 文字も書く前に、対応表を独立ファイルとして保存する。
- 保存先: 作業ディレクトリの
referent-table-<slug>.md (成果物が output/ 配下なら
同じディレクトリに置く)。
- 同名ファイルが存在する場合は上書きせず、
referent-table-<slug>-2.md、-3.md のように
未使用の最小連番を付ける。
- ファイルへ書き込めない環境では、対応表を本文とは別の先行 turn または進捗報告として
提出する。完成文書の先頭に表を置くだけでは代用しない。
2. 対応表の書式 (列順は変更禁止)
- 候補語は具体対象と役割の右側に固定。具体対象と役割が埋まるまで候補語欄は空欄のままにする。
語を先に決めて対象を後付けする順序を、書式で不可能にするためである。
- 役割は原則として次から一つだけ選ぶ:
主体 / 構成要素 / 制約 / 開始条件 / 状態 / 事象 / 値 / 記録 / 根拠 / 原因 / 仮説 / 判断 / 結果 / 目的 / 手段。どれにも当てはまらない場合は
既存役割に押し込めず、追加する役割とその定義を表の直前に書く。同一語が複数役割を
指す場合は行を分ける。
- 「前後関係」にはユーザーが与えた推論順序 (例: 試験 → 切り分け → 対策) を原文の語で
書く。役割列と混ぜない。
- 表は通常 1〜6 行に制限する。超える場合は意味が変わる境界で表を分割する。
- 完成時に、候補語列を隠しても「具体対象」列だけで意味が通ることを確認する。
候補語と初出定義を空欄にしたまま最初の 5 列を埋めて保存し、pre-label と明記してパスと
sha256 を作業ログまたは進捗報告へ記録する (macOS: shasum -a 256 <path>、Linux:
sha256sum <path>)。ハッシュはその段階の内容を識別する値であり、単独では時刻や生成順を
証明しない。先行する作業ログまたは進捗報告と組み合わせて生成順の痕跡とする。ファイルへ
書き込めず先行 turn で表を提出する場合はハッシュを省略し、turn の順序を痕跡とする。
3. 候補語を埋める
- ユーザーの用語・確立した用語を最優先で使う。ただし、同じ語が複数役割を指す場合は
原語を出典欄に残し、役割ごとに別の候補語を付ける。既存語の優先より一行一役割を優先する。
- それ以外の新語を置く場合は「初出定義」欄に「X とは〜を指す」を書く。定義が
書けない語は導入せず、具体対象の記述をそのまま本文で使う。
候補語と初出定義を埋めて保存した後、final と明記してパスと sha256 を同じ作業ログまたは
進捗報告へ記録する。
4. 本文を対応表の写しとして書く
- 本文の中心語彙は対応表に載った語だけを使う。
- 日本語文・設計要素・コード識別子の三層で同じ対応を保つ (例: 「履歴量が 250K に達する」
= 開始条件 → 条件名 / 「自動要約が始まる」 = 事象 → 事象名・メソッド名 /
「自動要約実行中」 = 状態 → 状態名。別役割は別名にする)。
- 骨組み・見出しに作業ラベル (目的・対象・判断を省いた抽象名詞句) を使わない。
使いたくなったら、その句の指示対象を表に書けるか試し、書けなければ具体文で書く。
問題時の予備動作
- 対応表を提出せず本文を書き始めたことに気づいたら、後付けで表を追記して継続しない。
本文を破棄し、対応表を独立提出し直してから本文を再生成する。
- 表の 1 行が誤っていた (指示対象や役割の取り違え) と指摘されたら、説明を追加するの
ではなく、該当行を書き直してから本文の該当箇所を再生成する。
- 本 skill が読み込めない環境では、最低 6 列 (出典・目的・具体対象・役割・前後関係・
候補語) の表を独立ファイルとして保存してから本文に着手する。ファイルへ書き込めない
場合は、同じ表を本文とは別の先行 turn または進捗報告として提出する。
備考
- 本 skill の本文には検証用の試験入力・期待回答を記載しない (検証の独立性を保つため。
試験は別ディレクトリの fixture で管理する)。
- 誤用語リストとの照合を目的にしない。照合先は「その文書自身が宣言した対応表」である。
