DNDACADEMY

@dnd-lab/desktop primitive 컴포넌트가 docs/VARIANT_GUIDELINES.md 의 변형·네이밍 표준을 따르는지 검사하고, 안전하게 자동 수정할 수 있는 위반은 사용자 승인 후 일괄 수정한다. "variant 검사해줘", "check-variants", "네이밍 통일 검사", "가이드라인 위반 찾아줘", "BottomTxt 같은 거 잡아줘", "primitive 컨벤션 점검" 같은 요청이나 새 컴포넌트 추가/수정 직후 셀프 점검이 필요할 때 반드시 이 스킬을 사용하라. 단순 위반(파일명, prop 케이싱, CSS export 접미사)은 사용자 승인 후 자동 Edit 까지 책임지고, API breaking change(compound 이름, variant prop 이름) 는 보고만 하고 사용자 결정에 맡긴다.

@dnd-lab/desktop 컴포넌트의 접근성 테스트 스펙(spec.stories.tsx)을 생성한다. 컴포넌트 파일을 보여주거나 "접근성 스펙 만들어줘", "a11y 테스트 작성해줘", "spec.stories 생성해줘", "키보드 테스트 작성", "ARIA 테스트", WAI-ARIA 패턴 관련 스펙이 필요할 때 반드시 이 스킬을 사용하라.

dnd-design-system 모노레포에서 changeset 파일(.changeset/*.md)을 작성한다. "changeset 만들어줘", "changeset 작성해줘", "변경사항 정리해줘", "버전업 노트 작성", "릴리즈 노트 초안", "패키지 변경 정리" 같은 요청이나 packages/token, packages/desktop 변경 후 CHANGELOG/슬랙 공지용 본문이 필요할 때 반드시 이 스킬을 사용하라. 변경 유형(🎨 토큰 / ✨ 새 컴포넌트 / 🔧 API 변경 / 🐛 버그 수정) 카탈로그에 맞춰 사용자 관점·해요체 본문을 작성한다.

dnd-design-system 모노레포에서 staged 변경사항을 분석해 conventional commit 형식의 메시지를 자동 생성·커밋한다. "커밋해줘", "커밋 메시지 만들어줘", "auto commit", "feat/fix 메시지 작성", "스코프 자동 감지" 같은 요청이나 사용자가 `git add` 후 커밋을 요청할 때 반드시 이 스킬을 사용하라. 워크스페이스(packages/token, packages/desktop, tools/) 기반 scope 자동 감지와 root 파일 처리 규칙(pnpm-lock.yaml, .gitignore 등은 커밋에 포함하되 scope 에서 제외)을 따른다.

@dnd-lab/desktop 디자인 시스템에 새 컴포넌트를 추가한다. "컴포넌트 만들어줘", "새 컴포넌트 추가", "desktop에 추가", "프리미티브 만들어줘" 같은 요청이나 @dnd-lab/desktop 패키지에서 컴포넌트 파일을 새로 생성할 때 반드시 이 스킬을 사용하라. 컴포넌트 구현 후 a11y-spec-writer 스킬로 접근성 스펙까지 자동 생성한다.

dnd-design-system 모노레포에서 5단계 디자인 변경 워크플로우의 마지막 단계 — 진행/보류/반려를 명시적으로 선택하고 그 근거를 함께 기록한다. "/decision", "결정", "이거 진행할게요", "보류로 바꿔주세요", "반려할게요" 같은 요청이나 proposal/impact/preview/review 까지 거친 변경에 대해 진행 의사를 확정해야 할 때 반드시 이 스킬을 사용하라. CLAUDE.local.md 4-5 에서 강조했듯 결정의 근거가 휘발되지 않게 박아두는 게 목적이다. `proceed` 면 후속으로 `/changeset` `/pr` 안내(자동 호출 X — 사용자가 명시적으로 다음 명령을 실행). 결과는 `.claude/workflow/<id>/decision.json` + `state.status` 갱신(`Approved | OnHold | Rejected`).

dnd-design-system 모노레포에서 5단계 디자인 변경 워크플로우의 두 번째 단계 — `/proposal` 이 만든 `proposal.json` 의 `targets[]` 가 실제로 어디까지 영향을 주는지 정적 분석한다. "/impact", "영향도 분석", "이 토큰 어디까지 쓰여요?", "Button 을 바꾸면 어디가 영향받아요?" 같은 요청이나 변경 결정 전에 노출 범위를 가늠해야 할 때 반드시 이 스킬을 사용하라. `packages/desktop/src/**/*.css.ts` 와 `*.tsx` 를 grep 으로 추적해 토큰 사용처와 컴포넌트 임팩트를 모으고, 디자이너가 읽을 수 있는 가독 포맷("주요 컴포넌트 N개 / 그중 노출도 높은 X")으로 요약해 `.claude/workflow/<id>/impact.json` 에 저장한다. raw count 는 별도 필드에만 두고 본문에는 노출하지 않는다 — 정보 과잉이 결정을 막는 것을 막기 위함이다.

dnd-design-system 모노레포에서 현재 브랜치 변경사항을 분석해 GitHub Pull Request 를 자동 생성한다. "PR 만들어줘", "PR 생성", "풀 리퀘스트 작성", "pull request 만들어", "main 으로 PR 올려줘" 같은 요청이나 작업 완료 후 PR 이 필요할 때 반드시 이 스킬을 사용하라. .github/PULL_REQUEST_TEMPLATE.md 의 섹션 구조(📝 변경사항 / 🔗 관련 링크)를 정확히 따르며 conventional commit 형식의 한국어 제목을 생성한다. 변경 규모에 따라 단순 bullet 부터 표·details·AS-IS/TO-BE 스크린샷 비교까지 본문 깊이를 조정한다. AI 코드 리뷰까지 자동으로 받고 싶다면 pr-with-review 스킬을 사용하라.

DND 신규 기수 모집 오픈 시점에 지원 폼/시트 정보(constants/index.ts, generate-applicant-count.ts)와 이벤트 상태/일정(event_status.json)을 한 번에 묶어 업데이트할 때 사용합니다. 사용자가 "기수 오픈", "15기 모집 시작 준비", "모집 오픈 작업", "지원 폼이랑 일정 같이 갱신", "다음 기수 오픈해줘", "모집 오픈" 같은 말을 하거나 새 기수의 폼/시트 + 일정/상태를 함께 알려주면 반드시 이 스킬을 사용하세요. recruitment-open과 event-status-update를 따로 부르는 것보다 순서/일관성 보장 측면에서 안전합니다.

DND 신규 기수 모집을 오픈할 때 지원 폼 URL, 응답시트 ID, CURRENT_FLAG를 한꺼번에 업데이트합니다. 사용자가 "지원 폼 업데이트", "지원 링크 바꿔", "구글폼 새로 만들었어", "응답시트 ID 바꿔줘", "CURRENT_FLAG 올려", "15기 폼 연결", "다음 기수 모집 준비" 같은 말을 하거나 새 기수 구글폼/응답시트 정보를 주면 반드시 이 스킬을 사용하세요. constants/index.ts와 generate-applicant-count.ts 두 파일을 동시에 손대야 해서 직접 수정하면 한쪽만 바뀌어 지원자 수 집계가 깨질 가능성이 높습니다.

DND 홈페이지 상단에 노출되는 이벤트 상태(모집 시작/마감/활동 시작 일정과 status 라벨)를 수정할 때 사용합니다. 사용자가 "이벤트 상태 바꿔줘", "모집 일정 업데이트", "지원 마감일 바꿔", "status를 ACTIVE로", "applicationStartDateTime 수정" 같은 말을 하거나 `event_status.json`을 직접 언급하면 반드시 이 스킬을 사용하세요. 기수 시작/모집 오픈/마감 시점마다 호출되는 핵심 운영 작업이라 절대 직접 JSON을 손대지 말고 이 스킬을 거치세요.

신규 운영진을 `organizers.json`에 등록할 때 사용합니다. 사용자가 "운영진 추가", "operators/organizers 업데이트", "이번 기수 운영진 등록", "운영진 폼 응답 넣어줘" 같은 말을 하거나 운영진 정보가 담긴 CSV/TSV 파일 경로를 주면 반드시 이 스킬을 사용하세요. 직군 매핑 규칙과 ID 자동 채번 때문에 직접 JSON을 수정하면 데이터 깨질 가능성이 높습니다.

DND 기수 종료 후 신규 프로젝트들을 `projects.json`에 등록할 때 사용합니다. 사용자가 "프로젝트 등록", "이번 기수 프로젝트 추가", "projects.json 업데이트", "14기 프로젝트 넣어줘" 같은 말을 하거나 프로젝트 데이터가 담긴 CSV/TSV 파일 경로를 주면 반드시 이 스킬을 사용하세요. 기수마다 한 번씩 돌아가는 운영 작업이고, 직접 JSON을 손대면 ID 충돌이나 S3 경로 오타가 자주 발생하니 반드시 이 스킬을 거치세요.

DND 기수 종료 후 참여자들의 개인 후기를 `reviews.json`에 등록할 때 사용합니다. 사용자가 "리뷰 추가", "이번 기수 후기 등록", "reviews.json 업데이트", "참여자 후기 넣어줘" 같은 말을 하거나 후기가 담긴 CSV/TSV 파일 경로를 주면 반드시 이 스킬을 사용하세요. 기수마다 한 번씩 돌아가는 운영 작업이고, projects-update와 짝으로 진행되는 경우가 많습니다.

DND 홈페이지 후원사 섹션(`SponsorSection/index.tsx`)에 후원사를 추가/제거/수정할 때 사용합니다. 사용자가 "후원사 추가", "후원사 등록", "후원사 빼줘", "후원사 제거", "후원사 업데이트", "후원사 로고 교체", "SponsorSection 수정", "스폰서 추가/삭제" 같은 말을 하거나 후원사 이름/URL/로고 파일을 주면 반드시 이 스킬을 사용하세요. 후원사 데이터가 JSON이 아니라 TSX 배열에 인라인으로 들어있고 로고 PNG 파일을 별도 폴더에 두는 이원 구조라, 직접 손대면 배열에는 추가했는데 로고는 빠지거나(404 발생) 반대로 로고만 남고 노출이 안 되는 사고가 자주 납니다.

DND 홈페이지 통계 카운터(누적 지원자/참여자/프로젝트/이탈자 수)를 갱신할 때 사용합니다. 사용자가 "지원수 업데이트", "통계 카운트 갱신", "이번 기수 N명 지원했어", "total_count_status.json" 같은 말을 하거나 기수 마감 후 합계 숫자를 알려주면 반드시 이 스킬을 사용하세요. 작은 파일이지만 홈페이지 상단 숫자에 직결되므로 직접 수정하지 말고 이 스킬을 거치세요.