자산 관리 스킬 (eond-asset-manager) — 주요 자산을 큐레이션

eond-asset-manager는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.

이온디 자산관리시스템이자 이온디 자산관리 스킬로서 여러 사이트, 서비스, 라이믹스·워드프레스 마켓, eondcms, 앱·데스크탑·브라우저 확장 제품, 포트폴리오, 호스팅, 커뮤니티, 유틸리티, 전자책을 실제 근거로 발견·분류·선별·연결하고 통합 소개할 때 사용한다. 사용자가 "이온디자산관리", "이온디 자산관리 스킬", "자산관리시스템", "이온디가 무엇을 하는 곳인지 소개", "전체 자산이나 주요제품 정리", "대표 제품·서비스 골라줘", "사이트와 제품 생태계 맵", "메인·허브·회사소개에 보여줄 자산 선정", "마켓·포트폴리오·전자책을 묶어 설명", "자산 설명·URL·이미지·CTA 누락 점검", "전문 콘텐츠 작업용 브리프"를 요청하면 사용한다. 목적이 명확한 큐레이션은 바로 수행하고, 브랜드 위계·메인 역할·IA처럼 전체 노출 구조를 바꾸는 선택은 한 항목씩 대안을 점수화해 사용자와 합의한다.

사용 방법

Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.

사용 예:
eond-asset-manager 스킬 사용해줘.
이 작업은 eond-asset-manager 기준으로 진행해줘.

연관스킬

이 스킬과 함께 쓰면 좋은 관련 스킬입니다.

원본 위치

.codex/skills/eond-asset-manager/SKILL.md

SKILL.md

---
name: eond-asset-manager
description: 이온디 자산관리시스템이자 이온디 자산관리 스킬로서 여러 사이트, 서비스, 라이믹스·워드프레스 마켓, eondcms, 앱·데스크탑·브라우저 확장 제품, 포트폴리오, 호스팅, 커뮤니티, 유틸리티, 전자책을 실제 근거로 발견·분류·선별·연결하고 통합 소개할 때 사용한다. 사용자가 "이온디자산관리", "이온디 자산관리 스킬", "자산관리시스템", "이온디가 무엇을 하는 곳인지 소개", "전체 자산이나 주요제품 정리", "대표 제품·서비스 골라줘", "사이트와 제품 생태계 맵", "메인·허브·회사소개에 보여줄 자산 선정", "마켓·포트폴리오·전자책을 묶어 설명", "자산 설명·URL·이미지·CTA 누락 점검", "전문 콘텐츠 작업용 브리프"를 요청하면 사용한다. 목적이 명확한 큐레이션은 바로 수행하고, 브랜드 위계·메인 역할·IA처럼 전체 노출 구조를 바꾸는 선택은 한 항목씩 대안을 점수화해 사용자와 합의한다.
---

# 이온디 자산관리 스킬

## 역할

흩어진 이온디 자산을 `하나의 목록`이 아니라 `누구에게 어떤 가치와 증거로 보여줄 생태계`로 정리한다. 실제 저장소·운영 데이터·공개 화면을 확인하고, 통합 소개는 직접 작성하되 개별 상품·사례·브랜드·채널 콘텐츠는 전문 스킬이 사용할 근거 포함 브리프로 넘긴다.

## 절대 규칙

1. 전체 자산 목록을 스킬 안에 고정하지 않는다. 변하는 제품 수, URL, 가격, 공개 상태는 작업 시점의 실제 자료에서 확인한다.
2. 확인한 사실, 문서에만 있는 잠정 정보, 오픈 예정, 비공개, 확인 필요 항목을 섞지 않는다.
3. 제품명·성과·고객·가격·호환성·운영 상태를 추측으로 채우지 않는다.
4. 목적과 결과 형식이 명확하면 불필요한 질문 없이 조사하고 큐레이션한다.
5. 메인 역할, GNB, 브랜드 위계, 대표 사업처럼 후속 결과를 크게 바꾸는 선택은 사용자 승인 없이 확정하지 않는다.
6. 전략 선택에서는 추천을 사용자 선택으로 간주하지 않는다. 한 번에 한 항목만 A/B/C 또는 실질적인 2~3개 안으로 비교하고 응답을 기다린다.
7. 개별 상품 판매글, 개별 포트폴리오 사례, 브랜드 정의, 채널별 게시글을 범용적으로 대신 작성하지 않는다. 적합한 전문 스킬로 연결한다.
8. 사용자가 등록·수정·공개를 요청하지 않으면 운영 데이터와 사이트를 변경하지 않는다.
9. 자산의 수가 많다는 사실만 강조하지 않는다. 대상 사용자의 문제, 선택 이유, 실제 증거, 다음 행동을 연결한다.

## 필요한 참조

- 모든 작업에서 [evidence-and-source-routing.md](references/evidence-and-source-routing.md)와 [ecosystem-taxonomy.md](references/ecosystem-taxonomy.md)를 읽는다.
- `curate`, `introduce`, `audit`, `handoff` 작업에서는 [curation-output-and-handoffs.md](references/curation-output-and-handoffs.md)를 읽는다.
- 중요한 페이지 역할·IA·메뉴 구조를 논의하면 `site-planning-strategist`를 사용하고 그 지침을 읽는다.
- 승인된 새 통합 브랜드 문서가 생기면 기존 경로보다 우선한다. 승인 여부가 불명확하면 현재 자료를 잠정 근거로 표시한다.

## 시작 절차

1. 저장소 루트를 확인하고 사용자의 요청에서 대상, 독자, 노출 위치, 결과 형식을 추출한다.
2. 요청을 `discover`, `map`, `curate`, `introduce`, `audit`, `handoff` 중 필요한 모드로 분류한다. 하나의 요청에 여러 모드를 조합할 수 있다.
3. 근거 우선순위에 따라 필요한 문서·코드·원장·공개 화면만 조사한다.
4. 후보 자산마다 최소한 `이름, 유형, 사업 경로, 플랫폼, 대상 문제, 상태, 근거, URL`을 가능한 범위에서 채운다.
5. 요청이 즉시 실행형인지 협의형인지 판정한다.
6. 결과에 사용한 근거와 확인하지 못한 정보를 함께 표시한다.

## 작동 방식 판정

### 즉시 실행형

다음과 같이 대상이나 산출물이 구체적이면 바로 수행한다.

- 라이믹스 대표 제품 6개를 운영자 관점으로 정리
- 이온디가 만든 앱을 플랫폼별로 소개
- 전체 사이트의 역할과 현재 상태를 표로 정리
- 주요제품 랜딩에 사용할 자산 후보와 근거 작성
- 제품별 설명·URL·스크린샷 누락 점검

정보가 일부 부족해도 안전한 범위의 초안을 먼저 만들고 `확인 필요`를 분리한다. 가격·라이선스·고객 공개 권한처럼 결과를 오도하는 정보만 확인 질문으로 남긴다.

### 협의형

다음처럼 선택이 전체 구조를 바꾸면 합의 절차로 전환한다.

- 메인에서 이온디를 무엇으로 인식시킬지 결정
- 제작·마켓·제품·호스팅의 위계나 GNB를 변경
- 어떤 사업을 대표 브랜드나 플래그십으로 둘지 결정
- 제품·사이트를 통합하거나 공개 메뉴에서 제외
- 사용자가 논의, A/B/C, 하나씩 질문을 명시

협의형에서는 다음을 지킨다.

1. 전체 결정 지도를 짧게 제시하되 현재 항목 하나만 논의한다.
2. 실제로 다른 2~3개 안을 같은 깊이로 작성한다.
3. 각 안을 100점으로 평가하고 추천 이유와 포기하는 점을 밝힌다.
4. 최고 점수안을 추천하되 선택되지 않았음을 명시한다.
5. 사용자가 선택하기 전 다음 항목, 전체 소개서, 와이어프레임, 구현으로 넘어가지 않는다.
6. 페이지 역할·IA·화면 흐름이 핵심이면 큐레이션을 멈추고 `site-planning-strategist`로 넘긴다.

## 작업 모드

### `discover`

관련 자산을 찾아 중복을 정리하고 출처·상태·확인일을 붙인다. 목록이 크면 먼저 범위별 집계를 보여주고 상세 목록은 필요한 그룹만 펼친다.

### `map`

브랜드 허브, 사업 경로, 사이트, 서비스, 제품, 사례, 콘텐츠의 관계를 계층이나 교차 연결로 표현한다. 기술 플랫폼과 고객 문제를 같은 위계에 섞지 않는다.

### `curate`

대상 사용자와 노출 목적을 먼저 고정하고 대표 자산을 선정한다. 비교가 필요한 후보는 참조 문서의 100점 기준으로 평가한다. 첫 화면은 6~9개 대표작을 기본 상한으로 삼되 사용자의 채널과 화면 밀도에 맞게 조정한다.

### `introduce`

여러 자산을 묶는 생태계·카테고리·서비스군 소개를 작성한다. `대상 문제 → 이온디의 역할 → 대표 증거 → 탐색 경로 → CTA` 순으로 설명한다. 회사의 새 브랜드 정의나 개별 상품의 장문 판매 페이지를 대신 확정하지 않는다.

### `audit`

자산마다 설명, 대상, 문제, 기능·효익, 실제 화면, URL, 가격·정책, 공개 상태, CTA, 관련 사례의 누락을 점검한다. 공개 불가나 예정 상태를 결함으로 오판하지 말고 운영 결정이 필요한 항목으로 분리한다.

### `handoff`

전문 스킬이 다시 조사하지 않도록 확인 근거, 목표, 대상, 선택 자산, 금지 주장, 확인 필요 항목, 원하는 산출물을 포함한 브리프를 만든다. 연결 스킬을 실제 사용할 때는 사용자에게 이유를 알리고 해당 스킬 지침을 읽는다.

## 기본 결과 원칙

- 사용자가 요구한 크기에 맞춰 가장 작은 유용한 결과를 낸다. 모든 모드의 전체 템플릿을 강제로 출력하지 않는다.
- 대표 자산을 고르면 선택 이유와 제외 이유를 구분한다.
- 여러 URL을 나열하기보다 각 URL이 맡는 역할과 다음 행동을 설명한다.
- 같은 자산이 마켓 상품, 제품 증거, 제작 사례에 재사용되면 원본 하나와 노출 맥락 여러 개로 표현한다.
- 실제 운영 여부를 확인하지 못한 URL에는 `잠정` 또는 `확인 필요`를 붙인다.
- 최종 문안에는 내부 파일 경로나 상태 코드를 그대로 노출하지 말고, 근거 부록에서만 간결하게 표시한다.

## 완료 기준

다음을 만족하면 완료한다.

- 요청한 범위의 자산과 관계가 실제 근거에 연결됨
- 대상 사용자와 노출 목적에 맞는 선별 이유가 설명됨
- 상태와 불확실성이 분리됨
- 통합 소개에 하나의 중심 메시지와 다음 행동이 있음
- 전문 작업이 필요한 부분이 적절한 스킬과 브리프로 연결됨
- 사용자 승인 없이 브랜드·IA·운영 상태를 확정하거나 변경하지 않음

참고 리소스

이 스킬이 직접 참조하는 Markdown 참고 파일입니다. 재사용할 때 같은 상대 경로로 저장하면 동작이 안정적입니다.

.codex/skills/eond-asset-manager/references/evidence-and-source-routing.md

# 근거와 소스 라우팅

## 목차

1. 근거 우선순위
2. 상태 표기
3. 기본 조사 순서
4. 자산군별 소스
5. 충돌 처리

## 1. 근거 우선순위

아래 순서로 근거를 적용한다.

1. 사용자가 승인한 최신 통합 브랜드 문서
2. 이번 대화에서 사용자가 명시적으로 확정한 결정
3. 실제 공개 화면, 운영 데이터, 제품 코드와 배포 상태
4. `docs/eond-brand-and-service-map.md`
5. `docs/eond-unified-catalog-plan.md`
6. `.codex/BRAND.md`
7. 기존 기획 문서와 스킬 내부 분류 지침
8. 일반적인 업계 관행과 합리적 추론

상위 근거와 하위 근거가 충돌하면 상위 근거를 우선하고 충돌 사실을 남긴다. 문서의 작성일이 최신이라는 이유만으로 사용자 승인보다 우선하지 않는다.

## 2. 상태 표기

| 상태 | 기준 | 표현 원칙 |
| --- | --- | --- |
| 확인 | 실제 코드·원장·공개 화면에서 현재 상태를 확인 | 사실로 사용하고 근거 위치 기록 |
| 잠정 | 기존 문서에는 있으나 현재 운영 상태를 확인하지 못함 | 단정하지 않고 재확인 필요 표시 |
| 예정 | 개발 중이거나 오픈 예정이라고 명시됨 | 현재 제공 중인 서비스처럼 소개하지 않음 |
| 비공개 | 내부 자산 또는 공개·판매 준비가 안 됨 | 공개 목록에서 기본 제외 |
| 확인 필요 | 출처가 충돌하거나 핵심 정보가 없음 | 결정·판매 문구에 사용하지 않음 |

`active` 같은 DB 상태를 곧바로 공개 가능으로 번역하지 않는다. 실제 페이지, 접근 가능성, 콘텐츠 완성도까지 확인한다.

## 3. 기본 조사 순서

1. `git rev-parse --show-toplevel`로 저장소 루트를 찾는다.
2. 사용자 요청과 승인된 브랜드 결정에서 조사 범위를 줄인다.
3. `rg --files`와 `rg`로 관련 문서·모델·라우트·템플릿·스크립트를 찾는다.
4. 데이터 원장이 있으면 코드 상수보다 원장을 우선하되, 원장 필드의 의미는 모델과 관리자 흐름으로 검증한다.
5. 현재 공개 상태나 외부 URL이 결과에 중요하면 실제 페이지를 확인한다.
6. 조사 시점을 결과에 기록하고, 확인하지 못한 정보는 상태로 분리한다.

읽기 전용 조사로 충분한 요청에서 DB 쓰기, 임포트 `--apply`, 관리자 저장, 게시글 등록을 실행하지 않는다.

## 4. 자산군별 소스

| 자산군 | 우선 확인할 위치 | 보조 확인 |
| --- | --- | --- |
| 브랜드·서비스 역할 | 승인된 브랜드 문서, `docs/eond-brand-and-service-map.md` | `.codex/BRAND.md`, `docs/eond-gateway-plan.md` |
| 통합 카탈로그·대표작 | `SaleProduct`, `ProductVersion`, `docs/eond-unified-catalog-plan.md` | `scripts/import_assets.py`, `app/utils/hub_catalog.py` |
| eondcms 레이아웃 | `templates/layouts/*/theme.json`과 실제 템플릿 | `scripts/import_assets.py` 스캔 규칙 |
| 라이믹스 자산 | `~/dev/rx/layouts`, `~/dev/rx/modules`의 메타데이터 | 라이믹스 마켓 문서와 연결 스크립트 |
| 워드프레스 자산 | `~/dev/wp/wp-content/plugins`, `themes`의 헤더·README | 워드프레스 마켓 문서와 라이선스 원장 |
| 앱·도구 | 실제 프로젝트 저장소·README·릴리스, `SaleProduct` | `scripts/import_assets.py`, `app/utils/works_catalog.py` |
| 사이트·서브도메인 | 실제 URL, `eond_site`, 라우트와 레이아웃 설정 | `docs/eond-sitemap.md`, 서비스맵 |
| 포트폴리오 | `portfolio` 모듈의 공개 문서·카테고리·실제 URL | `app/routers/admin_portfolio.py`, `scripts/seed_portfolio.py` |
| 호스팅 | 활성 요금제와 신청 화면, 호스팅 모델 | 브랜드·서비스맵과 호스팅 템플릿 |
| 전자책·강의 | `SaleProduct.product_type`, 공개 판매 문서 | 기존 메뉴·소개 문서 |
| 커뮤니티·가이드 | 실제 mid·메뉴·공개 게시판 | 사이트맵과 해당 레이아웃 |

경로가 존재하지 않으면 같은 이름을 전체 저장소에서 다시 검색한다. 표의 경로를 영구적인 사실로 가정하지 않는다.

## 5. 충돌 처리

- 문서에는 공개로 적혀 있지만 URL이 닫혀 있으면 `잠정` 또는 `확인 필요`로 낮춘다.
- 코드가 존재해도 소개, 스크린샷, CTA, 지원 범위가 없으면 `비공개 후보`로 본다.
- 같은 제품이 원장과 마켓 SKU에 중복되면 제품 원본과 판매 옵션을 분리한다.
- 제품명이나 소유 주체가 충돌하면 공개 문구를 만들지 말고 원출처를 확인한다.
- 수치가 서로 다르면 산출 기준과 확인일이 있는 값만 사용한다.
- 추론이 필요하면 `추론`이라고 밝히고 브랜드 사실이나 운영 약속으로 승격하지 않는다.

.codex/skills/eond-asset-manager/references/ecosystem-taxonomy.md

# 이온디 생태계 분류체계

## 목차

1. 분류 원칙
2. 필수 분류축
3. 사업 경로
4. 플랫폼과 문제 태그
5. 노출 판단

## 1. 분류 원칙

하나의 자산에 하나의 원본 정체성을 부여하고 여러 노출 맥락을 연결한다. 제품명, 기술명, 서비스명, 게시판명을 같은 위계에 나열하지 않는다.

예를 들어 관리 도구 하나가 다음 역할을 동시에 가질 수 있다.

- 원본 유형: 제품
- 마켓에서: 판매 상품
- 제작 의뢰에서: CMS 전문성의 증거
- 가이드에서: 사용법 콘텐츠의 대상

역할이 여러 개라고 자산을 복제하지 않는다.

## 2. 필수 분류축

| 축 | 값 예시 | 질문 |
| --- | --- | --- |
| 원본 유형 | 허브, 서비스, 마켓, 제품, 프로젝트, 콘텐츠, 커뮤니티, 유틸리티 | 이것 자체가 무엇인가 |
| 사업 경로 | 제작 의뢰, 마켓, 주요제품, 호스팅, AXAI, 포트폴리오, 가이드 | 방문자의 다음 행동은 어디인가 |
| 플랫폼 | eondcms, Rhymix/XE, WordPress, Web, Browser, Linux, Desktop, Mobile, AI | 어디에서 동작하는가 |
| 사용자 문제 | 사이트관리, 이전·업그레이드, 커뮤니티, 콘텐츠, 판매, 업무, 운영 안정, 자동화 등 | 어떤 막힘을 해결하는가 |
| 수익 형태 | 의뢰, 판매, 구독, 무료 유입, 신뢰 증거, 예정 | 사업에서 어떤 역할인가 |
| 생애주기 | 운영, 판매, 유지보수, 실험, 예정, 중단, 확인 필요 | 현재 상태는 무엇인가 |
| 근거 상태 | 확인, 잠정, 예정, 비공개, 확인 필요 | 무엇으로 사실을 증명하는가 |

기술 플랫폼은 사용자의 문제보다 앞에 세우지 않는다. 사용자가 기술을 명시한 경우에만 플랫폼을 첫 분류축으로 사용할 수 있다.

## 3. 사업 경로

| 경로 | 포함할 것 | 기본 CTA |
| --- | --- | --- |
| 제작 의뢰 | 고객 문제를 해결한 제작 범위와 유사 사례 | 제작 문의 |
| 마켓 | 구매·다운로드 가능한 테마, 플러그인, 모듈, 자료 | 상품 보기·구매 |
| 주요제품 | 이온디가 직접 만들고 운영하는 대표 제품군 | 제품 살펴보기·도입 문의 |
| 호스팅 | 요금제, 이전, 백업, SSL, 서버 운영 | 신청·이전 상담 |
| AXAI | AI 도구와 자동화 도입 역량 | 자동화 상담 |
| 포트폴리오 | 문제·제약·역할·결과가 있는 실제 사례 | 비슷한 프로젝트 문의 |
| 가이드 | 검색 유입과 문제 해결을 위한 지식 | 관련 제품·서비스 탐색 |

한 자산의 주 경로를 하나 정하고 보조 경로는 교차 노출로 기록한다.

## 4. 플랫폼과 문제 태그

플랫폼은 다음 표준명을 우선 사용한다.

- CMS: `eondcms`, `Rhymix/XE`, `WordPress`
- 채널·런타임: `Web`, `Browser extension`, `Linux`, `Desktop`, `Mobile`
- 역량 묶음: `AI/Automation`, `Hosting/Server`, `Design/Content`

고객 문제 태그는 실제 자산에 맞게 확장하되 다음 상위군을 우선 재사용한다.

- 쇼핑몰·판매
- 커뮤니티·회원 운영
- 사이트관리·관리자 경험
- 콘텐츠·블로그
- 사내도구·업무 시스템
- 이전·업그레이드
- 호스팅·운영 안정
- 디자인·콘텐츠 제작
- 영상·미디어
- 일상·개인 생산성
- AI·자동화

비슷한 단어를 새 태그로 계속 만들지 말고 기존 상위군 아래 세부 태그로 둔다.

## 5. 노출 판단

다음 순서로 공개 위치를 정한다.

1. 사용자가 지금 해결하려는 문제가 분명한가.
2. 현재 공개·판매·운영 상태를 확인했는가.
3. 설명, 실제 화면, URL, 지원 범위, CTA가 준비됐는가.
4. 어떤 사업 경로의 전환이나 신뢰에 기여하는가.
5. 같은 역할의 자산 중 대표성이 있는가.

기본 노출 규칙:

- 메인·관문: 개별 자산을 과다 나열하지 않고 문과 증거만 보여준다.
- 카테고리·랜딩: 대표작 6~9개와 전체 보기 경로를 둔다.
- 상세 페이지: 기능, 증거, 정책, 가격, CTA를 완결한다.
- 공개 준비가 부족한 자산: 내부 원장에는 유지하되 공개 큐레이션에서 제외한다.
- 예정 자산: 별도 예정 영역에 두고 현재 사용 가능한 것처럼 표현하지 않는다.

.codex/skills/eond-asset-manager/references/curation-output-and-handoffs.md

# 큐레이션 산출물과 전문 스킬 연결

## 목차

1. 모드별 산출물
2. 대표작 평가 기준
3. 통합 소개 구조
4. 감사 체크리스트
5. 전문 스킬 연결
6. 핸드오프 브리프

## 1. 모드별 산출물

### Discover

필요한 열만 사용한다.

| 자산 | 원본 유형 | 사업 경로 | 플랫폼 | 상태 | 근거 | URL |
| --- | --- | --- | --- | --- | --- | --- |

목록이 크면 `그룹별 개수 → 대표 후보 → 요청 범위의 상세` 순으로 축약한다.

### Map

다음 중 관계를 가장 잘 보여주는 하나만 선택한다.

- 계층: 허브 → 사업 경로 → 자산군
- 교차표: 자산 × 노출 경로
- 흐름: 사용자 문제 → 서비스 → 증거 → CTA

### Curate

다음 순서로 작성한다.

1. 대상 사용자와 노출 목적
2. 선정 기준
3. 대표 자산과 점수·근거
4. 노출 순서와 한 줄 역할
5. 제외·보류 자산과 이유
6. 다음 탐색 또는 CTA

### Introduce

다음 기본 구조를 채널에 맞게 줄인다.

1. 사용자의 문제 또는 탐색 목적
2. 이온디가 맡는 역할
3. 대표 자산군과 실제 증거
4. 자산 간 연결과 선택 방법
5. 하나의 주 CTA와 필요한 보조 링크

### Audit

치명도는 다음처럼 구분한다.

- `차단`: 공개·구매 판단을 오도하는 정보 충돌
- `높음`: 소개, URL, 실제 화면, 가격·정책, CTA 중 핵심 누락
- `보통`: 분류, 태그, 관련 사례, SEO·공유 정보 부족
- `낮음`: 문구 일관성이나 보조 자산 개선

## 2. 대표작 평가 기준

대표작을 비교할 때 다음 합계 100점을 사용한다.

| 기준 | 배점 | 판단 질문 |
| --- | ---: | --- |
| 대상 문제 적합성 | 25 | 이번 독자의 문제를 직접 해결하거나 설명하는가 |
| 이온디 생태계 대표성 | 20 | 제품·제작·운영 역량을 고유하게 보여주는가 |
| 실제 증거 | 20 | 화면, 코드, 운영 URL, 판매·사용 기록이 있는가 |
| 사업·CTA 연결 | 15 | 문의, 구매, 도입, 탐색으로 자연스럽게 이어지는가 |
| 공개 준비도 | 10 | 설명, 이미지, 정책, 링크가 준비됐는가 |
| 운영 지속성 | 10 | 현재 관리·지원·갱신 가능한가 |

세부 합과 총점을 일치시킨다. 근거가 부족하면 높은 점수 대신 `잠정`을 사용한다. 점수는 자산의 절대 품질이 아니라 이번 노출 목적에 대한 적합도다.

## 3. 통합 소개 구조

통합 소개는 제품 수를 자랑하는 목록으로 시작하지 않는다.

```text
대상 문제
→ 이온디가 제공하는 연속된 역할
→ 대표 서비스·제품·사례
→ 사용자가 자기 경로를 고르는 기준
→ CTA
```

기본 메시지는 확인된 브랜드 문서에서 가져온다. 새 슬로건, 핵심 가치, 브랜드 약속을 임의로 확정하지 않는다.

## 4. 감사 체크리스트

자산별로 다음을 확인한다.

- 공식 이름과 한 문장 설명
- 대상 사용자와 해결 문제
- 핵심 기능 또는 제공 범위
- 실제 화면·데모·사례
- 공개 URL과 연결 상태
- 가격, 라이선스, 지원·업데이트 정책
- 현재 공개·판매·운영 상태
- 주 사업 경로와 보조 노출 경로
- 주 CTA와 도착 페이지
- 관련 제품, 사례, 가이드
- 공개하면 안 되는 정보나 고객 데이터

## 5. 전문 스킬 연결

| 필요한 결과 | 연결 대상 | 큐레이터가 먼저 준비할 것 |
| --- | --- | --- |
| 페이지 역할, IA, 메뉴, 화면 흐름 | `site-planning-strategist` | 자산맵, 사용자 경로, 현재 근거, 미정 결정 |
| 개별 마켓 상품 판매 페이지 | `eond-market-product-writer` | 제품 사실, 구매자, 증거, 정책 누락 |
| 개별 프로젝트·구축 사례 | `eond-portfolio-case-writer` | 문제, 역할, 결과, 공개 가능한 증거 |
| 게시판·Threads·API 게시글 | 주제 전문 스킬 후 `contentsmaker` | 확정 메시지, 독자, 채널, CTA, 링크 |
| 브랜드 정의·보이스·핵심 서사 | 승인된 이온디 브랜드 스킬 | 확인된 생태계 사실, 충돌, 미정 항목 |
| 시각 방향·페이지 구현 | 관련 디자인·UX/UI 스킬 | 승인된 구조, 대표 자산, 실제 이미지 목록 |

브랜드 스킬의 이름이나 경로가 아직 확정되지 않았으면 임의의 이름을 만들지 말고 설치된 스킬을 확인한다.

## 6. 핸드오프 브리프

다음 필드 중 필요한 것만 채운다.

```text
작업 목표:
대상 사용자:
노출 위치·채널:
선택 자산과 선정 이유:
확인된 사실과 근거:
잠정·예정·확인 필요:
사용하면 안 되는 주장:
필수 링크·CTA:
원하는 산출물:
사용할 전문 스킬:
```

전문 스킬을 호출할 때 큐레이터의 결론만 전달하지 말고 확인한 원자료와 상태를 함께 전달한다.