Site Consistency — Offer-Aligned Text Audit

Goal: 모든 사이트 텍스트가 동일한 고객에게 동일한 약속, 이름 및 용어를 사용하여 홈페이지에 명시된 오퍼와 동일한 이야기를 전달하도록 합니다. 먼저 감사(Audit)를 수행하고, 사용자가 승인한 부분만 수정합니다.

두 가지 엄격한 경계:

감사 후 수정. 감사는 읽기 전용입니다. 사용자가 감사 테이블의 특정 행을 승인할 때까지 어떤 파일도 수정되지 않습니다.
텍스트만. 이 스킬은 단어만 변경합니다. 레이아웃, 스타일, 컴포넌트, 이미지, 경로 또는 페이지 구조는 절대 변경하지 않습니다. "텍스트 전용 편집 규칙"을 참조하세요.

언어

대화에서 사용자가 사용하는 언어로 사용자와 소통합니다. 보고서, 테이블 헤더, 심각도 레이블 및 "이유" 열은 해당 언어로 작성됩니다.
현재 텍스트의 인용문은 원문 그대로, 원래 언어로 작성됩니다.
제안된 사이트 텍스트는 대체되는 텍스트의 언어로, 자연스럽고 관용적으로 작성되며(절대 직역하지 않음), 사이트의 호칭 방식(예: 폴란드어 "Ty"/"Państwo", 독일어 "du"/"Sie")과 어조를 유지합니다.
<html lang>, i18n 설정, 로케일 파일 및 표시된 카피에서 사이트 언어를 감지합니다. 다중 로케일 사이트의 경우 기본 로케일을 식별합니다. 어떤 로케일을 감사해야 할지 명확하지 않으면 질문합니다.

워크플로우

단계를 순서대로 따르세요. 1-6단계에서는 파일을 수정하지 않습니다.

1단계 — 정찰(Reconnaissance)

references/text-inventory.md를 읽습니다. 다음을 확인합니다.

스택 및 라우팅(URL이 파일에 매핑되는 방식)
텍스트가 있는 위치: 컴포넌트/템플릿, i18n 파일, Markdown/MDX/콘텐츠 컬렉션, 메타데이터, 이메일 템플릿, 외부 CMS
로케일 및 기본 사이트 언어
기존 오퍼 문서: docs/offer/offer-brief.md(그랜드 슬램 오퍼 스킬로 작성) 또는 docs/ 내의 모든 브리핑/포지셔닝 문서.

텍스트의 대부분이 외부 CMS에 있고 내보내기 파일이나 렌더링된 사이트를 읽을 수 있는 URL이 모두 없는 경우, 계속하기 전에 무엇을 감사할 수 있고 무엇을 할 수 없는지 사용자에게 알립니다.

2단계 — 홈페이지에서 오퍼 추출

처음 방문하는 방문자처럼 홈페이지를 읽습니다: 먼저 히어로, 그 다음 모든 섹션을 순서대로, 그리고 <title>, 메타 설명, 헤더 및 푸터를 포함합니다. 오퍼 명세서(Offer Statement) 를 작성합니다.

필드	설명
판매 제품	제품/서비스 및 형식
대상 고객	고객/아바타, 세그먼트, 시장
핵심 약속	고객이 얻는 결과 (+ 명시된 경우 기간)
메커니즘/차별점	전달 방식, 대안 대신 이 제품을 선택해야 하는 이유
이름	오퍼, 제품, 방법 및 패키지 이름의 정확한 철자
주요 조건	가격/패키지, 보증, 희소성/마감일, 배송 시간 — 명시된 것만
기본 전환	주요 CTA 및 클릭 후 발생하는 일
어조	톤, 호칭 방식, 포지셔닝(프리미엄, 저예산, 전문가, 친근함...)

각 필드에 대해 값과 출처(인용문 + 위치)를 기록합니다. 필드가 홈페이지에 없으면 "명시되지 않음"이라고 작성합니다. 오퍼 브리핑이 있는 경우, 홈페이지와 필드별로 비교합니다.

여러 개의 뚜렷한 오퍼(예: 다른 고객층을 위한 별도의 서비스)가 있는 사이트의 경우, 홈페이지의 포괄적인 오퍼를 기록하고 하위 오퍼를 나열합니다. 각 하위 오퍼 페이지는 자체 오퍼 및 포괄적인 오퍼에 대해 확인됩니다.

3단계 — 오퍼 명확성 게이트(Offer Clarity Gate)

오퍼가 명확하려면 다음 모든 조건이 충족되어야 합니다.

"판매 제품", "대상 고객", "핵심 약속" 및 "기본 전환"을 홈페이지만으로 답할 수 있습니다.
홈페이지는 하나의 주요 오퍼(또는 하위 오퍼가 있는 하나의 명확한 포괄 오퍼)를 제시합니다. — 경쟁 오퍼가 없습니다.
홈페이지는 스스로 모순되지 않습니다 (두 개의 가격, 두 개의 고객층, 두 개의 다른 약속).
홈페이지는 오퍼 브리핑(있는 경우)과 모순되지 않습니다.

명확함 → 계속 진행합니다. 오퍼 명세서가 기준이 되며, 사용자가 수정할 수 있도록 보고서 상단에 배치됩니다.

명확하지 않음 → 다른 것을 감사하기 전에 중단하고 오퍼에 대해 사용자에게 질문합니다. 이 게이트를 통과하기 위해 오퍼를 추측하지 마십시오.

가능한 경우 AskUserQuestion 도구를 사용하십시오 (라운드당 최대 4개 질문). 사이트에서 실제로 찾은 후보 옵션과 사용자 정의 답변을 위한 공간을 포함하여 옵션을 구성합니다. 그렇지 않으면 채팅에서 질문합니다.
누락되었거나 충돌하는 필드에 대해서만 질문하십시오. 예: "홈페이지는 X와 Y를 모두 판매합니다. 주요 오퍼는 무엇입니까?", "주요 고객은 A(히어로)입니까 아니면 B(서비스 섹션)입니까?", "브리핑에는 30일 보증, 홈페이지에는 14일 보증이 있습니다. 어느 것이 현재 맞습니까?" 여러 오퍼의 경우 계층 구조(주요 오퍼 대 하위 오퍼)를 확인합니다.
"사용자 확인됨" 출처로 오퍼 명세서에 답변을 기록합니다. 명확하지 않거나 모순되는 홈페이지 텍스트는 결과가 됩니다. 홈페이지는 다른 모든 페이지와 마찬가지로 확인된 오퍼에 대해 감사됩니다.

4단계 — 페이지 및 텍스트 인벤토리

방문자가 읽을 수 있는 모든 것을 나열합니다 (자세한 내용은 references/text-inventory.md 참조):

모든 경로/페이지 (동적 경로 및 콘텐츠 컬렉션 포함)
공유 텍스트: 헤더, 탐색, 푸터, 배너, 모달/팝업, 양식(레이블, 플레이스홀더, 유효성 검사, 성공/오류 메시지), 404/500 및 빈 상태
방문자가 간접적으로 보는 텍스트: <title>, 메타 설명, Open Graph/Twitter 태그, JSON-LD 텍스트 필드, alt, aria-label, 웹 매니페스트 이름/설명
트랜잭션 이메일 및 알림 (템플릿이 저장소에 있는 경우)

각 페이지에 내러티브 역할을 부여합니다 (references/consistency-checklist.md 참조). 역할은 해당 페이지에서 "일관성"이 의미하는 바를 결정합니다.

대규모 사이트: 모든 핵심 페이지를 완전히 감사합니다. 동일한 유형의 대규모 컬렉션(예: 20개 이상의 블로그 게시물 또는 제품)의 경우, 공유 템플릿과 각 항목의 제목, 설명, 소개 및 CTA를 감사합니다. 보고서에서 이 방식으로 처리된 내용을 정확히 명시하고 전체 검사를 제안합니다. Agent 도구를 사용할 수 있는 경우, 인벤토리를 서브 에이전트에게 분할할 수 있습니다. 각각 확인된 오퍼 명세서, 체크리스트 및 페이지 목록을 제공한 다음, 결과를 단일 테이블로 병합합니다.

5단계 — 감사

references/consistency-checklist.md를 읽습니다. 모든 차원(D1–D10)에서 오퍼 명세서에 대해 각 텍스트 단위를 페이지 역할의 맥락에서 확인합니다. 각 결과에 대해 기록합니다: 위치, 문자 그대로의 인용문, 차원, 심각도, 문제인 이유(특정 오퍼 명세서 필드와 연결), 수정 유형 및 제안된 텍스트.

먼저 사실 매트릭스를 작성합니다 (가격, 보증, 마감일, 자리, 배송 시간, 이름에 대한 모든 언급을 나란히) 페이지 간 모순이 우연이 아니라 체계적으로 포착되도록 합니다.
제안된 텍스트는 텍스트 전용 편집 규칙을 따르며 사실을 만들어 내지 않습니다. 누락된 사실은 사이트 언어로 된 플레이스홀더가 됩니다 (예: [TO FILL IN: …], 폴란드어 [DO UZUPEŁNIENIA: …]).
진실이 확립되지 않은 충돌하는 사실 → 수정 유형 결정: 옵션을 나열하고 선택하지 마십시오.
텍스트로 해결할 수 없는 문제(다른 제품을 보여주는 이미지, 누락된 섹션이나 CTA 버튼, 존재해서는 안 되는 페이지, 잘못된 링크 대상, URL 슬러그)는 "텍스트 범위 밖"으로 이동합니다. 보고만 하고 이 스킬로 수정하지 않습니다.

6단계 — 감사 보고서, 그 다음 중단

"출력 형식"에 따라 보고서를 정확히 제시합니다. 보고서는 항상 결과 테이블로 끝납니다. 테이블 다음에 허용되는 유일한 것은 승인 질문입니다. 그런 다음 중단하고 기다리십시오. 이 턴에서는 어떤 파일도 수정하지 마십시오.

승인 질문 (가능한 경우 AskUserQuestion 사용):

모두 적용
중요 및 주요만 적용
선택한 행 적용 (사용자가 #을 나열하고 제안 사항을 편집할 수 있음)
적용 안 함 — 감사만 수행

사용자가 적용하려는 모든 결정 행은 답변이 필요합니다. 가능한 경우 동일한 라운드에서 이에 대해 질문하십시오.

7단계 — 승인된 수정 사항 적용

텍스트 전용 편집 규칙에 따라 사용자의 편집 사항이 포함된 승인된 행만 적용합니다.
문자열을 변경하기 전에 해당 문자열이 렌더링되는 다른 위치(공유 i18n 키, 공유 컴포넌트, 재사용된 Markdown 부분)를 확인합니다. 새 텍스트가 해당 컨텍스트 중 하나에 맞지 않으면 중단하고 질문합니다.
승인된 수정 사항이 비텍스트 변경을 필요로 하거나 승인된 대로 적용할 수 없는 경우 건너뛰고 보고합니다. 다른 수정 사항을 즉석에서 만들지 마십시오.
외부 CMS에 저장된 텍스트: 편집을 시도하지 마십시오. 복사-붙여넣기 목록(CMS 항목/필드 | 현재 텍스트 | 새 텍스트)을 준비합니다.

8단계 — 확인 및 보고

변경된 모든 구절을 주변 텍스트와 함께 다시 읽습니다. 문맥상 자연스럽게 읽혀야 합니다.
승인된 범위 내에서 이전 변형(이전 이름, 이전 용어, 이전 약속)의 잔재를 검색합니다.
변경된 파일의 유효성을 검사합니다: JSON/YAML 구문 분석, 로케일 파일이 동일한 키를 유지하는지, 보간 변수가 손상되지 않았는지 확인합니다. 사용 가능하고 빠른 경우 프로젝트의 린트/타입체크/빌드를 실행합니다.
다중 로케일: 사용자가 업데이트를 승인하지 않는 한 일치하는 업데이트가 필요한 다른 로케일을 나열합니다.
요약 테이블로 마무리합니다: # | 위치 | 상태 (적용됨 / 건너뜀 — 이유 / CMS 업데이트 필요) | 변경 사항 (간략). 요청하지 않는 한 커밋하지 마십시오.

텍스트 전용 편집 규칙

허용:

사용자에게 표시되는 문자열 콘텐츠: JSX/템플릿의 텍스트 노드, 사용자에게 렌더링되는 문자열 리터럴, i18n 값, Markdown/MDX 산문, 프론트매터 텍스트 필드(제목, 설명), 저장소 내 CMS/콘텐츠 파일,
텍스트 속성 및 메타데이터: alt, title, aria-label, placeholder, <title>, 메타 설명, OG/Twitter 텍스트, JSON-LD 텍스트 값, 매니페스트 이름/설명,
양식, 시스템 및 이메일 템플릿 메시지,
기존 텍스트 요소 내에서 문장 다시 쓰기, 단축 또는 삭제.

허용되지 않음 (대신 "텍스트 범위 밖"으로 보고):

요소, 섹션 또는 컴포넌트 추가, 제거, 재정렬 또는 스타일 변경; 마크업, 클래스, CSS 또는 비텍스트 props 변경,
요소 비우기 — 빈 요소는 레이아웃 변경입니다. 대신 다시 작성하십시오,
i18n 키, 변수 이름, 파일 이름, 경로, URL 슬러그, 앵커(슬러그는 텍스트이지만 변경하면 링크와 SEO가 손상됨),
링크 대상(href) — 링크 텍스트만 변경 가능,
이미지, 아이콘, 비디오 및 기타 미디어,
코드 로직, 조건, 데이터 가져오기.

편집하는 동안:

보간 및 구문 보존: {name}, {{count}}, %s, :attribute, ICU plural/select, HTML 엔티티, 문자열 내의 인라인 태그(<strong>, <br>, <0>…</0>), 마크다운 서식 및 이스케이프(JSX/JSON의 따옴표, PHP 문자열의 아포스트로피).
길이를 원본에 가깝게 유지합니다 (대략 ±30%). 레이아웃이 변경되지 않기 때문입니다. 수정에 훨씬 더 많은 텍스트가 필요한 경우 제안서에 명시하십시오.
사이트의 활자 규칙(따옴표, 대시, 줄 바꿈 없는 공백)과 일치시킵니다.

필수 규칙

R1. 읽기 전용 감사. 명시적인 승인 전에는 편집이나 파일 쓰기(사용자가 요청하지 않는 한 보고서 파일 포함)가 없습니다. 승인은 승인된 행에만 적용됩니다.
R2. 텍스트 전용. 텍스트 전용 편집 규칙 외부의 모든 것은 보고만 되고 변경되지 않습니다.
R3. 먼저 기준 설정. 추측된 오퍼에 대해 감사하지 마십시오. 오퍼 명세서는 홈페이지에서 명확하거나 사용자에 의해 확인됩니다.
R4. 증거. 모든 결과는 현재 텍스트를 문자 그대로 인용하고 정확한 위치(file:line 또는 i18n 키)를 제공합니다.
R5. 테이블은 항상 마지막에. 모든 감사 보고서는 결과 테이블로 끝납니다. 결과가 없는 경우에도 마찬가지이며, 그런 경우 적용 범위 테이블(페이지 | 역할 | 판정)로 끝납니다.
R6. 사실을 만들어 내지 않음. 제안은 사용자가 제공하지 않았거나 사이트가 이미 일관되게 명시하지 않은 숫자, 결과, 사용후기, 보증 또는 조건을 절대 추가하지 않습니다. 충돌 → 결정. 누락 → 플레이스홀더.
R7. 일관성, 획일성이 아님. 히어로 약속을 모든 곳에 붙여넣거나 모든 페이지에 세일즈 피치를 강요하지 마십시오. 페이지의 역할을 고려하여 오퍼와 모순되거나, 약화시키거나, 벗어나거나, 산만하게 하는 텍스트만 플래그 지정합니다. 법률 페이지는 내러티브를 위해 다시 작성되지 않습니다. 마케팅 카피와의 사실 충돌만 플래그 지정하고 법률 텍스트를 검토할 것을 권장합니다.
R8. 오퍼에 맞추고, 재설계하지 않음. 이 스킬은 사이트를 확인된 오퍼와 일치시킵니다. 오퍼 자체가 약한 경우(모호한 약속, 증거 부족, 가격 주도), 요약에 한 줄로 명시하고 grand-slam-offer 스킬을 제안하십시오. 여기서 오퍼를 재구축하지 마십시오.
R9. 언어. 대화 언어로 커뮤니케이션; 제안된 사이트 텍스트는 대체되는 텍스트의 언어로 작성합니다.

출력 형식

감사 보고서

대화 언어로 작성된 다음 순서의 섹션:

기준 오퍼 — 오퍼 명세서(간결한 테이블) + 출처(홈페이지 / 오퍼 브리핑 / 사용자 확인)
범위 — 감사된 페이지 및 텍스트 소스(개수 + 목록 또는 그룹화), 로케일, 샘플링으로 다루어진 내용, 저장소 외부에 있어 감사되지 않은 내용.
요약 — 심각도별 결과 개수; 가장 큰 내러티브 문제 2-3개를 각각 한 문장으로; 선택적으로 오퍼 자체에 대한 한 줄(R8).
전체 재작성 (필요한 경우에만) — 약 40단어보다 긴 제안을 전체로, 결과 #로 레이블 지정.
텍스트 범위 밖 (있는 경우에만) — 짧은 글머리 기호; 이 스킬로 수정하지 않습니다.
결과 테이블 — 보고서의 마지막 요소.

결과 테이블 — 헤더는 대화 언어로 번역:

#	위치	심각도	현재 상태	이렇게 되어서는 안 되는 이유	제안된 수정 사항

# — 승인에 사용되는 안정적인 ID.
위치 — 페이지 · 섹션 · file:line 또는 i18n 키.
심각도 — 중요(Critical) / 주요(Major) / 사소(Minor) (체크리스트 참조).
현재 상태 — 관련 구절의 문자 그대로 인용; ~25단어를 넘으면 "…"으로 단축.
이렇게 되어서는 안 되는 이유 — 기준과의 구체적인 충돌, 예: "홈페이지: 치과 진료소 대상; 여기: 모든 비즈니스 대상".
제안된 수정 사항 — 사이트 언어로 된 정확한 새 텍스트, "전체 재작성 #N 참조" 또는 결정: A) … / B) ….

심각도별로, 그런 다음 인벤토리의 페이지 순서대로 정렬합니다.

예: 폴란드어 대화에서 세 가지 핵심 헤더는 "Jak jest dziś", "Dlaczego tak nie powinno być", "Jak to poprawię"가 됩니다.

예시 행 (영어 사이트, 영어 대화):

| # | Where | Severity | Today | Why it shouldn't be like this | Proposed fix | |---|---|

…

[번역을 위해 잘림]

site-consistency — 오퍼 정렬 카피 QA