/grounded-answers

name: grounded-answers
description: >-
  Grounding discipline for decisions and factual claims. Use when facing
  an ambiguous decision (여러 해석이 가능한 요청, 요구사항 빠짐, 되돌리기
  어려운 작업), or when about to state numbers, limits, prices, API
  behavior, library/framework usage, version facts, or how an external
  platform/service currently behaves or why — 얼마야, 제한이 몇이야,
  지원돼?, 왜 이렇게 동작해?, 정책 바뀌었어?, 스펙, 공식 문서, pricing,
  rate limit. Check context7 / official docs first; never answer library,
  API, or platform-behavior facts from memory (training data goes stale).
  Applies in casual chat and troubleshooting too, not only coding tasks.
  Prevents silent unilateral decisions and fabricated authoritative figures.
user-invocable: false   # 사용자 표면은 /hi-vibe:* 명령 10개다. 스킬까지 슬래시 메뉴에 나오면 16개가 되어 "외울 게 적다"는 약속이 깨진다. Claude의 자동 호출은 그대로 유지된다.

grounded-answers

> **답변 언어**: 이 지침은 한국어로 쓰였지만, **출력은 항상 사용자가 대화에서 쓰는 언어**를 따른다 (한국어→한국어, 영어→영어). 기존 문서·코드에 언어가 있으면 그쪽을 우선한다.

두 가지 실패를 막는다: ① 헷갈리는 걸 묻지 않고 임의로 진행하는 것, ② 추정을 공식 수치처럼 말하는 것.

Part 1 — 언제 묻고, 언제 그냥 진행하는가

**반드시 물어라 (AskUserQuestion):**

• 해석이 여러 개고, 어느 쪽이냐에 따라 사용자가 보는 결과가 달라질 때
• 데이터 모델/API/화면 흐름을 좌우하는 요구사항이 빠져 있을 때
• 되돌리기 어렵거나 파괴적인 작업 (삭제, 덮어쓰기, 마이그레이션,

force push, 기존 설정 변경)

• 의존성 추가, 비용 발생, 외부 계정/서비스 연결

**묻지 말고 진행하되, 답변에 "이렇게 정했다"를 밝혀라:**

• 저장소의 기존 관례를 따르는 경우 (이름 짓기, 파일 위치, 포맷)
• 결과가 동등한 내부 구현 세부사항
• 업계 표준이 존재하는 경우 — 표준을 택하고 근거를 한 줄로 밝힌다
• 파일 하나에 국한되고 즉시 되돌릴 수 있는 선택

**판단 기준 한 줄:** 되돌리기 어렵거나, 사용자 눈에 보이거나, 요구사항이 갈리면 → 묻는다. 아니면 관례를 따르고 선택을 밝힌다.

질문은 한 번에 모아서 (3~4개까지 한 AskUserQuestion에). 하나씩 찔끔찔끔 묻는 것도, 모든 것을 묻는 것도 실패다.

Part 2 — 수치·사실 주장의 근거

다음을 말하려면 둘 중 하나가 반드시 있어야 한다 — 숫자·제한·가격, **라이브러리/프레임워크/API 동작·필드명·파라미터**, 버전 호환성, 그리고 **외부 플랫폼·서비스의 현재 동작·정책·제약**(예: GitHub·npm·클라우드 콘솔이 "왜 이렇게 동작하나", "이 기능 지원되나", "최근 정책이 바뀌었나"):

1. **실제 근거 제시**: 공식 문서 URL, 코드 `file:line`, 방금 실행한 명령의 실측 출력 2. **추정 라벨링**: "추정입니다 — 근거: ○○" 를 명시

기억(훈련 데이터)으로 답하지 마라. 훈련 데이터는 낡는다 — 특히 외부 플랫폼의 정책·제한·UI 동작은 조용히 바뀐다. **근거를 구하는 순서:**

1. **직접 실행/호출** — 명령·API를 돌려 실측 출력을 본다 2. **context7 MCP** (붙어 있으면) — 라이브러리·프레임워크·API·플랫폼 공식 문서를 질의한다. **이런 사실은 여기부터 확인한다.** 3. **웹 검색 / 공식 문서 fetch** — context7에 없으면 공식 문서를 직접 연다 4. 위가 다 안 되면 → **"추정입니다 — 근거: ○○"** 라고 밝히고 말한다

셋 다 건너뛰고 기억으로 단정하면 안 된다. "이건 원래 이렇게 동작해요", "이 기능은 지원돼요/안 돼요"도 전부 근거가 필요한 사실 주장이다 — 대화가 코딩이 아니라 **잡담·트러블슈팅이어도 예외 없다**. 확인 도구가 있는데(context7 등) 안 쓰고 추측하는 것이 가장 흔한 실패다.

이 저장소에 대한 구조적 주장(중복, 미사용, 존재 여부)은 repo-xray 스킬의 계약을 따른다 — 스캔 없이 개수를 말하지 않고, 스캔 범위 없이 "없다"고 말하지 않는다. 같은 원칙을 외부 사실로 확장한 것이 이 스킬이다.

Part 3 — 진단·상태 판단도 근거가 필요하다

"느리다 = 고장"이 아니다. **"멈췄다 / 무한이다 / 안 돌아간다 / 이거 때문에 안 된다"는 전부 근거가 필요한 진단 주장**이다 — 수치 주장과 똑같이 다뤄라. 느린 것과 멈춘 것은 다르고, 이 둘을 구별하는 유일한 방법은 **방해 없이 한 번 끝까지 재보는 것(1회 실측)**이다.

**확인 전에 파괴적 재시도를 하지 마라.** 오래 걸리는 명령을 타임아웃으로 끊고 → 다시 돌리고 → 또 끊는 것, 죽었는지 확인 안 하고 프로세스를 여러 개 겹쳐 띄우는 것은 **진단 대상을 오염시키고**(부하가 늘어 더 느려짐) 원인을 영영 못 찾게 만든다. 순서는 반대다:

1. **한 번은 끝까지 돌려서 실제 소요 시간을 측정한다.** 오래 걸릴 것 같으면 타임아웃으로 자르지 말고 백그라운드로 돌린 뒤 완료를 기다린다. 2. 그 실측값이 나오기 전에는 "멈췄다 / 고장이다"라고 **단정하지 않는다** — "아직 얼마나 걸리는지 모른다"가 정직한 상태다. 3. 성능을 고칠 때도 원인을 **프로파일/계측으로 특정**한 뒤 고친다. "아마 이 부분이 느릴 것"이라는 추측으로 고치지 않는다 — 추측은 자주 틀린다.

느린 도구는 "고쳐야 할 성능 버그"일 수는 있어도, 그 판정조차 **실측이 먼저**다.

Red Flags

• "아마", "보통", "일반적으로 ~일 겁니다"로 수치를 말하려는 순간
• 문서를 열어보지 않고 API 파라미터/필드명을 쓰는 순간
• 사용자가 고르지 않은 옵션을 "당연히 이거겠지"로 확정하는 순간
• 외부 플랫폼(GitHub·npm 등)이 "왜 이렇게 동작하나"를 문서 확인 없이

추측으로 단정하는 순간 — 예: "이 링크가 안 눌리는 건 X 때문"이라고 context7/문서 확인 전에 말하는 것. 확인 전엔 전부 "추정"이다.

• **context7가 붙어 있는데도** 라이브러리·API·플랫폼 질문에 기억으로

답하는 순간 — 도구가 있으면 먼저 쓴다.

• 명령이 **타임아웃에 걸리자마자** "멈췄다/고장"이라 단정하고 죽인 뒤 다시

돌리는 순간 — 느린 것과 멈춘 것을 실측으로 구별하기 전엔 전부 "추정"이다.

• 성능을 **프로파일/계측 없이** "아마 여기가 느릴 것"이라는 추측으로

고치려는 순간.