assumptionslisted

## Core Goal - 구현 전에 에이전트의 숨겨진 가정을 발굴하고 리스크를 수치화하여 팀이 무엇을 먼저 검증해야 하는지 명확히 함 - 4축(Value/Feasibility/Reliability/Ethics) 분석을 통해 기술적 가능성과 실제 운영 가능성의 갭을 조기에 발견 - 우선순위 점수(위험도 × 검증 난이도)를 기준으로 2일 이내에 실행 가능한 최소 검증 실험을 설계 --- ## Trigger Gate ### Use This Skill When - `opp-tree` 스킬로 기회를 선택한 후, 구현하기 전에 핵심 가정을 빠르게 검증하고 싶을 때 - 에이전트 아이디어가 있는데 "정말 작동할 것 같나"에 대한 우려가 있을 때 - 기술 팀은 구현 가능하다고 하는데 비즈니스 팀이 의심스러워할 때 - 윤리/안전 위험(예: 잘못된 판단이 고객에게 영향)이 있을 수 있다고 생각할 때 ### Route to Other Skills When - 검증 실험 설계 후 실제로 프롬프트/API를 테스트해야 할 때 → `hitl` 스킬 (Human-in-the-Loop으로 초기 신뢰도 측정) 또는 본 스킬 `--mode build-or-buy` - 가정 검증 결과 위험도가 매우 높으면 → `hitl` 스킬로 에스컬레이션 전략 설계 - 검증 통과 후 에이전트 설계 및 프롬프트/인스트럭션을 작성해야 할 때 → `deliver/agent-setup` - 8축 100점 evidence 루브릭으로 정량 채점이 필요할 때 → `evidence-rubric` (hplan plugin). V/F/R/E 4축과 상보적. ### Boundary Checks - **검증의 범위**: Assumptions는 가정을 "정의"하고 "우선순위"를 정하는 것이지, 실제로 검증 실험을 끝까지 실행하지는 않음 — 실험 실행은 팀이 직접 담당 - **이미 검증됨**: 기술 스택이 프로덕션에서 이미 검증되었다면(예: 우리 팀이 동일 모델로 다른 에이전트를 성공했다면) 그 가정의 점수는 내려야 함 --- ## Agent Assumption Map 에이전트 아이디어에는 수십 개의 숨겨진 가정이 있습니다. 그 중 단 하나만 틀려도 에이전트는 조용히 잘못된 방향으로 실행됩니다. 일반 제품과 다른 점: - 일반 제품: 사용자가 결과를 보고 판단 → 오류 발견 즉시 가능 - 에이전트: 자율 실행 → 오류가 쌓일 때까지 발견 어려움 Agent Assumption Map은 **4축 분석**으로 핵심 가정을 사전에 발굴합니다. --- ### 4축 정의 **Axis 1 — Value (가치 가정)** > "이 에이전트가 실제로 의미 있는 문제를 해결하는가?" 검토 질문: - 자동화 후 실제로 시간/비용/오류가 줄어드는가? - 사용자가 에이전트의 결과를 실제로 사용하는가? - 에이전트 없이도 충분히 빠르게/잘 할 수 있지 않은가? - 자동화로 해결되는 불편함이 진짜 불편함인가, 아니면 낮은 빈도의 사소한 불편인가? **Axis 2 — Feasibility (실현 가능성 가정)*