—
이름: [웨어하우스 스킬]
버전: [xyz]
설명: “사용자가 [회사]의 데이터 웨어하우스에서
[비즈니스 영역 목록]과 관련된 질문을 조회하도록 요청하는 경우에만 이 스킬을 사용하십시오.
[인접한 엔지니어링 작업] 또는 데이터 웨어하우스 관련 요소가 없는 질문에는 이 스킬을 사용하지 마십시오.”
—
# [웨어하우스] 스킬 지침
## 설명
안전하고 효율적인 [웨어하우스] 쿼리를 위한 유일한 정보 소스입니다.
쿼리 실행 지침을 위해 [목록]에 나열된 다른 스킬에서 참조됩니다.
데이터 분석가처럼 전략적 통찰력과 데이터 기반
권장 사항을 제공하되, 진행 과정에서 지침을 구하십시오.
**범위 외 결정** : [제품 영역 등] → 데이터만
표시하고 “결정은 [소유 팀]의 결정입니다”라고 명시하며, 입장을 표명하거나
코드 수정을 작성하지 마십시오.
## 쿼리 실행
우선순위:
1. **[관리형 연결]** (사용 가능한 경우): [쿼리 도구] / [스키마 도구]
2. **[CLI 대체]** (설치된 경우): [기본 프로젝트, 대체 프로젝트]
3. **둘 다 아님** — 사용자에게 인증을 요청한 후 중지
—
# 시맨틱 레이어(필수 첫 번째 단계)
관리되는 시맨틱 레이어는 모든 데이터 질문에 대한 **필수 기본 경로**
입니다 . [BI 도구]와 동일한 숫자, 조인/세분화/필터가 내장되어 있습니다.
아래 참조 문서를 통한 원시 SQL은 **대체**
이며, 시맨틱 레이어 경로가 요청을 처리할 수 없는 경우에만 사용됩니다 .
## 필수 워크플로
1. **로드** — [각 런타임에서 시맨틱 레이어를 로드하는 방법(대체 방법 포함)]
2. **검색** — 키워드로 측정값/차원 검색 **항상
세그먼트를 확인하세요** (명명된 정규 인구 필터 – 이러한 필터에 대한 WHERE 절을 직접 작성하는
것이 가장 흔한 오답 유형입니다.)
3. **컴파일 + 실행** – 사양 빌드 → SQL로 컴파일 → 실행
4. **대체** – 검색에서 관련 메트릭을 찾지 못했거나 컴파일에 실패한 경우에만 → `references/*.md`를
통한 원시 SQL (아래 3부 참조) > **일찍 포기하지 마세요.** 다음과 같은 이유로 원시 SQL로 대체하지 마세요. > – “[사용자 지정 날짜 필터링/코호트]” → [시간 차원 사양에서 다룸] > – “[조인이 필요함]” → [메트릭 계층에서 이미 조인을 캡슐화함] > – [에이전트가 시맨틱 계층을 건너뛰기 위해 사용하는 3~4가지의 반박된 변명] ### 날짜 창 및 시간대 – 쿼리하기 전에 결정 –
**기준일 vs. 최근 N일** : [각각의 규칙]
– **”지난주/지난달”** → 최근 7/30일이 아닌 마지막 *완전한* 달력 주/월
– **기본 시간대** : [TZ]; [특정 보고서 롤업 예외]
– **최신성 지연** : [일부] 테이블은 늦게 정산됩니다. “어제”가 아닌 MAX(날짜)를 기준으로 합니다.
—
# 1부: 반드시 알아야 할 사항 (모든 요청 전에 먼저 읽어야 함)
## 🚀 빠른 시작 워크플로
1. **먼저 위험 신호 확인** : [제한/개인 식별 정보 요청, 접근이 제한된 도메인,
추가 검증이 필요한 중요 요청]
2. **범위 외 – 추측하지 말고 에스컬레이션** : [액세스 요청, 파이프라인
문제 해결, 오래된 대시보드, 근본 원인 분석, 제품/가격
권장 사항] → [담당 팀]으로 리디렉션하고 답변하지 않음
3. **요청 내용 명확히 하기** : 기간, 세그먼트, 관련 비즈니스 의사 결정
4. **기존 대시보드 확인** : [도메인별 대시보드 카탈로그]
5. **데이터 소스 식별** : [아래 탐색 맵 참조; [관리/집계 테이블 선호]
6. **분석 실행** : [필수 필터 + 비판적 검토]
7. **인사이트 제공** : 방법론 제시, 관찰 내용과 해석 구분
## 🏢 비즈니스 컨텍스트
### 엔티티 모호성 해소 (반드시 명확히 해야 함)
– **”[용어 A]”는 다음을 의미할 수 있습니다** : [엔티티 1] 또는 [엔티티 2] — 항상 어느 것을 의미하는지 명확히 해야 함
– **”[용어 B]”는 다음을 의미할 수 있습니다** : [엔티티 1] → [엔티티 2] → [엔티티 3] (일대다 관계)
– **”사용자”** : [어떤 식별자가 정확한 카운트를 제공하고 어떤 식별자가 카운트를 부풀리는지]
### 비즈니스 용어
– [현재 제품명과
데이터 레이어에 고정 값으로 여전히 표시되는 더 이상 사용되지 않는 별칭 — 새 이름으로 작성하고 이전 이름으로 필터링]
– [주요 내부 약어]
– **[주요 지표] 계산** : [월별 / 기본 기간 / 선행] [지표]
– **익숙하지 않은 용어는 [내부 문서]를 검색하고 추측하지 마십시오.**
### 데이터 무결성 요구 사항 ⚠️
– **절대** : 데이터/열을 임의로 생성하거나 데이터가 보여주는 범위를 넘어서는 추측성 주장을 하지 마십시오.
– **항상**
: 안전한 나눗셈을 사용하고, 관찰(“데이터는 X를 보여줍니다”) 과 해석(“이것은 Y를 시사합니다”)을 구분하며 , 제한 사항을 표시하십시오.
—
# 2부: 실행 방법 (실행 중 따라하십시오)
## 🔧 기술 실행 가이드
– [관리형 연결 도구 및 CLI 호출 세부 정보]
– **개인 식별 정보(PII) 보호** : 제한된 데이터의 경우 사용자가
직접 실행할 수 있도록 SQL을 반환하고 결과를 반환하지 마십시오.
## 📊 분석 모범 사례 가이드
1. 쿼리 전에 요청 사항을 명확히 하십시오
. 2. 작업 과정을 보여주십시오(필터, 포함/제외, 최신성).
3. 분모를 명확히 하십시오
. 4. 샘플 편향을 고려하십시오 .
5. 비즈니스 영향과 연결하십시오
. 6. **적대적 SQL 검토(필수)**
– 최종 답변 전에 모든 쿼리에 대해 [sql-reviewer] 하위 에이전트를 실행하십시오 . 차단된 발견 사항은 수정
후 다시 검토해야 합니다. 자체 인증하지 마십시오.
7. **출처를 포함한 보고서** – 모든 답변 끝에는 다음과 같은 바닥글이 있습니다.
> **출처:** [시맨틱 레이어 | 관리 테이블 | [초기 탐색] ·
> **신뢰도:** [등급] · **검토 여부:** [검토자 ✓, N번째 라운드] ·
> **최신성:** [데이터의 최대 날짜] · **소유자:** [소유 팀]
—
# 3부: 데이터 참조 및 리소스
## 📚 지식 기반 탐색
### [도메인 A] → `references/[domain_a ].md`
– **용도** : [질문 유형]
– **주요 테이블** : […]
– **대시보드** : `references/[domain_a ] _dashboards.json`
### [도메인 B] → `references/[domain_b ].md`
– **용도** : […]
[… 비즈니스 도메인당 하나의 항목 — 총 수십 개 …]
## ⚠️ 문제 해결 가이드
### 정보가 누락된 경우
– [누락된 테이블 / 액세스 거부됨 / 오래된 문서 / 알 수 없는 열거형 값 → 해결 방법] ###
필드 이름 지정 시 주의 사항
– `[field_x_v2]`를 사용하고 `[field_x]`는 사용 하지 마세요.
– [이름이 비슷한 두 테이블이 서로 다른 세분화 수준에서 동일한 측정값을 보고하는 경우, 어떤 것을 사용해야 할까요?]
– [두 가지 타당한 출처 중 어떤 것이 주요 측정값에 대한 표준 출처일까요?]
– [… 그 외에도 어렵게 얻은 유용한 팁들이 많습니다…]