클로드로 화면 하나를 만드는 데서 시작해 이미지와 영상을 제작하고, 대화형 AI 제품을 설계하고, 결과의 안전성까지 점검하려면 어떤 스킬을 알아두면 좋을까요. 디자인 작업의 흐름을 다섯 분야로 나누고, 각 분야에서 눈여겨볼 스킬을 열 개씩 골랐습니다. 필요한 분야부터 하나씩 붙여도 되고, 전체 목록을 나만의 AI 제작 도구 상자로 활용해도 좋습니다.
핵심 화면을 만드는 스킬만으로 좋은 AI 제품이 완성되지는 않습니다. 시각 표현, 대화 흐름, 지시문, 품질과 안전을 함께 설계할 때 결과물이 실제로 쓸 수 있는 수준까지 올라갑니다.
먼저 보면 좋은 점
- 화면 디자인 10개로 레이아웃, 브랜드, 움직임과 브라우저 검수까지 다룹니다.
- 이미지·영상 제작 10개로 한 장의 그래픽부터 코드 영상과 3D 작업까지 확장합니다.
- AI 제품·프롬프트·신뢰와 안전 30개로 대화 경험과 결과 품질을 함께 설계합니다.
화면 디자인 추천 10개
1. `frontend-design` — 아이디어를 보기 좋은 웹 화면으로 빠르게 구현할 때 씁니다.
2. `impeccable` — 어긋난 색, 간격, 정렬과 시각적 위계를 찾아 화면을 한 번 더 다듬습니다.
3. `design-taste-frontend` — 기능은 갖췄지만 밋밋한 화면에 더 세련된 구성과 표현을 더합니다.
4. `animate` — 버튼, 카드, 화면 전환의 움직임을 부드럽고 자연스럽게 만듭니다.
5. `design-motion-principles` — 너무 빠르거나 튀는 움직임을 찾아 목적에 맞는 모션으로 고칩니다.
6. `theme-factory` — 색상, 글꼴, 여백과 구성요소의 스타일을 하나의 테마로 통일합니다.
7. `figma-to-code` — 피그마에서 만든 디자인을 실제 화면 코드로 옮길 때 활용합니다.
8. `playwright-mcp` — 브라우저에서 화면을 직접 열어 크기별 깨짐과 동작 문제를 확인합니다.
9. `brandkit` — 로고, 브랜드 색, 글꼴과 이미지 분위기를 한 세트로 관리합니다.
10. `designer-skills` — 화면 기획부터 구성, 제작과 최종 점검까지 디자인 작업의 흐름을 챙깁니다.
이미지·영상 제작 추천 10개
1. `nano-banana` — 말로 이미지를 만들고 원하는 부분을 다시 고치는 작업에 잘 맞습니다.
2. `banana-claude` — 이미지 생성에 필요한 장면, 구도, 빛과 분위기를 구체적인 지시문으로 정리합니다.
3. `canvas-design` — 카드뉴스, 포스터와 안내 이미지를 나중에도 수정할 수 있는 그래픽으로 만듭니다.
4. `algorithmic-art` — 규칙과 코드를 이용해 반복 무늬, 배경과 독특한 시각 패턴을 만듭니다.
5. `data-visualization` — 복잡한 숫자와 관계를 이해하기 쉬운 차트와 그래프로 바꿉니다.
6. `svg-logo-designer` — 크기를 바꿔도 선명한 로고를 만들고 여러 형태의 시안을 비교합니다.
7. `remotion-superpowers` — 장면, 자막, 움직임과 소리를 코드로 제어해 영상을 통째로 제작합니다.
8. `claude-remotion` — 자연어 지시로 짧은 소개 영상과 소셜 콘텐츠를 빠르게 만듭니다.
9. `blender-motion` — 입체적인 제품, 공간과 카메라 움직임이 필요한 3D 화면과 영상을 제작합니다.
10. `aftereffects-motion` — 자막, 전환, 합성과 시각 효과를 더해 영상의 완성도를 높입니다.
AI 제품 만들기 추천 10개
1. `context-window-design` — 대화에서 무엇을 기억하고 무엇을 덜어낼지 정해 AI의 기억을 관리합니다.
2. `conversation-patterns` — 대화가 길어지거나 잠시 끊겨도 자연스럽게 다시 이어지는 흐름을 설계합니다.
3. `generative-ui` — AI의 답을 긴 글에만 두지 않고 버튼, 카드, 표와 선택 화면으로 보여줍니다.
4. `progressive-disclosure` — 많은 기능과 정보를 한꺼번에 꺼내지 않고 필요한 순간에 차근차근 공개합니다.
5. `multimodal-orchestration` — 글, 이미지, 음성, 파일과 외부 도구를 한 작업 안에서 자연스럽게 연결합니다.
6. `mixed-initiative-flow` — AI가 먼저 제안할 때와 사용자가 방향을 정할 때를 나눠 협업의 리듬을 만듭니다.
7. `frustration-detection` — 반복 질문, 짧아진 답과 부정적인 표현을 읽어 사용자의 불편을 알아챕니다.
8. `feedback-loops` — 사용자의 선택과 수정 결과를 다음 작업에 반영해 제품을 계속 나아지게 합니다.
9. `human-in-the-loop` — 중요한 판단이나 되돌리기 어려운 실행 앞에서 사람이 확인하도록 합니다.
10. `agent-role-design` — 조사, 작성, 검수와 실행처럼 AI의 역할을 나눠 서로 확인하게 만듭니다.
프롬프트 설계 추천 10개
1. `system-prompt-structure` — 역할, 목표, 사용 정보, 금지 행동과 출력 형식의 뼈대를 잡습니다.
2. `persona-architecture` — AI의 성격, 관점과 말투가 대화마다 흔들리지 않도록 기준을 만듭니다.
3. `tone-calibration` — 설명, 사과문, 안내와 긴급 상황에 맞게 말의 온도와 단정함을 조절합니다.
4. `emotional-design` — 사용자의 감정 상태를 고려해 공감, 정보와 다음 행동의 순서를 설계합니다.
5. `template-design` — 반복 업무에 바로 다시 쓸 수 있는 입력칸과 출력 구조를 만듭니다.
6. `few-shot-patterns` — 원하는 답의 좋은 예시를 보여줘 형식과 판단 기준을 더 정확하게 전달합니다.
7. `chain-of-thought-design` — 복잡한 문제를 확인 가능한 작은 단계와 중간 결과로 나눕니다.
8. `constraint-specification` — 글의 길이, 형식, 포함할 내용과 하지 말아야 할 일을 분명히 적습니다.
9. `context-engineering` — 현재 작업에 필요한 정보만 골라 적절한 순서와 분량으로 제공합니다.
10. `prompt-versioning` — 지시문의 변경 이유와 결과를 버전별로 남겨 더 좋은 형태로 개선합니다.
신뢰·안전 추천 10개
1. `guardrail-design` — AI가 해도 되는 일과 넘지 말아야 할 선을 구체적으로 정합니다.
2. `trust-calibration` — 확실한 사실과 추정, 확인하지 못한 내용을 구분해 과신을 줄입니다.
3. `transparency-patterns` — AI가 사용한 정보, 할 수 있는 일과 한계를 사용자가 이해하게 보여줍니다.
4. `harm-anticipation` — 잘못된 답이나 실행이 만들 수 있는 피해를 미리 찾아 예방 장치를 둡니다.
5. `escalation-design` — 위험하거나 복잡한 상황을 적절한 사람과 전문 절차로 넘기게 합니다.
6. `bias-detection-design` — 특정 집단이나 관점을 불공정하게 다루는 답을 찾아 바로잡습니다.
7. `output-quality-rubrics` — 정확성, 완결성, 문체와 안전성을 기준표로 만들어 답의 품질을 점검합니다.
8. `failure-taxonomy` — 사실 오류, 지시 누락, 도구 실패와 위험 행동처럼 실패를 유형별로 나눕니다.
9. `task-success-metrics` — 작업 완료율, 수정 횟수와 사용자 만족처럼 성공 여부를 숫자로 확인합니다.
10. `handoff-protocols` — AI가 더 진행하지 말아야 할 때 필요한 정보와 함께 사람에게 자연스럽게 넘깁니다.
추천 목록은 이렇게 활용하면 좋습니다
처음부터 50개를 모두 한 작업에 붙일 필요는 없습니다. 지금 만드는 것이 웹 화면인지, 이미지인지, 대화형 제품인지 먼저 정한 뒤 해당 분야의 생성 도구와 검수 도구를 하나씩 골라 시작하면 됩니다.
이름이 실제 설치형 스킬, 외부 도구, 설계 방법론을 함께 가리킬 수 있으므로 설치할 때는 제작자와 공식 배포처만 확인하면 됩니다. 설치형 도구가 아니어도 팀의 프롬프트, 체크리스트와 평가 기준으로 충분히 활용할 수 있습니다.
화면 디자인은 만들기와 눈으로 확인하기를 묶습니다
화면을 예쁘게 만드는 도구 하나만으로는 완성도가 잘 오르지 않습니다. 코드를 생성하는 역할과 실제 화면을 열어 어긋남을 찾는 역할이 달라서입니다. 예를 들어 `frontend-design`이나 `impeccable` 계열의 지침으로 화면을 만든 뒤, 브라우저 자동화로 모바일과 데스크톱 화면을 직접 확인하는 식이 더 안정적입니다.
`theme-factory`와 `brandkit`처럼 색, 글자, 로고 규칙을 다루는 역할은 매 화면마다 새 취향을 발휘하지 않게 해줍니다. 먼저 색상 수, 글자 크기 단계, 여백 단위와 버튼 모양을 정해 두면 생성 도구가 바뀌어도 화면의 인상은 크게 흔들리지 않습니다.
추천 조합은 단순합니다. 새 화면 제작에는 생성 역할 하나, 브라우저 검수 하나, 브랜드 규칙 하나를 둡니다. 이미 있는 화면을 고칠 때는 새 생성 도구를 추가하기보다 `impeccable` 같은 점검 역할과 브라우저 검수에 집중하는 편이 낫습니다.
이미지와 영상은 결과물 형식부터 정합니다
`nano-banana`, `canvas-design`, `remotion-superpowers`, `blender-motion`은 모두 시각 결과를 다루지만 필요한 작업 환경은 완전히 다릅니다. 한 장의 대표 이미지를 만들려는 사람에게 영상 편집과 3D 도구까지 한꺼번에 붙이는 것은 도움이 되지 않습니다.
먼저 최종 파일을 정하면 선택지가 줄어듭니다. 사진이나 일러스트 한 장이면 이미지 생성·편집 도구, 수정 가능한 카드뉴스면 캔버스나 벡터 기반 도구, 반복 제작하는 짧은 영상이면 코드 기반 영상 도구, 공간과 입체 움직임이 핵심이면 3D 도구가 맞습니다.
여기에 반드시 검수 조건을 붙여야 합니다. 이미지라면 글자 오탈자, 손과 물체의 형태, 브랜드 색, 사용권과 출력 크기를 확인합니다. 영상이라면 첫 장면의 이해도, 자막 안전 영역, 소리 없이 봐도 뜻이 통하는지, 프레임 끊김과 최종 길이를 확인합니다. 프롬프트를 잘 쓰는 능력보다 이 합격 조건이 결과의 차이를 더 크게 만듭니다.
AI 제품 설계 항목은 기능 목록이 아니라 대화 흐름입니다
`context-window-design`, `conversation-patterns`, `generative-ui` 같은 항목은 버튼 하나로 켜는 장식이 아닙니다. 사용자가 무엇을 말했고, 시스템이 무엇을 기억하며, 다음 행동을 어떤 형태로 보여줄지 정하는 제품 설계에 가깝습니다.
가령 여행 계획을 돕는 AI라면 모든 정보를 한 번에 묻기보다 날짜와 지역부터 받고, 다음 단계에서 예산과 취향을 묻는 편이 자연스럽습니다. 답변도 긴 문장만 내놓기보다 후보 카드와 수정 버튼을 함께 보여줄 수 있습니다. 사용자가 지친 기색을 보이면 선택지를 줄이고, 결제나 삭제처럼 되돌리기 어려운 순간에는 사람의 확인을 받습니다.
이때 필요한 것은 스킬 열 개가 아니라 상태를 적은 작은 흐름도입니다. “현재 아는 정보”, “다음에 물을 한 가지”, “도구를 실행하기 전 확인”, “실패했을 때 돌아갈 곳”을 정하면 기억 관리, 점진적 공개, 사람 개입과 인계 원칙이 한 흐름 안에서 작동합니다.
프롬프트 10개는 하나의 문서로 합칠 수 있습니다
시스템 지시문 구조, 성격, 말투, 예시, 제약, 문맥 관리와 버전 관리는 따로 떨어진 기술처럼 보이지만 실제로는 하나의 작업 명세서에 들어갑니다. 역할과 목표를 먼저 쓰고, 사용할 정보와 하지 말아야 할 일을 정한 뒤, 좋은 입력과 출력 예시를 붙이는 순서면 충분합니다.
복잡한 문제를 다룬다고 해서 모델의 숨은 사고 과정을 길게 요구할 필요는 없습니다. 대신 필요한 중간 결과를 밖으로 드러내는 편이 좋습니다. 예를 들어 “후보 세 개를 비교표로 만들고, 선택 이유와 확인이 필요한 사실을 나눠 써라”처럼 검수할 수 있는 산출물을 요구합니다.
버전 관리도 중요합니다. 지시문을 고칠 때마다 전체를 덮어쓰면 무엇이 좋아졌는지 알 수 없습니다. 날짜나 버전을 붙이고, 바꾼 이유와 통과해야 할 대표 사례 몇 개를 함께 보관하면 프롬프트가 감에 의존하는 문장에서 반복해서 개선할 수 있는 제품 자산으로 바뀝니다.
신뢰와 안전은 마지막 점검표가 아닙니다
가드레일, 편향 점검, 품질 기준과 사람에게 넘기는 절차는 출시 직전에 덧붙이는 문구가 아닙니다. 어떤 일을 자동으로 해도 되는지 정하는 순간부터 함께 설계해야 합니다. 식당 추천의 실수와 송금 실행의 실수는 피해가 다르므로 같은 확인 절차를 쓸 수도 없습니다.
가벼운 초안 작성은 자동 실행하고 사용자가 고치게 할 수 있습니다. 외부 전송, 결제, 삭제, 개인정보 처리처럼 되돌리기 어렵거나 피해가 큰 행동은 실행 직전에 대상과 범위를 다시 보여주고 확인받아야 합니다. 확실하지 않은 정보는 추측으로 채우지 않고 무엇을 확인하지 못했는지 표시합니다.
`output-quality-rubrics`, `failure-taxonomy`, `task-success-metrics`가 가리키는 핵심도 여기에 있습니다. 좋은 답의 조건을 미리 적고, 실패를 몇 가지 유형으로 나누고, 실제 성공 여부를 측정해야 합니다. “자연스러운 답변” 같은 모호한 기준보다 “요청한 세 항목을 모두 포함했는가”, “근거 없는 숫자가 없는가”, “실행 전 확인을 받았는가”처럼 판정 가능한 기준이 낫습니다.
목적별 추천 목록은 이렇게 고를 수 있습니다
웹사이트나 앱 화면을 만드는 사람에게는 `frontend-design`, `impeccable`, `playwright-mcp`, `theme-factory` 조합을 먼저 권합니다. 첫 도구로 화면의 큰 구조를 만들고, 두 번째로 색과 정렬을 다듬고, 브라우저에서 실제 결과를 확인한 뒤, 마지막으로 색·글자·간격 규칙을 고정하는 흐름입니다. 이미 디자인 시스템이 있다면 `theme-factory`보다 기존 브랜드 규칙을 우선합니다.
브랜드 이미지와 카드뉴스가 목적이라면 `brandkit`, `nano-banana`, `canvas-design` 세 가지면 시작할 수 있습니다. 로고·색·폰트 기준을 먼저 정하고, 이미지 생성 도구로 소재를 만든 뒤, 수정 가능한 캔버스에서 문구와 배치를 마무리합니다. 데이터가 중심인 콘텐츠만 `data-visualization`을 추가합니다.
짧은 영상을 반복해서 만들려면 `banana-claude`로 장면별 이미지 지시를 정리하고 `remotion-superpowers`나 `claude-remotion` 가운데 하나를 고르는 편이 좋습니다. 입체 공간과 카메라 움직임 자체가 결과의 핵심일 때만 `blender-motion`을 추가합니다. 단순한 숏폼에 3D 효과와 후반 작업 도구까지 모두 붙일 필요는 없습니다.
대화형 AI 제품을 설계한다면 `conversation-patterns`, `progressive-disclosure`, `generative-ui`, `human-in-the-loop`를 추천합니다. 대화가 이어지는 규칙을 잡고, 한 번에 보여주는 정보를 줄이고, 답을 버튼과 카드로 바꾸며, 중요한 실행 전에 사람이 확인하도록 만드는 조합입니다. 긴 대화를 실제로 기억해야 할 때만 `context-window-design`을 더합니다.
프롬프트를 자주 관리하는 팀에는 `system-prompt-structure`, `constraint-specification`, `few-shot-patterns`, `prompt-versioning`이 실용적입니다. 역할과 목표를 정하고, 금지 조건과 출력 형식을 명시하고, 좋은 예시를 붙인 뒤, 변경 이력을 남기는 순서입니다. 감정적인 상담이나 브랜드 고객 응대처럼 말투가 중요한 경우에만 `tone-calibration`과 `emotional-design`을 추가합니다.
신뢰와 안전이 중요한 서비스에는 `guardrail-design`, `trust-calibration`, `output-quality-rubrics`, `handoff-protocols`를 기본으로 권합니다. 하지 말아야 할 행동, 확신이 낮을 때의 표현, 답변 합격 기준, 사람에게 넘길 조건을 차례로 정합니다. 의료·금융·법률이나 외부 전송·결제·삭제를 다루면 `harm-anticipation`과 `escalation-design`도 함께 검토해야 합니다.
처음 고른다면 이 다섯 역할이면 충분합니다
분야를 아직 정하지 못했다면 화면을 다듬는 `impeccable`, 실제 결과를 보는 `playwright-mcp`, 시각 소재를 만드는 `nano-banana`, 지시문의 뼈대를 잡는 `system-prompt-structure`, 결과의 합격선을 정하는 `output-quality-rubrics`부터 살펴볼 수 있습니다. 각각 제작, 검수, 이미지, 지시, 품질이라는 서로 다른 구멍을 메워서 겹침이 적습니다.
다만 이 다섯 이름이 모두 같은 설치 방식으로 제공된다는 뜻은 아닙니다. `impeccable`처럼 실제 스킬로 배포되는 항목이 있는 반면, 시스템 지시문 구조나 품질 평가표는 팀 문서와 테스트로 직접 구현하는 편이 더 맞을 수 있습니다. 이름보다 역할을 먼저 고르고, 공식 배포처가 확인되는 도구만 설치하는 것이 안전합니다.
처음에는 세 가지 조합만 만들면 됩니다
웹 화면을 고치려면 화면 개선 지침, 브라우저 검수, 브랜드 규칙을 묶습니다. 카드뉴스를 만들려면 이미지 생성, 수정 가능한 편집 도구, 출력 규격 검사를 묶습니다. 고객 응대 AI를 만들려면 대화 흐름, 지시문 명세, 사람에게 넘기는 조건을 묶습니다.
각 조합을 한 번 실행한 뒤에는 결과보다 실패 기록을 먼저 남깁니다. 화면이 모바일에서 잘렸는지, 이미지의 문자가 틀렸는지, AI가 묻지 않은 정보를 지어냈는지 적습니다. 다음 작업에서 그 실패를 막는 규칙 하나만 추가하면 도구 상자는 작아도 점점 단단해집니다.
좋은 스킬 목록의 가치는 50개라는 숫자에 있지 않습니다. 내가 놓친 역할을 보여주는 지도라는 데 있습니다. 지도 전체를 짐처럼 들고 다니기보다, 오늘 갈 곳에 필요한 도구만 골라 쓰는 것이 더 빠르고 안전합니다.
스킬별 Git 주소와 확인 결과
확인일: 2026-07-26. GitHub 검색 결과만으로 연결하지 않고 저장소를 직접 내려받아 동일 이름의 SKILL.md 또는 공식 대체 스킬 경로를 확인했습니다. GitHub API로 저장소의 폐쇄·보관 여부, 최근 갱신일과 라이선스를 다시 확인하고, 설치 스크립트·실행 파일·훅·MCP·외부 API 키 요구도 별도로 살폈습니다. 커뮤니티 저장소는 확인 이후에도 바뀔 수 있으므로 설치 전 링크의 최신 변경분을 다시 검토해야 합니다.
-
frontend-design · anthropics/skills
— 동일 이름의 Anthropic 공식 스킬 확인
공식 저장소. 전체 저장소가 아니라 필요한 스킬 경로와 포함 스크립트만 검토해 설치하세요. -
impeccable · pbakaus/impeccable
— 동일 이름의 커뮤니티 스킬 확인
CLI와 생성 파일이 포함됩니다. 설치 명령 실행 전 변경 파일과 권한 범위를 확인하세요. -
design-taste-frontend · Leonxlnx/taste-skill
— 동일 이름의 SKILL.md 확인
커뮤니티 저장소이며 현재 기본판은 실험 버전입니다. 프로젝트 단위 설치와 변경사항 검토를 권합니다. -
animate · pbakaus/impeccable
— 독립 스킬이 아닌 Impeccable의 모션 기능
별도 패키지로 찾지 말고 Impeccable 저장소의 해당 문서와 CLI 범위를 함께 확인하세요. -
design-motion-principles · kylezantos/design-motion-principles
— 동일 이름의 SKILL.md 확인
주로 지침 문서로 구성된 커뮤니티 스킬입니다. 외부 인물의 원칙을 재해석한 자료임을 확인했습니다. -
theme-factory · anthropics/skills
— 동일 이름의 Anthropic 공식 스킬 확인
테마 파일을 생성·수정하므로 작업 전 변경 대상과 출력 경로를 확인하세요. -
figma → code · openai/skills
— 원문 이름의 단일 공식 스킬 대신 동일 역할의 공식 스킬 연결
Figma 연동은 외부 디자인 데이터 접근 권한이 필요합니다. 읽을 파일과 팀 범위를 최소화하세요. -
playwright-mcp · microsoft/playwright-mcp
— Microsoft 공식 MCP 서버 확인
스킬이 아니라 브라우저를 조작하는 MCP입니다. 로그인 세션·다운로드·외부 전송 권한을 제한하고 격리된 프로필을 쓰세요. -
brandkit · Leonxlnx/taste-skill
— 동일 이름의 SKILL.md 확인
커뮤니티 지침형 스킬입니다. 생성 로고의 상표 유사성과 사용권은 별도로 검토해야 합니다. -
designer-skills · Owl-Listener/designer-skills
— 63개 디자인 스킬을 묶은 저장소 확인
묶음 전체 대신 필요한 하위 스킬만 설치해 컨텍스트와 권한 범위를 줄이세요. -
nano-banana · kkoppenhaver/cc-nano-banana
— 동일 이름의 Claude Code 스킬 확인
Gemini CLI 확장과 API 키가 필요합니다. 키를 명령줄·Git·대화에 넣지 말고 공식 확장 주소를 다시 확인하세요. -
banana-claude · AgriciDaniel/banana-claude
— 동일 목적의 Banana 스킬 확인
설치 스크립트가 홈 디렉터리와 MCP 설정을 수정합니다. curl 파이프 설치는 피하고 clone 후 스크립트를 읽어 실행하세요. -
canvas-design · anthropics/skills
— 동일 이름의 Anthropic 공식 스킬 확인
출력 파일과 사용 글꼴·이미지의 라이선스를 함께 확인하세요. -
algorithmic-art · anthropics/skills
— 동일 이름의 Anthropic 공식 스킬 확인
생성 코드를 실행하므로 브라우저·로컬 파일 접근 범위를 제한하고 결과를 검토하세요. -
data-visualization · Owl-Listener/designer-skills
— 동일 이름의 SKILL.md 확인
지침 중심 스킬입니다. 입력 데이터에 개인정보나 회사 기밀을 넣기 전 사용 환경을 확인하세요. -
svg-logo-designer · rknall/claude-skills
— 동일 이름의 SKILL.md 확인
실행 스크립트 없는 지침형 스킬이지만 저장소 라이선스 표기가 명확하지 않아 결과물 사용 조건을 별도 확인하세요. -
remotion-superpowers · DojoCodingLabs/remotion-superpowers
— 동일 이름의 Claude Code 플러그인 확인
셸 훅과 5개 MCP, 여러 외부 API 키를 사용합니다. 기본 일괄 설치보다 필요한 서버만 골라 격리 환경에서 검토하세요. -
claude-remotion · remotion-dev/skills
— 원문 이름의 단일 공식 스킬 대신 Remotion 공식 제작 스킬 연결
Node 패키지 설치와 영상 렌더링 코드를 실행합니다. 프로젝트 디렉터리와 출력 경로를 제한하세요. -
blender-motion · LobzyJay/motion-design-with-claude
— 동일 이름의 SKILL.md 확인
지침형 스킬이지만 Blender 파이썬 실행으로 이어집니다. 받은 장면 파일과 스크립트는 별도 작업 공간에서 여세요. -
aftereffects-motion · LobzyJay/motion-design-with-claude
— 동일 이름의 SKILL.md 확인
After Effects 스크립트 실행을 전제로 합니다. 프로젝트 백업 후 스크립트의 파일 쓰기와 렌더 경로를 검토하세요. -
context-window-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
지침 중심의 MIT 커뮤니티 스킬. 외부 실행 파일 없이 사용할 수 있습니다. -
conversation-patterns · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
지침 중심의 MIT 커뮤니티 스킬. 실제 대화 데이터에는 개인정보를 넣지 마세요. -
generative-ui · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
생성 UI가 실행하는 행동과 링크를 애플리케이션에서 별도로 검증해야 합니다. -
progressive-disclosure · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
지침 중심의 MIT 커뮤니티 스킬입니다. -
multimodal-orchestration · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
파일·이미지·도구를 함께 다룰 때 각 연결 도구의 데이터 전송 범위를 따로 확인하세요. -
mixed-initiative-flow · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
지침 중심의 MIT 커뮤니티 스킬입니다. -
frustration-detection · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
감정 추정은 오판할 수 있으므로 민감한 사용자 분류나 자동 제재에 직접 연결하지 마세요. -
feedback-loops · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
사용자 피드백 저장 시 동의·보존 기간·삭제 절차를 함께 설계하세요. -
human-in-the-loop · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
사람 확인 단계가 실제 실행 권한을 차단하는지 애플리케이션 수준에서 시험하세요. -
agent-role-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
역할 분리는 권한 분리와 다릅니다. 각 에이전트의 도구 권한을 별도로 제한하세요. -
system-prompt-structure · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
지시문에 비밀키·개인정보·내부 접근 주소를 직접 넣지 마세요. -
persona-architecture · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
실존 인물 사칭이나 과도한 정서 의존을 유도하지 않도록 검토하세요. -
tone-calibration · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
말투가 정확성이나 위험 고지를 약화하지 않는지 평가하세요. -
emotional-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
감정 추정을 의료·심리 진단처럼 표현하거나 취약성을 이용하지 마세요. -
template-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
템플릿 변수의 외부 입력은 명령·HTML·SQL 삽입 위험을 별도로 검사하세요. -
few-shot-patterns · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
예시에 실제 고객 정보나 저작권 있는 원문을 넣지 마세요. -
chain-of-thought-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
숨은 사고과정 공개를 요구하기보다 검증 가능한 중간 결과와 근거를 요청하세요. -
constraint-specification · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
프롬프트 제약만 믿지 말고 중요한 제한은 코드와 권한에서도 강제하세요. -
context-engineering · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
수집 문서의 프롬프트 인젝션과 민감정보를 필터링한 뒤 문맥에 넣으세요. -
prompt-versioning · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
버전 기록에 운영 비밀이나 실제 사용자 입력을 복제하지 마세요. -
guardrail-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
지침형 가드레일만으로 충분하지 않습니다. 고위험 행동은 코드·권한·승인 절차로 차단하세요. -
trust-calibration · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
확신 표현과 실제 정확도가 맞는지 별도 평가 데이터로 확인하세요. -
transparency-patterns · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
투명성 설명에 내부 지시문·비밀·개인정보를 노출하지 않도록 구분하세요. -
harm-anticipation · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
위험 목록을 실제 차단·복구 시험과 연결해야 합니다. -
escalation-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
인계 대상과 응답 시간, 실패 시 대체 경로가 실제 운영되는지 확인하세요. -
bias-detection-design · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
편향 검사는 데이터와 평가자 구성에 따라 달라지므로 단일 점수를 절대 기준으로 쓰지 마세요. -
output-quality-rubrics · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
평가표가 안전성의 증거를 대신하지 않으며 고위험 결과는 사람이 확인해야 합니다. -
failure-taxonomy · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
실패 로그에 사용자 원문과 민감정보가 남지 않도록 익명화하세요. -
task-success-metrics · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
달성률만 최적화해 안전·품질을 희생하지 않도록 함께 측정하세요. -
handoff-protocols · Owl-Listener/ai-design-skills
— 동일 이름의 SKILL.md 확인
인계 문서에는 업무에 필요한 최소 정보만 넣고 자격증명은 전달하지 마세요.
메모
- 입문 추천: `impeccable`, `playwright-mcp`, `nano-banana`, `system-prompt-structure`, `output-quality-rubrics` 역할부터 확인
- 설치 전 확인: 공식 배포처, 제작자, 지원 환경, 권한, 최근 수정일, 예시 결과
- 작업 시작: 원하는 결과물을 파일이나 화면 단위로 한 문장에 적기
- 최소 구성: 생성 역할 하나, 직접 확인하는 역할 하나, 합격 기준 하나
- 운영 기록: 실패 유형과 수정한 규칙을 버전별로 남기기