포트폴리오 사례 작성 스킬 (eond-portfolio-case-writer) — 구축 사례 정리

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

이온디가 제작한 웹사이트, WordPress·Rhymix·XE·eondcms 구축, 쇼핑몰·커뮤니티·ERP·업무 시스템, 웹앱, 모바일앱, 데스크탑앱, 브라우저 확장, AI 자동화, 서버 이전·운영, 디자인 프로젝트를 포트폴리오 사례로 기획하고 작성할 때 사용한다. 사용자가 "포트폴리오 글 써줘", "작업 사례 정리", "프로젝트 소개", "구축 사례 페이지", "내가 만든 것을 보기 좋게 정리", "성과와 역할을 설명", "포트폴리오 대표이미지·목업 기획", "기존 포트폴리오 개선"을 요청하면 전문 에이전시 기획자 관점으로 문제·제약·해결·역할·결과·증거·관련 서비스 CTA와 이미지 스토리보드를 만든다.

사용 방법

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

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

연관스킬

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

원본 위치

.codex/skills/eond-portfolio-case-writer/SKILL.md

SKILL.md

---
name: eond-portfolio-case-writer
description: 이온디가 제작한 웹사이트, WordPress·Rhymix·XE·eondcms 구축, 쇼핑몰·커뮤니티·ERP·업무 시스템, 웹앱, 모바일앱, 데스크탑앱, 브라우저 확장, AI 자동화, 서버 이전·운영, 디자인 프로젝트를 포트폴리오 사례로 기획하고 작성할 때 사용한다. 사용자가 "포트폴리오 글 써줘", "작업 사례 정리", "프로젝트 소개", "구축 사례 페이지", "내가 만든 것을 보기 좋게 정리", "성과와 역할을 설명", "포트폴리오 대표이미지·목업 기획", "기존 포트폴리오 개선"을 요청하면 전문 에이전시 기획자 관점으로 문제·제약·해결·역할·결과·증거·관련 서비스 CTA와 이미지 스토리보드를 만든다.
---

# Eond Portfolio Case Writer

## 목표

작업물을 단순 갤러리가 아니라 `이온디가 비슷한 문제를 해결할 수 있다는 증거`로 만든다. 독자가 프로젝트를 빠르게 이해하고 자신의 상황과 연결해 제작 문의 또는 관련 제품 탐색으로 이동하게 한다.

## 작업 원칙

1. 예쁜 화면보다 고객 문제, 제약, 판단, 구현과 결과를 우선한다.
2. 이온디의 역할과 외부 협업자의 역할을 구분한다.
3. 공개 가능한 사실만 쓰고 고객명·데이터·성과 수치의 공개 권한을 확인한다.
4. 수치가 없으면 만들지 않는다. 대신 변경된 흐름, 기능, 운영 방식과 산출물로 결과를 증명한다.
5. 실제 화면을 우선한다. 생성 이미지로 존재하지 않는 결과물이나 고객 화면을 만들지 않는다.
6. 기술 스택은 자랑 목록이 아니라 왜 그 선택이 문제 해결에 적합했는지 설명한다.
7. 각 사례는 가장 가까운 제작 서비스와 관련 마켓 제품으로 연결한다.

## 시작 절차

1. 프로젝트 URL, 저장소, 기존 글, 계약·작업 메모, 스크린샷, 릴리스 기록을 조사한다.
2. 고객 프로젝트, 자체 제품, 실험·프로토타입, 운영·개선 사례 중 하나로 분류한다.
3. [case-study-framework.md](references/case-study-framework.md)의 입력 항목을 채운다.
4. 사실을 `확인`, `추론`, `공개 전 확인`으로 분리한다.
5. 비공개 정보나 수치가 핵심이면 익명화 방식만 정하고 임의 보완하지 않는다.

## 사례 기획

다음 질문에 한 문장씩 답한 뒤 본문을 쓴다.

1. 누가 어떤 상황에서 무엇이 필요했는가
2. 기존 방식의 가장 큰 문제는 무엇이었는가
3. 일정, 데이터, CMS, 기기, 예산 등 핵심 제약은 무엇이었는가
4. 이온디는 어떤 판단과 구현을 담당했는가
5. 사용자는 무엇을 더 쉽게 할 수 있게 되었는가
6. 이를 입증하는 실제 화면·기능·운영 결과는 무엇인가
7. 비슷한 방문자는 어떤 서비스로 문의해야 하는가

## 작성 모드

- `full`: 사례 전략, 전체 원고, 이미지 스토리보드, SEO, 등록 필드를 작성한다.
- `brief`: 목록 카드용 제목, 요약, 대표이미지 브리프만 만든다.
- `rewrite`: 기존 글의 사실을 보존하며 문제 해결형 사례로 재구성한다.
- `audit`: 맥락, 역할, 증거, 시각 자료, CTA 누락을 점수화한다.
- `batch`: 여러 프로젝트를 공통 템플릿으로 정리하되 각 사례의 문제와 결과를 구별한다.

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

## 기본 출력

1. `사례 진단`: 프로젝트 유형, 대상 독자, 핵심 문제, 한 줄 결과
2. `사실 상태`: 확인, 추론, 공개 전 확인
3. `목록 카드`: 제목, 80~140자 요약, 카테고리, 태그
4. `상세 원고`: [case-study-framework.md](references/case-study-framework.md) 순서
5. `이미지 스토리보드`: [portfolio-visual-story.md](references/portfolio-visual-story.md) 기준
6. `SEO·공유`: 제목, 설명, 대표이미지 대체텍스트
7. `관련 전환`: 관련 제작 서비스, 제품, 주 CTA와 보조 CTA
8. `등록 필드`: [eond-portfolio-fields.md](references/eond-portfolio-fields.md) 기준
9. `품질 점검`: 아래 점수와 미달 항목

## 품질 게이트

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

- 맥락: 누가 왜 필요했는지 이해되는가
- 전문성: 제약과 판단, 이온디 역할이 구체적인가
- 결과: 전후 변화가 사실에 근거해 보이는가
- 시각 증거: 핵심 화면과 반응형·기능 흐름이 보이는가
- 전환: 유사 고객이 다음 행동을 알 수 있는가

## 이미지 작업

- 실제 URL이 있으면 데스크톱·태블릿·모바일 화면을 캡처한다.
- 대표이미지 제작과 Rhymix 첨부 연결은 `portfolio-thumbnail-maker`를 사용한다.
- 캡처 전에 개인정보, 관리자 정보, API 키, 고객 데이터를 가린다.
- 이미지 생성은 배경·설명용 도식에만 사용하고 실제 결과 화면을 대체하지 않는다.

## 연계 스킬

- 포트폴리오와 함께 판매할 제품이 있으면 `eond-market-product-writer`로 별도 상품 페이지를 만든다.
- 게시판 등록 payload가 필요하면 `contentsmaker`의 실제 API 규칙을 확인한다.
- 사용자가 명시적으로 등록·공개를 요청하지 않으면 초안과 이미지 계획만 만든다.

참고 리소스

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

.codex/skills/eond-portfolio-case-writer/references/case-study-framework.md

# 포트폴리오 사례 프레임워크

## 입력 항목

- 프로젝트명과 공개 가능 고객명
- 프로젝트 유형과 공개 URL
- 기간과 공개 가능 연도
- 대상 사용자
- 시작 전 문제
- 핵심 요구사항과 제약
- 이온디 담당 범위
- 주요 판단과 구현
- 기술 스택과 선택 이유
- 결과와 확인 가능한 지표
- 실제 화면·문서·후기
- 관련 서비스·제품 링크

## 상세 원고 순서

### 1. 첫 화면

- 결과 또는 프로젝트 유형이 드러나는 제목
- 대상, 문제, 결과를 담은 2문장 요약
- 가장 강한 실제 화면
- 역할·분야·연도 메타
- 관련 서비스 문의 CTA

### 2. 프로젝트 배경

고객 또는 사용자가 어떤 상황에 있었는지 설명한다. 고객명을 공개할 수 없으면 업종과 규모를 과도하게 특정하지 않는 범위에서 익명화한다.

### 3. 해결해야 했던 문제

문제 2~4개를 실제 업무·사용 흐름으로 적는다. `사이트가 필요했다`보다 왜 기존 방식으로는 부족했는지 쓴다.

### 4. 제약과 판단

레거시 데이터, 기존 CMS, 운영 인력, 일정, 기기, 권한, 성능 등 난점을 제시하고 어떤 우선순위로 해결했는지 설명한다.

### 5. 이온디의 역할

기획, 정보구조, 디자인, 프론트엔드, 백엔드, CMS, 이전, 배포, 운영 중 실제 담당한 범위만 쓴다. 외부 디자인이나 고객 제공 콘텐츠를 이온디 작업으로 표현하지 않는다.

### 6. 핵심 구현

3~5개 기능을 `문제 → 선택 → 구현 → 사용자 변화 → 화면 증거`로 설명한다.

### 7. 결과

검증된 수치가 있으면 기준 기간과 출처를 붙인다. 수치가 없으면 다음처럼 관찰 가능한 변화로 쓴다.

- 여러 도구가 한 화면으로 통합됨
- 관리자가 개발자 없이 수정할 수 있게 됨
- 모바일에서도 핵심 업무를 완료할 수 있게 됨
- 레거시 게시글·회원 데이터를 유지하며 전환함

### 8. 기술과 운영

기술 목록은 짧게 쓰고 선택 이유, 유지관리 방식, 확장 가능성을 설명한다.

### 9. 마무리 전환

비슷한 문제를 가진 방문자가 이동할 제작 서비스, 관련 제품, 상담 CTA를 제시한다. 사례와 무관한 모든 서비스를 나열하지 않는다.

.codex/skills/eond-portfolio-case-writer/references/portfolio-visual-story.md

# 포트폴리오 이미지 스토리

## 권장 순서

| 순서 | 전달할 내용 | 권장 자산 |
|---:|---|---|
| 1 | 프로젝트 정체성과 완성도 | 대표 화면 또는 desktop·tablet·mobile 목업 |
| 2 | 시작 전 문제 | 기존 화면, 수작업 흐름, 문제 다이어그램 |
| 3 | 정보 구조와 해결 방향 | 사이트맵, 사용자 흐름, 구조도 |
| 4 | 핵심 기능 1 | 실제 화면 전체와 핵심 영역 확대 |
| 5 | 핵심 기능 2 | 전후 비교 또는 작업 순서 |
| 6 | 반응형·접근성 | 같은 기능의 desktop·mobile 비교 |
| 7 | 운영·관리 | 관리자 화면, 자동화, 배포 구조 |
| 8 | 결과와 다음 행동 | 확인된 결과, 관련 서비스 CTA |

## 이미지별 출력

- `목적`
- `캡처 URL 또는 파일`
- `viewport`: desktop, tablet, mobile
- `캡처 상태`: 로그인, 데이터, 스크롤 위치, 열어야 할 메뉴
- `헤드라인과 캡션`
- `민감정보 마스킹`
- `비율과 배치`
- `대체텍스트`

## 대표이미지 규칙

- 목록에서 작은 크기로 보아도 프로젝트 유형이 구분되어야 한다.
- 텍스트만 있는 카드보다 실제 완성 화면을 우선한다.
- 여러 기기를 합성할 때 동일 화면의 단순 반복 대신 각 기기의 핵심 사용 장면을 보여준다.
- URL 캡처가 불가능한 데스크탑앱은 실제 앱 창과 OS 맥락을 함께 보여준다.
- 브라우저 확장은 팝업만 확대하지 말고 실제 웹페이지에서 작동하는 장면을 포함한다.
- CMS 모듈은 사용자 화면과 관리자 설정 화면을 짝으로 보여준다.

## 금지 사항

- 고객 승인 없는 로고·매출·내부 데이터 공개
- 생성한 가상 화면을 실제 구축 화면으로 표현
- 작은 스크린샷을 과도하게 겹친 목업
- 화면과 무관한 스톡 이미지로 대표이미지 대체
- 이미지 안에 본문 전체를 넣는 과밀 구성

.codex/skills/eond-portfolio-case-writer/references/eond-portfolio-fields.md

# 이온디 포트폴리오 등록 출력

## 기본 필드

```yaml
mid: portfolio
title: 결과 또는 프로젝트 유형이 드러나는 제목
summary: 대상·문제·결과를 포함한 80~140자 설명
content: 사례 상세 HTML 또는 Markdown
category: website | rhymix | wordpress | app | ai 등 실제 게시판 분류
tags: 업종, 플랫폼, 해결 문제, 담당 범위
thumbnail_url: 실제 대표이미지 공개 URL
pending_file_srls: 업로드 후 연결할 첨부 식별자
status: PUBLIC 또는 초안 상태
visibility: 공개 범위
```

## 사례 메타

```yaml
project_type: 고객 구축 | 자체 제품 | 프로토타입 | 운영 개선
client_display: 공개 고객명 또는 익명 표기
year: 공개 가능한 연도
duration: 공개 가능한 기간
role: 이온디가 실제 담당한 범위
platform: WordPress | Rhymix | eondcms | Web | App | Desktop | Extension
live_url: 공개 가능한 실제 URL
related_service_url: 가장 가까운 제작 의뢰 URL
related_product_url: 연결되는 마켓 제품 URL
```

## 등록 안전 규칙

- 실제 게시판의 `module_srl`, 카테고리와 `extra_vars` 구조를 등록 전에 확인한다.
- 기존 문서 수정 시 `document_srl`, 첨부, 조회·댓글·SEO URL을 보존한다.
- 운영 게시물 이미지는 Rhymix 첨부 경로와 본문 첫 이미지 연결 규칙을 따른다.
- 공개 권한을 확인하지 못한 고객명과 성과는 초안에 `공개 전 확인`으로 남긴다.