[Chore/#8] Figma WDS 컴포넌트 매칭 컨벤션 및 /component 스킬 추가

[xeoxxn]

#️⃣연관된 이슈

• Closes Figma WDS 컴포넌트 매칭 컨벤션 및 /component 스킬 추가 #8

🎯 해결하려는 문제가 무엇인가요?

Figma MCP로 Stream 디자인을 코드로 옮길 때마다, 화면에 쓰인 컴포넌트가 원티드 디자인 시스템(WDS)인지 Stream 자체 로컬 컴포넌트인지를 매번 수작업(get_libraries → search_design_system → get_design_context 대조)으로 판별해야 했다. 사람마다 판별·구현 방식이 달라지면 컴포넌트 구조가 제각각이 된다.

❓ 왜 해결해야 하나요?

WDS로 이미 존재하는 컴포넌트를 매번 새로 마크업하면 중복 구현이 생기고, 팀원마다 컴포넌트 파일 구조가 달라져 유지보수가 어려워진다.

⭐ 어떻게 해결했나요?

• docs/conventions/wds-component-usage.md: Stream Figma 파일에서 실제로 쓰이는 WDS 컴포넌트 목록을 이름·componentKey·문서 링크까지 대조해 정리한 참고 문서 (git 추적되는 위치로 이동해 팀원도 볼 수 있게 함)
• docs/conventions/component-convention.md: 컴포넌트 파일 위치(feature 전용 vs 공용), 파일 구조(컴포넌트=파일 하나, Figma variant → Props 유니온 타입), WDS import 규칙, Stream 고유 UI 작성 규칙, 완료 체크리스트
• .claude/skills/component/SKILL.md: /component <figma URL>로 호출하면 WDS 대조 → WDS는 import로 치환, 나머지는 컨벤션대로 새 컴포넌트 작성 → 배치·검증까지 이어지는 워크플로우

🧩 이 PR의 한계 & 트레이드오프

• wds-component-usage.md는 현재 시점 스냅샷이라, Figma 디자인이 바뀌면 다시 대조해야 한다. /component 스킬이 실행될 때마다 새로 확정되는 매핑을 이 문서에 계속 추가하도록 설계했다.
• 실제 화면으로 /component를 시험 실행해보진 않았다 — 다음 작업에서 진행 예정.

⛓️ 기존 기능에 미치는 영향

문서·스킬 추가뿐이라 기존 코드에 영향 없음.

🔀 Edge Case & 실패 시나리오

없음 (문서/스킬 작업)

📋 검토한 대안과 선택 이유

Figma Code Connect(add_code_connect_map)로 WDS 라이브러리에 공식 매핑을 등록하는 것도 검토했으나, WDS는 우리가 소유하지 않은 Community 라이브러리라 Code Connect를 라이브러리 쪽에 직접 걸 수 없어 제외했다. 대신 이름+componentKey 대조 절차를 스킬 내부에 고정했다.

💬 리뷰 포인트

• [c] component-convention.md의 파일 위치 규칙(feature 우선, 재사용 확인되면 components/ui로 승격)이 팀 방향과 맞는지

[xeoxxn]

브랜치명을 컨벤션(커밋 type과 일치)에 맞게 chore/#8-... → docs/#8-...로 정리하는 과정에서 이 PR이 자동으로 닫혔습니다. 같은 내용으로 #10 다시 열었습니다.