cc-designer
디자인 실무 레퍼런스 + 의사결정 스킬 (UI 디자인, 인터랙션 디자인, 정보 구조, 디자인 시스템, 디자인 옵스, 비주얼 크리틱). owl-listener/designer-skills에서 vendoring·adapt한 57개 스킬과 하우스 정보 구조(IA) 스킬 7종을 화면 기능 개발 중 레퍼런스로 쓰고, 스펙·시안에 답이 없는 디자인 판단은 design-decision 프로토콜로 되묻지 않고 확정 (cc-dev Step 7.1)
디자인 실무 레퍼런스 + 의사결정 스킬 (UI 디자인, 인터랙션 디자인, 정보 구조, 디자인 시스템, 디자인 옵스, 비주얼 크리틱). owl-listener/designer-skills에서 vendoring·adapt한 57개 스킬과 하우스 정보 구조(IA) 스킬 7종을 화면 기능 개발 중 레퍼런스로 쓰고, 스펙·시안에 답이 없는 디자인 판단은 design-decision 프로토콜로 되묻지 않고 확정 (cc-dev Step 7.1)
Design-practice reference skills — UI design, interaction design, information architecture, design systems, design ops, and visual critique — for use during screen-feature development (see
cc-dev's Step 7.1 Design Reference & Decision).
Beyond reference, the house design-decision skill and /cc-designer:decide command let an unattended pipeline
settle practical design judgments (colour, spacing, state behaviour, feedback style, copy, input format) from evidence instead of stopping to ask.
Skills#
| 이름 | 설명 |
|---|---|
| coui-product-style | CoUI로 제품 화면의 브랜드 스타일을 정하거나 리디자인할 때 사용합니다. 전체 테마와 부품별 스타일을 대표 화면에서 검증하고 나머지 화면·코드에 연결합니다. |
| critique-affordance | 버튼과 조작 요소가 사용 가능한 것으로 보이는지 검토할 때 사용합니다. 클릭 가능성, 상태 표시와 주요 행동의 발견 가능성을 확인해 개선안을 정리합니다. |
| critique-brand-consistency | 화면이 정해진 브랜드와 표현 방식에 맞는지 검토할 때 사용합니다. mood.md·voice.md·tokens.md를 기준으로 색·문구·디자인 토큰의 일관성을 확인합니다. |
| critique-color | 화면의 색상 사용과 접근성을 검토할 때 사용합니다. 글자·배경 대비, 팔레트 일관성과 상태별 색의 의미를 확인하고 색 구분이 어려운 상황을 점검합니다. |
| critique-composition | 화면의 배치와 시각적 균형을 검토할 때 사용합니다. 여백, 요소 간 묶음과 반복되는 배치 흐름을 확인해 구도 개선안을 정리합니다. |
| critique-information-density | 화면이 복잡하거나 중요한 내용을 찾기 어려울 때 사용합니다. 정보량과 우선순위를 검토하고 한 번에 보여줄 내용과 단계적으로 펼칠 내용을 정리합니다. |
| critique-restraint | 화면의 장식·설명·강조가 과한지 검토할 때 사용합니다. 요소를 덜어냈을 때 정보와 행동이 유지되는지 확인하고 삭제·통합·유지할 항목을 정리합니다. |
| critique-specificity | 디자인이 평범해 제품의 특성과 차별점이 드러나지 않을 때 사용합니다. 실제 서비스의 목적과 자료가 화면에 반영됐는지 확인하고 고유성을 높일 방향을 제안합니다. |
| critique-typography | 화면의 글자가 잘 읽히고 일관되는지 검토할 때 사용합니다. 글자 크기·굵기·줄 간격과 디자인 토큰 사용을 확인해 수정할 지점을 정리합니다. |
| critique-visual-hierarchy | 화면에서 중요한 정보와 행동이 먼저 보이는지 검토할 때 사용합니다. 시선의 시작점·이동 순서와 강조의 분배를 확인해 우선순위를 조정합니다. |
| design-decision | 색·간격·문구·상태 표현 등 여러 대안이 있는 디자인 판단을 정리할 때 사용합니다. 명세·시안·기존 코드와 디자인 원칙을 근거로 선택하고 결정 이유와 별도 확인이 필요한 항목을 기 |
| design-review | 구현한 화면을 Figma 시안과 대조해 디자인 QA를 할 때 사용합니다. 상태별 밝은·어두운 화면의 픽셀 차이, 동작과 CoUI 토큰·컴포넌트 사용을 검토해 수정 위치를 보고합니다 |
| design-system | CoUI의 디자인 토큰을 선택하거나 앱 테마를 구성할 때 사용합니다. 색·글자·간격·형태·크기·모션과 테마의 밝기·표면·밀도 설정을 확인합니다. |
| designer-index | 디자인 작업에 맞는 전문 스킬을 고를 때 사용합니다. 화면 표현, 상호작용, 정보 구조, 디자인 시스템과 팀 운영·리뷰로 요청을 나눠 적합한 문서를 안내합니다. |
| dops-critique | 디자인 피드백 회의를 준비하거나 진행할 때 사용합니다. 논의 목표와 피드백 기준을 정하고 의견을 실행 가능한 수정 항목으로 정리합니다. |
| dops-debt-audit | 제품 전반의 디자인 불일치를 조사하거나 개편 우선순위를 정할 때 사용합니다. 반복되는 화면·부품 문제를 분류하고 영향과 수정 비용을 고려해 개선 계획을 만듭니다. |
| dops-handoff-spec | 디자인을 개발자에게 전달할 명세를 작성할 때 사용합니다. 치수, 상태별 동작, 이미지 자산과 예외 상황을 정리해 구현에 필요한 정보를 제공합니다. |
| dops-impact-reporting | 디자인 개선의 효과를 이해관계자에게 보고할 때 사용합니다. 확인된 사용자·사업 지표와 변경 내용을 연결해 성과와 남은 과제를 설명합니다. |
| dops-qa-checklist | 구현한 화면이 디자인 명세에 맞는지 점검할 항목을 만들 때 사용합니다. 디자인 QA 체크리스트와 오류 접수 기준을 정리합니다. |
| dops-review-process | 디자인 검토 시점과 승인 절차를 정할 때 사용합니다. 단계별 검토 기준, 체크리스트와 결정 책임을 정의합니다. |
| dops-sprint-plan | 짧은 기간에 문제 정의부터 시안 검증까지 진행할 때 사용합니다. 디자인 스프린트의 일정, 참여자와 활동을 정하고 프로토타입 테스트까지 연결합니다. |
| dops-team-workflow | 디자인팀의 협업 방식을 정하거나 개선할 때 사용합니다. 업무 관리, 정기 공유·리뷰와 사용할 도구의 역할을 정리합니다. |
| dops-version-control | 디자인 파일과 컴포넌트 라이브러리의 변경 이력을 관리할 때 사용합니다. 버전·브랜치 운영과 디자인 토큰 변경 기록의 작성 기준을 정합니다. |
| dsys-accessibility-audit | 디자인의 접근성을 종합적으로 감사할 때 사용합니다. WCAG·ARIA 기준으로 문제를 확인하고 심각도와 개선 순서를 정리합니다. |
| dsys-component-spec | UI 컴포넌트의 설계·사용 명세를 작성할 때 사용합니다. 속성, 상태와 변형, 접근성 요구사항과 사용 예를 정리합니다. |
| dsys-design-token | 색·간격·글꼴 등 반복되는 디자인 값을 토큰으로 정리할 때 사용합니다. 토큰의 계층, 이름과 용도별 사용 기준을 정의합니다. |
| dsys-documentation-template | 디자인 시스템 문서의 공통 형식을 만들 때 사용합니다. 컴포넌트·패턴·사용 지침에 필요한 항목을 담은 문서 템플릿을 작성합니다. |
| dsys-governance | 디자인 시스템의 기여와 변경 관리 방식을 정할 때 사용합니다. 제안·검토·배포, 버전 관리와 사용 중단 절차의 책임과 기준을 정의합니다. |
| dsys-icon-system | 제품 전반의 아이콘 규칙을 만들 때 사용합니다. 그리드·크기·이름·분류와 개발에 전달할 자산·구현 기준을 정리합니다. |
| dsys-localization | 여러 언어와 지역에 맞는 인터페이스를 설계할 때 사용합니다. 번역 후 글자 길이 변화, 오른쪽에서 왼쪽으로 읽는 언어와 문화별 표현 차이를 검토합니다. |
| dsys-motion-system | 제품 전체의 애니메이션 규칙을 정할 때 사용합니다. 지속 시간·속도 변화 토큰과 모션 감소 설정을 정의해 움직임을 일관되게 적용합니다. |
| dsys-naming-convention | 컴포넌트·토큰·디자인 파일의 이름을 통일할 때 사용합니다. 이름의 구성 규칙과 예시를 만들고 기존의 불일치를 정리합니다. |
| dsys-pattern-library | 반복되는 UX 문제와 해결 방식을 문서화할 때 사용합니다. 패턴별 문제 상황, 적용 방법과 사용 예·관련 패턴을 정리합니다. |
| dsys-theming-system | 여러 브랜드나 다크·고대비 모드를 지원하는 테마를 설계할 때 사용합니다. 공통 토큰과 테마별 값을 연결하고 전환 구조를 정의합니다. |
| ia-card-sorting | 메뉴·카테고리 구성이 사용자의 예상과 맞는지 검증할 때 사용합니다. 카드 분류와 트리 탐색 연구를 설계하고 결과에서 그룹·메뉴 이름의 수정안을 도출합니다. |
| ia-content-audit | 도움말·문서 사이트나 화면 안내의 내용을 정리할 때 사용합니다. 콘텐츠를 목록화해 부정확함·중복·누락을 확인하고 유지·수정·통합·삭제할 항목을 정합니다. |
| ia-controlled-vocabulary | 같은 개념이 화면·문서마다 다른 이름으로 불릴 때 사용합니다. 대표 용어와 동의어·관련어를 정리해 라벨, 번역 원본과 검색 용어를 통일합니다. |
| ia-metadata-schema | 목록의 표시 항목·검색·필터·정렬에 필요한 데이터 속성을 정할 때 사용합니다. 필드별 의미, 타입·필수 여부와 허용값을 정리한 속성 사전을 만듭니다. |
| ia-sitemap | 앱·웹의 전체 화면 구조를 정리하거나 개편할 때 사용합니다. 경로 정의에서 사이트맵을 만들고 연결되지 않은 화면, 중복 경로와 과도한 이동 깊이를 점검합니다. |
| ia-taxonomy | 메뉴·콘텐츠·기능의 분류 체계를 설계할 때 사용합니다. 그룹 이름과 소속 기준을 정하고 계층·필터 방식 중 적절한 구조를 선택합니다. |
| ia-user-flow | 사용자가 목표를 이루는 화면 이동과 처리 순서를 설계할 때 사용합니다. 시작부터 완료까지 인증·권한·오류·중간 이탈 등의 분기를 포함한 흐름도를 만듭니다. |
| ix-animation-principles | 요소의 움직임과 화면 전환을 설계할 때 사용합니다. 목적에 맞는 지속 시간, 속도 변화와 실행 순서를 정해 애니메이션을 다듬습니다. |
| ix-doherty-threshold | 응답 시간 목표나 대기 중 피드백을 정할 때 사용합니다. 도허티 임계값을 참고해 즉각적인 반응과 로딩 표시를 설계하고 체감 지연을 줄일 방법을 검토합니다. |
| ix-error-handling | 사용자 오류와 시스템 실패의 안내·복구 흐름을 설계할 때 사용합니다. 오류 예방, 입력 검증과 다시 시도할 수 있는 경로를 정리합니다. |
| ix-feedback-patterns | 사용자 행동 뒤에 보여줄 결과와 상태 안내를 설계할 때 사용합니다. 확인 표시, 진행 상태와 토스트·알림의 내용과 표시 시점을 정합니다. |
| ix-fitts-law | 누르기 쉬운 버튼과 터치 영역을 설계할 때 사용합니다. 피츠의 법칙을 참고해 대상의 크기·위치와 이동 거리를 검토합니다. |
| ix-form-design | 입력 폼이나 여러 단계의 작성 흐름을 설계할 때 사용합니다. 항목 배치, 입력 방식과 검증·오류 안내를 정해 사용자가 작성을 완료하도록 돕습니다. |
| ix-gesture-patterns | 스와이프·드래그·확대 등 제스처 동작을 설계할 때 사용합니다. 터치와 포인터 환경별 조작 방식, 피드백과 대체 입력을 정리합니다. |
| ix-hicks-law | 선택지가 많아 결정을 내리기 어려운 화면을 정리할 때 사용합니다. 힉의 법칙을 참고해 메뉴·옵션을 묶고 제시 시점을 조정합니다. |
| ix-interfaces-that-feel | 기능은 동작하지만 화면의 표현과 반응이 밋밋할 때 사용합니다. 문구의 톤, 움직임의 시점과 조작 피드백을 살펴 구체적인 개선안을 제안합니다. |
| ix-loading-states | 데이터를 기다리는 동안의 화면을 설계할 때 사용합니다. 로딩 표시, 스켈레톤과 점진적 노출·낙관적 갱신 중 적절한 방식을 정합니다. |
| ix-micro-interaction-spec | 버튼 반응 등 작은 상호작용을 상세히 명세할 때 사용합니다. 시작 조건, 동작 규칙과 피드백·반복·모드 전환을 정의합니다. |
| ix-millers-law | 정보 목록이나 입력 단계를 읽기 쉬운 묶음으로 나눌 때 사용합니다. 밀러의 법칙을 참고해 작업 기억의 부담을 줄이고 메뉴·폼·온보딩 구성을 검토합니다. |
| ix-navigation-patterns | 제품의 화면 이동 방식을 선택하거나 설계할 때 사용합니다. 사용자 과업과 플랫폼 관례에 맞춰 탭바, 사이드 메뉴와 현재 위치 표시를 구성합니다. |
| ix-onboarding-design | 신규 사용자의 가입과 첫 실행 경험을 설계할 때 사용합니다. 제품 안내, 초기 빈 화면과 동의·권한 요청을 필요한 순서로 배치합니다. |
| ix-search-ux | 검색 입력부터 결과 확인·재검색까지의 경험을 설계할 때 사용합니다. 자동완성, 결과 배치·필터와 결과가 없는 상황의 안내를 구성합니다. |
| ix-state-machine | 복잡한 UI의 상태와 전환 조건을 명확히 정의할 때 사용합니다. 이벤트별 동작을 유한 상태 머신으로 표현해 다단계 폼과 예외 흐름을 정리합니다. |
| ui-aesthetic-usability | 화면의 첫인상과 시각적 완성도를 검토할 때 사용합니다. 심미성·사용성 효과를 참고해 일관된 표현과 신뢰감을 살피고 실제 사용 편의도 함께 점검합니다. |
| ui-color-system | 브랜드·중립·상태 색상을 체계적으로 정할 때 사용합니다. 색상 팔레트와 용도별 토큰을 정의하고 글자·배경의 대비와 접근성을 확인합니다. |
| ui-dark-mode | 다크 모드를 설계하거나 어두운 화면의 대비를 검토할 때 사용합니다. 배경·표면·글자 색의 관계와 밝기 전환 방식을 정리합니다. |
| ui-data-visualization | 데이터에 맞는 차트나 대시보드를 설계할 때 사용합니다. 비교 목적에 맞는 그래프 유형을 선택하고 색상·라벨·접근성을 검토합니다. |
| ui-illustration-style | 제품에 사용할 일러스트의 스타일과 적용 규칙을 정할 때 사용합니다. 그림의 시각적 표현, 색상과 온보딩·빈 화면 등 용도별 기준을 정리합니다. |
| ui-law-of-common-region | 배경이나 경계선으로 관련 요소를 묶을 때 사용합니다. 공통 영역의 법칙을 참고해 카드·패널·모달의 구분이 필요한지 검토합니다. |
| ui-law-of-proximity | 여백으로 요소의 관계와 그룹을 표현할 때 사용합니다. 근접성의 법칙을 참고해 폼·카드·섹션의 내부 간격과 그룹 사이 간격을 조정합니다. |
| ui-layout-grid | 페이지의 열·열 사이 간격·바깥 여백을 정할 때 사용합니다. 화면 폭이 달라져도 정렬을 유지하는 반응형 그리드를 설계합니다. |
| ui-readable-measure | 본문이 너무 넓거나 좁아 읽기 어려울 때 사용합니다. 글자 크기와 화면 폭에 맞춰 텍스트 영역의 너비와 한 줄 길이를 조정합니다. |
| ui-responsive-layout | 여러 화면 크기와 입력 방식에 맞는 배치를 설계할 때 사용합니다. 터치·마우스·키보드 동작과 전환 기준을 정하고 CoUI·Flutter·Jaspr 구현에 연결합니다. |
| ui-spacing-system | 제품 전반의 여백과 화면 밀도를 통일할 때 사용합니다. 기준 단위와 간격 단계를 정의하고 안쪽 여백·요소 간격·밀도 모드의 적용 규칙을 정합니다. |
| ui-typography-scale | 제목과 본문의 글꼴·크기·굵기를 체계적으로 정할 때 사용합니다. 단계별 글자 크기와 줄 간격의 관계를 정의해 화면의 가독성과 일관성을 맞춥니다. |
| ui-visual-hierarchy | 사용자가 먼저 볼 정보와 행동을 정할 때 사용합니다. 크기·굵기·색·여백·위치로 우선순위를 표현하고 화면을 훑어보기 쉬운지 검토합니다. |
| ui-von-restorff-effect | 여러 요소 중 하나를 가장 눈에 띄게 강조할 때 사용합니다. 폰 레스토프 효과를 참고해 주요 행동이나 추천 항목을 선택하고 주변 요소와의 차이를 조정합니다. |
| 런타임 권한과 선택 동의 | 로그인 후 알림, 위치, 카메라처럼 기기 권한을 요청하는 흐름을 설계할 때 사용한다. |
| 무드 — 차분하고 정돈된 업무 도구 | 이 문서는 CoUI 로 만드는 서비스 화면의 기본 「무드」를 정의하고, 화면이 그 무드에 맞는지 판단하는 순서를 적습니다. 색 값 · 모서리 · 내부 여백 같은 생김새는 CoUI |
| 문구 — 하우스 말투 | 이 문서는 CoUI 로 만드는 서비스 화면의 기본 말투를 정합니다. 교육 · 병원 · 커머스 · 사내 도구 어느 도메인이든 이 말투가 바닥선입니다. 서비스의 말투 문서(`voice |
| 브랜드 테마 → 컴포넌트 스타일 → 대표 화면 → 전체 확장 | 모든 시각·인터랙션 속성을 제품에 맞게 설계할 수 있다. 현재 라이브러리 preset이나 API에 없다는 |
| 참고 구현 — 한 사내 도구의 v2 시안에서 가져온 원칙 | 이 문서는 이 스킬의 규칙 여럿이 나온 참고 구현(한 사내 도구의 v2 시안)에서 무엇을 원칙으로 가져왔고 무엇을 가져오지 않았는지 적습니다. 가져온 것은 구조 · 위계 · |
| 참고 구현 — 한 손님용 앱 시안에서 가져온 원칙 |
이 문서는
손님용 앱 기본 예시
(
mood.md
1-1,
layout.md
10절)가 나온 참고 구현에서 무엇을 원칙으로 가져왔고 무엇을 가져오지 않았는지 적습니다.
|
| 토큰 쓰는 자리 — 면 · 선 · 글자 · 강조 · 상태색 | 이 문서는 CoUI 로 그리는 모든 서비스 화면에서 어느 CoUI 색 토큰을 어느 자리에 쓰는지 를 정합니다. 아래는 CoUI 기본 매핑 예시이며, 제품은 브랜드 테마에서 모 |
| 패턴 — 알림 · 상태 · 권한 · 도메인 컴포넌트 | 이 문서는 CoUI 로 만드는 모든 서비스 화면에서 알림 두 가지(Alert · Toast), 빈 상태 · 진행 · 실패 · 확인 대화상자, 11가지 상태 점검, 권한 구조, 도메 |
| 피그마 파일 구성 | 이 문서는 CoUI 로 그리는 서비스 피그마 파일의 페이지 순서 · 섹션과 프레임 이름 · 캡션과 배치 · 공통 화면 처리 · 새 화면을 만드는 순서 · 다크 확인 · 디자인 판단 |
| 화면 구성 · 여백 | 이 문서는 CoUI 로 만드는 서비스 화면의 뼈대를 정합니다. 셸, 페이지 순서, 본문의 데이터 표현, 상세 · 설정 · 만들기 흐름, 여백 리듬, 모서리 · 그림자 위계, 글자 |
Commands#
| 이름 | 설명 |
|---|---|
| /cc-designer:critique-screen — 화면 전체 시각 크리틱 9종 세트 | 화면에 대해 시각 크리틱 9종(위계·브랜드·구도·타이포·색·어포던스·정보 밀도·고유성·절제)을 모두 실행하고, 우선순위가 매겨진 수정 목록을 출력합니다. 출시 전에 화면을 전방위로 |
| /cc-designer:decide — 디자인 판단을 물어보지 않고 끝내기 | 디자인 판단을 되묻지 않고 확정합니다 — 근거 사다리(스펙→시안→코드 선례→디자인 시스템→정량 기준)로 결론을 내고 DDR 기록을 남깁니다. |
관련 플러그인#
| 플러그인 | 설명 |
|---|---|
| cc-blueprint | 피그마 디자인·화면 개발 워크플로우 — CoUI Figma 라이브러리로 페이지 저작(/design), 프레젠테이션 온리 화면 개발 + 위젯북(/build), Figma↔Widget |
| cc-bricks | cob(co-bricks) 기반 브릭 생성 가이드. kobic Clean Architecture feature 모듈 11종 + 그린필드 프로젝트 초기 세팅(project-init |
| cc-compass | 코코드 스킬 저장소 나침반 — 작업 유형(워크플로우/도구/규칙/레퍼런스)에 따라 알맞은 플러그인·커맨드·스킬로 안내 |
| cc-coui | CoUI 컴포넌트 라이브러리 (크로스플랫폼 컴포넌트 128종) + 조합/확장 가이드 |
| cc-coui-upgrade | 앱이 참조하는 coui 버전 올리기(Flutter 앱·Jaspr 웹 앱) — 형제 패키지를 한 커밋으로 고정하는 핀 계산·검사(coui_pin.py), 홉 계획, 시각 회귀 게이트 |
| cc-deeplink | 딥링크 & Universal Links 설정 관리 (AASA, assetlinks.json, GoRouter 연동, 도메인 마이그레이션) |
| cc-dev | 개발 사이클 자동화 (이슈 사이클, 버그 사이클, 세션, ZenHub, Agent Teams) |
| cc-e2e | flutter-skill 탐색 → Gherkin 초안 → Patrol 박제로 이어지는 E2E 시나리오 저작 파이프라인 |
| cc-flutter | Flutter 개발 핵심 (UI 패턴, Feature 생성, BLoC, 테스트) |
| cc-flutter-docs | Flutter 토픽별 레퍼런스 스킬 모음 (공식 문서 기반, 21개 스킬) |
| cc-i18n | 국제화 (Slang 기반 i18n) |
| cc-marionette | Marionette MCP 래퍼 — CoUI 컴포넌트에 맞춘 위젯 트리 단위 Flutter 자동화 (Widgetbook 회귀 테스트, 커스텀 인터랙티브 위젯 감지, 인프로세스 탭/ |
| cc-mcp-toolkit | mcp_flutter / mcp_toolkit 래퍼 (Arenukvern) — Dynamic Tools Registration 기반 앱 내부 MCP. 실행 중인 Flutter 앱이 |
| cc-pixel-loop | Figma + Marionette + Dart MCP를 활용한 픽셀 퍼펙트 Flutter UI 에이전틱 루프 (Read → Write → Reload → Capture → Comp |
| cc-product | 통합 제품개발 파이프라인 (Discovery → Specification → Planning → Design → Scaffold → Epic → Development → Launc |
| cc-quality | 코드 품질 (코드 리뷰, 체크리스트, 버그 리포트, QA Health Score) |
| cc-security | 보안 통합 — API/앱 보안, 보안 감사, CI 시크릿, 결제/IAP 엔드포인트 보안, 도서 PDF DRM (구 cc-uiux-security 확장) |
| cc-serverpod | Serverpod 백엔드 — 모델/엔드포인트 생성, 마이그레이션 + 심화 패턴(아키텍처, 인증, 캐싱, DB, IAP, 테스트; 구 cc-backend 통합) |
| cc-serverpod-docs | Serverpod 상세 레퍼런스 스킬 모음 (공식 문서 기반, 19개 스킬) |
| cc-spec | Jev 판정 게이트 — Seed spec 을 쓰고 TypeSafe Jev(판정 전용 모델)로 모호성·3관점 패널·드리프트를 보정 확률로 판정해 잠금 |
| cc-writing | 제품 화면 문구와 공개 웹 콘텐츠를 고객 질문·검증된 근거·실제 행동에 맞춰 작성하고 코드까지 반영하는 라이팅 플러그인 |
설치#
curl -fsSL https://skills.cocode.im/install.sh | bash -s -- --plugin cc-designer