@uzysjung/agent-harness 26.83.0

package/templates/skills/investor-outreach/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: investor-outreach
+description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
+origin: ECC
+---
+
+# Investor Outreach
+
+Write investor communication that is short, concrete, and easy to act on.
+
+## When to Activate
+
+- writing a cold email to an investor
+- drafting a warm intro request
+- sending follow-ups after a meeting or no response
+- writing investor updates during a process
+- tailoring outreach based on fund thesis or partner fit
+
+## Core Rules
+
+1. Personalize every outbound message.
+2. Keep the ask low-friction.
+3. Use proof instead of adjectives.
+4. Stay concise.
+5. Never send copy that could go to any investor.
+
+## Voice Handling
+
+If the user's voice matters, run `brand-voice` first and reuse its `VOICE PROFILE`.
+This skill should keep the investor-specific structure and ask discipline, not recreate its own parallel voice system.
+
+## Hard Bans
+
+Delete and rewrite any of these:
+- "I'd love to connect"
+- "excited to share"
+- generic thesis praise without a real tie-in
+- vague founder adjectives
+- begging language
+- soft closing questions when a direct ask is clearer
+
+## Cold Email Structure
+
+1. subject line: short and specific
+2. opener: why this investor specifically
+3. pitch: what the company does, why now, and what proof matters
+4. ask: one concrete next step
+5. sign-off: name, role, and one credibility anchor if needed
+
+## Personalization Sources
+
+Reference one or more of:
+- relevant portfolio companies
+- a public thesis, talk, post, or article
+- a mutual connection
+- a clear market or product fit with the investor's focus
+
+If that context is missing, state that the draft still needs personalization instead of pretending it is finished.
+
+## Follow-Up Cadence
+
+Default:
+- day 0: initial outbound
+- day 4 or 5: short follow-up with one new data point
+- day 10 to 12: final follow-up with a clean close
+
+Do not keep nudging after that unless the user wants a longer sequence.
+
+## Warm Intro Requests
+
+Make life easy for the connector:
+- explain why the intro is a fit
+- include a forwardable blurb
+- keep the forwardable blurb under 100 words
+
+## Post-Meeting Updates
+
+Include:
+- the specific thing discussed
+- the answer or update promised
+- one new proof point if available
+- the next step
+
+## Quality Gate
+
+Before delivering:
+- the message is genuinely personalized
+- the ask is explicit
+- the proof point is concrete
+- filler praise and softener language are gone
+- word count stays tight

package/templates/skills/market-research/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: market-research
+description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
+origin: ECC
+---
+
+# Market Research
+
+Produce research that supports decisions, not research theater.
+
+## When to Activate
+
+- researching a market, category, company, investor, or technology trend
+- building TAM/SAM/SOM estimates
+- comparing competitors or adjacent products
+- preparing investor dossiers before outreach
+- pressure-testing a thesis before building, funding, or entering a market
+
+## Research Standards
+
+1. Every important claim needs a source.
+2. Prefer recent data and call out stale data.
+3. Include contrarian evidence and downside cases.
+4. Translate findings into a decision, not just a summary.
+5. Separate fact, inference, and recommendation clearly.
+
+## Common Research Modes
+
+### Investor / Fund Diligence
+Collect:
+- fund size, stage, and typical check size
+- relevant portfolio companies
+- public thesis and recent activity
+- reasons the fund is or is not a fit
+- any obvious red flags or mismatches
+
+### Competitive Analysis
+Collect:
+- product reality, not marketing copy
+- funding and investor history if public
+- traction metrics if public
+- distribution and pricing clues
+- strengths, weaknesses, and positioning gaps
+
+### Market Sizing
+Use:
+- top-down estimates from reports or public datasets
+- bottom-up sanity checks from realistic customer acquisition assumptions
+- explicit assumptions for every leap in logic
+
+### Technology / Vendor Research
+Collect:
+- how it works
+- trade-offs and adoption signals
+- integration complexity
+- lock-in, security, compliance, and operational risk
+
+## Output Format
+
+Default structure:
+1. executive summary
+2. key findings
+3. implications
+4. risks and caveats
+5. recommendation
+6. sources
+
+## Quality Gate
+
+Before delivering:
+- all numbers are sourced or labeled as estimates
+- old data is flagged
+- the recommendation follows from the evidence
+- risks and counterarguments are included
+- the output makes a decision easier

package/templates/skills/market-research/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Market Research"
+  short_description: "Source-attributed market, competitor, and investor research"
+  brand_color: "#2563EB"
+  default_prompt: "Research this market and summarize the decision-relevant findings"
+policy:
+  allow_implicit_invocation: true

package/templates/skills/nextjs-turbopack/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: nextjs-turbopack
+description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
+origin: ECC
+---
+
+# Next.js and Turbopack
+
+Next.js 16+ uses Turbopack by default for local development: an incremental bundler written in Rust that significantly speeds up dev startup and hot updates.
+
+## When to Use
+
+- **Turbopack (default dev)**: Use for day-to-day development. Faster cold start and HMR, especially in large apps.
+- **Webpack (legacy dev)**: Use only if you hit a Turbopack bug or rely on a webpack-only plugin in dev. Disable with `--webpack` (or `--no-turbopack` depending on your Next.js version; check the docs for your release).
+- **Production**: Production build behavior (`next build`) may use Turbopack or webpack depending on Next.js version; check the official Next.js docs for your version.
+
+Use when: developing or debugging Next.js 16+ apps, diagnosing slow dev startup or HMR, or optimizing production bundles.
+
+## How It Works
+
+- **Turbopack**: Incremental bundler for Next.js dev. Uses file-system caching so restarts are much faster (e.g. 5–14x on large projects).
+- **Default in dev**: From Next.js 16, `next dev` runs with Turbopack unless disabled.
+- **File-system caching**: Restarts reuse previous work; cache is typically under `.next`; no extra config needed for basic use.
+- **Bundle Analyzer (Next.js 16.1+)**: Experimental Bundle Analyzer to inspect output and find heavy dependencies; enable via config or experimental flag (see Next.js docs for your version).
+
+## Examples
+
+### Commands
+
+```bash
+next dev
+next build
+next start
+```
+
+### Usage
+
+Run `next dev` for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
+
+## Best Practices
+
+- Stay on a recent Next.js 16.x for stable Turbopack and caching behavior.
+- If dev is slow, ensure you're on Turbopack (default) and that the cache isn't being cleared unnecessarily.
+- For production bundle size issues, use the official Next.js bundle analysis tooling for your version.

package/templates/skills/north-star/NORTH_STAR.template.md

@@ -0,0 +1,114 @@
+# [Project Name] — North Star
+
+> 장기 방향성. PRD/SPEC이 "무엇을 어떻게"를 다루면, 본 문서는 **왜·어디로**를 다룬다.
+> 의사결정이 모호할 때 본 문서를 기준으로 우선순위를 판정한다.
+
+---
+
+## 1. North Star Statement
+
+> **"[한 문장: 5년 뒤 이 프로젝트가 무엇이 되어 있어야 하는가. 도메인 명사 + 사용자 + 측정 가능한 결과]"**
+
+[2-3 문장: 단순 X를 넘어, 어떤 시스템/사이클을 지향하는가.]
+
+---
+
+## 2. North Star Metric (NSM)
+
+**1차 지표 (현재 단계)**: **[지표 약어 — 풀네임]**
+- 정의: [어떻게 계산하는가]
+- 목표: [수치 + 도달 시점]
+- 의미: [이 지표가 달성되면 무엇이 증명되는가. 미달 시 무엇이 부족함을 시사하는가]
+
+**2차 보조 지표**
+
+| Metric | 정의 | 목표 |
+|--------|------|------|
+| [Metric A] | [계산법] | [수치] |
+| [Metric B] | [계산법] | [수치] |
+| [Metric C] | [계산법] | [수치] |
+
+> 모든 지표는 [환경 — single-user / team / public 등]에서 자가 수집. [향후 단계 진입 시 재정의 조건].
+
+---
+
+## 3. Strategic Boundaries (방향성 경계)
+
+### 3.1 Will (집중)
+
+- **[집중 영역 1]**: [짧은 설명]
+- **[집중 영역 2]**: [짧은 설명]
+- **[집중 영역 3]**: [짧은 설명]
+- **[집중 영역 4]**: [짧은 설명]
+
+### 3.2 Won't (의도적 비-방향)
+
+scope creep의 1차 방어선. "X는 안 한다"를 명시.
+
+- **[안 하는 것 1]**: [왜 안 하는지 한 문장]
+- **[안 하는 것 2]**: [근거]
+- **[안 하는 것 3]**: [근거]
+- **[안 하는 것 4]**: [근거]
+- **[안 하는 것 5]**: [근거]
+
+### 3.3 Trade-offs (의식적 선택)
+
+| 선택 | 포기한 것 | 근거 |
+|------|----------|------|
+| [선택 A] | [반대편 옵션] | [왜 이 쪽인가] |
+| [선택 B] | [반대편 옵션] | [근거] |
+| [선택 C] | [반대편 옵션] | [근거] |
+
+---
+
+## 4. Phase Roadmap (장기 진화 단계)
+
+### Phase 1 — [이름] (현재)
+- 목표: [한 문장]
+- 성공 조건: [측정 가능 기준]
+- 핵심 산출물: [3-5개]
+
+### Phase 2 — [이름]
+- 목표: [한 문장]
+- 진입 조건: [Phase 1 무엇이 충족되면]
+- 핵심 산출물: [3-5개]
+
+### Phase 3 — [이름]
+- 목표: [한 문장]
+- 진입 조건: [Phase 2 무엇이 충족되면]
+
+### Phase 4 (탐색) — [이름]
+- 가설: [무엇을 검증]
+- 진입 조건: [Phase 3 안정화 + NSM 도달]
+- 결정 사항: 본 문서 정기 갱신 시 검토
+
+---
+
+## 5. Decision Heuristics (의사결정 휴리스틱)
+
+신규 요청·제안이 들어왔을 때 다음 4 게이트를 **모두** 통과해야 우선순위 진입.
+
+| Gate | 질문 | Pass/Fail 기준 |
+|------|------|---------------|
+| **1. Trend** | 본 프로젝트의 핵심 트렌드/원칙(섹션 X 참조) 1개 이상에 매핑되는가? | 매핑 명시 = Pass |
+| **2. Persona** | Primary persona([이름])에게 직접 가치를 주는가? Anti-persona 위주면 거절 | YES = Pass |
+| **3. Capability** | [도메인 특수 능력 — 예: MCP 노출 / API 제공 / 키보드 단축키]가 동등하게 가능한가? | YES = Pass (UI-only면 -1) |
+| **4. Lean** | Phase 1/2/3 정의 내에 있는가? 외부면 Open Question으로 적재 | YES = Pass |
+
+4개 모두 Pass = 우선순위 진입. 1개라도 Fail = 보류 또는 거절.
+
+---
+
+## 6. Versioning & Review
+
+- 본 문서는 **분기 1회** 또는 **NSM 도달/미달** 시 갱신.
+- 주요 갱신 (Major CR): NSM 변경 / Phase 정의 변경 / Won't 변경.
+- 가벼운 갱신 (Clarification): Trade-off 추가, 트렌드 매핑 보강.
+- 갱신 시 사유 + 날짜 1줄을 Changelog에 기록.
+
+---
+
+## 7. Changelog
+
+- YYYY-MM-DD: 초안 작성. 참조: [관련 ideation/raw 문서].
+- (이후 갱신 기록)

package/templates/skills/north-star/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: north-star
+description: "Defines and enforces a project's long-term direction (North Star Statement, NSM, Will/Won't, 4-gate decision heuristic). Use when starting a new project, when scope creep is suspected, or when a non-obvious feature request needs prioritization. Sits one layer above SPEC/PRD — answers 'why and where to', not 'what and how'."
+---
+
+# North Star
+
+## Purpose
+
+SPEC/PRD가 "무엇을 어떻게"를 다루면, North Star는 **왜·어디로**를 다룬다.
+- 의사결정이 모호할 때 우선순위 판정의 SSOT.
+- 신규 요청·기능이 "범위 안인가?"를 검증 가능한 기준으로 거른다.
+- Won't (의도적 비-방향)을 명시해 scope creep을 사전 차단.
+
+CLAUDE.md의 P1(가정 금지) / P2(Simplicity First) / Decision Making 메타원칙의 **프로젝트 단위 인스턴스**.
+
+## When to Invoke
+
+| 트리거 | 행동 |
+|--------|------|
+| 신규 프로젝트 (`/uzys:spec` 시작) | `docs/NORTH_STAR.md` 부재 시 작성 제안 |
+| Major CR / scope 확대 의심 | 4-gate 통과 여부 점검 |
+| 분기 1회 정기 리뷰 | NSM 변경, Phase 정의 변경, Won't 변경 검토 |
+| 신규 기능 요청 진입 시 (`/uzys:plan`) | 4-gate 통과 시만 우선순위 진입 |
+
+## Process
+
+### 1. North Star Statement 작성
+
+한 문장으로 프로젝트의 종착점을 표현. 5년 뒤 이 프로젝트가 무엇이 되어 있어야 하는가.
+
+**좋은 예**: 도메인 명사 + 사용자 + 측정 가능한 결과.
+**나쁜 예**: "최고의 X" / "사용자 만족" — 측정 불가.
+
+### 2. North Star Metric (NSM) 정의
+
+1차 지표 1개 + 2차 보조 지표 2-4개. 모두 단일 사용자 환경에서 자가 수집 가능해야 한다.
+
+NSM 결정 기준:
+- Lagging (결과) vs Leading (원인) — Leading 권장
+- 단일 행동만 측정 (composite 금지)
+- 목표값 명시 ("≥ 40% by 2026")
+
+### 3. Will / Won't / Trade-offs
+
+- **Will**: 집중 영역 4-6개. 동사로 시작 ("개인 사용 깊이 우선", "AI 친화 1급 시민").
+- **Won't**: 의도적 비-방향 5-8개. "X는 안 한다" 명시. 가장 중요한 섹션 — scope creep의 1차 방어선.
+- **Trade-offs**: "X 선택 → Y 포기 → 근거" 표. 의식적 결정의 추적 기록.
+
+### 4. 4-Gate Decision Heuristic
+
+신규 요청·제안이 들어왔을 때 다음 4개 게이트를 **모두** 통과해야 우선순위 진입:
+
+| Gate | 질문 | 통과 기준 |
+|------|------|----------|
+| **Trend** | 프로젝트의 핵심 트렌드/원칙 중 1개 이상에 매핑되는가? | YES |
+| **Persona** | Primary persona에게 직접 가치를 주는가? Anti-persona 위주는 거절 | YES |
+| **Capability** | 현재 시스템이 이 기능을 동등하게 노출 가능한가? (UI 한정 기능은 -1) | YES |
+| **Lean** | 정의된 Phase 범위 내에 있는가? 외부면 Open Question으로 적재 후 분기 1회 재평가 | YES |
+
+게이트 명칭은 프로젝트마다 customize 가능하나 **4개 ALL True** 원칙은 유지.
+
+### 5. Versioning
+
+- 분기 1회 또는 NSM 도달/미달 시 갱신.
+- 주요 갱신: NSM 변경 / Phase 정의 변경 / Won't 변경 → Major CR 분류.
+- 가벼운 갱신: Trade-off 추가, 트렌드 매핑 보강 → Clarification.
+- 갱신 시 Changelog 1줄 (날짜 + 사유).
+
+## Output Template
+
+`docs/NORTH_STAR.md`에 다음 구조로 저장. 본 skill 디렉토리의 `NORTH_STAR.template.md`를 복사해 채운다.
+
+7 섹션:
+1. North Star Statement (1문장)
+2. North Star Metric (1차 + 2차)
+3. Strategic Boundaries (Will / Won't / Trade-offs)
+4. Phase Roadmap (장기 진화 단계)
+5. Decision Heuristics (4-gate)
+6. Versioning & Review
+7. Changelog
+
+## Integration with Workflow
+
+- **`/uzys:spec`**: 시작 시 `docs/NORTH_STAR.md` 존재 확인. 없으면 본 skill 호출 권유.
+- **`/uzys:plan`**: 신규 task 진입 전 4-gate 체크. 1개 이상 게이트 fail 시 사용자에게 보고 후 결정 대기.
+- **자동 hook 없음** — 의식적 결정을 강제하지 않음. 게이트는 가이드 도구.
+
+## Anti-Patterns
+
+- **NSM이 vanity metric** ("downloads", "stars") — 사용자 행동 측정 X
+- **Won't가 비어있음** — scope creep 방어선 부재
+- **4-gate 검증 없이 "유용해 보이니까" 추가** — Decision Making 메타원칙 위반
+- **NORTH_STAR.md를 작성만 하고 한 번도 참조 안 함** — 죽은 문서. 분기 리뷰로 살림
+
+## Examples
+
+GoalTrack 프로젝트의 NORTH_STAR.md (참고 사례, 도메인 종속):
+- NSM: WAGI (Weekly AI-Initiated Goal Items) ≥ 40%
+- Won't: 팀 협업 도구 / 모바일 우선 / 게이미피케이션 / 외부 통합 폭발 / CRDT
+- 4-gate: Trend × Persona × MCP × Lean
+
+본 skill은 그 패턴을 도메인 비종속으로 일반화한 것.