opp-treelisted

## Core Goal - 자동화 기회를 체계적으로 탐색하고 우선순위를 정하여 팀이 가장 값있는 에이전트에 투자하도록 함 - 반복빈도, 자동화가능성, 판단의존도를 기준으로 기술적 가능성과 비즈니스 가치의 균형을 맞춤 - 검증 실험 설계를 통해 구현 전에 핵심 가정(Value/Feasibility/Reliability/Ethics)을 빠르게 테스트 --- ## Trigger Gate ### Use This Skill When - 에이전트 도입을 고려 중인데 어디서부터 시작할지 결정해야 할 때 - 조직의 반복 작업, 병목 지점, 자동화 기회를 체계적으로 매핑해야 할 때 - 여러 개의 에이전트 아이디어가 있는데 어느 것을 먼저 구현할지 우선순위를 정해야 할 때 - 기술 팀과 비즈니스 팀의 의견이 갈려 "에이전트를 만들어야 하는가"를 데이터 기반으로 판단해야 할 때 ### Route to Other Skills When - 선택된 기회의 가정(Value/Feasibility/Reliability/Ethics)을 깊이 있게 검증해야 할 때 → `assumptions` 스킬 - 최우선 기회의 기술 구현 방식(Trigger Agent vs Pipeline Agent vs Research Agent)을 결정해야 할 때 → `discover/assumptions --mode build-or-buy` - 선택한 에이전트에 인간 개입 지점을 설계해야 할 때 → `hitl` 스킬 - Opportunity Tree를 Mermaid + `docs/OPPORTUNITY_TREE.md`로 영구화하고 5/3 strong-Push 패턴으로 검증할 때 → `ost` (hplan plugin) ### Boundary Checks - **범위 확인**: AOT는 "어떤 에이전트를 만들 것인가"를 정하는 것이지, "어떻게 만드는가"를 설명하지 않음 — 구현은 `deliver/agent-setup`으로 연결 - **판단 의존도 주의**: 점수가 5점을 넘어가거나 판단 의존도가 높다면(4~5점) AOT 대상이 아닐 수 있음 — 그냥 Rule-based 자동화나 인간 처리가 더 나을 수 있음 --- ## Agent Opportunity Tree (AOT) 에이전트를 "만들 수 있냐"가 아니라 "만들어야 하냐"를 결정하는 프레임워크. Teresa Torres의 Opportunity Solution Tree를 AI 에이전트 디스커버리에 맞게 재설계했습니다. --- ### 왜 에이전트에는 다른 OST가 필요한가 일반 OST는 제품 기능을 탐색할 때 씁니다. 에이전트 OST는 다릅니다. 에이전트는 **자율적으로 행동**하기 때문에 잘못된 기회를 선택하면 오류가 조용히 증폭됩니다. 에이전트 디스커버리에서 빠지기 쉬운 함정: - "기술적으로 가능하니까" 만든다 → 아무도 안 씀 - "반복 작업이니까" 자동화한다 → 판단이 필요한 부분을 건드려 더 큰 문제 발생 - 에이전트 1개로 너무 많은 걸 해결하려 한다 → 실패율 급증 AOT는 이 함정을 피하기 위해 **