article-review-panel은(는) 무엇을 하나요?
버전: 1.0
기술 문서 초안 옆에 세 개의 검토 파일을 생성하며, 각 파일은 서로 다른 전문가 페르소나가 작성합니다: 도메인 전문가(기술적 주장의 정확성), 편집자(구조, 명확성, 대상 독자, 플랫폼 적합성), 통계학자(데이터가 결론을 뒷받침하는지 여부). 각 파일은 동일한 Good / Wrong / Needs more explanation 형식을 사용하여 작성자가 바로 조치를 취할 수 있도록 합니다. 진실의 원천은 초안 폴더에 있는 원시 데이터, 스크립트 및 메모이며, 초안 자체의 요약이 아닙니다.
중요 규칙 (먼저 읽으세요)
- 한 줄이라도 쓰기 전에 전체 폴더를 읽으세요. 초안, 메모, 첫 댓글 초안, 관련 게시물, 벤치마크 스크립트 및 원시 결과 파일을 모두 읽어야 합니다. 초안만 읽는 검토는 데이터를 잘못 인용하는 초안을 잡을 수 없습니다.
- 초안에 있는 모든 숫자를 검증하세요. 원시 데이터에서 다시 계산하거나, 검증되지 않았다고 표시하세요. 파일과 값을 인용하세요:
results_gc.json: 173 → 166 MB. - '잘못됨'은 스타일 선호도가 아니라 실제 오류를 의미합니다. 폴더에 증거가 없는 주장, 데이터와 모순되는 숫자, 분석이 뒷받침하지 않는 결론, 플랫폼에서 깨져 보일 문장 등이 해당됩니다. 취향 차이는 '추가 설명 필요'에 넣으세요.
- 모든 '잘못됨' 항목에는 구체적인 수정 방안이 포함되어야 합니다: 대체 문구, 주장을 테스트할 명령어, 또는 삭제.
- 각 렌즈는 자신의 영역에 충실해야 합니다. 다른 파일의 결과를 반복하는 대신 교차 참조하세요("기술적 정확성은
REVIEW-…-JVM.md에 있습니다"). - 통계학 렌즈: 눈으로 보지 말고 분석하세요. 원시 데이터에 대해
scripts/paired_stats.py를 실행하세요. 신뢰 구간과 최소 감지 효과 수치 없이 "노이즈" 또는 "효과 없음"이라고 결론 내리지 마세요. - 길이 예산을 준수하세요. 초안의 문자 수를 플랫폼 제한(LinkedIn: 3,000자)과 비교하고, 각 추가 내용이 어떤 비용을 수반하는지 명시하세요.
- 기밀 정보를 표시하세요. 내부 이름, 티켓 ID, 호스트, 고객 또는 프로덕션 수치: 커뮤니케이션/법무팀의 승인이 필요하다고 표시하세요. 제한된 데이터(회원, 청구, 건강, 자격 증명)를 검토나 검색에 절대 넣지 마세요.
우선 읽기 테이블
| 출처 | 경로 | 추출할 내용 |
|---|---|---|
| 초안 | 사용자가 지정한 파일 | 모든 사실적 주장, 모든 숫자, 모든 명령어, 후크(처음 ~210자), CTA, 문자 수 |
| 작성자 메모 | *.md 관련 파일 (데이터 노트, 첫 댓글, 관련 게시물) | 작성자가 생략한 자신의 주의사항 및 수정사항; 관련 게시물 간 반복 텍스트 |
| 벤치마크 스크립트 | 폴더 내 *.py, *.sh, Dockerfiles | 실행 순서(무작위? 블록?), 각 메트릭이 실제로 측정하는 대상 및 샘플링 시점 |
| 원시 결과 | *.json, *.csv, *.log | 재계산할 숫자; 페어링을 위한 블록 크기 |
| 도메인 렌즈 가이드 | references/domain-lens.md | 도메인 체크리스트; JVM 섹션은 작업 예시 도메인 |
| 편집 렌즈 가이드 | references/editorial-lens.md | 플랫폼 규칙(LinkedIn 마크다운, 접기, 제한) 및 구조 체크리스트 |
| 통계학 렌즈 가이드 | references/statistics-lens.md | 분석 레시피 및 표준 방법론 플래그 |
| 과거 교훈 | ~/.claude/skill-memory/article-review-panel.md (없으면 생성) | 이전 실행 피드백; 초안 작성 전 적용 |
워크플로우
1단계. 목록 작성
폴더를 나열하세요. 초안과 모든 메모, 스크립트, 결과 파일을 읽으세요. 초안의 문자 수를 세세요. 주장 목록을 만드세요: 각 숫자와 각 사실적 주장, 그리고 해당 줄 번호.
2단계. 렌즈 선택
기본값은 세 가지 모두입니다. 사용자가 지정한 렌즈만 실행하세요("통계학자처럼 행동해줘"). 도메인 렌즈의 경우, 사용자로부터 분야를 입력받거나("JVM", "Kubernetes", "Postgres") 초안에서 추론하여 선택한 분야를 알리세요.
3단계. 검증
각 주장을 원시 데이터에서 재계산하세요. 벤치마크의 경우 다음을 실행하세요:
python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> --list
python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> \
--block-size <variants per round> --pair <A>:<B> [--pair ...] --metrics <m1,m2>
모든 정성적 주장("시작되지 않음", "묵묵히 무시됨")에 대한 증거를 폴더에서 찾으세요. 증거가 없으면 "잘못됨: 테스트되지 않음"으로 표시하고 테스트 명령어를 포함하세요.
4단계. 렌즈별 파일 작성
초안 폴더에 REVIEW-<초안-파일명>-<렌즈>.md 이름으로 파일을 쓰세요. 렌즈는 JVM/<DOMAIN>, EDITORIAL, STATISTICS 중 하나입니다. 아래 출력 형식과 references/ 폴더의 렌즈 가이드를 따르세요.
5단계. 등급 부여 및 보고
채점 하위 에이전트(깨끗한 컨텍스트로 evals.md, 초안 및 검토 파일만 제공)를 통해 evals.md를 실행하세요. 모든 실패를 수정하고 재채점하세요. 그런 다음 사용자에게 보고하세요: 렌즈별로 한 줄씩 최상위 '잘못됨' 항목과 파일 경로를 포함하세요. 사용자가 제공하는 새로운 교훈이 있으면 ~/.claude/skill-memory/article-review-panel.md에 추가하세요(최신 항목이 위로 오도록; 없으면 생성).
출력 형식
# Review of <초안 파일>: <렌즈 이름>
Reviewer view: <페르소나>. <무엇을 무엇과 대조하여 확인했는지.>
## Verdict
<2-4문장: 게시 가능 여부, 가장 강력한 점, 수정 필수 항목 개수.>
## Good
- **<굵은 주장>.** <증거, 파일 및 숫자 포함.>
## Wrong: <게시 전 수정 필수 | 데이터가 결론을 뒷받침하지 않음>
### 1. <결함에 대한 한 줄 설명>
<초안에서 말하는 내용, 데이터가 말하는 내용, 왜 중요한지.>
Suggested fix: <문구, 명령어 또는 삭제>.
## Needs more explanation
### N. <주제>
<누락된 내용과 제안된 한 줄>.
## Smaller points
- **<레이블>:** <한두 문장>.
통계 파일은 헤더 뒤에 How the analysis was done 섹션을 추가하고, 끝에 Recommended re-runs 목록을 추가합니다.
작업 예시
입력:
act like an experienced JVM engineer and review POST-1-DEFAULT-CDS-EN.md in ~/aot-exploration/linkedin-cds, then an editor, then a statistician
Claude가 수행하는 단계:
- 게시물,
DADOS-POST.md, 첫 댓글 초안, 게시물 2,bench*.py및results*.json을 읽습니다. 3,000자 중 2,623자를 확인합니다. - 도메인 렌즈: ZGC가
classes_nocoops.jsa를 매핑하는지 확인합니다.AOTCache를 언급하는 파일이 없으므로 "JVM이 시작조차 하지 않는다"는 주장은 테스트 명령어와 함께 '잘못됨'으로 표시됩니다. - 편집 렌즈: 87자 후크가 접기 위에 맞습니다; 백틱으로 감싸진 네 개의 명령어는 LinkedIn에서 문자 그대로 렌더링됩니다(잘못됨).
- 통계학 렌즈: 라운드 루프 내에
random.shuffle(order)가 있으므로paired_stats.py --block-size 12를 실행합니다. 통합 이동은 -2.1% [-3.2%, -1.5%]이므로 "노이즈"는 잘못됨입니다. "+2%"는 쌍을 이루지 않은 중앙값을 비교한 데서 비롯되었습니다. - 세 개의
REVIEW-POST-1-*.md파일을 작성하고,evals.md로 등급을 부여한 후 보고합니다.
출력(통계 파일, 발췌):
### 1. "시작 시간: -4% ~ +2%. 노이즈입니다."는 데이터가 말하는 바가 아닙니다
| 설정 | 쌍별 이동 | 95% CI | CDS로 더 빠름 | 정확한 p값 |
|---|---|---|---|---|
| Serial | -69 ms | [-104, -49] | **10/10** | **0.002** |
| **통합, 50쌍** | **-2.1%** | **[-3.2%, -1.5%]** | **39/50** | n/a |
올바른 결론은 "작지만 실제하는 효과: 약 2%, 또는 20-70 ms"이며, "노이즈"가 아닙니다.
이 실행의 전체 세 파일 출력은 references/examples.md에 요약되어 있습니다.
참조 파일
references/domain-lens.md: 도메인 전문가 체크리스트; JVM/CDS/AOT 작업 예시 도메인.references/editorial-lens.md: 편집자 체크리스트 및 LinkedIn 플랫폼 규칙.references/statistics-lens.md: 분석 레시피 및 표준 방법론 플래그.references/examples.md: CDS 게시물 실행, 항목별 분석.evals.md: 통과/실패 검사. 전달 전에 깨끗한 컨텍스트의 채점기로 실행.~/.claude/skill-memory/article-review-panel.md: 교훈 로그, 최신 항목 우선, 이 머신에 비공개(memory.md참조). 초안 작성 전에 읽으세요.
스크립트
scripts/paired_stats.py: 표준 라이브러리만 사용하는 쌍별 A/B 분석(정확한 Wilcoxon, 부호 검정, Hodges-Lehmann, 부트스트랩 CI, MDE, 통합 이동, 드리프트 및 순서 검사).--list는 변형 및 메트릭을 표시하고,--self-test는 8가지 검사를 실행합니다.
이 스킬을 사용하지 말아야 할 경우
- 코드, 브랜치 또는 PR 검토: diegourban:gh-pr-review, diegourban:branch-review 또는 /code-review를 사용하세요.
- 코드베이스가 실제로 어떻게 동작하는지 확인: diegourban:fact-checker를 사용하세요.
- 게시물 자체를 작성하거나 재작성: 직접 대화를 하세요. 이 스킬은 검토만 합니다.
- 덱 또는 슬라이드: 사용자가 요청한 경우에만 이 스킬로 콘텐츠를 검토하고, build-slide-deck을 사용하세요.