generate-retest-prompts

name	generate-retest-prompts
description	baseline-report.json을 기반으로 하네스 적용 재작업에 사용할 구조화된 프롬프트 스펙을 자동 생성한다. 재작업자가 동일 조건에서 하네스 효과를 공정하게 비교할 수 있도록 작업 요청서를 만든다.
allowed-tools	Read Grep Glob Bash

재작업용 프롬프트 스펙 생성

이 스킬의 목적

baseline-report.json의 각 task를 입력으로 받아, 하네스 적용 상태에서 동일 작업을 재현할 수 있는 구조화된 작업 요청서를 생성한다.

재작업자(사용자 또는 에이전트)가 이 문서만 보고 동일 조건에서 작업을 재실행할 수 있어야 한다.

입력

• docs/harness-evaluation/baseline-report.json (collect-baseline-data 산출물)
• 프로젝트의 현재 하네스 구성 (CLAUDE.md, rules, skills, hooks)

생성 절차

Step 1: baseline-report.json 로드

각 task에서 아래 필드를 추출한다.

• original_request — 원본 작업 요청
• difficulty — 작업 난이도
• scope.modules_affected — 영향 모듈
• implicit_constraints — 리뷰에서 드러난 암묵적 제약
• review_metrics.by_category — 카테고리별 지적 건수
• review_metrics.harness_preventable — 하네스 예방 가능 분류
• session_conversation_flow — 세션 대화 흐름 데이터 (있는 경우)
  • initial_request — 세션에서 추출한 최초 요청 원문
  • initial_request_urls — 피그마, GitHub 이슈 등 외부 링크
  • follow_up_instructions — 최초 요청 이후 추가 지시 목록
  • revision_requests — 재수정 요청 목록
  • total_turns_to_completion — 완성까지 총 대화 턴 수

Step 1.5: 참조 자료 누락 경고 확인

baseline-report.json의 각 task에서 missing_reference_warning.detected가 true인지 확인한다.

• detected: true이고 resolved가 없으면: 재작업 요청서 상단 경고에 아래를 추가한다.

  경고: 이 작업에 참조 자료(피그마, 기획 문서 등)가 누락되었을 수 있다. 원본 작업 시 참조 자료가 있었다면 프롬프트에 포함해야 공정한 비교가 된다. harness-evaluator를 통해 진행했다면 이미 확인이 완료된 상태여야 한다.

• resolved: "no_reference_existed"이면: 경고 없이 진행한다.

• initial_request_urls에 값이 있으면: 경고 없이 정상 포함한다.

Step 2: 현재 하네스 구성 스캔

프로젝트에 현재 적용된 하네스 파일을 확인한다.

• 루트 CLAUDE.md
• 모듈별 CLAUDE.md (영향 모듈 기준)
• .claude/rules/*.md 중 해당 모듈 경로에 매칭되는 것
• .claude/skills/ 중 작업과 관련된 것
• .claude/hooks/ 중 활성화된 것

이 목록은 프롬프트 스펙의 "활성 하네스" 섹션에 포함된다.

Step 3: 프롬프트 스펙 생성

각 task별로 아래 템플릿에 맞춰 마크다운 파일을 생성한다.

# 재작업 요청서: {task_id}

> **주의: 이 파일은 평가 진행자용 참고 문서다.**
> 이 파일 전체를 에이전트에게 전달하지 않는다.
> 에이전트에게 전달하는 것은 "재작업 실행 방법" 섹션의 프롬프트 블록뿐이다.
> 그 외 내용(암묵적 제약, baseline 지적, 검증 포인트)은
> 재작업 완료 후 평가자가 결과를 검증할 때 참고하는 용도다.

## 원본 요청

> {original_request 원문 그대로}

## 원본 작업 컨텍스트

> 세션 데이터가 있으면 JSONL에서 추출한 상세 정보를 포함한다.
> 세션 데이터가 없으면 git 기반 간접 추정 정보를 대신 포함한다.

### 외부 참조 링크
{initial_request_urls 목록 — 피그마, GitHub 이슈, 문서 링크 등}

### 최초 요청 이후 추가 지시 흐름
원본 작업 시 사용자가 최초 요청 이후 추가로 내린 지시들이다.
하네스가 이 추가 지시 없이도 올바른 결과를 내는지 확인하는 참고 자료다.

| 턴 | 추가 지시 | 유형 |
|----|----------|------|
{follow_up_instructions 테이블}

### 재수정 이력
원본 작업 시 사용자가 에이전트 출력을 거부/수정 요청한 내역이다.
하네스가 이 재수정 없이도 올바른 출력을 내는지 확인하는 핵심 비교 포인트다.

| 턴 | 재수정 요청 | 유형 | 대상 |
|----|-----------|------|------|
{revision_requests 테이블}

### 원본 작업 완성 통계

**세션 데이터 기반** (있는 경우):
- 완성까지 총 대화 턴: {total_turns_to_completion}
- 재수정 요청 횟수: {revision_requests 수}
- 추가 지시 횟수: {follow_up_instructions 수}

**git 기반 간접 추정** (세션 데이터 없는 경우):
- 총 커밋 수: {total_commits}
- fix 커밋 수: {fix_commits} (시행착오 하한값)
- force push 횟수: {force_pushes} (큰 방향 수정 신호)
- PR 작업 기간: {pr_created_at} ~ {last_commit_at}

## 작업 조건

- **난이도**: {difficulty}
- **영향 모듈**: {modules_affected}
- **base commit**: {base_commit}
- **브랜치**: 하네스측정용 브랜치에서 위 base commit 기준으로 작업

## 제약 조건

### 명시적 제약 (원본 요청에 포함)
{original_request에서 추출한 제약 조건 목록}

### 암묵적 제약 (baseline 리뷰에서 발견)
{implicit_constraints 목록}

> 이 제약들은 원본 요청에 없었지만 리뷰에서 지적된 것이다.
> 하네스가 이 제약들을 사전에 인식시키는지 확인하는 것이 핵심이다.
> **재작업 시 이 제약을 요청에 추가하지 않는다.**
> 하네스(CLAUDE.md, rules)가 스스로 이 제약을 인식하고 지켜야 한다.

## baseline 지적 요약

| 카테고리 | 건수 | 하네스 예방 가능 |
|----------|------|-----------------|
{카테고리별 테이블}

> 이 표는 재작업 후 비교 기준으로 사용된다.
> 재작업 결과에서 위 항목들이 발생하지 않으면 하네스 효과로 판단한다.

## 활성 하네스

재작업 시 아래 하네스 파일이 적용된 상태여야 한다.

### 전역
{루트 CLAUDE.md, 전역 rules 목록}

### 모듈별
{영향 모듈의 CLAUDE.md, 모듈 스코프 rules 목록}

### Skills
{관련 skills 목록}

### Hooks
{활성 hooks 목록}

## 재작업 실행 방법

1. 하네스측정용 브랜치로 체크아웃
2. base commit에서 새 작업 브랜치 생성
3. Claude Code 세션 시작
4. 아래 프롬프트를 **그대로** 입력:

\```
{original_request 원문}

{외부 참조 링크가 있는 경우 아래에 포함}
참고 자료:
- {피그마 링크}
- {GitHub 이슈 링크}
- {기타 문서 링크}
\```

> **프롬프트 구성 규칙**:
> - 원본 요청 원문은 변형하지 않는다.
> - 외부 참조 링크(피그마, 이슈, 문서)는 원본 작업 시에도 제공되었던 것이므로
>   재작업에서도 동일하게 포함한다. 이것은 작업 입력의 일부다.
> - 단, 암묵적 제약, baseline 지적, 검증 포인트는 절대 포함하지 않는다.
> - 외부 참조 링크가 없으면 "참고 자료" 섹션을 생략한다.

5. 추가 지시 없이 에이전트가 하네스만으로 작업하게 둔다
6. 완료 후 커밋

## 검증 포인트

재작업 완료 후 아래를 확인한다:

### 하네스 효과 검증
- [ ] 암묵적 제약을 별도 지시 없이 지켰는가
- [ ] baseline에서 지적된 convention_violation이 재발하지 않았는가
- [ ] baseline에서 지적된 architecture_violation이 재발하지 않았는가
- [ ] 불필요한 변경(unnecessary_change)이 없는가
- [ ] fix 커밋 없이 한 번에 올바른 결과가 나왔는가

### 대화 효율 검증 (세션 데이터 있는 경우)
- [ ] 원본 작업의 추가 지시 없이 동일 범위를 완성했는가
- [ ] 원본 작업에서 발생한 재수정 요청이 재작업에서는 불필요했는가
- [ ] 완성까지 대화 턴 수가 원본보다 줄었는가 (원본: {total_turns_to_completion}턴)
- [ ] 외부 참조 링크(피그마 등)의 내용을 하네스가 사전 반영하고 있는가

### 간접 효율 검증 (세션 데이터 없는 경우 대체)
- [ ] fix 커밋 수가 원본보다 줄었는가 (원본: {fix_commits}개)
- [ ] 총 커밋 수가 원본보다 줄었는가 (원본: {total_commits}개)
- [ ] force push 없이 완료했는가 (원본: {force_pushes}회)
- [ ] PR 작업 기간이 원본보다 짧은가

Step 4: 인덱스 파일 생성

전체 task의 요약 인덱스를 생성한다.

# 재작업 프롬프트 인덱스

| task_id | PR | 난이도 | 영향 모듈 | 프롬프트 |
|---------|-----|--------|----------|---------|
| task-001 | #42 | moderate | feature-player, core-shared | [링크](task-001.md) |

출력

docs/harness-evaluation/retest-prompts/
├── index.md          # 전체 task 요약 인덱스
├── task-001.md       # task별 재작업 요청서
├── task-002.md
└── ...

중요 규칙

• 원본 요청을 변형하지 않는다. 재작업 프롬프트에 암묵적 제약을 섞어 넣으면 비교가 무의미해진다.
• 외부 참조 링크는 프롬프트에 포함한다. 피그마, GitHub 이슈, 문서 링크 등은 원본 작업의 입력 컨텍스트이므로 재작업에서도 동일하게 제공해야 공정한 비교가 된다.
• 암묵적 제약은 "검증 포인트"로만 기록하고, 하네스가 스스로 인식하는지 확인하는 용도로 쓴다.
• task-xxx.md 파일 전체를 에이전트에게 전달하지 않는다. 전달하는 것은 "재작업 실행 방법"의 프롬프트 블록뿐이다.
• 하네스 구성 스캔 결과가 비어 있으면 (아직 하네스 셋업이 안 된 상태) 경고를 출력한다.
• baseline-report.json에 null인 필드는 "데이터 없음"으로 표기한다.