agentleFS
gwonvibegwonvibe/gwonvibe-agent-skills/skills/site-auditor/SKILL.md

site-auditor

Skill4 starsChanged 42 days agoMITView on GitHub

웹사이트·웹앱의 핵심 기능, 접근성, 검색 노출, 성능, 보안, 운영 준비도 중 둘 이상을 함께 점검하고 근거와 우선순위를 통합할 때 사용한다. 단일 영역 요청에는 범위를 넓히지 않는다.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

사이트 종합 점검

모든 사이트에 같은 체크리스트와 점수를 적용하지 않는다. 사이트의 목적과 기능에 해당하는 영역만 선택하고, 코드에서 확인한 것과 실제 화면에서 검증한 것을 구분한다.

초보자를 위한 용어

  • 정적 확인: 코드를 읽어 문제 가능성을 찾는 일이다. 실제 화면이 작동한다는 증명은 아니다.
  • 실행 확인: 사이트를 직접 열고 행동해 결과를 확인하는 일이다.
  • 접근성: 키보드, 화면 읽기 도구, 확대 등 다양한 방법으로 사이트를 사용할 수 있게 하는 품질이다.
  • 색인: 검색엔진이 페이지를 수집해 검색 결과 후보로 저장하는 일이다.
  • 핵심 흐름: 방문, 검색, 신청, 구매처럼 사이트 목적에 직접 연결되는 사용자 행동이다.
  • 차단 요소: 공개나 배포 전에 해결하지 않으면 중요한 사용자 피해나 운영 손실이 생기는 문제다.

먼저 지킬 원칙

  • “전체 사이트 점검”처럼 둘 이상의 품질 영역을 요청했을 때 사용한다.
  • 성능이나 보안 한 영역만 요청받았다면 종합 감사를 덧붙이지 않는다.
  • 감사의 기본값은 읽기 전용이다. 요청 없이 코드·설정·의존성·운영 데이터를 바꾸지 않는다.
  • 저장소만 봤다면 운영 사이트를 확인했다고 말하지 않는다.
  • URL만 봤다면 내부 코드·데이터베이스·권한 설정을 확인했다고 말하지 않는다.
  • 자동 검사 통과는 실제 사용성·접근성·보안의 완전한 증명이 아니다.
  • 확인하지 못한 항목은 감점이나 실패로 만들지 않고 이유와 함께 미확인으로 남긴다.
  • 서로 다른 점수를 억지로 하나의 종합 점수나 등급으로 합치지 않는다.
  • 실제 로그인, 결제, 이메일 발송, 파일 업로드, 운영 데이터 작성은 대상과 정리 방법을 확인하고 별도 승인을 받는다.

1. 대상과 목적을 확인한다

사이트 주소 또는 프로젝트 위치:
사이트 목적:
주요 사용자:
가장 중요한 사용자 흐름:
공개 검색 대상 여부:
로그인·결제·개인정보·업로드 여부:
점검 환경: 코드 / 로컬 실행 / 미리보기 / 운영:
배포 결정에 사용할지 여부:

이미 주어진 정보는 다시 묻지 않는다. 접근할 수 없는 환경은 추정하지 않는다.

2. 적용할 영역을 고른다

조건점검 영역
사용자가 행동하는 화면이 있음핵심 기능과 오류 경로
렌더링되는 사용자 화면이 있음UI와 접근성
공개 검색에서 발견돼야 함콘텐츠와 검색 노출
로딩·반응 속도가 중요함성능
로그인·권한·결제·개인정보·입력이 있음보안과 데이터
백엔드·DB·외부 API·운영 배포가 있음운영 준비도

블로그에 결제 감사를 강제하거나 내부 관리자 도구에 공개 검색 점검을 강제하지 않는다. 해당하지 않는 영역은 해당 없음으로 표시한다.

3. 핵심 기능과 오류 경로

사이트 목적에 직접 연결되는 흐름부터 확인한다.

시작 화면 → 주요 행동 → 처리 중 → 성공 결과 → 다시 찾는 방법

각 흐름에서 본다.

  • 버튼과 링크가 기대한 위치로 이동하는가
  • 입력 검증과 오류 메시지가 이해되는가
  • 로딩 중 중복 클릭이나 무한 대기가 생기지 않는가
  • 실패 뒤 입력과 진행 상태가 필요한 만큼 보존되는가
  • 새로고침·뒤로 가기·직접 주소 접근 뒤 상태가 일관적인가
  • 데이터 없음과 서버 오류가 구분되는가

로그인·결제처럼 실제 상태를 바꾸는 흐름은 승인된 테스트 조건이 없으면 정적 구조와 안전한 범위만 확인한다.

4. UI와 접근성

대표 화면과 핵심 흐름에서 확인한다.

  • 제목과 시각적 순서가 작업 순서와 맞는가
  • 키보드만으로 이동하고 실행할 수 있는가
  • 현재 포커스가 눈에 보이는가
  • 입력 항목에 이해 가능한 이름과 오류 안내가 있는가
  • 이미지에 목적에 맞는 대체 설명이 있는가
  • 색상만으로 상태를 구분하지 않는가
  • 확대하거나 작은 화면에서도 내용과 조작이 사라지지 않는가
  • 움직임이 필수 정보 이해를 방해하지 않는가

자동 접근성 검사만으로 키보드 흐름과 화면 읽기 경험이 검증됐다고 말하지 않는다.

5. 콘텐츠와 검색 노출

공개 검색 대상일 때만 확인한다.

  • 페이지마다 목적에 맞는 제목과 설명이 있는가
  • 주요 내용이 실제 HTML에서 읽히는가
  • 같은 내용의 주소가 여러 개라면 대표 주소가 분명한가
  • 내부 링크가 사용자가 관련 페이지를 찾도록 돕는가
  • 잘못된 주소가 적절한 상태와 안내를 반환하는가
  • 검색 차단 설정이 공개 의도와 맞는가
  • 사이트맵이 실제 공개 페이지와 일치하는가
  • 구조화 데이터가 있다면 화면 내용과 일치하고 현재 공식 형식에 맞는가

파일이 존재한다는 이유만으로 검색엔진이 실제로 수집·색인했다고 말하지 않는다. 실제 색인 여부는 검색엔진 도구나 검색 결과처럼 별도의 운영 증거가 필요하다.

6. 성능

중요한 페이지와 동작을 같은 조건에서 측정한다.

  • 첫 주요 내용이 보이기까지의 시간
  • 클릭·입력 뒤 반응 지연
  • 화면 요소가 갑자기 밀리는 현상
  • 실제 페이지가 받는 이미지·폰트·자바스크립트 크기
  • 서버 응답과 외부 API·데이터베이스 대기

점수 하나나 코드 패턴으로 원인을 단정하지 않는다. 기준선이 있으면 같은 환경에서 전후를 비교하고, 공식 기준이 필요하면 점검 시점의 공식 문서를 확인한다.

7. 보안과 데이터

민감한 경계가 있을 때만 확인한다.

  • 로그인 뒤에도 역할과 데이터 소유권을 서버에서 확인하는가
  • 가격, 권한, 소유자, 승인 상태를 브라우저 입력으로 결정하지 않는가
  • 허용한 입력 필드·형식·크기만 처리하는가
  • 사용자 입력을 쿼리·명령·HTML·외부 URL에 안전하게 전달하는가
  • 시크릿과 개인정보가 브라우저 코드·응답·로그에 노출되지 않는가
  • 결제·웹훅·크레딧·예약의 중복 실행을 막는가
  • 다른 사용자 권한으로 접근을 시도하는 부정 테스트가 있는가

정적 확인과 실제 권한 테스트를 구분한다. 운영 사용자 데이터로 무단 테스트하지 않는다.

8. 운영 준비도

백엔드나 운영 인프라가 있을 때만 확인한다.

  • 대상 환경의 필수 설정이 값 노출 없이 존재하는가
  • 개발·미리보기·운영 자원이 섞이지 않았는가
  • 데이터 변경의 백업·호환·복구 경로가 있는가
  • 외부 호출의 시간 초과와 부분 실패를 처리하는가
  • 중요한 실패를 로그와 알림에서 알아차릴 수 있는가
  • 배포할 버전과 산출물을 추적할 수 있는가
  • 배포 뒤 핵심 흐름을 확인하고 중단·복구할 기준이 있는가

미리보기 주소가 열리거나 빌드가 성공했다는 사실만으로 운영 준비 완료를 선언하지 않는다.

9. 증거 수준을 표시한다

  • 실행 확인: 실제 화면이나 요청을 직접 검증했다.
  • 정적 확인: 코드와 설정에서 구조를 확인했다.
  • 도구 결과: 자동 검사나 측정 도구의 결과다.
  • 사용자 제공 정보: 원본이나 환경을 직접 확인하지 못했다.
  • 미확인: 접근 권한, 환경, 자료가 없어 판단하지 못했다.

하나의 증거가 보장하는 범위를 넘겨 결론내리지 않는다.

우선순위와 판정

  • 배포 차단: 핵심 기능 실패, 무권한 접근, 데이터·금액 손실, 필수 설정 누락처럼 현재 근거로 중요한 피해가 확인됐다.
  • 높은 우선순위: 다수 사용자가 막히거나 검색·접근성·성능·운영에 큰 영향을 주지만 즉시 손실은 확인되지 않았다.
  • 점진적 개선: 현재 사용을 막지는 않지만 품질을 높일 수 있다.
  • 판정 보류: 배포 판단에 필요한 중요한 검사를 수행하지 못했다.

최종 상태는 다음 중 하나다.

배포 차단
판정 보류
확인한 범위 내 차단 요소 없음

마지막 판정은 전체 안전 보장이 아니라 확인한 범위의 결론이다.

출력 형식

# 사이트 점검 결과

## 판정
- 배포 차단 / 판정 보류 / 확인한 범위 내 차단 요소 없음
- 가장 중요한 근거:

## 점검 범위
| 영역 | 상태 | 증거 수준 | 확인 내용 또는 미확인 이유 |
|---|---|---|---|

## 배포 차단 사항
- [근거가 확인된 문제만]

## 높은 우선순위
- [이번 배포 전 검토할 문제]

## 점진적 개선
- [차단이 아닌 개선]

## 확인하지 못한 영역
- [접근 불가와 범위 밖을 구분]

## 다음 확인
- [판단을 바꿀 수 있는 최소 확인 하나]

같은 원인의 문제를 영역마다 반복하지 않고 하나로 합친 뒤 영향받는 영역을 함께 표시한다.

초보자가 바로 쓸 요청 예시

이 사이트를 공개하기 전에 핵심 기능, 모바일 접근성,
성능, 검색 노출을 함께 점검해줘.
코드와 실제 화면에서 확인한 내용을 구분하고 아직 수정하지는 말아줘.
로그인과 결제가 있는 웹앱이야.
사용자 흐름, 권한, 오류 처리, 운영 준비도를 종합 점검하되
실제 결제와 운영 데이터 변경은 하지 말아줘.
저장소만 있고 배포 주소는 없어.
정적으로 확인 가능한 부분만 감사하고,
실제 브라우저나 운영 환경이 필요한 항목은 미확인으로 남겨줘.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.