마켓 상품 작성 스킬 (eond-market-product-writer) — 판매용 소개문 작성

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

이온디마켓에서 판매하거나 배포할 워드프레스 테마·플러그인, 라이믹스 레이아웃·스킨·모듈·게시판 스킨·애드온·위젯, 웹앱, 모바일앱, 데스크탑앱, 브라우저 확장, 개발 도구의 상품 기획과 판매 콘텐츠를 작성할 때 사용한다. 사용자가 "마켓 상품 소개 써줘", "판매글 작성", "상품 상세페이지 기획", "제품 등록 문구", "기능을 소비자 관점으로 설명", "대표이미지나 상세페이지 이미지 구성", "가격·라이선스·FAQ·CTA 설계", "기존 상품글 개선"을 요청하면 MD·마케팅·판매전략 관점으로 조사, 포지셔닝, 카피, 이미지 그래픽 브리프, SEO와 등록 필드를 만든다.

사용 방법

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

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

연관스킬

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

원본 위치

.codex/skills/eond-market-product-writer/SKILL.md

SKILL.md

---
name: eond-market-product-writer
description: 이온디마켓에서 판매하거나 배포할 워드프레스 테마·플러그인, 라이믹스 레이아웃·스킨·모듈·게시판 스킨·애드온·위젯, 웹앱, 모바일앱, 데스크탑앱, 브라우저 확장, 개발 도구의 상품 기획과 판매 콘텐츠를 작성할 때 사용한다. 사용자가 "마켓 상품 소개 써줘", "판매글 작성", "상품 상세페이지 기획", "제품 등록 문구", "기능을 소비자 관점으로 설명", "대표이미지나 상세페이지 이미지 구성", "가격·라이선스·FAQ·CTA 설계", "기존 상품글 개선"을 요청하면 MD·마케팅·판매전략 관점으로 조사, 포지셔닝, 카피, 이미지 그래픽 브리프, SEO와 등록 필드를 만든다.
---

# Eond Market Product Writer

## 목표

기술 산출물을 소비자가 10초 안에 이해하고, 자신의 문제와 연결하고, 구매 전 불안을 해소한 뒤 구매 또는 문의할 수 있는 상품 페이지로 바꾼다.

## 작업 원칙

1. 기능보다 `누구의 어떤 문제를 얼마나 쉽게 해결하는가`를 먼저 쓴다.
2. 확인된 사실, 합리적 추론, 추가 확인 필요 항목을 분리한다.
3. 호환 버전, 설치 방법, 라이선스, 업데이트, 지원 범위를 확인 없이 만들지 않는다.
4. 실제 제품 화면을 최우선 증거로 사용한다. 생성 이미지로 존재하지 않는 UI나 결과를 만들지 않는다.
5. 과장된 1위, 완벽, 무조건, 한정 판매, 허위 할인과 근거 없는 절감 수치를 쓰지 않는다.
6. 개발자 용어는 유지하되 바로 뒤에 소비자 효익을 설명한다.
7. 하나의 상품 페이지에는 하나의 주된 구매 이유를 세우고 나머지는 보조 근거로 배치한다.

## 시작 절차

1. 저장소, README, 데모 URL, 기존 판매글, 릴리스 기록, 스크린샷을 먼저 조사한다.
2. 상품을 [product-taxonomy.md](references/product-taxonomy.md)에 따라 분류한다.
3. 다음 최소 정보를 확보한다.
   - 제품명과 한 문장 기능
   - 대상 사용자와 사용 상황
   - 해결 전 불편과 사용 후 변화
   - 핵심 기능 3개와 이를 입증할 화면
   - 지원 플랫폼·버전·필수 환경
   - 설치 난이도와 제공 파일
   - 가격, 라이선스, 업데이트, 기술지원 정책
   - 데모, 문서, 문의, 구매 URL
4. 정보가 부족해도 초안은 진행하되 `확인 필요` 표를 앞에 둔다. 구매 판단에 치명적인 가격·호환성·라이선스만 질문한다.

## 판매 기획

다음 순서로 상품의 판매 논리를 만든다.

1. **구매자**: 실제 결제할 사람 한 유형을 우선한다.
2. **구매 순간**: 어떤 문제를 겪을 때 검색하거나 구매하는지 정의한다.
3. **핵심 약속**: 제품 사용 후 얻는 변화를 한 문장으로 쓴다.
4. **차별 근거**: 직접 개발, 국내 CMS 경험, 설치지원, 연동성 등 증명 가능한 이유를 고른다.
5. **불안 제거**: 호환성, 설치, 데이터 보존, 환불·지원 범위를 명시한다.
6. **CTA**: 즉시 구매, 데모 확인, 설치지원 문의 중 상품 상태에 맞는 하나를 주 CTA로 둔다.

기능은 항상 `기능 → 사용자 효익 → 증거 화면`으로 변환한다. 상세 구조는 [sales-page-framework.md](references/sales-page-framework.md)를 따른다.

## 이미지 기획

[visual-merchandising.md](references/visual-merchandising.md)를 읽고 다음을 출력한다.

- 대표이미지 1장: 제품명보다 결과와 제품 유형을 먼저 인지시킨다.
- 상세 이미지 5~8장: 문제, 핵심 결과, 주요 기능, 사용 흐름, 호환성, 지원 순서로 구성한다.
- 각 이미지마다 목적, 화면/자산, 헤드라인, 보조문구, 권장 비율을 적는다.
- 실제 화면이 있으면 캡처와 디바이스 목업을 사용한다.
- 화면이 없으면 기능 흐름도나 전후 비교 그래픽을 만들되 실제 동작처럼 위장하지 않는다.
- 이미지 생성이 필요하면 `imagegen`은 배경·개념 그래픽·장식 자산에만 사용한다.

## 작성 모드

- `full`: 조사부터 판매 페이지, 이미지 브리프, SEO, 등록 필드까지 작성한다.
- `brief`: 상품명, 한 줄 설명, 핵심 효익, CTA만 빠르게 만든다.
- `rewrite`: 기존 판매글을 진단하고 사실을 보존하며 다시 쓴다.
- `audit`: 구매자 관점의 누락, 불신 요소, 이미지 부족과 전환 저해 요소를 점수화한다.
- `batch`: 여러 상품을 동일한 분류·톤으로 처리하되 상품별 핵심 약속은 중복하지 않는다.

사용자가 지정하지 않으면 `full`을 사용한다.

## 기본 출력

1. `상품 진단`: 분류, 구매자, 구매 순간, 핵심 약속, 차별 근거
2. `확인 필요`: 구매 판단에 영향을 주는 누락 정보
3. `판매 메타`: 상품명, 목록 제목, 한 줄 설명, 요약, 태그, SEO 제목·설명
4. `상세페이지 원고`: [sales-page-framework.md](references/sales-page-framework.md) 순서
5. `이미지 스토리보드`: [visual-merchandising.md](references/visual-merchandising.md) 형식
6. `가격·라이선스·지원`: 확인된 정책만 표기
7. `FAQ`: 실제 구매 장애 요인 5~8개
8. `CTA`: 주 CTA와 보조 CTA
9. `등록 필드`: [eond-market-fields.md](references/eond-market-fields.md) 기준
10. `품질 점검`: 아래 점수와 미달 항목

## 품질 게이트

각 항목을 20점으로 평가하고 80점 미만이면 보완한다.

- 10초 이해도: 제품 유형, 대상, 결과가 첫 화면에서 보이는가
- 구매 적합성: 호환성, 제공 범위, 설치 조건이 명확한가
- 신뢰 증거: 실제 화면, 데모, 문서, 버전 또는 사례가 있는가
- 전환 구조: 핵심 약속과 CTA가 한 방향으로 이어지는가
- 시각 전달: 이미지마다 한 메시지만 있고 작은 화면에서도 읽히는가

## 연계 스킬

- 게시판 API 등록이 필요하면 `contentsmaker`의 실제 등록 스키마를 확인한다.
- 제품이 실제 구축 사례와 연결되면 `eond-portfolio-case-writer`로 사례 글을 별도 작성한다.
- 대표이미지는 실제 화면 캡처를 우선하고, 포트폴리오형 목업이 필요하면 `portfolio-thumbnail-maker`를 활용한다.
- 사용자가 명시적으로 등록·공개를 요청하지 않으면 초안만 만들고 운영 데이터는 변경하지 않는다.

참고 리소스

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

.codex/skills/eond-market-product-writer/references/product-taxonomy.md

# 상품 분류와 구매자 관점

## 분류 순서

`제품군 → 플랫폼 → 유형 → 해결 문제 → 구매자` 순서로 정리한다.

| 제품군 | 플랫폼 예시 | 유형 예시 | 주요 구매자 질문 |
|---|---|---|---|
| CMS 자료 | Rhymix/XE | 레이아웃, 모듈, 스킨, 게시판 스킨, 애드온, 위젯 | 내 버전에서 작동하는가, 기존 자료와 충돌하는가 |
| CMS 자료 | WordPress | 테마, 플러그인, 블록, 관리자 도구 | 테마·빌더와 호환되는가, 업데이트는 계속되는가 |
| 브라우저 도구 | Chrome/Edge | 확장 프로그램 | 어떤 권한을 쓰며 데이터는 어디에 저장되는가 |
| 데스크탑 | Windows/Linux/macOS | GUI 앱, 트레이 도구, CLI | 지원 OS와 설치 방식, 업데이트 방법은 무엇인가 |
| 모바일 | Android/iOS | 앱, 관리 앱 | 지원 기기, 계정·동기화·백업 방식은 무엇인가 |
| 웹 제품 | Web/SaaS | 웹앱, 관리도구, 편집기 | 가입·요금·데이터 보관·브라우저 지원은 무엇인가 |
| 개발 서비스 | 공통 | 설치, 커스텀, 이전, 자동화 | 범위, 기간, 산출물, 유지보수 기준은 무엇인가 |

## 이온디 마켓 필드 매핑

현재 `eond_sale_products` 기준으로 디지털 제품은 보통 다음처럼 매핑한다.

- `product_type`: `digital`을 우선하되 실제 운영값을 확인한다.
- `platform`: 현재 코드가 사용하는 `rhymix`, `wordpress`, `chrome`, `general`을 우선한다.
- `sub_type`: `layout`, `skin`, `module`, `theme`, `plugin`, `extension` 등 실제 값을 확인한다.
- `code`: 라이선스 검증에 사용하는 안정적인 제품 식별자다. 추측해 만들지 않는다.
- `tags`: 기술명이 아니라 고객 문제 태그를 함께 넣는다.

새 플랫폼·유형이 필요하면 콘텐츠 값과 DB 허용값을 구분해 제안한다. 스키마를 확인하지 않고 임의 값을 등록하지 않는다.

## 구매자 수준

- 초보 운영자: 설치 난이도, 설정 화면, 지원을 먼저 설명한다.
- 숙련 운영자: 호환성, 확장 지점, 성능, 변경 파일을 먼저 설명한다.
- 개발자·에이전시: 라이선스 범위, 재사용 조건, 코드 품질, 업데이트를 먼저 설명한다.
- 기업 담당자: 운영 안정성, 권한, 데이터, 유지관리와 책임 범위를 먼저 설명한다.

한 페이지에서 모든 구매자를 같은 비중으로 설득하지 않는다. 주 구매자 1명과 보조 구매자 1명까지만 둔다.

.codex/skills/eond-market-product-writer/references/sales-page-framework.md

# 판매 상세페이지 구조

## 1. 첫 화면

- 제품 유형 라벨
- 결과 중심 헤드라인 25자 안팎
- 대상과 사용 상황이 포함된 보조문구 1~2문장
- 실제 제품 화면 또는 결과 화면
- 가격과 주 CTA

제목 공식 예시:

- `[반복 작업]을 [짧은 방식]으로 끝내는 [제품 유형]`
- `[대상 사용자]를 위한 [핵심 결과] [제품 유형]`
- `[기존 도구]에서 바로 쓰는 [문제 해결]`

## 2. 문제 공감

구매자가 현재 겪는 불편 3개를 실제 상황 언어로 쓴다. 제품을 아직 언급하지 않아도 자신의 문제라고 느껴야 한다.

## 3. 핵심 변화

도입 전과 후를 비교한다. 수치가 없으면 시간 절감 수치를 만들지 말고 단계 수, 화면 이동, 수동 작업의 변화로 설명한다.

## 4. 핵심 효익 3개

각 항목은 다음 형식을 따른다.

1. 효익 제목
2. 사용 상황 설명
3. 이를 만드는 기능
4. 실제 화면 또는 데모 증거

## 5. 기능과 사용 흐름

- 기능을 나열하지 말고 시작부터 결과까지 3~5단계로 보여준다.
- 고급 기능은 기본 흐름 뒤에 배치한다.
- 설정이 필요하면 예상 소요와 선행 조건을 밝힌다.

## 6. 적합·부적합 사용자

`이런 분께 적합합니다`와 `이 경우에는 먼저 문의하세요`를 함께 쓴다. 부적합 조건 공개는 환불과 불만을 줄인다.

## 7. 호환성과 제공 범위

- 지원 플랫폼과 버전
- 필수 플러그인·모듈·권한
- 제공 파일과 문서
- 설치·업데이트 방식
- 데이터 저장 위치와 외부 전송 여부
- 라이선스 사이트 수와 상업 이용 범위
- 기술지원 채널과 기간

## 8. 가격 제시

가격은 개발 시간이나 기능 개수보다 구매자가 대체하게 되는 작업·도구·위험과 연결한다. 허위 정상가, 상시 할인, 근거 없는 긴급성을 쓰지 않는다.

## 9. FAQ

호환성, 설치, 기존 데이터, 속도, 보안·권한, 라이선스, 업데이트, 환불, 지원을 우선한다. 답을 모르면 정책을 만들지 말고 확인 필요로 남긴다.

## 10. 최종 CTA

핵심 결과를 한 번 반복하고 다음 행동을 하나로 제시한다. 구매 전 확인이 필요한 상품은 `구매`보다 `호환성 문의`를 우선할 수 있다.

.codex/skills/eond-market-product-writer/references/visual-merchandising.md

# 상품 이미지 머천다이징

## 기본 세트

| 순서 | 목적 | 권장 내용 |
|---:|---|---|
| 1 | 목록에서 제품 인지 | 제품 유형, 핵심 결과, 실제 대표 화면 |
| 2 | 문제 공감 | 기존 작업의 불편 3개 또는 전후 비교 |
| 3 | 핵심 효익 | 가장 강한 결과 한 가지와 증거 화면 |
| 4 | 기능 이해 | 주요 기능 3개를 실제 UI 확대 컷으로 설명 |
| 5 | 사용 난이도 해소 | 설치부터 결과까지 3~5단계 |
| 6 | 구매 적합성 | 지원 버전, OS, 브라우저, CMS 호환표 |
| 7 | 신뢰 형성 | 실제 적용 사례, 업데이트 기록, 지원 방식 |
| 8 | 행동 유도 | 제공 범위, 가격, CTA 또는 문의 조건 |

## 작성 형식

각 이미지마다 다음을 적는다.

- `목적`
- `헤드라인`: 모바일에서도 읽히는 짧은 문장
- `보조문구`: 최대 2문장
- `사용 자산`: 파일명, URL, 캡처할 화면
- `구도`: 전체 화면, 확대, 비교, 순서도, 목업 중 하나
- `비율`: 목록용 4:3 또는 1:1, 상세용 16:9 또는 세로형
- `대체텍스트`

## 금지 사항

- 실제 제품에 없는 버튼, 통계, 기능 화면 생성
- 텍스트가 많은 인포그래픽 한 장에 모든 기능 배치
- 작은 캡처 여러 개를 의미 없이 콜라주
- 제품을 식별할 수 없는 분위기용 이미지 단독 사용
- 출처나 사용 권한이 불명확한 경쟁사 이미지 사용

## 자산 우선순위

1. 실제 제품·관리자 화면
2. 실제 사용 결과
3. 데스크톱·태블릿·모바일 목업
4. 기능 흐름도와 호환성 그래픽
5. 생성한 개념 배경 또는 장식 요소

.codex/skills/eond-market-product-writer/references/eond-market-fields.md

# 이온디마켓 등록 출력

## 콘텐츠 필드

```yaml
title: 목록과 상세에 사용할 상품명
summary: 80~140자 구매자 중심 요약
content: 상세페이지 HTML 또는 Markdown
tags: 고객 문제 태그와 기술 태그
thumbnail_brief: 대표이미지 제작 지시
seo_title: 검색 의도와 제품 유형을 포함한 제목
seo_description: 대상·문제·결과가 포함된 설명
```

## 판매 필드

```yaml
product_type: 실제 DB 허용값
platform: 실제 DB 허용값
sub_type: 실제 DB 허용값
code: 기존 라이선스 제품 코드 또는 확인 필요
price: 원 단위 정수 또는 확인 필요
license_scope: 설치 가능 사이트·기기 수
compatibility: CMS·OS·브라우저·런타임 버전
included_files: 제공 파일과 문서
support_policy: 지원 채널·범위·기간
update_policy: 업데이트 제공 기준
demo_url: 실제 동작 확인 URL
market_url: 공개 구매 URL
```

## 등록 안전 규칙

- `SaleProduct.price`가 가격의 우선 진실값이다. 본문 문자열 가격만 바꾸지 않는다.
- 기존 상품은 `document_srl`, `code`, 구매·라이선스 연결을 보존한다.
- 무료, 유료, 준비 중을 임의로 바꾸지 않는다.
- 등록 API나 관리자 스키마를 실제 코드에서 확인한 뒤 payload를 만든다.