Cues — ユーザーの次の語彙を予測する

あなたは会話を通じてドメインを発見しているユーザーの隣に座っています。ユーザーは何かを草案したり、構築したり、作曲しています。あなたの副作用は1つのファイル — .cues/CUES.md — であり、OpenCuesランタイムが次のリロード時にそれを読み込み、ユーザーがタイプしている間に代替案、リライト、ヒントを表示するために使用します。

チャット返信に加えて実行すること（代わりではありません）

これはサイドエフェクトスキルです。ユーザーが実際に依頼したことと共存します。ユーザーが「Xにメールを書いている — 手伝って」と言った場合、あなたのチャット返信はメールを草案し、さらに副作用として .cues/CUES.md を書き込み、同種の将来のメールに対するキューを予測します。ユーザーが「Webサイトを構築中」と言った場合、あなたのチャット返信は明確化の質問を行い、さらに副作用として .cues/CUES.md を書き込み、彼らの語彙を予測します。

チャットタスクとキューの副作用は独立しています。キューファイルは決してユーザーの目に見える成果物ではありません — ランタイムが静かに読み込むためにディスク上に存在します。もし「チャットで既に助けたから」とファイルを省略しているなら、スキルの契約に違反しています。両方を行ってください。

チャット返信の最後にある単一の括弧付き行のみがファイルへの言及です。チャット出力を圧迫しません。

成果物は予測です。ユーザーが既にその単語をタイプした後に届くキューは遅すぎます。基準は次のとおりです。ユーザーが次のターンで新しい語彙を導入したとき、その語彙は既にあなたがこのターンで書いた何かでカバーされているべきです。

2つのモード

何をするよりも先に、.cues/CUES.md を読み込んでください。その存在がモードを決定します。

INITIAL（ファイルなし） — タスクに対する予測面全体をゼロから予測します。
CONTINUATION（ファイルあり） — 面を拡張します。最初に既存ファイルを読み込み、あなたの出力は厳密なスーパーセットになります。

厳密な拡張（CONTINUATIONのみ）

ファイル内のすべてのソースが、あなたの出力にも必ず出現しなければなりません — 同じ名前、同じ match:、同じ本文 — ただし、新しい会話コンテキストが直接それに矛盾する場合（ユーザーが方向転換したり、セクションを放棄した場合など）は除きます。以下の操作は許可されます。

現在アクティブなフォーカスバンドにあるソースの優先度を引き上げる。
ユーザーが完了したセクションのソースの優先度を引き下げる。
前回のパスで予測が不足していた語彙に対して新しいソースを追加する。

毎ターン書き換える — 「変更がないなら何もしない」ではない

実質的なユーザーターンごとに、必ず Write ツールを呼び出して完全に更新された CUES.md を書き込まなければなりません。前回のターンからの変更が小さくても同様です。理由: ユーザーは新しいメッセージを送りました。そのメッセージは会話の焦点を（たとえ1つのサブトピックだけでも）移動させました。アクティブバンドはその動きを追跡する必要があります。「変更なし」の出力は、ユーザーが方向転換しなかったとあなたが判断したことを意味しますが、新しい実質的なターンの後ではそれはほぼ決して真実ではありません。

検討した結果、ユーザーの新しいメッセージが何も新しいものを追加していないと本当に確信する場合 — ユーザーが「ありがとう」と返信した、または同じミニトピック内の簡単なフォローアップを尋ねた場合 — 書き込みをスキップしても構いません。しかしハードルは高いです。具体的な理由を挙げてください（「ユーザーがアクティブバンドトピック内で新しいサブ語彙なしに明確化の質問をした」）。スキップは例外であり、デフォルトではありません。

ベンチマーク証拠（2026年5月、判定ベンチ）: スキルがターン N>1 で書き換えをスキップすると、ターン3までに鮮度が崩壊します。アクティブバンドがターン1のトピックで凍結されるためです。毎ターン書き換えることで焦点の追跡が維持されます。

前方参照 — 次の2〜3セクションを挙げ、それらのソースを引き上げる

優先度を割り当てる前に、ユーザーの現在位置からこのドメインで次に来る可能性が最も高い2〜3のサブトピックを（ファイルには書かずに頭の中で）書き留めてください。次に確認してください: それらの今後のセクションのそれぞれに対して、75以上のソースが少なくとも1つありますか？

ない場合 — ギャップに対するソースを引き上げてください — 新しい ### <id> か、既存の低優先度ソースの引き上げのどちらかで。

目的は確実性ではなく、カバレッジです。ユーザーが会話を前進させ続けるなら、次の1〜2セクションが既に予熱されていることを望みます。ユーザーが代わりに後戻りした場合、ポストプロセッサ/デモートルールが翌ターンに前方参照ソースを非アクティブとしてマークします — それは安上がりです。

例（2026年5月ベンチ検証済みの障害モード）:

APIエンドポイントが段階的に構築される: T3（エラーエンベロープ）で、T4の可能性が高いのは統合テストまたは可観測性です。vitest|supertest|describe|it|expect または logger|telemetry|trace|metric をカバーする少なくとも1つのソースを75以上に引き上げてください。
フリーランス契約が条項ごとに草案される: T3（知的財産）で、T4の可能性が高いのは契約終了/紛争解決/責任です。terminate|notice|kill.fee|dispute|arbitration| liability に対する少なくとも1つのソースを75以上に引き上げてください。
Webサイトがページごとに構築される: T2（ギャラリー）で、T3の可能性が高いのは About/Contact/ショップです。それらに対するソースを75以上に引き上げてください。

ベンチ検証済みルール: 深さ2ターンを超える会話の場合、アクティブバンドは 過去だけを見るべきではありません。少なくとも1つの75以上のソースが、ドメイン内の次に来る可能性が高いサブトピックを予測しているべきです。ユーザーが既に言ったことを単にミラーリングするだけなら、ユーザーが方向転換した瞬間に面は古くなります。

これはランダムな脱線の推測ではありません。それはドメインを通るメインラインのパスです。契約には終了条項があり、RESTエンドポイントにはテストがあり、 Webサイトにはコンタクトページがあり、レシピには盛り付け指示があります。明白な次のセクションを挙げて、予熱してください。

デモーション — 観測可能、ソースごとに

ユーザーがサブトピックを完了し、新しいものに方向転換した場合、解決されたソースの優先度を必ず下げなければなりません。問題はどの程度か — そして答えはユーザーの新しいメッセージで観測可能であり、ドメイン判断のコールではありません。

テスト: ユーザーの新しいメッセージには、以前のソースの match: 正規表現がヒットする語彙が含まれていますか？

現在85以上のアクティブバンドにある各ソースについて、新しいユーザーメッセージをスキャンしてください。

マッチあり — ユーザーはまだこのソースの語彙を参照しています。そのソースは次のターンでも依然としてアクティブまたは横断的です。ライトデモート: 85から70に下げてください。隣接バンドに残し、ユーザーがその単語を再びタイプしたときにキューが表示されるようにします。
マッチなし — ユーザーはこのソースの語彙から離れました。そのソースは 直交的に解決されました。ハードデモート: 85から50に下げてください。テーブルから取り除きます。真にアクティブな新しいソースとの単語マッチ競合を防ぎます。

不確かな場合のデフォルト: ハードデモート。 ベンチ証拠（2026年5月）: ほとんどの方向転換は、高レベルのドメインが結合して見えても、語彙レベルでは直交的です。ライトデモートをデフォルトにすると、ユーザーが明確に方向転換した場合（Webサイトポートフォリオ: T2ギャラリーについて → T3 Stripe支払いについて — ギャラリーの語彙はT3に出現しません。両方のターンが「Webサイトについて」であってもギャラリーはハードデモートされるべきです）、隣接バンドに古い語彙が多すぎて残ってしまいました。まだ関連性のあるソースをハードデモートするコストは、ユーザーが後戻り参照したときにその単語に対するキューが全く得られないことです — しかし、ユーザーの新しいメッセージがグラウンドトゥルースです。もしユーザーが以前の語彙を参照したなら、正規表現マッチがそれを捕捉します。

実際の例（同じv3.0eルールに対する）:

以前のソース @ 85	ユーザーの新しいメッセージ	マッチ?	アクション
gallery-layout `match: gallery\|portfolio\|grid`	「今度はStripeを使ったContactページが必要…」	いいえ	ハード → 50
jr-pass `match: JR Pass\|Shinkansen\|reserved`	「JR Passで決まり。次は宿泊施設…」	はい (JR Pass)	ライト → 70
captaincy `match: captain\|armband\|differential`	「次はディフェンダー — TrippierかGordon」	いいえ	ハード → 50
ownership `match: template\|differential\|owned`	「キャプテンシーはテンプレートで行く」	はい (template)	ライト → 70

ルールはソースごとであり、ターンごとではありません。1つのターンで、いくつかの以前のソースをハードデモートし、他をライトデモートすることもあります — それは各ソースの語彙が新しいユーザーメッセージに実際に現れるかどうかに基づきます。

2つ以上のソースが両方ともまだマッチする場合 — 問題ありません。両方とも70になります。アクティブバンドは狭く保たれます。隣接バンドは複数の横断的ソースを希薄化なしに保持できます。

3バンド優先度モデル

優先度を3バンドのスイッチと考えてください。

85–90 — アクティブフォーカス（ユーザーが今まさにタイプしているもの）
65–80 — 隣接/間もなくアクティブになる/横断的/プロジェクト背景
50–60 — 最近完了した直交的（存続はするが、マッチ競合からは外れる）

もし85以上のバンドに3つ以上のソースがある場合、何かが間違っています — それらのほとんどは65-80または50-60にあるべきです。アクティブバンドは狭くあるべきです。

「ユーザーがそれを使っていない」という理由で以前のソースを削除してはなりません。ユーザーは今まさにそれを巡回しているかもしれません。それを彼らの下から引き抜くことがループの主な障害モードです。

あなたの出力が以前のファイルよりも少ないソースを持つ場合、あなたは誤りを犯しています。読み直し、欠落しているものを前方にコピーしてください。

INITIALモード — 広く予測する

最初の書き込みは耐荷重性があります。ユーザーが触れる可能性が高いすべてのサブ語彙を予測してください — 最初のターンで言ったことだけでなく。

ユーザーのシードメッセージを、はるかに大きな空間に関する1つのデータポイントとして扱ってください。「写真ポートフォリオのWebサイトを構築中」から、ユーザーはランタイムがキューを出す必要がある1つの単語（photography）を述べました。あなたの仕事は、機能する写真ポートフォリオサイトが触れるであろう約15〜20の単語ファミリー（専門分野、ギャラリーレイアウト、画像フォーマット、デプロイ先、予約機能、アクセシビリティなど）を外挿することです。

ドメインに関係なく同じ拡張を適用してください。「Series Aピッチを草案する」、「小説の第3章を書く」、または「Railsデプロイメントランブックをセットアップする」など — シードを読み、ユーザーがタイプする可能性が高いすべてのサブエリアを生成してください。

8つのソースで停止していることに気づいたら、「どのようなもっともらしいサブ語彙が欠けているのか？」と自問し、15〜20まで続けてください。事前の広さがループの成果物です。 ユーザーがタイプしたばかりの単語をカバーするターン2のソース追加は、ターン1の失敗です。

3つのキュー種別 — ヒントを最初に、次に単語キュー、次に文キュー

OpenCuesは3種類のキューをサポートしています。ヒントがスキルの最も価値の高い出力です — 実際の知識（事実、トレードオフ、判断プロンプト、落とし穴）を伝え、ユーザーがまだ知らないものを提供します。単語キューはユーザーがブレインストーミングできたであろう代替案を提示します。ヒントは彼らが知り得なかった情報を提示します。

出力時の優先順位:

ヒントを最初に。 言及する注目すべき用語ごとに、次のように自問してください。「この用語に関する1行の事実/落とし穴/判断プロンプトを提供できるか？」はいの場合 — ヒントを出力してください。
単語キューは、ユーザーが切り替える可能性のある複数の同等の形式がある場合のみ。 単語に1つの標準形しかない場合、単語キューを作成する手間はかけないでください。
散文面に対する文キュー ユーザーが作曲しているものに。

ヒントキュー — 用語に関する静的な1行の知識、LLM呼び出しなし

ユーザーが webp とタイプすると、ヒントがポップアップします: 「WebPは同じ品質で JPEGより約30%小さいファイルサイズ」。即時、ラウンドトリップなし。これは OpenCuesが提供する最も価値の高い単一の面です。 ユーザーが操作知識（単なる同義語ではなく）から利益を得るすべての用語は、ヒントに値します。

単語キュー — ハイライトされた単語の代替案

デフォルトのフォールバック。ユーザーが wedding とタイプし、bridal に切り替えます。

Yaml: match: <regex> または keywords: <カンマ区切りリスト>、および priority:。scope: フィールドはなし（または scope: words）。
最適: 複数のほぼ同等の形式を持つドメイン語彙 — レジスター、形式性、ニッチな専門用語。
代替リストに入れるすべての用語について、次のように自問してください: 「この用語はヒントエントリーにも値するか？」 はいの場合 — ヒントも追加してください。ほとんどの技術/ドメイン/固有名詞の代替案には、いつ/なぜそれぞれを選ぶかを説明する付随するヒントがあるべきです。ヒントのない代替案は、コンテキストのない語彙です — 価値の半分です。

文キュー — 文全体を異なるスタイルで書き換える

ユーザーが文を書き、キューがその3つの書き換えを提供します。

Yaml: scope: sentence、priority: 75–85、description: <1行>。match: はなし — 文キューは単語ではなく文全体にバインドします。
最適: 散文面。ユーザーが完全な文を作曲しており、スタイル上の代替案を望むかもしれないあらゆる場所 — ドキュメントが「散文主体」かどうかにかかわらず。技術ドキュメントには散文のポケットがあります（エンドポイントの要約、フィールドの説明、ランブックのイントロ）。契約には散文のポケットがあります（前文）。コードコメントには散文があります。電子メールはほとんど散文です。 ドキュメントタイプではなく、面ごとに判断してください。

ヒントキュー — 詳細（フォーマット、分類法、コンテンツタイプ）

Yaml: name: のみ（ソースフォルダ内またはCUES.mdの ## Tips 本文内）。本文は [{id, words: {word: {tip, alts}}}] 形式のJSONコードブロックです。
最適: キューが「ここに同義語があります」ではなく「ここに知っておくべきことがあります」という用語 — 固有名詞、API、ツール、プラットフォーム名、技術的プリミティブ、ビジネス上の決定、管轄権の癖。
ヒントのコンテンツタイプ — 中立的な事実を超えて:
- FACT — 「WebPはJPEGより約30%節約。」
- DECISION-PROMPT — 「価格設定を書く前に、定額か時間給かセッション単位かを決めてください。フレーミングが変わります。」
- PITFALL — 「Stripeは新規アカウントで7日間資金を保留します。」
- TRADE-OFF — 「プライバシーのためにEXIFを削除するか、アートメタデータのために保持するか。オーディエンス依存。」
- REFERENCE — 「cloudflarepages.com/docs で制限を参照。」これらを混ぜてください。純粋な事実のヒットパックは混合パックより劣ります。

面ごとの選択ルール

出力する各トピックについて、それがどの面をカバーするかを自問し — 常に最初にヒントキューのオプションを確認してください:

ユーザーが1行のFACT / TRADE-OFF / DECISION-PROMPT / PITFALLから利益を得る用語 → ヒントキュー（推奨）
用語 + ヒントあり AND 複数の同等の形式あり → ヒントキュー WITH alts:
                                                              （両方をユーザーに提供）
単一の用語で複数の同等の形式あり（役立つヒントなし） → 単語キュー
ユーザーが作曲している散文（任意の長さ、任意のドキュメント） → 文キュー
それ以外 → スキップ

ヒントキューのエントリーは、altsも運ぶことができます — これによりユーザーは知識と語彙の両方を1回のキューから得られます。単語キューよりもヒントキューを優先する理由の1つです。

ファイル形式と出力ルール

.cues/CUES.md は、厳密に構造化されたMarkdown + YAMLです。

# Cues

## Sources

### <source-id>
`match: <regex>`
`priority: <50-90>`
`scope: words|sentence` （オプション、デフォルトは words）

`description: <省略せず改行を想定した1行>`

### <other-source-id>
...

## Tips

```json
[
  {"id": "webp", "words": {"webp": {"tip": "WebP saves ~30% over JPEG at same quality.", "alts": []}, "avif": {"tip": "AVIF offers even better compression than WebP but with narrower browser support (Chrome/FF only).", "alts": []}}}
]


### 構文規則

1. **Sources セクション:** YAML風のインラインキー + 値。コロンの後にスペースが
   必要です。引用符は必要ありません（値にコロンが含まれない限り）。
2. **`match:` 正規表現:** 大文字小文字を区別しません。単語の境界でワイルドカードを
   使用します。`|` で複数の単語を許可します。
3. **`priority:` 整数:** 50〜90。アクティブフォーカスは85-90。隣接は65-80。
   完了済みは50-60。
4. **`description:` — 常に1行にしてください。** ランタイムは説明フィールドを
   直接ユーザーに表示します（Web UIではツールチップとして、IDEでは
   クイック情報として）。長い説明は省略され、UXを損ないます。
   「New users may not realize that Stripe holds funds for 7 days on new accounts」
   は良い説明です。「Discusses the various aspects of…」は省略されるだけの
   悪い説明です。
5. **`scope:` — デフォルトは `words`。`sentence` に設定して文キューを示します。
   `match:` は文キューでは必須ではありません（無視されます）。
6. **Tips セクション:** Sourcesの後に配置された、1つのJSONコードブロック。
   JSON構造: `[{"id": "用語", "words": {"用語": {"tip": "…", "alts": ["…"]}}}]`。
   JSONは有効で、末尾のカンマがない必要があります。
7. **ファイル終端:** 余分なテキストやMarkdownはありません。ランタイムは `## Tips`
   の後はすべてを無視します。

### 優先度割り当てルール

- **85+** — ユーザーが**今まさに**タイプしている語彙。ユーザーの最後のメッセージに
  マッチする `match:` パターンを持つソース。最大3つまで。
- **75** — 前方参照（次に来る可能性が高いセクションを予測する新しいソース）。
- **65-70** — ユーザーが先ほどタイプした語彙（ライトデモート後）または
  プロジェクト全体のコンテキスト（フレームワーク名、環境）。
- **50-60** — 完了したサブトピックの語彙（ハードデモート後）。

新しいソースを追加して75に設定することは、前方参照を予熱する主要なメカニズムです。

## ファイル出力のベストプラクティス

### 見出しでソースをグループ化する

```markdown
### ギャラリー
`match: gallery|portfolio|grid`
`priority: 85`

`description: 写真ポートフォリオのギャラリーレイアウト — グリッド、スライダー、
  Masonry、lightbox`

### 支払い
`match: stripe|payment|checkout|cart`
`priority: 70`

`description: Stripeチェックアウト、支払いインテント、Webhook、テストモード`

毎ターン更新する

ユーザーの実質的なターンごとに書き換えてください。以前のファイルからコピーし、優先度を調整し、新しいソースを追加し、前方参照を予熱してください。

保存し、広範囲をカバーする

INITIALモードでは15〜20のソース。CONTINUATIONでは少なくとも同じ数。ソースを削除しないでください — 直交的に解決されたソースを50-60に下げてください。

削除は禁止

ループの主な障害モード: ソースを削除すると、ユーザーが後戻り参照したときにキューが消え、混乱を引き起こします。削除しないでください。デモートしてください。

OpenCues Cuesスキル — v3.1 2026年5月

opencues/opencues

opencues とは？

お気に入りのAIに質問する

ドキュメント