[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PDJR1Y9BAM48RDKRQHK5MQ":3,"skill-same:01M6PDJR1Y9BAM48RDKRQHK5MQ":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":42,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6PDJR1Y9BAM48RDKRQHK5MQ","release-showcase",null,"정식 릴리스의 변경을 이전·이후 스크린샷, 클릭 흐름 녹화 영상, 비교·단계·탭·흐름도 같은 HTML 컴포넌트로 보여 주는 파일 하나짜리 릴리스 문서를 만든다. 텍스트뿐인 릴리스 노트로는 어떤 UX가 바뀌었고 새 기능을 어떻게 쓰는지 감이 안 올 때 쓴다. '릴리스 노트 문서 만들어 줘', '릴리스 쇼케이스', '이번 배포 변경사항 정리해서 공유', '릴리즈 노트 HTML', '변경사항을 화면으로 보여 주는 문서', '업데이트 소개 페이지', 'what's new 페이지', 'release notes with screenshots', 'changelog page', '배포 공지 자료'처럼 버전 태그 사이의 변경을 팀·고객에게 시각적으로 알릴 때 반드시 사용한다. git 태그로 릴리스하는 저장소라면 웹·데스크톱·모바일 어느 앱이든 쓴다. 커밋 목록만 필요한 CHANGELOG.md 갱신, 릴리스 태그·배포 자체, 마케팅 영상 제작에는 쓰지 않는다.","douinc\u002Fagent-skills","douinc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F104253814?v=4","01M6PDGX2D777TNA7NETDKDHCW","dou inc.","01M6PDGX6QMFW72GNMX59GKN6P",1,"MIT","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"release showcase","showcase","release","page","release notes","with","notes","changelog","git","html","screenshots","2026-11-10 10:12:30",false,"---\nname: release-showcase\ndescription: \"정식 릴리스의 변경을 이전·이후 스크린샷, 클릭 흐름 녹화 영상, 비교·단계·탭·흐름도 같은 HTML 컴포넌트로 보여 주는 파일 하나짜리 릴리스 문서를 만든다. 텍스트뿐인 릴리스 노트로는 어떤 UX가 바뀌었고 새 기능을 어떻게 쓰는지 감이 안 올 때 쓴다. '릴리스 노트 문서 만들어 줘', '릴리스 쇼케이스', '이번 배포 변경사항 정리해서 공유', '릴리즈 노트 HTML', '변경사항을 화면으로 보여 주는 문서', '업데이트 소개 페이지', 'what's new 페이지', 'release notes with screenshots', 'changelog page', '배포 공지 자료'처럼 버전 태그 사이의 변경을 팀·고객에게 시각적으로 알릴 때 반드시 사용한다. git 태그로 릴리스하는 저장소라면 웹·데스크톱·모바일 어느 앱이든 쓴다. 커밋 목록만 필요한 CHANGELOG.md 갱신, 릴리스 태그·배포 자체, 마케팅 영상 제작에는 쓰지 않는다.\"\nmetadata:\n  author: develinu\n  version: \"1.2.0\"\n---\n\n# release-showcase — 화면으로 보여 주는 릴리스 문서\n\n릴리스 노트가 커밋 제목 목록이면 읽는 사람은 무엇이 어떻게 바뀌었는지, 자기가 무엇을 해야 하는지 알 수 없다. 이 스킬은 **사용자가 겪는 변화 단위**로 묶은 이야기(`story.json`)에 저장소가 이미 가진 시각 자료를 붙여, 메신저에 그대로 올릴 수 있는 HTML 한 파일을 만든다.\n\n- 화면은 **지어내지 않는다.** 이전·이후 태그 시점에 커밋된 스크린샷(골든)을 `git show`로 꺼내고, 영상은 태그 시점 코드를 띄워 녹화한다.\n- **실데이터 위주로 보여 준다.** 사용자가 실제로 넣을 자료(실제 서류·기록·사진, 식별 정보는 가림)와 그 자료로 제품이 실제로 낸 결과가 \"합성 예시\"보다 훨씬 잘 읽힌다. 테스트 데이터는 실제 자료를 구할 수 없을 때만 쓰고, 그 사실을 팀 참고에 적는다(아래 \"실데이터\").\n- 글 품질은 손으로 기억하지 않는다. `check`가 기계로 보고(TODO·없는 그림·미배포 PR·앱에 없는 메뉴 이름·쓰지 않기로 한 말·어투), `verify`가 데스크톱·모바일 폭으로 열어 넘침·빈 이미지·영상·상호작용을 본다.\n- 결과물: `\u003Cstories>\u002F\u003C태그>\u002F\u003C태그>.html` (이미지·영상이 base64로 들어 있어 첨부 하나로 끝난다).\n\n경로 표기: `\u003CSKILL_DIR>`는 이 SKILL.md가 있는 폴더다. 명령은 대상 저장소 안에서 `python3 \u003CSKILL_DIR>\u002Fscripts\u002Fshowcase.py …`로 실행한다(아래에서는 `showcase`로 줄인다).\n\n## 진행 체크리스트\n\n아래를 할 일 목록으로 만들고 차례로 닫는다. 게이트를 통과하지 못하면 다음 단계로 가지 않는다.\n\n- [ ] 0 준비 — 설정 파일·도구\n- [ ] 1 범위 — 이번 태그와 기준 태그\n- [ ] 2 재료 — 화면 후보·PR 본문 읽기\n- [ ] 3 story.json 쓰기 + 실데이터 고르기\n- [ ] 4 clips.json 쓰기 (녹화할 수 있는 앱만)\n- [ ] 5 `check` 오류 0\n- [ ] 6 `build --record --verify` 통과\n- [ ] 7 남긴 화면을 직접 열어 보기\n- [ ] 8 한국어 문장 다듬기\n- [ ] 9 보고·공유\n\n## 0. 준비\n\n- 저장소 루트에 `.release-showcase\u002Fconfig.json`이 있는지 본다. 없으면 `references\u002Fconfig.md`대로 만든다. 앱마다 태그 접두사·소스 경로·스크린샷 폴더·화면 문구 경로·녹화 방법을 적는다. 저장소에 프로젝트 전용 스킬이나 CLAUDE.md가 있으면 거기 적힌 릴리스 규칙(기준 태그 고르는 법, 쓰지 않는 말)을 먼저 읽는다.\n- 필요한 것: git, Python 3.10+, `gh`(PR 본문·릴리스 파일 — 없으면 그 부분만 빠진다), Node 18+ 또는 bun(녹화·검수), ffmpeg + libx264(영상 녹화·MP4 인코딩 — 없으면 흐릿한 WebM으로 물러나 Safari·iPhone에서 재생되지 않는다). Playwright는 프로젝트의 `node_modules`에 있으면 그것을, 없으면 `~\u002F.cache\u002Frelease-showcase`에 한 번 설치한다.\n- `git fetch --tags`로 태그를 최신으로 맞춘다.\n\n## 1. 범위\n\n```bash\nshowcase init \u003C이번 태그>            # 기준 태그를 골라 story.json 초안과 .media\u002Fbrief.md를 만든다\nshowcase init \u003C이번 태그> --base \u003C태그>\n```\n\n- **기준(base)은 사용자가 직전에 실제로 쓰던 정식 버전이다.** staging·beta·rc 태그는 기준이 아니다. 며칠 만에 핫픽스가 이어졌으면(예: 1.4.4 → 다음 날 1.4.5) 그 사슬은 건너뛰고 그 앞 버전을 기준으로 둔다. `init`이 이 규칙으로 고른 이유를 출력하니 맞는지 확인한다.\n- 브랜치가 갈라져 있어도(stable·main, cherry-pick) 변경 목록은 PR 번호로 가르므로 이중 계산이 없다.\n\n게이트: 기준 태그가 정식 태그이고, 고른 이유를 설명할 수 있다.\n\n## 2. 재료\n\n- `.media\u002Fbrief.md`를 읽는다: 범위, 새로 생기거나 바뀐 화면 목록, 새 기능 PR 본문 요약, 고친 것 목록.\n- **새 화면**은 하이라이트 후보, **바뀜**은 대부분 공통 요소(로고·문구) 변화라 작은 카드(minor) 후보다. `showcase goldens \u003C태그>`로 다시 볼 수 있다.\n- 하이라이트에 쓸 PR은 `gh pr view N`으로 본문 전체를 읽고 **왜** 바꿨는지, 사용자 흐름이 어떻게 달라지는지 확인한다. 제목만 보고 쓰지 않는다.\n- 같은 기간 서버 변경 중 이 앱 사용자가 느끼는 것(품질·한도·속도)은 팀 참고(notes) 후보다.\n- 보여 줄 화면이 저장소에 없으면 먼저 스크린샷 테스트(골든)를 더하는 것이 정석이다. 급하면 직접 찍은 그림을 `.media\u002F`에 두고 `local`로 쓴다(references\u002Fstory.md).\n\n## 3. story.json\n\n형식은 `references\u002Fstory.md`, 문장 기준과 좋은·나쁜 예는 `references\u002Fwriting.md`를 **먼저 읽고** 쓴다. 요점:\n\n- 하이라이트 3~6개. 각각 `lead`(예전에는 어땠고 지금은 어떤지 두 문장), `points`(사실만 — 숫자·조건·화면 문구), `how`(따라 할 순서, 메뉴 경로는 앱 문구 그대로), `prs`, `media`.\n- **하이라이트마다 시각 자료가 하나는 있다.** 바뀐 화면은 `compare`, 여러 단계 흐름은 `video`+`steps`, 상태가 여럿이면 `tabs`, 절차가 바뀌었으면 `flow`.\n- `metrics`(선택): 좋아진 정도를 **잰 숫자**가 있으면 맨 위에 항목별로 요약한다(무엇을 쟀는지, 이전 → 이후). 잰 값만 쓰고, 어떻게 쟀는지는 `caption`과 팀 참고에 적는다. 숫자가 없는 릴리스에는 넣지 않는다.\n- `audience`: 독자별(처음 쓰는 분 \u002F 이미 쓰던 분 \u002F 지원·영업 등) 카드에 **할 일이 있는지 없는지를 먼저** 말한다.\n- 태그에 없는 기능은 쓰지 않는다 — 머지됐어도 이 태그에 안 들어갔으면 다음 문서 몫이다. `check`가 하이라이트의 PR이 태그에 있는지 본다.\n\n## 3-1. 실데이터\n\n하이라이트마다 \"사용자가 넣는 것 → 제품이 내는 것\"이 있으면 그 둘을 실제 사례로 보여 줄 수 있는지 먼저 본다(예: 첨부 기능이면 실제 검사지·기록 화면 사진과 그걸로 만든 실제 결과).\n\n- 자료는 사용자·팀에게 받는다. 받은 자료는 **식별 정보(이름·등록번호·생년월일·연락처·기관명, 뒷면 비침)를 가린 사본**만 쓴다. 가린 사본을 직접 열어 남은 것이 없는지 확인한다.\n- 실제 자료와 그 결과는 **커밋하지 않는다** — `\u003Cstory>\u002F.media\u002Freal\u002F`(gitignore)에 둔다. `check`는 clips가 가리키는 파일이 없으면 오류를 내므로, 다른 사람이 다시 만들 때는 자료를 받아 같은 자리에 둔다.\n- 결과도 지어내지 않는다. 제품의 실제 처리(서비스 함수·API)를 그 자료로 한 번 돌려 받은 출력을 쓴다. 이때 관측 도구(추적·로그)에 자료 원문이 남지 않게 끈다.\n- 녹화 하네스가 목 응답을 쓰면 clip의 `initScript`·`initData`로 그 응답만 실제 결과로 바꾸고, 자료는 `upload` 단계로 넣는다(references\u002Fstory.md \"clips.json\").\n- 팀 참고(notes)에 어떤 화면이 실데이터이고(무엇을 가렸는지), 어떤 화면이 테스트 데이터인지 적는다. 실제 처리 시간을 영상에서 줄였으면 그것도 적는다.\n\n## 4. clips.json (녹화)\n\n설정에 `record`가 있는 앱만 한다. 새 기능의 대표 흐름 1~2개를 30초 안팎으로 고른다. 단계는 화면의 텍스트·버튼 이름으로 찾는다(형식은 references\u002Fstory.md \"clips.json\").\n\n- 단계 이름은 태그 시점 소스에서 확인한다(`git grep -n \"\u003C문구>\" \u003C태그> -- \u003CuiDir>`). 실패하면 `.media\u002F\u003Cid>.fail.png`에 그 순간 화면이 남으니 열어 보고 고친다.\n- 녹화할 수 없는 앱(모바일 네이티브 등)은 시뮬레이터 녹화 파일을 `.media\u002F\u003Cid>.webm`(또는 `.mp4`)으로 넣고 챕터를 `.media\u002F\u003Cid>.chapters.json`에 적는다. 영상 없이 `steps`·`tabs`만으로도 된다.\n\n## 5. 검사\n\n```bash\nshowcase check \u003C태그>\n```\n\n- `✗` 오류는 전부 고친다. 빌드는 오류가 있으면 멈춘다.\n- `△` 경고는 고치거나, 그대로 둘 이유를 보고에 적는다. 특히 \"앱 소스에서 찾지 못했어요\"는 메뉴 이름을 지어냈다는 뜻일 때가 많다.\n- `·` 범위 안내의 \"글에 안 쓴 새 기능 N건\"을 훑어 빠뜨린 큰 변화가 없는지 본다.\n\n게이트: 오류 0, 남긴 경고마다 이유가 있다.\n\n## 6. 빌드·검수\n\n```bash\nshowcase build \u003C태그> --record --verify   # 처음: 태그 worktree에서 녹화 → HTML → 검수\nshowcase build \u003C태그> --verify            # 글만 고친 뒤: 녹화본 재사용, 몇 초\nshowcase verify \u003C태그>                    # 만들어 둔 HTML만 다시 검수\n```\n\n- `--record`는 태그 시점 코드를 임시 worktree로 꺼내 설치·실행하고 녹화한 뒤 지운다. 작업 중인 브랜치로 녹화하면 아직 나가지 않은 화면이 섞인다.\n- `--verify`는 1280px·400px로 열어 가로 넘침, 빈 이미지, 재생 안 되는 영상, 누르지 않았는데 틀어지는 영상, 영상 길이를 넘는 챕터, 반응 없는 비교·단계·탭·챕터·크게 보기, 작게 열리는 크게 보기, 콘솔 오류를 잡고 `.media\u002Freview\u002F`에 화면을 남긴다.\n\n게이트: 검수 통과.\n\n## 7. 눈으로 보기\n\n`.media\u002Freview\u002F`의 `desktop-*`·`mobile-*` PNG를 **직접 열어** 본다. 기계가 못 잡는 것: 글과 그림이 맞지 않음, 비교의 이전·이후가 바뀐 점을 못 보여 줌, 영상이 너무 길거나 핵심 전에 끝남, 영상·그림 속 제품 화면이 틀에 비해 작음, 모바일에서 한 줄에 한두 글자씩 끊기는 제목, 화면 속 자료가 \"합성·테스트\"처럼 보여 실제 쓰임이 안 그려짐(실데이터로 바꿀 수 있는지 다시 본다), 가리지 못한 식별 정보.\n\n## 8. 한국어 문장\n\n`check`가 `.media\u002Fcopy.txt`에 사람이 읽는 글만 모아 둔다. `ko-natural` 스킬이 있으면 그 린트로 한 번 돌리고(`--register casual`), 없으면 references\u002Fwriting.md 기준으로 직접 다듬는다. 고친 뒤 `build`를 다시 한다.\n\n## 9. 보고·공유\n\n- 사용자에게: 결과 HTML 절대 경로, 범위(기준 → 이번), 하이라이트 목록, 남긴 경고와 이유, 영상이 없는 하이라이트와 그 이유.\n- 공유는 결과 HTML 한 파일을 팀 메신저에 첨부하거나 GitHub Release 파일로 올린다. 프로젝트에 정해진 공유 경로가 있으면 그것을 따른다.\n- `.media\u002F`(녹화본·재료·검수 화면)와 결과 HTML은 커밋하지 않는다(`.gitignore`). 커밋하는 것은 `config.json`, `story.json`, `clips.json`뿐이다.\n\n## 함정\n\n- **실데이터는 가린 사본만, 저장소 밖에만.** 가리지 않은 원본이나 실데이터를 커밋하지 않는다. 골든·녹화에 우연히 실제 사용자 정보가 보이면 그 화면은 싣지 않는다.\n- 스크린샷 안의 버전 표기·날짜가 테스트 고정값일 수 있다. 그렇다면 설정 `notes`에 한 줄 적어 팀 참고에 남긴다.\n- 비교(`compare`)는 같은 파일 이름이라도 두 태그에서 내용이 같으면 `check`가 막는다 — 바뀌지 않은 화면은 `image`로.\n- 녹화에서 두 번째 영상이 멈추는 일을 막으려고 영상마다 별도 프로세스로 찍는다. 녹화가 느리면 영상 수를 줄인다.\n- 영상은 장치 픽셀(`record.scale`) 그대로 찍는다(Chrome screencast + ffmpeg). Playwright 기본 녹화는 배율을 무시해 제품 화면이 틀 왼쪽 위에 작게 찍히므로 쓰지 않는다 — ffmpeg가 없을 때만 그쪽으로 물러난다(흐릿함).\n- 영상은 **멈춘 채로 시작한다.** 읽는 사람이 재생 단추나 챕터를 눌러야 틀어지고, 그 전에는 첫 장면이 보인다(`poster`를 주지 않으면 ffmpeg로 첫 장면을 뽑는다). 첫 장면이 빈 로딩 화면이면 `poster`에 내용이 보이는 그림을 준다.\n- 그림을 누르면 화면에 맞춰 가장 크게 열린다(작은 그림은 1.5배까지). 화면보다 큰 그림은 한 번 더 누르면 원래 크기로 넓어져 스크롤해 볼 수 있다.\n- 영상은 **H.264 MP4**로 싣고 페이지가 열릴 때 Blob 주소로 바꿔 튼다. WebM은 Safari·iPhone이 못 틀고, `data:` 주소 영상은 Safari가 열지 못한다. `verify`는 영상을 실제로 틀어 시간이 흐르는지 본다.\n- 결과 HTML이 10MB를 넘으면 메신저 첨부 한도에 걸린다. 영상을 줄이거나(30초 안팎) `steps`로 바꾼다.\n","# release-showcase — 화면으로 보여 주는 릴리스 문서\n\n릴리스 노트가 커밋 제목 목록이면 읽는 사람은 무엇이 어떻게 바뀌었는지, 자기가 무엇을 해야 하는지 알 수 없다. 이 스킬은 **사용자가 겪는 변화 단위**로 묶은 이야기(`story.json`)에 저장소가 이미 가진 시각 자료를 붙여, 메신저에 그대로 올릴 수 있는 HTML 한 파일을 만든다.\n\n- 화면은 **지어내지 않는다.** 이전·이후 태그 시점에 커밋된 스크린샷(골든)을 `git show`로 꺼내고, 영상은 태그 시점 코드를 띄워 녹화한다.\n- **실데이터 위주로 보여 준다.** 사용자가 실제로 넣을 자료(실제 서류·기록·사진, 식별 정보는 가림)와 그 자료로 제품이 실제로 낸 결과가 \"합성 예시\"보다 훨씬 잘 읽힌다. 테스트 데이터는 실제 자료를 구할 수 없을 때만 쓰고, 그 사실을 팀 참고에 적는다(아래 \"실데이터\").\n- 글 품질은 손으로 기억하지 않는다. `check`가 기계로 보고(TODO·없는 그림·미배포 PR·앱에 없는 메뉴 이름·쓰지 않기로 한 말·어투), `verify`가 데스크톱·모바일 폭으로 열어 넘침·빈 이미지·영상·상호작용을 본다.\n- 결과물: `\u003Cstories>\u002F\u003C태그>\u002F\u003C태그>.html` (이미지·영상이 base64로 들어 있어 첨부 하나로 끝난다).\n\n경로 표기: `\u003CSKILL_DIR>`는 이 SKILL.md가 있는 폴더다. 명령은 대상 저장소 안에서 `python3 \u003CSKILL_DIR>\u002Fscripts\u002Fshowcase.py …`로 실행한다(아래에서는 `showcase`로 줄인다).\n\n## 진행 체크리스트\n\n아래를 할 일 목록으로 만들고 차례로 닫는다. 게이트를 통과하지 못하면 다음 단계로 가지 않는다.\n\n- [ ] 0 준비 — 설정 파일·도구\n- [ ] 1 범위 — 이번 태그와 기준 태그\n- [ ] 2 재료 — 화면 후보·PR 본문 읽기\n- [ ] 3 story.json 쓰기 + 실데이터 고르기\n- [ ] 4 clips.json 쓰기 (녹화할 수 있는 앱만)\n- [ ] 5 `check` 오류 0\n- [ ] 6 `build --record --verify` 통과\n- [ ] 7 남긴 화면을 직접 열어 보기\n- [ ] 8 한국어 문장 다듬기\n- [ ] 9 보고·공유\n\n## 0. 준비\n\n- 저장소 루트에 `.release-showcase\u002Fconfig.json`이 있는지 본다. 없으면 `references\u002Fconfig.md`대로 만든다. 앱마다 태그 접두사·소스 경로·스크린샷 폴더·화면 문구 경로·녹화 방법을 적는다. 저장소에 프로젝트 전용 스킬이나 CLAUDE.md가 있으면 거기 적힌 릴리스 규칙(기준 태그 고르는 법, 쓰지 않는 말)을 먼저 읽는다.\n- 필요한 것: git, Python 3.10+, `gh`(PR 본문·릴리스 파일 — 없으면 그 부분만 빠진다), Node 18+ 또는 bun(녹화·검수), ffmpeg + libx264(영상 녹화·MP4 인코딩 — 없으면 흐릿한 WebM으로 물러나 Safari·iPhone에서 재생되지 않는다). Playwright는 프로젝트의 `node_modules`에 있으면 그것을, 없으면 `~\u002F.cache\u002Frelease-showcase`에 한 번 설치한다.\n- `git fetch --tags`로 태그를 최신으로 맞춘다.\n\n## 1. 범위\n\n```bash\nshowcase init \u003C이번 태그>            # 기준 태그를 골라 story.json 초안과 .media\u002Fbrief.md를 만든다\nshowcase init \u003C이번 태그> --base \u003C태그>\n```\n\n- **기준(base)은 사용자가 직전에 실제로 쓰던 정식 버전이다.** staging·beta·rc 태그는 기준이 아니다. 며칠 만에 핫픽스가 이어졌으면(예: 1.4.4 → 다음 날 1.4.5) 그 사슬은 건너뛰고 그 앞 버전을 기준으로 둔다. `init`이 이 규칙으로 고른 이유를 출력하니 맞는지 확인한다.\n- 브랜치가 갈라져 있어도(stable·main, cherry-pick) 변경 목록은 PR 번호로 가르므로 이중 계산이 없다.\n\n게이트: 기준 태그가 정식 태그이고, 고른 이유를 설명할 수 있다.\n\n## 2. 재료\n\n- `.media\u002Fbrief.md`를 읽는다: 범위, 새로 생기거나 바뀐 화면 목록, 새 기능 PR 본문 요약, 고친 것 목록.\n- **새 화면**은 하이라이트 후보, **바뀜**은 대부분 공통 요소(로고·문구) 변화라 작은 카드(minor) 후보다. `showcase goldens \u003C태그>`로 다시 볼 수 있다.\n- 하이라이트에 쓸 PR은 `gh pr view N`으로 본문 전체를 읽고 **왜** 바꿨는지, 사용자 흐름이 어떻게 달라지는지 확인한다. 제목만 보고 쓰지 않는다.\n- 같은 기간 서버 변경 중 이 앱 사용자가 느끼는 것(품질·한도·속도)은 팀 참고(notes) 후보다.\n- 보여 줄 화면이 저장소에 없으면 먼저 스크린샷 테스트(골든)를 더하는 것이 정석이다. 급하면 직접 찍은 그림을 `.media\u002F`에 두고 `local`로 쓴다(references\u002Fstory.md).\n\n## 3. story.json\n\n형식은 `references\u002Fstory.md`, 문장 기준과 좋은·나쁜 예는 `references\u002Fwriting.md`를 **먼저 읽고** 쓴다. 요점:\n\n- 하이라이트 3~6개. 각각 `lead`(예전에는 어땠고 지금은 어떤지 두 문장), `points`(사실만 — 숫자·조건·화면 문구), `how`(따라 할 순서, 메뉴 경로는 앱 문구 그대로), `prs`, `media`.\n- **하이라이트마다 시각 자료가 하나는 있다.** 바뀐 화면은 `compare`, 여러 단계 흐름은 `video`+`steps`, 상태가 여럿이면 `tabs`, 절차가 바뀌었으면 `flow`.\n- `metrics`(선택): 좋아진 정도를 **잰 숫자**가 있으면 맨 위에 항목별로 요약한다(무엇을 쟀는지, 이전 → 이후). 잰 값만 쓰고, 어떻게 쟀는지는 `caption`과 팀 참고에 적는다. 숫자가 없는 릴리스에는 넣지 않는다.\n- `audience`: 독자별(처음 쓰는 분 \u002F 이미 쓰던 분 \u002F 지원·영업 등) 카드에 **할 일이 있는지 없는지를 먼저** 말한다.\n- 태그에 없는 기능은 쓰지 않는다 — 머지됐어도 이 태그에 안 들어갔으면 다음 문서 몫이다. `check`가 하이라이트의 PR이 태그에 있는지 본다.\n\n## 3-1. 실데이터\n\n하이라이트마다 \"사용자가 넣는 것 → 제품이 내는 것\"이 있으면 그 둘을 실제 사례로 보여 줄 수 있는지 먼저 본다(예: 첨부 기능이면 실제 검사지·기록 화면 사진과 그걸로 만든 실제 결과).\n\n- 자료는 사용자·팀에게 받는다. 받은 자료는 **식별 정보(이름·등록번호·생년월일·연락처·기관명, 뒷면 비침)를 가린 사본**만 쓴다. 가린 사본을 직접 열어 남은 것이 없는지 확인한다.\n- 실제 자료와 그 결과는 **커밋하지 않는다** — `\u003Cstory>\u002F.media\u002Freal\u002F`(gitignore)에 둔다. `check`는 clips가 가리키는 파일이 없으면 오류를 내므로, 다른 사람이 다시 만들 때는 자료를 받아 같은 자리에 둔다.\n- 결과도 지어내지 않는다. 제품의 실제 처리(서비스 함수·API)를 그 자료로 한 번 돌려 받은 출력을 쓴다. 이때 관측 도구(추적·로그)에 자료 원문이 남지 않게 끈다.\n- 녹화 하네스가 목 응답을 쓰면 clip의 `initScript`·`initData`로 그 응답만 실제 결과로 바꾸고, 자료는 `upload` 단계로 넣는다(references\u002Fstory.md \"clips.json\").\n- 팀 참고(notes)에 어떤 화면이 실데이터이고(무엇을 가렸는지), 어떤 화면이 테스트 데이터인지 적는다. 실제 처리 시간을 영상에서 줄였으면 그것도 적는다.\n\n## 4. clips.json (녹화)\n\n설정에 `record`가 있는 앱만 한다. 새 기능의 대표 흐름 1~2개를 30초 안팎으로 고른다. 단계는 화면의 텍스트·버튼 이름으로 찾는다(형식은 references\u002Fstory.md \"clips.json\").\n\n- 단계 이름은 태그 시점 소스에서 확인한다(`git grep -n \"\u003C문구>\" \u003C태그> -- \u003CuiDir>`). 실패하면 `.media\u002F\u003Cid>.fail.png`에 그 순간 화면이 남으니 열어 보고 고친다.\n- 녹화할 수 없는 앱(모바일 네이티브 등)은 시뮬레이터 녹화 파일을 `.media\u002F\u003Cid>.webm`(또는 `.mp4`)으로 넣고 챕터를 `.media\u002F\u003Cid>.chapters.json`에 적는다. 영상 없이 `steps`·`tabs`만으로도 된다.\n\n## 5. 검사\n\n```bash\nshowcase check \u003C태그>\n```\n\n- `✗` 오류는 전부 고친다. 빌드는 오류가 있으면 멈춘다.\n- `△` 경고는 고치거나, 그대로 둘 이유를 보고에 적는다. 특히 \"앱 소스에서 찾지 못했어요\"는 메뉴 이름을 지어냈다는 뜻일 때가 많다.\n- `·` 범위 안내의 \"글에 안 쓴 새 기능 N건\"을 훑어 빠뜨린 큰 변화가 없는지 본다.\n\n게이트: 오류 0, 남긴 경고마다 이유가 있다.\n\n## 6. 빌드·검수\n\n```bash\nshowcase build \u003C태그> --record --verify   # 처음: 태그 worktree에서 녹화 → HTML → 검수\nshowcase build \u003C태그> --verify            # 글만 고친 뒤: 녹화본 재사용, 몇 초\nshowcase verify \u003C태그>                    # 만들어 둔 HTML만 다시 검수\n```\n\n- `--record`는 태그 시점 코드를 임시 worktree로 꺼내 설치·실행하고 녹화한 뒤 지운다. 작업 중인 브랜치로 녹화하면 아직 나가지 않은 화면이 섞인다.\n- `--verify`는 1280px·400px로 열어 가로 넘침, 빈 이미지, 재생 안 되는 영상, 누르지 않았는데 틀어지는 영상, 영상 길이를 넘는 챕터, 반응 없는 비교·단계·탭·챕터·크게 보기, 작게 열리는 크게 보기, 콘솔 오류를 잡고 `.media\u002Freview\u002F`에 화면을 남긴다.\n\n게이트: 검수 통과.\n\n## 7. 눈으로 보기\n\n`.media\u002Freview\u002F`의 `desktop-*`·`mobile-*` PNG를 **직접 열어** 본다. 기계가 못 잡는 것: 글과 그림이 맞지 않음, 비교의 이전·이후가 바뀐 점을 못 보여 줌, 영상이 너무 길거나 핵심 전에 끝남, 영상·그림 속 제품 화면이 틀에 비해 작음, 모바일에서 한 줄에 한두 글자씩 끊기는 제목, 화면 속 자료가 \"합성·테스트\"처럼 보여 실제 쓰임이 안 그려짐(실데이터로 바꿀 수 있는지 다시 본다), 가리지 못한 식별 정보.\n\n## 8. 한국어 문장\n\n`check`가 `.media\u002Fcopy.txt`에 사람이 읽는 글만 모아 둔다. `ko-natural` 스킬이 있으면 그 린트로 한 번 돌리고(`--register casual`), 없으면 references\u002Fwriting.md 기준으로 직접 다듬는다. 고친 뒤 `build`를 다시 한다.\n\n## 9. 보고·공유\n\n- 사용자에게: 결과 HTML 절대 경로, 범위(기준 → 이번), 하이라이트 목록, 남긴 경고와 이유, 영상이 없는 하이라이트와 그 이유.\n- 공유는 결과 HTML 한 파일을 팀 메신저에 첨부하거나 GitHub Release 파일로 올린다. 프로젝트에 정해진 공유 경로가 있으면 그것을 따른다.\n- `.media\u002F`(녹화본·재료·검수 화면)와 결과 HTML은 커밋하지 않는다(`.gitignore`). 커밋하는 것은 `config.json`, `story.json`, `clips.json`뿐이다.\n\n## 함정\n\n- **실데이터는 가린 사본만, 저장소 밖에만.** 가리지 않은 원본이나 실데이터를 커밋하지 않는다. 골든·녹화에 우연히 실제 사용자 정보가 보이면 그 화면은 싣지 않는다.\n- 스크린샷 안의 버전 표기·날짜가 테스트 고정값일 수 있다. 그렇다면 설정 `notes`에 한 줄 적어 팀 참고에 남긴다.\n- 비교(`compare`)는 같은 파일 이름이라도 두 태그에서 내용이 같으면 `check`가 막는다 — 바뀌지 않은 화면은 `image`로.\n- 녹화에서 두 번째 영상이 멈추는 일을 막으려고 영상마다 별도 프로세스로 찍는다. 녹화가 느리면 영상 수를 줄인다.\n- 영상은 장치 픽셀(`record.scale`) 그대로 찍는다(Chrome screencast + ffmpeg). Playwright 기본 녹화는 배율을 무시해 제품 화면이 틀 왼쪽 위에 작게 찍히므로 쓰지 않는다 — ffmpeg가 없을 때만 그쪽으로 물러난다(흐릿함).\n- 영상은 **멈춘 채로 시작한다.** 읽는 사람이 재생 단추나 챕터를 눌러야 틀어지고, 그 전에는 첫 장면이 보인다(`poster`를 주지 않으면 ffmpeg로 첫 장면을 뽑는다). 첫 장면이 빈 로딩 화면이면 `poster`에 내용이 보이는 그림을 준다.\n- 그림을 누르면 화면에 맞춰 가장 크게 열린다(작은 그림은 1.5배까지). 화면보다 큰 그림은 한 번 더 누르면 원래 크기로 넓어져 스크롤해 볼 수 있다.\n- 영상은 **H.264 MP4**로 싣고 페이지가 열릴 때 Blob 주소로 바꿔 튼다. WebM은 Safari·iPhone이 못 틀고, `data:` 주소 영상은 Safari가 열지 못한다. `verify`는 영상을 실제로 틀어 시간이 흐르는지 본다.\n- 결과 HTML이 10MB를 넘으면 메신저 첨부 한도에 걸린다. 영상을 줄이거나(30초 안팎) `steps`로 바꾼다.\n",{"name":5,"metadata":35,"description":7},{"author":36,"version":37},"develinu","1.2.0","main","ccb24817a09f75f7b2fa18d9309d8da62760b331","skills\u002Frelease-showcase",0,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills","https:\u002F\u002Fgithub.com\u002Fdouinc","https:\u002F\u002Fdou.so","A clinical intelligence company","2026-11-12 10:02:01",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add douinc\u002Fagent-skills --skill release-showcase",{"tool":53,"command":54},"bunx","bunx skills add douinc\u002Fagent-skills --skill release-showcase",{"tool":56,"command":57},"pnpm","pnpm dlx skills add douinc\u002Fagent-skills --skill release-showcase","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002FSKILL.md",true,[61,67,71,75,81,85,89],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fconfig.md","REFERENCE","参考文档",6078,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Freferences\u002Fconfig.md",{"path":68,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fstory.md",7485,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Freferences\u002Fstory.md",{"path":72,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fwriting.md",4839,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Freferences\u002Fwriting.md",{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"scripts\u002Fcheck.mjs","SCRIPT","脚本",13280,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Fscripts\u002Fcheck.mjs",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"scripts\u002Frecord.mjs",12482,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Fscripts\u002Frecord.mjs",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"scripts\u002Fshowcase.py",62843,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Fscripts\u002Fshowcase.py",{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Ftemplate.html",26115,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002Fscripts\u002Ftemplate.html",[94,111,149,164,194,217],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":105,"publishedAt":30},"01M6PDKC7XDA3NYF969T945D7S","template-skill","Replace with description of the skill and when the agent should use it.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftemplate\u002FSKILL.md",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[106,107,108,109,110,24],"template skill","template","use","name","it",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":129,"publishedAt":30},"01M6PDK6MNC6EMGA8W7KD7NJQX","writing-project-readme","Use when explicitly invoked to write or fully rewrite a project README that must cover tech stack, architecture, features, and service description in a single document — readable by non-engineers (PM, design, ops, domain experts) as well as developers. Triggers on requests like \"write the README\", \"redo README.md based on the whole project\", \"make a comprehensive README everyone can understand\". Skip for one-section edits, badge tweaks, or generating a CHANGELOG.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-project-readme\u002FSKILL.md",[117,120,121,126],{"categoryNo":118,"categoryName":119,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":127,"categoryName":128,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000036","内容创作者",[130,131,132,133,134,135,136,137,138,139,26,140,141,142,143,144,145,146,147,148],"writing","README","project","writing project readme","project readme","features","tech","design","for","architecture","cover","alpha","stack","experts","write","domain","make","pm","as",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":158,"publishedAt":30},"01M6PDK2S8KXK1NDM22C9FKE49","ux-writing-korean","한국어로 UI\u002FUX 문구를 작성하거나 검수할 때 사용합니다. 해요체, 능동형, 긍정형, 캐주얼 경어, 명사 조합 회피 등 5가지 핵심 원칙과 예외 규칙을 적용합니다.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fux-writing-korean\u002FSKILL.md",[155,156,157],{"categoryNo":118,"categoryName":119,"taxonomyType":103,"taxonomyTypeDesc":104},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},{"categoryNo":127,"categoryName":128,"taxonomyType":124,"taxonomyTypeDesc":125},[130,159,160,161,162,163],"ux","korean","ux writing","ux writing korean","ui",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":174,"publishedAt":30},"01M6PDJXK3DVWFR0420XV79HZ6","token-audit","Audit a Claude Code or Codex CLI project for token waste and fix it with the user's approval. Use whenever the user wants to check, reduce, or optimize token usage, context bloat, or API\u002Fsubscription costs of an agent project — phrases like \"토큰 점검\", \"토큰 낭비 찾아줘\", \"토큰 최적화\", \"컨텍스트 최적화\", \"Claude Code 비용 줄여줘\", \"API 비용이 너무 나와\", \"audit token efficiency\", \"check my CLAUDE.md\u002FAGENTS.md\u002FMCP setup\". Also trigger when the user complains that sessions hit context limits too fast, that costs jumped unexpectedly, or asks whether their project setup is token-efficient — even if they don't say the word \"token\".","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftoken-audit\u002FSKILL.md",[170,171],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},{"categoryNo":172,"categoryName":173,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000030","开发工程师",[175,176,177,178,179,180,181,182,183,184,132,185,186,187,188,189,190,191,192,193],"token audit","token","audit","token efficiency","limits","bloat","reduce","my","usage","MCP","efficiency","optimize","fix","context","api","code","codex cli","cli","mcp setup",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":202,"publishedAt":30},"01M6PDJJEQMBWWXW4TPXYNNV38","public-sector-rfp-authoring","Use when drafting or revising Korean government or local-government bid notices, requests for proposals, statements of work, or public-sector service\u002Fproject specifications from the ordering agency's perspective.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fpublic-sector-rfp-authoring\u002FSKILL.md",[200,201],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[203,204,205,206,108,207,208,209,210,160,211,138,212,213,214,215,132,216],"public sector rfp authoring","authoring","rfp","public","proposals","work","hermes agent","hermes","perspective","requests","specifications","agency","service","local",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":230,"publishedAt":30},"01M6PDJBRJXB46K8JKRNHSBRYY","onboarding-design","Use when designing, reviewing, or auditing signup flows, goal-selection quizzes, permission prompts, paywalls, or any screen a user sees before their first meaningful action.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fonboarding-design\u002FSKILL.md",[223,226,227],{"categoryNo":224,"categoryName":225,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},{"categoryNo":228,"categoryName":229,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000038","人力资源",[231,232,137,233,234,235,236,237,238,239,240,241,242,108,243,244],"onboarding","onboarding design","screen","quizzes","action","flows","paywalls","signup","permission","selection","prompts","goal","user","first"]