dnd-design-system

@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-design-system 모노레포에서 PR 을 생성하면서 AI 인라인 코드 리뷰까지 자동으로 받는다. "PR 만들고 리뷰", "AI 리뷰 받으면서 PR", "PR with review", "리뷰 포함 PR 생성", "코드 리뷰 같이 올려줘" 같은 요청이나 PR 생성 시 자동 코드 리뷰가 필요할 때 반드시 이 스킬을 사용하라. pr 스킬과 동일한 절차를 따르되 `gh pr create` 명령 끝에 `# ai-review` 주석을 붙여 pr-review 훅을 트리거한다. 리뷰 코멘트가 등록되면 사용자에게 반영 여부를 묻고, 수락 시 코드를 수정하고 각 코멘트에 답글을 단다.

dnd-design-system 모노레포에서 5단계 디자인 변경 워크플로우의 세 번째 단계 — `/impact` 가 추정한 영향 범위를 디자이너가 시각적으로 확인할 수 있게 Storybook 링크와 before/after 비교 노트로 정리한다. "/preview", "미리보기 만들어줘", "이 변경 어떻게 보여요?", "Storybook 으로 비교해줘" 같은 요청이나 변경 결정 전에 실제 모양을 봐야 할 때 반드시 이 스킬을 사용하라. `packages/desktop/.storybook/` 의 기존 Storybook 인프라를 활용해 노출도 높은 컴포넌트 3~5 개의 URL 을 산출하고, before/after 노트(토큰 변경이면 값 차이, 컴포넌트 변경이면 props 차이)를 `.claude/workflow/<id>/preview.md` 에 Markdown 으로 저장한다. v1 범위는 컴포넌트 단위 미리보기까지 — 페이지 컨텍스트 미리보기는 후순위.

dnd-design-system 모노레포에서 디자인 변경 워크플로우의 첫 단계 — 자연어로 표현된 변경 의도를 구조화된 `proposal.json` 으로 정리한다. "변경 제안", "/proposal", "버튼을 더 둥글게 하고 싶어요", "이 색을 진하게 바꾸자", "X 컴포넌트가 필요해요" 같이 디자이너/개발자가 변경 의도를 자연어로 풀어놓고 시작할 때 반드시 이 스킬을 사용하라. 변경 타입(token-value/token-add/token-remove/component-new/component-api/bug) 6 가지 카탈로그(`references/change-types.md`)에 맞춰 분류하고, 토큰명·컴포넌트명 후보를 grep 으로 검증해 `targets[]` 까지 채운 뒤 `.claude/workflow/<id>/proposal.json` 으로 직렬화한다. 후속 단계(`/impact /preview /review /decision`)의 입력이 되는 단계이므로 자연어 원문은 `raw` 필드에만 보존하고 이후 단계는 구조화 필드만 사용한다.

dnd-design-system 모노레포에서 5단계 디자인 변경 워크플로우의 네 번째 단계 — 변경을 디자인/개발 비용/접근성 세 관점으로 점검한다. "/review", "리뷰", "이 변경 검토해줘", "접근성 점검", "색 대비 확인" 같은 요청이나 결정 직전에 다른 관점을 한 번 더 거쳐야 할 때 반드시 이 스킬을 사용하라. 자동 점검(WCAG AA 색 대비 — 색 토큰 한정, 토큰 일관성)은 자동으로 돌리고, 정성 평가가 필요한 영역(디자인 톤, 개발 비용)은 `humanAsks[]` 로 분류해 `AskUserQuestion` 으로 받는다. CLAUDE.local.md 5번에서 강조했듯 자동화 비율이 낮은 단계라 처음부터 하이브리드(자동 점검 + 사람 검토)로 설계됨. 결과는 `.claude/workflow/<id>/review.json`.

dnd-design-system 모노레포의 모든 프로젝트 스킬 SKILL.md 본문을 사용 경험 메모로부터 자동 갱신한다. "skill-admin", "스킬 갱신해줘", "스킬 개선", "메모로 스킬 고쳐줘", "changeset 본문 다듬기", "pr 절차 보강", "이 스킬 좀 더 명확하게" 같이 스킬을 쓰다가 발견한 부족함·모호함·누락 메모를 모아 SKILL.md 를 수정해야 할 때 반드시 이 스킬을 사용하라. 누적 메모를 분석해 어느 스킬의 어디를 어떻게 고칠지 제안하고, 사용자 승인 후 자동 Edit. 단, 5단계 워크플로우의 공통 룰(R#)·단계 구조·SSOT(`docs/AGENTS.md`)에 영향 있는 변경이면 `workflow-admin` 으로 위임한다 — skill-admin 은 단일 SKILL.md 본문의 절차·표현·예시·옵션 다듬기만 책임진다.

dnd-design-system 모노레포의 5단계 디자인 변경 워크플로우(`/proposal /impact /preview /review /decision`)를 관리한다. SSOT 인 `docs/AGENTS.md` 와 5개 단계 스킬·`.claude/workflow/README.md` 의 일관성을 유지하는 메타 스킬이다. "workflow-admin", "워크플로우 룰 추가해줘", "공통 룰 변경", "워크플로우 단계 추가", "5단계 스킬 일괄 수정", "AGENTS.md 갱신", "워크플로우 정합성 점검", "디자인 워크플로우 거버넌스" 같은 요청이나 룰(R1~R11)을 추가·수정·제거할 때, 단계를 추가·삭제할 때, 단계 스킬의 책임이 바뀔 때 반드시 이 스킬을 사용하라. SSOT(`docs/AGENTS.md`)를 먼저 수정하고 grep 으로 영향받는 `SKILL.md` 와 `workflow/README.md` 를 찾아 동기화한 뒤 변경 이력을 한 줄 박는다. 단일 스킬의 절차만 손보는 작은 수정은 이 스킬 없이 직접 해도 되지만, 공통 룰·흐름·구성 요소가 바뀌면 반드시 이 스킬을 거친다.