Menu
UX 디자이너의 PR/브랜치를 기존 기능과 통합하는 표준 워크플로우. PR 분석 → 프론트엔드 리뷰 → rebase 머지 → 백엔드 연동 계획. PR URL이나 번호를 인자로 받는다.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | integrate-ux |
| description | UX 디자이너의 PR/브랜치를 기존 기능과 통합하는 표준 워크플로우. PR 분석 → 프론트엔드 리뷰 → rebase 머지 → 백엔드 연동 계획. PR URL이나 번호를 인자로 받는다. |
UX 디자이너가 작업한 PR/브랜치를 기존 코드베이스의 기능과 통합하는 스킬. 프론트엔드 레포 전용.
useState로 관리하던 데이터를 서버 액션 + router.refresh() 패턴으로 교체window.prompt(), window.confirm(), alert() → Shadcn Dialog/AlertDialog로 교체# cwd: <repo root>
gh pr view {PR번호} --json title,body,additions,deletions,changedFiles
gh pr diff {PR번호} --name-only
gh pr diff {PR번호}
(GitHub Enterprise 사용 시 GH_HOST=... prefix)
확인할 것:
UX가 대체하려는 기능이 이미 구현되어 있는지 확인:
src/components/{feature}/)src/actions/)src/app/api/)src/lib/hooks/)UX 코드에서 인라인 패턴을 찾아 공통 컴포넌트로 교체:
Shadcn 우선 규칙 (필수):
<select>, <button>, <dialog>, <input>)을 써도 코드에선 항상 Shadcn 컴포넌트로 통일<select> → Select/SelectTrigger/SelectContent/SelectItemDialog / AlertDialogInput, 여러 줄 → Textarea레포별 공통 컴포넌트 매핑은 skills-variants/{repo}/integrate-ux-mapping.md 참조.
UX 디자이너는 프론트엔드 전문가가 아님 — 시니어 프론트엔드 엔지니어 관점에서 코드 품질을 검토하고 개선 계획을 세운다.
UX 코드는 종종 하나의 거대 컴포넌트에 모든 로직을 담음. 분리 기준:
3단계에서 식별한 인라인 패턴을 공통 컴포넌트로 교체. 추가로:
components/common/으로 추출 검토UX 코드의 로컬 state 변경을 서버 액션으로 교체:
useState로 관리하던 추가/수정/삭제를 서버 액션 + router.refresh()로 교체// 패턴: 낙관적 업데이트 + 서버 액션
onSelectHistory={async (id, imagePath) => {
setItems(prev => /* 로컬 즉시 반영 */);
await selectItem(id); // 서버 동기화
}}
as any 사용 금지UX 디자이너는 빠른 목업을 위해 매직 값과 암묵적 관례를 많이 사용. 통합 시 반드시 명시적 인터페이스로 개선.
Magic String / Magic Number 스캔:
constants/)로 추출내부 계산 대신 Props 전달:
-1 = 전체) → discriminated union 또는 명시적 prop"__all__") → 타입 시스템으로 보호되는 union type원칙: 매직 값 없이 타입만 보고 의도를 파악할 수 있는 인터페이스가 양쪽 모두에게 유지보수 비용을 낮춘다.
아래 항목에 대해 반드시 사용자와 논의:
docs/code-architecture.md — 새 디렉터리/컴포넌트 반영docs/adr.md — 필요 시 ADR 추가docs/flow.md — 플로우 변경 반영PR 반영 방식 — rebase 후 머지 (main에 바로 머지 금지):
main에 바로 gh pr merge하지 않는다. PR 브랜치에서 main을 rebase하고, conflict를 해결한 뒤, 사용자가 PR diff를 확인한 후 머지한다.
절차:
git rebase origin/main으로 최신 main 반영git push --force-with-lease로 PR 업데이트 (force는 사용자 승인 필요)표준 phase 구조:
| Phase | 내용 |
|---|---|
| 1 | PR 브랜치 checkout + main rebase + conflict 해결 |
| 2 | 기존 기능 유지 검증 + 빌드 + force-with-lease push (사용자 승인 후) |
| 3 | PR 댓글 + 사용자 리뷰 대기 |
/build-with-teams tasks/{task-name} 로 실행한다.
task 완료 후 원본 UX PR에 댓글을 달고 close.
댓글 내용 템플릿:
## 반영 완료 — 코드 직접 구현 방식
PR의 UX 디자인을 분석하여 기존 코드베이스에 직접 구현했습니다 (커밋 `{hash}`).
### 반영된 항목
- ✅ 항목 1
- ✅ 항목 2
### 반영하지 않은 항목
- ❌ 항목 (사유)
### UX 디자이너께 제안 (참고용)
디자인 관점에서 개선하면 좋을 포인트 (코드는 원안 유지, 의사결정은 디자이너 몫):
1. {제안 내용 1}
2. {제안 내용 2}
### 후속 plan 예정
- {다음에 이어질 작업}
### 직접 머지하지 않은 이유
- 스키마 변경/리팩토링으로 인한 대규모 충돌
UX PR이 대부분 이 파일을 수정함 (탭 연결, 서브스텝 추가). 여러 PR을 순차 merge하면 충돌 빈발.
해결: 우리 버전을 base로, UX의 추가 코드(import, 정의, 렌더링)를 수동 반영.
UX 코드에서 흔한 패턴:
// UX 목업 (교체 대상)
const [data, setData] = useState(SAMPLE_DATA);
function updateItem(idx, field, value) {
setData(p => p.map((d, i) => i === idx ? { ...d, [field]: value } : d));
}
// 교체 후 (DB 연동)
// props로 서버 데이터 받기 → onBlur 시 서버 액션 → router.refresh()
/integrate-ux는 UX 코드를 분석하고 머지하는 단계. 머지 후 백엔드 연동이 필요하면:
/integrate-ux (PR 분석 → 머지 → 프론트엔드 리뷰)
↓ 분석 결과 + 개선 항목 목록 도출
/planning (DB 설계 → API 설계 → 아키텍처 결정 → docs 반영)
↓ 구현 계획 확정
/build-with-teams (task 생성 → 자동 실행)
/integrate-ux 완료 시 출력:
/planning으로 설계할까요?" 제안Phase 3의 push 직전에 아래를 확인 — 모두 0건이어야 force-with-lease push 진행:
# cwd: <repo root>
grep -rn "window\.\(prompt\|confirm\|alert\)" src/components/{영향 디렉토리}/
grep -rn "as any" src/components/{영향 디렉토리}/
grep -rn "console\.log" src/components/{영향 디렉토리}/