Menu
baseline-report.json과 하네스 적용 후 작업 결과를 비교하여 하네스 효과를 수치화한다.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | compare-harness-effectiveness |
| description | baseline-report.json과 하네스 적용 후 작업 결과를 비교하여 하네스 효과를 수치화한다. |
| allowed-tools | Read Grep Glob Bash |
동일 작업의 before(baseline) / after(하네스 적용) 결과를 수치적으로 비교하여 하네스 도입 효과를 증명한다.
docs/harness-evaluation/baseline-report.json (collect-baseline-data 산출물)baseline의 각 task에 대해 하네스 적용 후 재작업 결과를 1:1 매칭한다. 매칭 기준: 동일한 original_request, 동일 base commit.
재작업 세션 ID가 제공되면, baseline과 동일한 방식으로 after 세션 JSONL을 파싱하여 대화 흐름 데이터를 수집한다.
세션 데이터 위치: ~/.claude/projects/{프로젝트경로인코딩}/{sessionId}.jsonl
after 세션에서 추출할 항목:
추출 명령은 collect-baseline-data Step 4의 JSONL 파싱 방법과 동일하다.
각 task pair에 대해 아래를 계산한다.
출력 품질 지표:
| 지표 | 계산식 | 해석 |
|---|---|---|
| 리뷰 지적 감소율 | (before 지적수 - after 지적수) / before 지적수 x 100 | 양수 = 개선 |
| 하네스 예방 적중률 | before에서 "하네스 예방 가능"이었던 항목 중 after에서 실제로 발생하지 않은 비율 | 하네스가 실제로 문제를 예방했는가 |
| fix 커밋 비율 변화 | (before fix비율 - after fix비율) | 양수 = 시행착오 감소 |
| 빌드 실패 감소율 | (before 실패수 - after 실패수) / before 실패수 x 100 | 양수 = 개선 |
| 암묵적 제약 위반 제거율 | before에서 발견된 implicit_constraints 중 after에서 위반하지 않은 비율 | 하네스가 암묵 지식을 명시화한 효과 |
운영 효율 지표 (세션 데이터가 있는 경우):
| 지표 | 계산식 | 해석 |
|---|---|---|
| 세션 수 변화 | after 세션수 - before 세션수 | 음수 = 더 적은 세션으로 완료 |
| 사용자 거부/수정 감소율 | (before - after) / before x 100 | 양수 = 에이전트 출력이 더 정확 |
| 방향 수정 감소율 | (before - after) / before x 100 | 양수 = 에이전트가 올바른 방향 유지 |
대화 효율 지표 (세션 JSONL 파싱 기반):
| 지표 | 계산식 | 해석 |
|---|---|---|
| 대화 턴 절감률 | (before 턴수 - after 턴수) / before 턴수 x 100 | 양수 = 더 적은 대화로 완성 |
| 추가 지시 제거율 | (before 추가지시수 - after 추가지시수) / before 추가지시수 x 100 | 양수 = 최초 요청만으로 작업 완성에 가까워짐 |
| 재수정 요청 제거율 | (before 재수정수 - after 재수정수) / before 재수정수 x 100 | 양수 = 에이전트가 한 번에 올바른 출력 |
| 완료후재수정 제거율 | (before - after) / before x 100 | 양수 = "완료" 선언이 실제 완료와 일치 |
| 불필요질문 감소율 | (before 불필요질문수 - after) / before x 100 | 양수 = 하네스가 사전 정보를 제공하여 질문 불필요 |
리뷰 코멘트 카테고리별로 before/after를 비교하여, 하네스가 어떤 유형의 문제를 잘 잡고, 어떤 유형에 효과가 없는지 파악한다.
| 카테고리 | before 건수 | after 건수 | 변화 | 하네스 기여 요인 |
|---|---|---|---|---|
| convention_violation | N | M | -K | 어떤 rule/skill이 예방했는가 |
| architecture_violation | N | M | -K | 어떤 rule이 예방했는가 |
| ... | ... | ... | ... | ... |
"하네스 기여 요인"은 실제로 어떤 CLAUDE.md 항목, rule, skill이 해당 문제 예방에 기여했는지를 구체적으로 기록한다. 기여 요인이 없는데 개선된 경우, 모델 자체 능력 향상 가능성을 명시한다.
after에서도 여전히 발생한 리뷰 지적을 분석하여, 현재 하네스에서 커버하지 못하는 영역을 식별한다.
출력:
이 출력은 propose-next-harness-step skill의 입력으로 활용 가능하다.
docs/harness-evaluation/comparison-report.json에 저장한다.
{
"generated_at": "ISO 8601 timestamp",
"task_comparisons": [
{
"task_id": "task-001",
"original_request": "요청 원문",
"difficulty": "moderate",
"quality_metrics": {
"review_comments": { "before": 8, "after": 2, "change_rate": -75 },
"harness_prevention_hit_rate": 85.7,
"fix_commit_ratio": { "before": 0.4, "after": 0.13, "change": -0.27 },
"ci_failures": { "before": 2, "after": 0, "change_rate": -100 },
"implicit_constraint_violation_eliminated": 100
},
"efficiency_metrics": {
"sessions": { "before": 3, "after": 1, "change": -2 },
"user_rejections": { "before": 3, "after": 0, "change_rate": -100 },
"direction_corrections": { "before": 1, "after": 0, "change_rate": -100 }
},
"conversation_efficiency_metrics": {
"total_turns": { "before": 24, "after": 8, "change_rate": -66.7 },
"follow_up_instructions": { "before": 5, "after": 1, "change_rate": -80 },
"revision_requests": { "before": 3, "after": 0, "change_rate": -100 },
"completion_then_revised": { "before": 2, "after": 0, "change_rate": -100 },
"unnecessary_questions": { "before": 3, "after": 0, "change_rate": -100 }
},
"category_breakdown": {
"convention_violation": {
"before": 3, "after": 0,
"harness_contributor": ".claude/rules/swift-conventions.md"
},
"architecture_violation": {
"before": 1, "after": 0,
"harness_contributor": "Modules/Player/CLAUDE.md"
}
},
"remaining_gaps": [
{
"issue": "에러 핸들링 누락",
"harness_suggestion": "error-handling-policy rule 추가",
"preventable": true
}
]
}
],
"summary": {
"total_tasks_compared": 0,
"avg_review_comment_reduction": 0,
"avg_harness_prevention_hit_rate": 0,
"avg_fix_commit_ratio_improvement": 0,
"avg_turn_reduction_rate": 0,
"avg_follow_up_elimination_rate": 0,
"avg_revision_elimination_rate": 0,
"harness_coverage_gaps": [],
"top_contributing_harness_files": []
}
}
3개 지표 카테고리 모두 비교한다:
세션이 있는 쪽의 데이터만 절대값으로 기록하고,
없는 쪽은 git 기반 간접 추정값(data_source: "inferred_from_git")을 사용한다.
비교 가능한 항목만 비교하고, 비교 불가 항목은 "change_rate": null로 표기한다.
간접 추정값끼리의 비교는 "confidence": "low"를 명시한다.
conversation_efficiency_metrics 전체를 생략하고,
아래 대체 지표로 간접 비교한다:
| 대체 지표 | 계산식 | 해석 |
|---|---|---|
| fix 커밋 비율 변화 | (before fix비율 - after fix비율) | 양수 = 시행착오 감소 |
| 총 커밋 수 변화 | (before - after) / before x 100 | 양수 = 더 적은 커밋으로 완성 |
| PR 작업 기간 변화 | (before 기간 - after 기간) | 양수 = 더 빠르게 완료 |
| force push 변화 | (before - after) | 양수 = 큰 방향 수정 감소 |
이 경우 리포트에 아래를 명시한다:
"session_data_available": false"comparison_mode": "git_proxy_only"data_source: "inferred_from_git")과 직접 파싱값을 명확히 구분한다.Use when the user wants to design an in-app user survey or questionnaire — triggers include "인앱 설문", "사용자 설문 만들어줘", "설문 문항 설계", "설문지 만들어줘", "in-app survey", "user survey questionnaire". Produces a Korean questionnaire that enforces The Mom Test and survey validity/reliability principles so any teammate gets consistent, decision-driven surveys.
기획 브레인스토밍 스킬. "아이디어 정리해주세요", "뭘 만들지 같이 고민해주세요", "설계 논의", "디자인 같이 해주세요", "이거 어떻게 만들면 좋을까요?", "기능 구상", "접근법 제안해주세요" 등의 요청 시 트리거. 구현에 들어가기 전에 아이디어를 탐색하고, 접근법을 비교하고, 디자인을 확정하는 협업 대화 스킬. 새로운 기능, 컴포넌트 생성, 기존 동작 변경 등 모든 창작 작업 전에 반드시 이 스킬을 먼저 사용해야 한다. AI Driven Development 파이프라인의 1단계이자 진입점 — 대상 프로젝트와 Memory URL을 확정하여 이후 스킬로 전파한다.
기획 시작 스킬. "기획 시작", "기획 시작해주세요", "플래닝 시작", "새 기획", "기획 킥오프" 등의 요청 시 트리거. plan-1이 확정한 프로젝트의 Memory(용어집·플로우차트)를 로드하고, 기존 플로우/로직과의 정합성을 검사하여 기획 초안을 작성한다. AI Driven Development 파이프라인의 2단계.
기획 Edge Case 검사 스킬. "edge case 검사", "엣지케이스 검토", "예외 상황 검토", "예외 케이스", "edge case 분석" 등의 요청 시 트리거. plan-2 기획 초안에서 Constraint 위반을 먼저 경고하고 누락된 edge case를 식별한다. AI Driven Development 파이프라인의 3단계. 반드시 Step 2(기획 시작)이 완료된 상태에서 사용한다.
기획 UI Layout 스킬. "UI 레이아웃", "화면 구성", "UI 설명", "레이아웃 만들어주세요", "화면 그려주세요" 등의 요청 시 트리거. 사용자가 대략적으로 설명하는 UI를 듣고 텍스트 기반 와이어프레임으로 표현하고, flowchart Memory와 진입 경로 일관성을 검증한다. AI Driven Development 파이프라인의 4단계. 반드시 Step 3(Edge Case 검사)가 완료된 상태에서 사용한다.
HTML 와이어프레임 생성 스킬. "와이어프레임 만들어주세요", "wireframe", "HTML 와이어프레임", "화면 프로토타입" 등의 요청 시 트리거. plan-4(UI Layout)의 화면 정의를 기반으로 B&W HTML 와이어프레임을 단일 파일로 생성한다. AI Driven Development 파이프라인의 5단계. 반드시 Step 4(UI Layout)가 완료된 상태에서 사용한다.