Cues — 사용자의 다음 어휘 예측은(는) 무엇을 하나요?

당신은 대화를 통해 도메인을 탐색하는 사용자 옆에 앉아 있습니다. 사용자는 초안을 작성하거나, 코드를 만들거나, 글을 쓰고 있습니다. 당신의 사이드 이펙트는 단 하나의 파일 — .cues/CUES.md — 입니다. OpenCues 런타임은 이 파일을 다음 리로드 시 로드하여 사용자가 타이핑할 때 대안, 재작성, 팁을 표시합니다.

채팅 응답에 추가로 파일을 작성해야지, 채팅 응답을 대체해서는 안 됩니다

이것은 사이드 이펙트 스킬입니다. 사용자가 실제로 요청한 작업과 함께 동작합니다. 사용자가 "X에게 이메일 초안을 작성 중입니다 — 도와주세요"라고 말하면, 당신의 채팅 응답은 이메일 초안을 작성하며, 동시에 사이드 이펙트는 .cues/CUES.md를 작성하여 앞으로 이런 유형의 이메일 작성 시 필요한 큐를 예측합니다. 사용자가 "웹사이트를 만들고 있어요"라고 말하면, 채팅 응답은 명확한 질문을 하고, 사이드 이펙트는 .cues/CUES.md를 작성하여 그들의 어휘를 예측합니다.

채팅 작업과 큐 사이드 이펙트는 독립적입니다. 큐 파일은 절대 사용자의 가시적인 결과물이 아닙니다 — 런타임이 조용히 로드할 수 있도록 디스크에 존재합니다. 만약 "채팅으로 이미 도움을 줬으니까"라는 이유로 파일 작성을 생략한다면, 이 스킬의 계약을 위반하는 것입니다. 두 가지를 모두 수행하세요.

채팅 응답 끝에 있는 한 줄의 괄호만이 이 파일의 유일한 언급입니다. 채팅 출력을 방해하지 않습니다.

결과물은 예측입니다. 사용자가 이미 그 단어를 입력한 후에 도착하는 큐는 너무 늦습니다. 기준은: 사용자가 다음 턴에 새 어휘를 도입할 때, 그 어휘는 이미 이번 턴에 당신이 작성한 내용에 포함되어 있어야 합니다.

두 가지 모드

다른 작업을 하기 전에, .cues/CUES.md를 읽으세요. 파일의 존재 여부에 따라 모드가 결정됩니다.

INITIAL (파일 없음) — 작업에 필요한 전체 예측 표면을 처음부터 만듭니다.
CONTINUATION (파일 있음) — 표면을 확장합니다. 기존 파일을 먼저 읽고, 당신의 출력은 엄격한 상위 집합이어야 합니다.

엄격한 확장 (CONTINUATION만 해당)

새 대화 맥락이 직접적으로 모순되지 않는 한(사용자가 전환했거나, 섹션을 포기했거나 등), 파일에 이미 있는 모든 소스가 당신의 출력에 동일한 이름, 동일한 match:, 동일한 본문으로 나타나야 합니다. 다음을 수행할 수 있습니다:

현재 활성 집중 범위에 있는 소스의 우선순위를 높입니다.
사용자가 완료한 섹션의 소스 우선순위를 낮춥니다.
이전 패스에서 예측이 부족했던 어휘에 대한 새 소스를 추가합니다.

매 턴마다 다시 작성 — "변경 사항이 없으면 아무것도 하지 않음"이 아닙니다

사용자의 실질적인 턴마다 반드시 Write 도구를 호출하여 완전히 업데이트된 CUES.md를 작성해야 합니다. 이전 턴과 비교해 변경 사항이 작더라도 마찬가지입니다. 이유: 사용자가 방금 새 메시지를 보냈습니다. 그 메시지는 대화의 초점을 이동시켰습니다. 비록 단 하나의 하위 주제일지라도 말이죠. 활성 범위는 그 움직임을 추적해야 합니다. "변경 없음" 출력은 사용자가 전환하지 않았다고 결정한 것인데, 이는 거의 항상 틀립니다. (새로운 실질적 턴 이후에는 특히 더 그렇습니다.)

만약 생각해본 결과 사용자의 새 메시지가 정말로 새로운 내용을 추가하지 않는다고 믿는다면 — 사용자가 "고마워요"라고 답했거나, 여전히 같은 미세 주제 내에서 빠른 후속 질문을 한 경우 — 파일 작성을 건너뛸 수 있습니다. 그러나 기준은 높습니다: 구체적인 이유를 명시하세요 ("사용자가 활성 범위 주제 내에서 새로운 하위 어휘 없이 명확한 질문을 함"). 건너뛰기는 예외이지, 기본값이 아닙니다.

벤치마크 증거 (2026년 5월, judge-bench): 스킬이 N>1 턴에서 재작성을 건너뛰면, 턴 3까지 활성 범위가 턴 1의 주제에 고정되어 참신성이 급격히 떨어집니다. 매 턴마다 다시 작성하면 초점이 사용자를 따라 움직입니다.

선행 예측 — 다음 2-3개 섹션을 이름 짓고, 그에 대한 소스 우선순위를 높이세요

우선순위를 할당하기 전에, (파일에는 적지 말고 머릿속으로) 사용자의 현재 위치에서 이 도메인에서 다음에 나올 가능성이 가장 높은 2-3개의 하위 주제를 적어보세요. 그런 다음 확인하세요: 이 표면에 그 각각의 예상 섹션에 대해 75+ 이상의 소스가 하나 이상 있습니까?

없다면, 그 빈 곳을 채울 소스를 상승시키세요 — 완전히 새로운 ### <id>거나 기존 낮은 우선순위 소스를 올리는 것입니다.

요점은 확실성이 아니라 범위입니다. 만약 사용자가 대화를 계속 진행한다면, 다음 1-2개 섹션이 이미 예열되어 있기를 바랍니다. 대신 사용자가 뒤로 돌아간다면, 후처리기/하향 규칙이 다음 턴에 선행 예측 소스를 비활성화할 것입니다 — 이는 저렴한 비용입니다.

예시 (2026년 5월 벤치마크 검증된 실패 모드):

API 엔드포인트를 단계별로 구축: T3(에러 봉투)에서 예상 T4는 통합 테스트 또는 관측 가능성. vitest|supertest|describe|it|expect 또는 logger|telemetry|trace|metric을 포함하는 소스 하나 이상을 75+로 상승시키세요.
프리랜서 계약서를 조항별로 작성: T3(지식 재산권)에서 예상 T4는 해지 / 분쟁 해결 / 책임. terminate|notice|kill.fee|dispute|arbitration|liability에 대한 소스 하나 이상을 75+로 상승시키세요.
웹사이트를 페이지별로 구축: T2(갤러리)에서 예상 T3는 소개 / 연락처 / 쇼핑몰. 이에 대한 소스를 75+로 상승시키세요.

벤치마크 검증된 규칙: 2턴 이상 진행된 대화의 경우, 활성 범위는 과거만 바라보면 안 됩니다. 최소한 하나의 75+ 소스는 도메인에서 그럴듯한 다음 하위 주제를 예측해야 합니다. 사용자가 이미 말한 것만 반영한다면, 사용자가 전환하는 순간 표면은 낡은 것이 됩니다.

이것은 무작위 잡담에 대한 추측이 아닙니다. 그것은 도메인의 주요 경로입니다: 계약에는 해지 조항이 있고, REST 엔드포인트에는 테스트가 있으며, 웹사이트에는 연락처 페이지가 있고, 레시피에는 플레이팅 지침이 있습니다. 명백한 다음 섹션을 이름 짓고 미리 예열하세요.

우선순위 하향 — 관찰 가능하며, 소스별로 수행

사용자가 하위 주제를 완료하고 새 주제로 전환하면, 해결된 소스의 우선순위를 반드시 낮춰야 합니다. 문제는 얼마나 낮출 것인가입니다 — 그리고 답은 사용자의 새 메시지에서 관찰 가능하며, 도메인 판단 호출이 아닙니다.

테스트: 사용자의 새 메시지에 이전 소스의 match: 정규식이 일치하는 어휘가 포함되어 있습니까?

현재 85+ 활성 범위에 있는 각 소스에 대해, 새 사용자 메시지를 스캔하세요:

일치 발견 — 사용자가 여전히 이 소스의 어휘를 참조하고 있습니다. 해당 소스는 다음 턴에도 여전히 활성 상태이거나 교차적입니다. 약하게 하향: 85에서 70으로 떨어뜨리세요. 인접 범위에 유지하여 사용자가 그 단어를 다시 입력할 때 큐가 표시되도록 합니다.
일치 없음 — 사용자가 이 소스의 어휘에서 멀어졌습니다. 해당 소스는 직교적으로 해결되었습니다. 강하게 하향: 85에서 50으로 떨어뜨리세요. 테이블에서 제거하세요. 진정으로 활성화된 새 소스와 단어 일치를 위해 경쟁하지 못하게 합니다.

불확실할 때의 기본값: 강하게 하향. 벤치마크 증거 (2026년 5월): 대부분의 전환은 어휘 수준에서 직교적입니다, 상위 수준 도메인이 결합되어 보여도 마찬가지입니다. 약하게 하향을 기본값으로 사용하면 사용자가 명확히 전환했을 때 인접 범위에 너무 많은 낡은 어휘가 남습니다 (웹사이트 포트폴리오: T2 갤러리 → T3 Stripe 결제 — 갤러리 어휘는 T3에 나타나지 않음; 갤러리는 두 턴 모두 "웹사이트에 관한" 것이더라도 강하게 하향되어야 합니다). 여전히 관련 있는 소스를 강하게 하향하는 비용은 사용자가 다시 언급할 때 해당 단어에 대한 큐가 전혀 없게 되는 것입니다. 그러나 사용자의 새 메시지가 진실입니다: 이전 어휘를 참조했다면 정규식 일치가 잡아냅니다.

실제 예시 (동일한 v3.0e 규칙 적용):

85에서의 이전 소스	사용자의 새 메시지	일치?	작업
gallery-layout `match: gallery	portfolio	grid`	"이제 Stripe가 있는 연락처 페이지가 필요해요…"
jr-pass `match: JR Pass	Shinkansen	reserved`	"JR Pass로 할게요. 이제 숙소…"
captaincy `match: captain	armband	differential`	"다음은 수비수 — Trippier 또는 Gordon"
ownership `match: template	differential	owned`	"주장은 템플릿으로 갈게요"

규칙은 턴별이 아니라 소스별입니다. 한 턴에서 일부 이전 소스는 강하게 하향하고 다른 것은 약하게 하향할 수 있습니다 — 각 소스의 어휘가 새 사용자 메시지에 실제로 나타나는지에 따라 결정됩니다.

두 개 이상의 소스가 모두 여전히 일치해도 괜찮습니다 — 둘 다 70으로 갑니다. 활성 범위는 좁게 유지됩니다; 인접 범위는 여러 교차적 소스를 희석 없이 보유할 수 있습니다.

3밴드 우선순위 모델

우선순위를 세 가지 범위 스위치로 생각하세요:

85–90 — 활성 집중 (사용자가 지금 당장 입력 중인 것)
65–80 — 인접 / 곧 활성화될 / 교차적 / 프로젝트 배경
50–60 — 최근 완료된 직교적 (유지되지만 일치 경쟁에는 참여하지 않음)

만약 85+ 범위에 소스가 3개 이상 있다면, 뭔가 잘못된 것입니다 — 대부분은 65-80 또는 50-60에 있어야 합니다. 활성 범위는 좁아야 합니다.

"사용자가 사용하지 않았다"는 이유로 이전 소스를 삭제할 수 없습니다. 사용자가 바로 지금 그 주제를 다시 다룰 수도 있습니다; 사용자 모르게 제거하는 것이 이 루프의 주요 실패 모드입니다.

출력에 이전 파일보다 소스가 적다면 실수한 것입니다. 다시 읽고 누락된 것을 앞으로 복사하세요.

INITIAL 모드 — 광범위하게 예측

첫 번째 쓰기는 중요한 작업입니다. 사용자가 접촉할 가능성이 있는 모든 하위 어휘를 예측하세요 — 시작 턴에서 말한 것만이 아닙니다.

사용자의 시드 메시지를 훨씬 더 큰 공간에 대한 하나의 데이터 포인트로 취급하세요. "내 사진 포트폴리오 웹사이트를 만들고 있어요"에서 사용자는 런타임이 큐를 제공해야 하는 단어를 하나만 말했습니다 (photography); 당신의 임무는 모든 작동하는 사진 포트폴리오 사이트가 접촉할 ~15–20개의 단어군 (전문 분야, 갤러리 레이아웃, 이미지 형식, 배포 대상, 예약 메커니즘, 접근성 등)을 추론하는 것입니다.

도메인에 관계없이 동일한 확장을 적용하세요. "시리즈 A 피치 작성", "소설 3장 쓰기", "Rails 배포 런북 설정"에 대해 — 시드를 읽고, 사용자가 입력할 모든 하위 영역을 생성하세요.

만약 8개 소스에서 멈추게 된다면, "내가 놓치고 있는 그럴듯한 하위 어휘는 무엇인가?"라고 묻고 15–20개까지 계속 가세요. 초기 폭이 루프의 결과물입니다. 사용자가 방금 입력한 단어를 커버하는 턴 2의 소스 추가는 턴 1의 실패입니다.

세 가지 큐 유형 — 팁을 첫 번째로, 그 다음 단어 큐, 그 다음 문장 큐

OpenCues는 세 가지 큐 종류를 지원합니다. 팁은 이 스킬의 가장 가치 있는 출력입니다 — 사용자가 아직 모르는 실제 지식(사실, 절충점, 결정 프롬프트, 함정)을 전달합니다. 단어 큐는 사용자가 브레인스토밍할 수 있었던 대안을 표면화합니다; 팁은 그들이 알 수 없었던 정보를 표면화합니다.

발행 시 우선순위:

팁 우선. 언급할 주목할 만한 용어마다 "한 줄의 사실/함정/결정 프롬프트를 줄 수 있나?"라고 묻습니다. 그렇다면 — 팁을 발행합니다.
단어 큐는 사용자가 여러 동등한 형태 사이를 오갈 가능성이 있을 때만 사용합니다. 단어에 하나의 표준 형태가 있다면 단어 큐는 신경 쓰지 마세요.
산문 표면을 위한 문장 큐 사용자가 작성 중인 경우.

팁 큐 — 용어에 대한 정적 한 줄 지식, LLM 호출 없음

사용자가 webp를 입력하면 팁이 뜹니다: "WebP는 동일한 품질에서 JPEG보다 약 30% 작은 파일을 제공합니다." 즉시, 왕복 없음. 이것은 OpenCues가 제공하는 단일 가장 가치 있는 표면입니다. 사용자가 동의어뿐만 아니라 운영 지식을 필요로 하는 모든 용어는 팁을 받을 자격이 있습니다.

단어 큐 — 강조 표시된 단어에 대한 대안

기본 폴백. 사용자가 wedding을 입력하면 bridal로 순환합니다.

Yaml: match: <정규식> 또는 keywords: <쉼표 목록>, 더하기 priority:. scope: 필드 없음 (또는 scope: words).
최적: 여러 대략 동등한 형태(레지스터, 격식, 틈새 전문 용어)가 있는 도메인 어휘.
alts 목록에 넣는 모든 용어에 대해, "이 용어도 팁 항목을 받을 자격이 있나?"라고 묻습니다. 그렇다면 팁도 추가하세요. 대부분의 기술/도메인/고유 명사 alts에는 각각을 선택하는 시기/이유를 설명하는 팁이 동반되어야 합니다. 팁이 없는 alts는 문맥 없는 어휘입니다 — 가치의 절반입니다.

문장 큐 — 전체 문장을 다른 스타일로 재작성

사용자가 문장을 썼습니다; 큐가 그 문장의 세 가지 재작성을 제공합니다.

Yaml: scope: sentence, priority: 75–85, description: <한 줄>. match: 없음 — 문장 큐는 단어가 아니라 전체 문장에 바인딩됩니다.
최적: 산문 표면. 사용자가 전체 문장을 작성하고 스타일 대안을 원할 수 있는 모든 곳 — 문서가 "산문이 많은"지 여부와 관계없이. 기술 문서에는 산문 주머니가 있습니다 (엔드포인트 요약, 필드 설명, 런북 소개); 계약서에는 산문 주머니가 있습니다 (전문); 코드 주석에는 산문이 있습니다; 이메일은 대부분 산문입니다. 문서 유형별이 아니라 표면별로 결정하세요.

팁 큐 — 세부 정보 (형식, 분류, 콘텐츠 유형)

Yaml: name:만 (소스 폴더 내 또는 CUES.md의 ## Tips 본문 내). 본문은 JSON 코드 블록이며 [{id, words: {word: {tip, alts}}}] 형태입니다.
최적: 큐가 "동의어입니다"보다 "이것을 알아야 합니다"에 가까운 용어 — 고유 명사, API, 도구, 플랫폼 이름, 기술 기본 요소, 비즈니스 결정, 관할권 특이 사항.
팁 콘텐츠 유형 — 중립적 사실을 넘어서세요:
- FACT — "WebP는 JPEG보다 약 30% 절약합니다."
- DECISION-PROMPT — "가격 책정을 작성하기 전에, 고정 vs 시간당 vs 세션당을 결정하세요 — 프레이밍이 바뀝니다."
- PITFALL — "Stripe는 새 계정에서 7일 동안 자금을 보류합니다."
- TRADE-OFF — "개인 정보 보호를 위해 EXIF를 제거하거나 예술 메타데이터를 위해 유지. 대상에 따라 다름."
- REFERENCE — "제한 사항은 cloudflarepages.com/docs를 참조하세요." 혼합하세요. 순수 팩트 팩보다 혼합 팩이 더 좋습니다.

표면별 선택 규칙

발행할 각 주제에 대해 어떤 표면을 다루는지 질문하고, 항상 팁 큐 옵션을 먼저 확인하세요:

사용자가 한 줄의 FACT / TRADE-OFF / DECISION-PROMPT / PITFALL의 혜택을 받을 용어 → 팁 큐 (선호)
용어 + 팁이 있고 여러 동등한 형태가 있음 → 팁 큐와 alts 함께:
                                                             (사용자에게 둘 다 제공)
여러 동등한 형태가 있는 단일 용어 (유용한 팁 없음) → 단어 큐
사용자가 작성 중인 산문 (모든 길이, 모든 문서) → 문장 큐
그 외 → 건너뛰기

팁 큐 항목은 alts도 함께 가질 수 있습니다.

… (전체 SKILL.md 내용 계속)

예시: 파일 구조

CUES.md는 다음과 같이 구성됩니다:

# Cues

## Sources

### gallery-layout
- **priority:** 85
- **match:** gallery|portfolio|slideshow
- **alts:** ["갤러리", "포트폴리오", "슬라이드쇼"]
- **tip:** "정사각형 썸네일 그리드는 모바일에서 빠르게 로드됩니다."

## Tips

```json
[
  {
    "id": "gallery-layout",
    "words": {
      "gallery": {
        "tip": "정사각형 썸네일 그리드는 모바일에서 빠르게 로드됩니다. 썸네일 크기를 300x300px로 유지하세요.",
        "alts": ["갤러리", "포트폴리오"]
      }
    }
  }
]


## 요약

이 스킬은 사용자가 도메인 작업을 할 때마다 항상 `.cues/CUES.md` 파일을 생성/갱신합니다.
사용자의 현재 대화 턴에서 다음 턴에 사용할 어휘, 지식, 대안을 예측하여 기록합니다.
파일은 OpenCues 런타임이 로드하여 사용자가 타이핑할 때 팁, 단어 대안, 문장 재작성을 제공합니다.

- 도메인 신호가 있을 때만 작동합니다 (감사, 확인 등은 건너뛰기).
- 사용자가 도메인을 전환하면 (예: Express API → Next.js 사이트) 파일을 새로 작성합니다.
- 매 실질적 턴마다 다시 작성하며, 변경 사항이 작아도 추적합니다.
- 활성 범위(85+), 인접 범위(65-80), 완료 범위(50-60)로 우선순위를 관리합니다.
- 팁 유형을 가장 선호하며, 단어 큐와 문장 큐가 뒤따릅니다.
- 첫 번째 작성 시 15-20개의 어휘군을 예측하고, 이후 각 턴에서 확장합니다.

---
*이 파일은 OpenCues 런타임에 의해 자동으로 읽히며, 사용자에게 직접 표시되지 않습니다.*

Cues — 사용자의 다음 어휘 예측