القائمة
Design the metrics hierarchy and OKRs for an AI agent — North Star, KPI derivation, and OKR setting. Supports --step north-star | kpi | okr | all (default).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
2-step 디자인 파이프라인: --step brief (타겟 분석 → DESIGN_BRIEF.md 생성) → --step token (토큰/DESIGN.md 생성). --step all이 기본값.
Design an agent memory system — working memory, episodic memory, semantic memory, and procedural memory. Use when building agents that need to remember context across sessions, learn from interactions, or maintain persistent knowledge. Covers storage strategy, retrieval patterns, and context management.
Select and design the right orchestration pattern for multi-agent systems. Evaluate Sequential, Parallel, Router, and Hierarchical patterns against your use case requirements. The Router pattern covers both agent selection (classify input to the right specialist) and model selection (route tasks to the right LLM by complexity to balance cost, latency, quality, and fallback chains). Use when deciding how multiple agents should coordinate, share context, delegate tasks, or which model each task should run on.
전략 설계 통합 — 비즈니스 모델 캔버스(biz-model), 경쟁 해자 분석(moat), 성장 루프 설계(growth-loop) 통합. Use when defining business strategy, competitive positioning, or growth mechanics for an AI product.
에이전트 환경 설정 통합 — 7요소 인스트럭션 작성(agent-instructions)과 CLAUDE.md/AGENTS.md 구성(claude-md) 통합. 에이전트 정체성·도구·제약·실패 모드 정의부터 프로젝트 메모리 파일까지 한 스킬로. Use when setting up a new agent or updating agent instructions.
PM이 사람에게 질문하고 답을 모으는 비동기 채널 — comms MCP(Gmail/Notion/Zoom/Slack)를 감싸는 번역기. --mode ask(질문 초안 작성), --mode pull-answers(스레드·회의록에서 답 수집), --mode digest(수집한 답 요약 → decision-log/ticket-bridge 라우팅), --mode review(PRD 스테이크홀더 리뷰 — 리뷰어 배정·코멘트 수집·Signoff audit trail), --mode solo(팀원 없을 때 Claude가 역할 대리 시뮬레이션), --mode init(팀 세팅 대화형 온보딩). 메시지를 자동 발송하지 않는다 — 초안/코멘트까지만. 솔로 유저는 solo, 기업 PM은 review로 분기. Use when a PM needs to ask teammates for status/decisions, run a multi-stakeholder PRD review, and collect answers into hplan.
| name | metrics-design |
| description | Design the metrics hierarchy and OKRs for an AI agent — North Star, KPI derivation, and OKR setting. Supports --step north-star | kpi | okr | all (default). |
| argument-hint | [agent or product] [--step north-star|kpi|okr|all] |
| allowed-tools | ["Read","Write"] |
| model | inherit |
AI 에이전트의 메트릭 계층 설계 — North Star 정의 후 KPI 파생
North Star Metric은 에이전트의 성공을 하나의 숫자로 표현한다. KPI는 그 숫자를 분해한 운영 건강도(잘 돌아가는가)와 비즈니스 임팩트(가치를 만드는가)의 두 축이다. 두 층을 함께 설계하지 않으면 "정확도만 높고 쓸모없는" 또는 "가치있지만 불안정한" 에이전트가 된다.
You are designing metrics for: $ARGUMENTS
Parse --step from the arguments:
--step north-star → Run Phase A only--step kpi → Run Phase B only--step okr → Run Phase C only (OKR 설계)--step all or no --step flag → Run Phase A then Phase B then Phase C (default)--step north-star or --step both)A1 — North Star Criteria 체크
좋은 North Star Metric은 다음 5가지를 충족해야 한다:
A2 — 후보 생성
3~5개 후보를 다음 공식으로 생성한다:
North Star = f(Quality, Volume, Impact)
예시:
- "Successful agent actions per week" (volume × quality)
- "Hours saved per user per month" (impact × adoption)
- "Accurate outputs delivered within SLA" (quality × reliability)
- "Revenue-impacting decisions supported" (impact × quality)
A3 — 평가 매트릭스
| 후보 | Actionable | Measurable | Understandable | Leading | Composite | Score |
|---|---|---|---|---|---|---|
| ✓/✗ | ✓/✗ | ✓/✗ | ✓/✗ | ✓/✗ | /5 |
A4 — 분해 트리
North Star: [metric]
├── Driver 1: [sub-metric]
│ ├── Lever: [팀이 통제하는 요소]
│ └── Lever: [팀이 통제하는 요소]
├── Driver 2: [sub-metric]
│ └── Lever: [팀이 통제하는 요소]
└── Driver 3: [sub-metric]
└── Lever: [팀이 통제하는 요소]
A5 — 목표 설정
North Star: [metric name]
현재값: ___
3개월 목표: ___
6개월 목표: ___
12개월 목표: ___
A6 — Anti-Metrics (Guardrails)
Anti-metric 1: [악화되면 안 되는 지표]
└── Floor: [최소 허용값]
Anti-metric 2: [악화되면 안 되는 지표]
└── Floor: [최소 허용값]
A 출력 — North Star Card
┌─────────────────────────────────────────┐
│ 🌟 North Star: [metric name] │
├─────────────────────────────────────────┤
│ Current: [value] → Target: [value] │
│ Timeframe: [period] │
├── Drivers ──────────────────────────────┤
│ 1. [driver] — current: [val] │
│ 2. [driver] — current: [val] │
│ 3. [driver] — current: [val] │
├── Guardrails ───────────────────────────┤
│ ⚠️ [anti-metric 1] must stay > [floor] │
│ ⚠️ [anti-metric 2] must stay > [floor] │
└─────────────────────────────────────────┘
--step kpi or --step both)B1 — 운영 건강도 KPI
| Metric | Formula | Target | Alert Threshold |
|---|---|---|---|
| Accuracy | Correct outputs ÷ Total executions | >95% | <90% |
| Reliability | Successful runs ÷ Total runs | >99% | <95% |
| Latency | Average execution time | <Xs | >2Xs |
| Cost per Execution | Total cost ÷ Executions | <$X | >1.5×$X |
| Error Rate | Failed runs ÷ Total runs | <1% | >5% |
B2 — 비즈니스 임팩트 KPI
| Metric | Formula | Target |
|---|---|---|
| Time Saved | Manual time - Agent time per task | >X hrs/week |
| Cost Saved | Manual cost - Agent cost | >$X/month |
| Throughput Increase | Tasks with agent ÷ without | >Xx |
| User Satisfaction | NPS or CSAT | >X |
B3 — KPI 대시보드 정의
각 KPI:
KPI: [name]
├── Definition: [precise formula]
├── Data Source: [측정 출처]
├── Collection Method: [automated/manual]
├── Frequency: [real-time/daily/weekly]
├── Owner: [담당자]
├── Baseline: [현재값]
├── Target: [목표값]
└── Alert: [review 트리거 임계값]
B4 — Leading vs Lagging 분리
Leading (미래 예측 신호):
- 입력 데이터 품질 점수
- 프롬프트 버전 성능 delta
- 사용자 참여 빈도
Lagging (과거 성과 확인):
- 월간 비용 절감
- 분기 비즈니스 임팩트
- 사용자 유지율
B5 — 리뷰 주기
| 주기 | 확인 항목 | 행동 |
|---|---|---|
| 일간 | Error rate, latency 급등 | 즉시 수정 |
| 주간 | Accuracy 추이, 비용 추적 | 최적화 |
| 월간 | 비즈니스 임팩트 KR | 전략 조정 |
| 분기 | North Star + OKR 연결 검토 | 목표 재설정 |
B 출력 — KPI Card
┌─────────────────────────────────────┐
│ Agent: [name] │
├── Operational Health ────────────────┤
│ Accuracy: [current] → [target] │
│ Reliability: [current] → [target] │
│ Latency: [current] → [target] │
│ CPE: [current] → [target] │
├── Business Impact ───────────────────┤
│ Time Saved: [current] → [target] │
│ Cost Saved: [current] → [target] │
│ Throughput: [current] → [target] │
└─────────────────────────────────────┘
| 실패 상황 | 감지 | 대응 |
|---|---|---|
| North Star 달성 불가 | 3개월 연속 목표 미달 | 보수적 타겟 재설정 + 분해 트리 막힌 드라이버 파악 |
| Anti-metric 악화 | North Star 최적화 중 다른 지표 급락 | North Star 재정의 (품질 가중치 상향) |
| KPI 정의 불명확 | 팀마다 다른 계산 방식 | formula·data source·collection method 명시 표준화 |
| 임계값 달성 불가 | 첫 주부터 Alert 발동 | 현재 기준선 기반 단계적 목표로 재설정 |
| 팀 정렬 부족 | 개별 KPI만 최적화, North Star 무관 | 월간 North Star 리뷰 고정 + OKR 연결 명시 |
Phase A
Phase B
--step both입력: "고객 지원 에이전트 메트릭 설계해줘"
[Phase A]
🌟 North Star: "월별 정확한 지원 건수"
정의: (월간 집행 건수) × (Accuracy %) × (FCR %)
기준선: 4,000 × 92% × 85% = 3,128건
목표: 3개월 3,500건 / 6개월 4,000건 / 12개월 4,500건
Guardrails: Accuracy > 90% / CPE < $0.15
[Phase B]
운영 건강도: Accuracy 94%→96%, Latency 1.2s→1.0s, CPE $0.08→$0.06
비즈니스 임팩트: Time Saved 8hrs/day, Cost Saved $2,400/month, CSAT 4.2/5.0
리뷰: 일간 alert · 주간 trend · 월간 OKR 연결
"Accuracy를 North Star로 하자"
❌ 문제점:
- Composite 부족 — 비용·볼륨 미반영
- Actionable 불명확 — 팀 통제 범위 미정의
- Anti-metric 없음 — Accuracy 99%이지만 비용 폭증 가능
- 분해 트리 없음 — "어떻게 높이나?"에 답 불가
정의된 North Star 또는 KPI를 기준으로 에이전트 변경의 통계적 유효성을 검증한다.
핵심 체크포인트:
A/B 테스트 전체 플로우(가설 수립 → 표본 계산 → 실행 → p-value 분석)가 필요하면 이 스킬에서 확장하거나 별도 운영한다.
North Star 추이를 버전별·세그먼트별·TK 축적 단계별로 추적한다.
코호트 분석 방법론:
성능 저하 패턴:
최소 추적 기간: 코호트당 4주 이상. 1주 데이터는 노이즈로 간주. 리텐션 건강 기준: Week 12 리텐션 > 30% = 건강한 에이전트.
보조 파일이 존재할 때만 자동 로드됩니다. 파일이 없으면 건너뜁니다.
!cat references/test-cases.md 2>/dev/null || echo ""
!cat context/domain.md 2>/dev/null || echo ""
--step okr or --step all)C1 — 에이전트 Objective 작성 비즈니스 임팩트 중심의 야심차고 질적인 목표 1개
C2 — Business Impact KR 2개 측정 가능한 비즈니스 아웃컴 지표 현재값 → 목표값 → 달성 기한
측정 지표 유형:
C3 — Operational Health KR 2개 정확도 / 비용 / 신뢰성 / 레이턴시 중 가장 중요한 2개 현재값 베이스라인 추정 또는 수집 계획
C4 — 측정 방법 정의 각 KR을 어떻게 측정할 것인가 (자동/수동, 도구)
C5 — 리뷰 사이클 설정
OKR 템플릿
O: [에이전트 이름]이 [사용자]의 [문제]를 [방식]으로 해결하는
신뢰할 수 있는 파트너가 된다.
KR1 (Business Impact):
[측정 지표] [현재값] → [목표값] by [날짜]
KR2 (Business Impact):
[측정 지표] [현재값] → [목표값] by [날짜]
KR3 (Operational Health):
[측정 지표] [현재값] → [목표값] by [날짜]
KR4 (Operational Health):
[측정 지표] [현재값] → [목표값] by [날짜]
| 실패 상황 | 감지 | 대응 |
|---|---|---|
| 비즈니스 임팩트 KR이 측정 불가능 | KR을 읽었을 때 정량화 방법이 불명확 | 프록시 지표로 변경 (예: "사용자 만족도" → "재사용률 80% 이상") |
| 월간 리뷰 시 데이터 부재로 KR 달성률 계산 불가 | 주간 로그가 없거나 측정 도구 설정 안 됨 | 다음 달부터 자동 로깅 설정, 현재 달은 추정값으로 임시 평가 |
| KR이 너무 높게 설정되어 달성 불가능 확실 | 주간 검토 시 KR 달성 가능성 1% 미만 | 즉시 KR 재협상 (낮게 재설정하되, 이유 문서화) |
| 비용 KR 초과 | 비용 모니터링 중 임계값 초과 감지 | 원인 분석 + 즉시 수정 액션 (프롬프트 최적화/도구 호출 감소) |