site-review-fix는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.
사용자가 “검수 결과 바탕으로 수정해줘”, “site-review 결과를 반영해줘”, “사이트 검수 이슈 고치고 재검수해줘”, “기능보강까지 진행해줘”라고 요청할 때 사용한다. site-review 리포트나 실제 사이트 검수 결과를 입력으로 받아 우선순위대로 수정, 기능보강, 회귀 확인, 재검수 리포트를 수행한다.
사용 방법
Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.
사용 예:
site-review-fix 스킬 사용해줘.
이 작업은 site-review-fix 기준으로 진행해줘.연관스킬
이 스킬과 함께 쓰면 좋은 관련 스킬입니다.
원본 위치
.codex/skills/site-review-fix/SKILL.md
SKILL.md
---
name: site-review-fix
description: 사용자가 “검수 결과 바탕으로 수정해줘”, “site-review 결과를 반영해줘”, “사이트 검수 이슈 고치고 재검수해줘”, “기능보강까지 진행해줘”라고 요청할 때 사용한다. site-review 리포트나 실제 사이트 검수 결과를 입력으로 받아 우선순위대로 수정, 기능보강, 회귀 확인, 재검수 리포트를 수행한다.
---
# Site Review Fix
## 버전
- v1.1.1 (2026-07-15): 단건 수정 후 같은 이슈 클래스 전체를 검색·수정·재검수하는 회귀 방지 규칙을 추가했다. 스킬 자체를 수정한 경우 공개 프롬프트/게시글/패키지 버전 문구까지 동기화하도록 보강했다.
## 목적
- `site-review` 검수 결과를 실제 수정 작업으로 연결한다.
- Blocker/High 이슈를 먼저 해결하고, 필요한 기능보강을 최소 범위로 구현한다.
- 수정 후 같은 경로를 재검수해 해결 여부와 남은 리스크를 확인한다.
## 절대 규칙
- 검수 결과 없이 막연히 “좋게 고쳐줘”라고 하면 먼저 핵심 URL과 목표를 확인하거나 `site-review`를 선행한다.
- 사용자가 수정 승인을 했을 때만 파일, DB, 설정을 변경한다.
- Blocker와 High를 먼저 처리한다. Medium/Low는 사용자의 범위나 시간에 맞춰 분리한다.
- 기획 판단이 필요한 변경은 바로 구현하지 말고 A/B/C 선택지를 점수와 함께 제시하고, 사용자가 선택한 안만 구현한다.
- 깨진 링크, 상세 본문 미노출, 저장 실패, 잘못된 active 상태처럼 명확한 결함은 별도 선택지 없이 우선 수정할 수 있다.
- 사용자 데이터 삭제, 대량 DB 변경, 배포, 결제/권한 정책 변경은 별도 확인 없이 진행하지 않는다.
- 수정 후에는 반드시 재검수 결과를 남긴다.
- 하나의 결함을 고치면 같은 **이슈 클래스** 전체를 검색한다. 예: 다운로드 URL을 고쳤으면 모든 스킨/템플릿/프론트엔드의 다운로드 href, 관련 API 라우트, 라우터 등록 순서, 정적 파일/Nginx 충돌 가능성을 함께 확인한다.
- “수정 완료”라고 말하기 전에 같은 패턴의 미수정 항목이 남았는지 `rg` 등으로 증거를 남긴다. 남은 항목이 있으면 완료가 아니라 부분 완료로 보고한다.
- 스킬 문서를 수정한 경우, 연결된 공개 프롬프트 글이나 배포 패키지가 있으면 버전·변경 요약·다운로드 안내 문구를 함께 업데이트한다. 실제 게시글 반영이 권한/DB/배포 때문에 막히면 파일 업데이트와 미반영 사유를 분리해 보고한다.
## 입력으로 받아야 할 것
- 대상 사이트 URL 또는 로컬 실행 경로
- `site-review` 검수 리포트 또는 이슈 목록
- 수정 범위: 전체 / Blocker+High만 / 특정 이슈만
- 가능하면 테스트 계정과 핵심 사용자 흐름
## 진행 순서
### 1. 이슈 정리
- 검수 리포트의 이슈를 Blocker, High, Medium, Low로 재정렬한다.
- 각 이슈를 “원인”, “수정 대상”, “확인 방법”으로 쪼갠다.
- 중복 이슈는 합치고, 같은 수정으로 해결되는 항목은 묶는다.
- 사이트별로 Fix 체크리스트를 만든다. 여러 사이트를 다루면 사이트 도메인 또는 site_id별로 분리한다.
- 각 항목에 상태를 붙인다: `todo`, `doing`, `done`, `blocked`, `defer`.
### 2. 수정 계획
- 먼저 고칠 항목 1~5개를 선정한다.
- 각 항목에 변경 파일/DB/설정, 예상 영향, 검증 방법을 적는다.
- 기능보강이 필요한 경우 기존 패턴을 우선 사용한다.
- UI/UX 보강은 실제 사용자 흐름을 기준으로 최소 변경부터 진행한다.
- UX/IA/메뉴/화면 구조처럼 선택지가 있는 항목은 `Fix 선택안`을 먼저 만든다.
- 메뉴별 소개문구, 빈 상태, CTA, 메타 설명처럼 텍스트 맥락 문제가 있으면 먼저 텍스트 인벤토리를 만들고 메뉴 기대치와 대조한다.
### 2-1. Fix 선택안 작성
아래에 해당하면 구현 전에 A/B/C 안을 만든다.
- 메뉴명과 화면 내용의 불일치를 어떻게 풀지 결정해야 한다.
- 카드형, 게시판형, 가이드형, 마켓형 등 UI 패턴 선택이 필요하다.
- 빈 상태, CTA, 필터, 사이드바, 상세 화면 정보 구조를 어떤 깊이로 보강할지 판단이 갈린다.
- 비용이 큰 기능보강, 운영 정책, 결제/권한/회원 흐름처럼 사용자의 의사결정이 필요하다.
각 안은 100점 만점으로 평가한다. 점수는 아래 기준으로 매긴다.
- 사용자 기대 일치: 25점
- 구현 난이도와 리스크: 20점
- 현재 코드/디자인 패턴 적합성: 20점
- 운영 확장성: 15점
- 공개 전 점수 상승 효과: 20점
반드시 추천안을 하나 고르고, 추천 이유와 포기하는 트레이드오프를 같이 적는다.
사용자가 이미 특정 방향을 강하게 말했으면 그 방향을 A안 또는 추천안으로 둔다.
```text
Fix 선택안
[A안] 최소 수정형 — 88점
- 내용:
- 장점:
- 단점:
- 예상 수정:
- 추천 여부:
[B안] 사용자 흐름 보강형 — 94점
- 내용:
- 장점:
- 단점:
- 예상 수정:
- 추천 여부: 추천
[C안] 구조 개편형 — 90점
- 내용:
- 장점:
- 단점:
- 예상 수정:
- 추천 여부:
선택 필요
- 어떤 안으로 진행할지 사용자의 선택을 기다린다.
```
선택지가 필요한데 사용자가 “알아서 해”라고 한 경우에는 추천안을 선택해 진행한다.
### 3. 구현
- 기존 코드와 데이터 구조를 읽고 패턴에 맞춰 수정한다.
- 링크 깨짐, 메뉴 URL, active 상태, 빈 상태, 폼 검증, 반응형 깨짐처럼 명확한 문제는 바로 고친다.
- “좋아 보이게” 식의 주관적 변경은 하지 않는다. 사용자 목표에 연결되는 근거가 있어야 한다.
- DB 수정이 필요한 경우 멱등하게 처리하고 변경 전후 값을 확인한다.
- 선택안으로 결정된 UX/IA 보강은 선택한 안의 범위만 구현하고, 선택되지 않은 안은 `defer`로 남긴다.
### 3-1. 텍스트 맥락 Fix
전체 사이트 텍스트가 메뉴 역할과 맞지 않을 때는 아래 순서로 수정한다.
1. 메뉴별로 `메뉴명`, `H1`, `리드 문구`, `빈 상태`, `CTA`, `카드/목록 대표 문구`, `메타 설명`을 수집한다.
2. 각 메뉴의 사용자 기대를 한 문장으로 정의한다. 예: 프롬프트는 “무료/유료 프롬프트를 탐색하고 구매/등록하는 마켓형 목록”이다.
3. 현재 문구가 기대와 다른 경우 `현재 문구 -> 수정 문구 -> 수정 위치 -> 확인 URL`로 Fix 후보를 만든다.
4. 명백한 오타, 다른 사이트 설명, 더미 문구, 빈 상태 불친절 문구는 바로 수정한다.
5. 브랜드 톤, 운영 정책, 가격/라이선스/환불처럼 책임 있는 표현은 사용자 확인이 필요하면 A/B/C 안으로 제시한다.
6. 수정 후 같은 URL에서 보이는 텍스트와 메타 설명이 함께 바뀌었는지 확인한다.
문구 수정 원칙:
- 메뉴명과 첫 문장의 약속이 같아야 한다.
- 빈 목록은 “없음”에서 끝내지 않고 다음 행동을 제시한다.
- 아직 구현되지 않은 구매/다운로드 기능을 완성된 것처럼 말하지 않는다.
- 무료/유료, 마켓, 커뮤니티, 자료실 같은 핵심 용어는 사이트 전체에서 같은 의미로 쓴다.
### 4. 재검수
- 수정한 URL과 관련 흐름을 다시 확인한다.
- 원래 이슈가 해결됐는지, 새 문제가 생기지 않았는지 확인한다.
- 가능하면 같은 검수 방법을 반복한다: HTTP 상태, HTML/DOM, 브라우저 렌더링, 주요 사용자 흐름.
### 4-1. 동일 패턴 회귀 방지
수정이 끝난 뒤 아래를 완료해야 한다.
1. 원래 이슈를 일반화한 검색어를 2개 이상 만든다. 예: `href="/files/`, `/download`, `data-sidebar-download`, `api/market`.
2. 코드 전체에서 검색하고 결과를 `수정 대상`, `정상 예외`, `보류`로 나눈다.
3. 같은 수정을 적용할 수 있는 항목은 함께 고친다. 예외는 왜 안전한지 적는다.
4. 라우트/프록시/정적 파일 충돌형 문제는 앱 라우트 순서와 운영 URL 응답을 둘 다 확인한다.
5. 재검수 결과에 `동일 패턴 검색 결과`를 반드시 포함한다.
완료 판정:
- `done`: 원래 이슈와 같은 패턴이 검색상 남지 않았거나, 남은 항목이 안전한 예외로 설명됐다.
- `partial`: 대표 이슈는 고쳤지만 같은 패턴이 일부 남았다.
- `blocked`: DB 권한, 로그인 계정, 배포 권한, 운영 프록시 설정 접근권한 부족으로 확인이 막혔다.
## 기능보강 판단 기준
- **필수 보강**: 깨진 링크를 실제 페이지로 연결, 빈 상태 CTA 추가, 잘못된 active 상태 수정, 로그인 복귀 흐름 보완.
- **권장 보강**: 더 명확한 라벨, 실제 콘텐츠 수와 맞는 카운트, 신뢰 요소, 검색/필터의 일관성.
- **보류 보강**: 새 결제 시스템, 대규모 데이터 모델 변경, 별도 관리자 기능, 운영 정책이 필요한 기능.
## 바로 수정 vs 선택 후 수정
- **바로 수정**: 404, 상세 본문 미노출, 메뉴 URL 오타, 잘못된 템플릿 분기, placeholder 링크, 더미 통계, 명백히 틀린 메타 설명.
- **바로 수정**: 메뉴와 무관한 소개문구, 다른 사이트 설명, 더미 빈 상태, CTA 라벨 오타, 모바일에서 핵심 카드가 밀리는 과도한 필터 UI.
- **선택 후 수정**: 메뉴 구조 변경, 온보딩 허브 재구성, 프롬프트 마켓 상세 정보 구조, 가격/구매 정책, 카드/리스트 레이아웃 전환, 새 필터 체계.
- **사용자 확인 필수**: 결제 흐름, 권한 정책, 데이터 삭제/마이그레이션, 대량 게시글 수정, 운영 정책 문구.
## 사이트별 Fix 체크리스트 형식
수정 전 또는 수정 중간에 아래 형식으로 체크리스트를 만든다.
```text
사이트별 Fix 체크리스트
ai.eond.com
- [todo] [High] /prompt/examples 404 제거
- 수정 대상:
- 확인 URL:
- 완료 기준:
- [todo] [Medium] 홈 더미 통계 제거
- 수정 대상:
- 확인 URL:
- 완료 기준:
```
수정이 끝난 항목은 `done`으로 바꾸고 증거를 붙인다. 외부 결정이 필요한 항목은 `blocked`,
이번 범위에서 하지 않는 항목은 `defer`로 표시한다.
## 점수 재산정
- `site-review`의 점수 산정 기준을 그대로 사용한다.
- 수정 전 점수와 수정 후 점수를 같이 보여준다.
- 라이브 검수가 불가능하면 “소스/DB 기준 잠정 점수”와 “라이브 확인 전 최종 점수 아님”을 명시한다.
- 목표는 100점이지만, 공개 판단은 Blocker/High 0개를 먼저 본다.
## 출력 형식
```text
수정 범위
- 대상:
- 반영한 이슈:
- 보류한 이슈:
사이트별 Fix 체크리스트
- [done] [High] ...
- [blocked] [Medium] ...
- [defer] [Medium] 선택되지 않은 C안 ...
Fix 선택안
- A안:
- B안:
- C안:
- 추천안:
- 사용자가 선택한 안:
변경 내용
- 파일/DB/설정:
- 사용자에게 보이는 변화:
텍스트 맥락 Fix
- 수정한 문구:
- 기대 맥락과 맞춘 이유:
- 확인 URL:
재검수 결과
- 수정 전 점수:
- 수정 후 점수:
- 공개 판단:
- 해결됨:
- 부분 해결:
- 미해결:
- 새로 발견한 이슈:
확인한 흐름
- URL/기능:
- 결과:
남은 우선순위
1. 다음에 고칠 것
2. 기획 확인이 필요한 것
3. 출시 전 최종 확인
```
## 완료 기준
- 선택한 이슈가 실제로 해결됐다는 증거가 있다.
- 수정 전 검수에서 지적된 흐름을 다시 확인했다.
- 남은 리스크와 후속 작업이 명확하다.
0 좋아요
0 답글
3 조회