Communitygithub.com

yetone/kill-ai-slop

웹 프로젝트에서 AI 생성물 특유의 진부한 시각적 요소와 카피를 찾아 제거합니다. 사용자가 'AI 슬롭 제거', 'AI 티 내기', '템플릿처럼 보이는 디자인 수정'을 요청할 때 사용합니다.

kill-ai-slop란 무엇인가요?

Kill AI Slop은 AI 생성 웹 프로젝트에서 흔히 발견되는 진부한 디자인 패턴(인디고→바이올렛 그라데이션, 글자 클리핑, 기본 시맨틱 팔레트, 복사기 어조 등)을 감지하고 수정하는 전문 기술(skill)입니다. HTML/CSS, React, Vue, Svelte, Astro, Tailwind, PHP, Markdown 등 다양한 기술 스택을 지원하며, Node.js 기반의 의존성 없는 스캐너를 사용하여 코드베이스에서 문제 지점을 찾아냅니다. 단순한 린트 규칙과 달리, 사람이 직접 각 히트를 검토하여 의도적인 디자인과 진정한 슬롭을 구분하고, 최소한의 변경으로 프로젝트의 독창성을 해치지 않으면서도 더 명확하고 인간적인 느낌을 되찾도록 돕습니다. 고유한 `deslop-ignore` 주석 시스템을 통해 의도적으로 유지할 패턴을 관리할 수 있으며, 모든 수정 사항은 사용자에게 보고되고 승인을 받은 후 적용됩니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/yetone/kill-ai-slop/tree/HEAD/skill

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Kill AI Slop

AI 슬롭(AI slop)은 독특한 방식으로 추합니다: 가능한 모든 스타일과 디테일을 쌓아올리면서도 하나의 초점을 정하지 않습니다. 그라데이션, 글로우, 마스코트, 이모지, 빛나는 카드 벽—모든 기본값이 한꺼번에 켜져서 모든 제품이 똑같은 템플릿처럼 보입니다. 썸네일에서는 '디자인된' 것처럼 보이지만, 누군가가 실제로 들여다보면 무너집니다. 여러분의 임무는 실제 사람이 선택할 만한 모습으로 되돌리는 것입니다.

모든 수정 작업에 적용되는 원칙:

  1. 장식하기 전에 결정하라. 모든 시각적 선택은 설명 가능해야 합니다.
  2. 하나의 강조, 하나의 목소리.
  3. 크기와 여백으로 위계를 만들어라. 단어에 색을 입히거나 폰트를 바꾸는 것은 지름길일 뿐입니다.
  4. 먼저 빼라. 추하지 않게 되는 첫 번째 움직임은 무언가를 제거하는 것입니다.
  5. 복사에서는 '강렬함'보다 '구체적'이어야 합니다.
  6. 장식은 의미가 있어야 합니다 — 아이콘, 배지, 콜아웃은 신호입니다.

워크플로우

아래 단계를 순서대로 따르세요. 사용자가 보고서를 확인하기 전에 일괄 수정하지 마세요.

1. 범위 설정

무엇을 스캔할지 확인하세요. 기본값은 앱/사이트 소스(node_modules, dist, build, .git, vendor, 잠금 파일, 축소된 파일은 건너뜀)입니다. 프로젝트가 여러 앱을 혼합하고 있다면 물어보세요.

2. 스캔

번들된 스캐너를 실행하세요. 각 틸(tell)의 코드 수준 신호를 코드베이스에서 grep하여 file:line 히트를 그룹화하여 출력합니다:

node scripts/scan.mjs <root>          # 사람이 읽을 수 있는 보고서
node scripts/scan.mjs <root> --json   # 기계가 읽을 수 있는, 분류용

순수 Node(의존성 없음)이며 파일을 절대 수정하지 않습니다. 출력물을 시작 지도로 사용하되, 각 히트는 코드를 읽어 확인하세요.

스캔 범위 좁히기: --only=01,06 / --skip=19로 틸 ID를 필터링하고, --exclude=legacy는 경로를 제거합니다(프로젝트 상대 경로의 부분 문자열 일치). --rules=extra.mjs는 추가 프로젝트별 또는 언어별 틸을 로드합니다(scripts/rules.ru.mjs는 배송된 러시아어 복사 예시이며 사용자 정의 템플릿 역할을 합니다). 사용자가 의도적이라고 확인한 히트는 소스에 deslop-ignore, deslop-ignore-next-line 06, 또는 deslop-ignore-file 주석으로 고정할 수 있습니다. ID 범위 형태를 선호하여 새로운 틸이 계속 표면화되도록 하세요.

3. 분류

모든 히트에 대해 파일을 열고 슬롭 vs. 의도적인지 결정하세요. 이 단계가 이 스킬을 린트 규칙과 구분 짓는 부분입니다. 그라데이션, 세리프, 또는 이모지는 실제로 방어 가능한 선택일 수 있습니다. 사용자가 분명히 선택한 것(브랜드 토큰, 로고, 의도적인 일러스트레이션)은 유지하세요. 기본값만 플래그 지정합니다.

references/taxonomy.md에서 각 틸이 무엇이며 왜 기계가 만든 것처럼 읽히는지, 그리고 references/detection.md에서 정확한 패턴과 일반적인 오탐지를 읽어보세요.

4. 보고

무엇이든 변경하기 전에 사용자에게 그룹화된 요약을 제공하세요: 각 틸, 확인된 file:line 히트, 왜 그런지에 대한 한 문장, 그리고 제안된 수정 사항. 다음 형식을 따르세요:

슬롭  src/Hero.tsx:12   인디고→바이올렛 그라데이션        → 하나의 단색 강조색
슬롭  src/Hero.tsx:31   그라데이션 클리핑 제목            → 단색 잉크, 크기 키우기
슬롭  src/Note.tsx:8    border-l-4 콜아웃 ×3             → 1개는 aside, 나머지는 본문
슬롭  copy.md:1         "단순한 X가 아니라 — Y입니다"    → 구체적인 내용을 말하세요
→ 4개 그룹, 11개 히트.

그런 다음 어떤 그룹을 적용할지, 아니면 모두 진행할지 물어보세요.

5. 수정

틸을 제거하면서도 의도와 기능을 유지하는 최소한의 변경을 적용하세요. references/fixes.md에서 틸별 before→after 패턴을 확인하세요.

  • 모든 호출 지점을 건드리기보다는 공유 토큰/컴포넌트를 편집하는 것을 선호하세요.
  • 새로운 브랜드 색상을 절대 발명하지 마세요. 팔레트를 변경해야 한다면 중성색 + 프로젝트의 기존 강조색을 제안하고 사용자가 확인하게 하세요.
  • 복사 의미를 유지하고, 구체적으로 만들되 단순히 삭제하지 마세요.
  • 수정 후 스캐너를 다시 실행하여 카운트가 감소했는지 확인하고, 의도적으로 남겨둔 히트(이유와 함께)를 기록하세요.

보호 장치

  • 저작자 존중. 익숙하지 않은 파일과 의도적인 장식은 누군가의 선택으로 대우하세요. 슬롭인지 확실하지 않으면 물어보고, 제거하지 마세요.
  • 작고 검토 가능한 diff. 관련 없는 코드를 절대 재포맷하지 마세요. git add -A를 절대 실행하지 말고, 명시적인 파일만 스테이징하고 다른 사람의 작업 중인 내용은 그대로 두세요.
  • 이 작업을 위한 새로운 의존성은 금지.
  • 가능하면 시각적으로 확인하세요. 개발 서버가 있다면 before와 after를 살펴보세요. 스캔 통과가 더 나은 페이지와 같지는 않습니다.

참고 자료

  • references/taxonomy.md — 35가지 틸: 각각이 무엇인지, 왜 슬롭인지, 수정 방법.
  • references/detection.md — 구체적인 ripgrep/regex 패턴 + 오탐지.
  • references/fixes.md — before→after 수정 패턴.
  • scripts/scan.mjs — 의존성 없는 스캐너.

관련 스킬