메뉴
문서 콘텐츠(포스팅, 깃헙 위키, 리드미 등)의 품질을 검수할 때 사용한다. "문서 검수", "리뷰해줘", "검토해줘", "글 점검" 등의 요청이나 writing 스킬 완료 후 호출한다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | doc-review |
| description | 문서 콘텐츠(포스팅, 깃헙 위키, 리드미 등)의 품질을 검수할 때 사용한다. "문서 검수", "리뷰해줘", "검토해줘", "글 점검" 등의 요청이나 writing 스킬 완료 후 호출한다. |
문서 콘텐츠를 4개 관점에서 검수한다. 각 관점은 독립 서브에이전트가 병렬로 수행하며, 최대 3회 루프를 돈다.
작성 컨벤션: .claude/skills/_shared/conventions/writing.md
conventions/writing.md)| 체크 항목 | 판정 기준 |
|---|---|
문체 ~다. 또는 명사형 종결 | ~합니다/~요/~습니다 없음 |
| 한 줄 한 문장, 길면 대시 리스트 전환 | 한 문장이 2줄 이상 이어지지 않음 |
표 셀 가운데 정렬(:---:) | 모든 표에 적용 |
| 표 셀 간격 임의 조절 금지 | 구분선 길이 변경 없음 |
| HTML 태그 사용 금지 | 순수 마크다운 문법만 사용 |
| 헤더 중심 구성 | 산문형 단락 대신 헤더 + 짧은 설명 조합 |
| 메서드 호출 narrative 없음 | prose 본문에 X.foo() 형태 노출 없음 (T4 룰), 도메인 행위로 치환됨 |
| 동의어 통일 | writing.md의 동의어 통일 표 기준 일관 표기 |
| 약어 풀어쓰기 | 도메인 약어 첫 등장 시 1회 풀어쓰기 |
| 평가·과시 형용사·번역투 없음 | "가장/최고의/이상적인" 류 평가 형용사, "~를 통해/~함으로써/방식을 사용한다" 번역투가 사실·수치·구체 동사로 대체됨 |
| 문장 밀도 적절 | 짧은 단정문이 연발하지 않고 연결어미로 자연스러운 길이, 긴 불릿은 하위 뎁스로 분해됨 |
| 체크 항목 | 판정 기준 |
|---|---|
| 시간 순서 모순 없음 | 과거→현재 흐름이 역전되지 않음 |
| 용어 일관성 | 같은 개념에 다른 이름 사용 없음 |
| 서술 관점 통일 | 중간에 시점(1인칭/3인칭)이 바뀌지 않음 |
| 도입부-본문-결론 연결 | 도입에서 제시한 문제를 결론에서 회수 |
| 중복 서술 없음 | 같은 내용을 다른 섹션에서 반복하지 않음 |
| 체크 항목 | 판정 기준 |
|---|---|
| 코드 블록 정확성 | 실제 소스 코드와 대조해 불일치 없음 |
| 상태/타입/필드 목록 | 실제 enum, record, class와 대조 |
| 다이어그램 정합성 | Mermaid 전이/흐름이 코드 로직과 일치 |
| 수치/버전 정확성 | 구체적 수치나 버전이 검증됨 |
| 체크 항목 | 판정 기준 |
|---|---|
| 전문 용어 첫 등장 시 설명 | 약어, 프로젝트 고유 개념에 설명 있음 |
| 다이어그램 자기 설명성 | 참여자 이름, 화살표 레이블이 충분 |
| 코드 블록 전후 맥락 | "무엇을 왜 보여주는지" 설명 유무 |
| 배경 지식 전제 최소화 | 사전 지식 없이도 핵심 전제를 파악 가능 |
| 시각적 요소 적절 배치 | 텍스트만 이어지지 않고 표/다이어그램/코드로 환기 |
각 서브에이전트에 전달: 검수 대상 문서 경로 + 해당 관점의 체크 항목 표 + (규격 준수 관점에는 conventions/writing.md 경로, 기술 정확성 관점에는 "참조 소스 코드를 직접 읽어 대조" 지시).
프롬프트 템플릿:
문서 검수를 수행한다.
검수 대상: {문서 경로} / 검수 관점: {관점명}
아래 체크 항목을 각각 PASS/FAIL로 판정하고, FAIL 항목에는 구체적 위치(줄 번호 또는 섹션명)와 수정 방향을 기록한다.
체크 항목: {해당 관점의 체크 항목 표}
출력 형식:
### {관점명} — PASS / FAIL
| 체크 항목 | 판정 | 위치 | 수정 방향 |
|:---:|:---:|:---:|:---:|
## 검수 라운드 N
### 관점 1~4: <이름> — PASS / FAIL (각 결과)
### 종합
- PASS: N개 / FAIL: N개
- 다음 행동: (수정 후 재루프 / 종료)
| 문서 유형 | 규격 준수 | 서사 일관성 | 기술 정확성 | 독자 친화성 |
|---|---|---|---|---|
| 포스팅 | 필수 | 필수 | 필수 | 필수 |
| 깃헙 위키 | 필수 | 필수 | 필수 | 필수 |
| 리드미 | 필수 | 선택 | 필수 | 필수 |
서사 일관성이 선택인 유형에서는 해당 서브에이전트를 디스패치하지 않는다.
코드 변경(diff, 브랜치, 커밋 범위, PR)을 배경–직관–코드–퀴즈 4섹션의 자기완결 인터랙티브 HTML 페이지로 풀어 설명한다. "diff 설명해줘", "이 PR 설명 페이지 만들어줘", "변경 내용 인터랙티브로 정리", "이 브랜치에서 뭘 바꿨는지 학습용으로 설명" 등 변경 사항의 리치 설명을 요청하면 HTML을 직접 언급하지 않아도 반드시 이 스킬을 사용한다. workflow ship 단계의 리뷰 통과 직후(A5)에도 자동 호출된다. 문제점을 찾는 검토 요청은 review 스킬, 대화 내 짧은 텍스트 요약은 일반 응답으로 처리한다.
payment-platform 워크플로우의 discuss 단계를 실행한다. 사용자가 새 기능/버그/개선의 설계를 논의하거나, "discuss 시작", "설계 논의", "어떻게 구현할지 얘기해보자", "방법 고민" 등을 말할 때 이 스킬을 사용한다. 구현 전에 결정해야 할 사항을 명확히 하는 것이 목적이다.
payment-platform 워크플로우의 execute 단계를 실행한다. docs/<TOPIC>-PLAN.md가 존재하고 사용자가 "execute 시작", "구현 시작", "코딩 시작", "태스크 실행", "다음 태스크" 등을 말할 때 이 스킬을 사용한다. TDD로 태스크를 하나씩 구현하고 커밋하는 것이 목적이다.
payment-platform 워크플로우의 ship 단계(코드 리뷰 + 마무리)를 실행한다. execute 완료 후 "ship 시작", "리뷰 시작", "코드 리뷰", "리뷰하고 마무리", "검증하고 마무리", "아카이브", "PR 만들어줘" 등을 말할 때 이 스킬을 사용한다. 리뷰 → 수정 → 최종 검증 → 문서 동기화 → 아카이브 → PR 흐름이다.
payment-platform의 discuss → plan → execute → ship 워크플로우 오케스트레이터. docs/STATE.md에 활성 토픽이 있거나, 사용자가 "discuss 시작", "plan 작성", "execute 시작", "워크플로우로", "다음 단계", "세션 재개", "이어서 진행", "어디까지 했지" 등을 말할 때 반드시 이 스킬을 사용한다. 단순 질문, 빠른 수정, 일회성 코드 변경에는 사용하지 않는다.
사용자가 "포트폴리오 수정", "포트폴리오 사이트", "payment-flows", "포트폴리오 페이지", "포트폴리오 배포", "index.html 고쳐", "포트폴리오 확인" 같은 표현으로 결제 플랫폼 포트폴리오 페이지를 참조·수정하라는 신호를 줄 때 반드시 사용한다. 이 포트폴리오(구 `docs/site/payment-flows.html`)는 payment-platform이 아니라 **별도 blog 저장소**(`notes/blog`, Astro)에서 관리되며 payment-platform 트리 안엔 존재하지 않으므로, 이 스킬이 정본 페이지(`src/pages/payment-platform-portfolio/index.astro` — CSS·데이터·로직은 각각 `src/styles/`·`src/data/paymentPortfolio/`·`src/scripts/portfolio/` 모듈로 분리)와 dev 툴 위치를 자동으로 찾아 Read / Grep / Edit 으로 접근하게 해준다. "포트폴리오" 단어가 없어도 결제 플랫폼 소개 페이지·시스템 아키텍처 다이어그램·시나리오 극장·섹션 밴드/모션 같은 그 페이지의 콘텐츠를 손봐야 하는 맥락이면 사용을 고려한다.