Field Test

---
name: field-test
description: "Nova 방법론을 실제 프로젝트에서 검증해 개선 포인트를 찾을 때. — MUST TRIGGER: 신규 Nova 기능 검증, 사용자가 실전 피드백을 요청할 때, 워크트리 격리 환경에서 방법론을 리허설할 때."
description_en: "Use when validating the Nova methodology on real projects to find improvement points. — MUST TRIGGER: new Nova feature validation, when the user asks for real-world feedback, or when rehearsing methodology in a worktree-isolated environment."
user-invocable: false
---

# Nova Field Test

실제 프로젝트에 서브에이전트를 파견하여 Nova 커맨드를 사용하게 하고, 마찰 포인트를 수집한다.

## 핵심 원칙

- **오케스트레이터는 코드에 개입하지 않는다.** 관찰자 역할만 한다.
- **서브에이전트에게 자연어로 지시한다.** 실제 팀원에게 말하듯이.
- **워크트리로 격리한다.** 테스트 후 삭제하여 흔적을 남기지 않는다.
- **Nova 개선 포인트 수집이 목적이다.** 코드 품질 자체가 목적이 아니다.

## Execution

### Phase 1: 프로젝트 설정 (인터랙티브)

사용자에게 순서대로 질문한다:

**Q1**: "몇 개 프로젝트로 필드 테스트를 진행할까요?"

사용자가 개수를 답하면, 각 프로젝트별로 반복:

**Q2**: "프로젝트 {N}/{총개수}의 경로를 알려주세요."

**Q3**: "이 프로젝트에서 어떤 작업을 시켜볼까요? 아래에서 골라도 되고, 자유롭게 말씀해도 됩니다."

시나리오 메뉴를 제시한다:

```
1. 탐색 + 리뷰 — "코드 전체적으로 훑어보고 개선점 찾아봐"
2. 레거시 정리 — "오래된 코드 찾아서 리팩토링해봐"
3. 기능 구현 — "TODO/FIXME 하나 골라서 구현해봐"
4. 검증 — "기존 코드 테스트 돌리고 갭 분석해봐"
5. 설계 — "새 기능 하나 기획해서 plan → design까지"
6. 자유 — 직접 지시 입력
7. 알아서 — 프로젝트 상태 보고 자동 판단
```

모든 프로젝트 설정이 끝나면 확인 요약을 보여주고 승인을 받는다:

```
━━━ Field Test 설정 확인 ━━━
  1. zippit/ — 레거시 정리
  2. ccm-hub/ — 탐색 + 리뷰
  3. planreview/ — 기능 구현

  진행할까요? (y/n)
━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### Phase 2: 워크트리 생성

각 대상 프로젝트 레포에서 워크트리를 생성한다.

**기존 워크트리 재사용**: `EnterWorktree` 도구의 `path` 파라미터를 활용하여, 이전 필드 테스트에서 생성한 워크트리가 남아있으면 새로 생성하지 않고 재사용한다.

```bash
# 기존 워크트리 확인
EXISTING=$(git -C {프로젝트_경로} worktree list | grep "nova-field-test" | awk '{print $1}')

if [ -n "$EXISTING" ]; then
  # 기존 워크트리 재사용 (EnterWorktree path 파라미터 활용)
  cd "$EXISTING"
else
  # 새 워크트리 생성
  cd {프로젝트_경로}
  git worktree add /tmp/nova-field-test-{프로젝트명}-{timestamp} -b nova-field-test-{timestamp}
fi
```

워크트리 생성 실패 시 해당 프로젝트는 건너뛰고 사유를 기록한다.

### Phase 3: 서브에이전트 파견

각 프로젝트별로 서브에이전트를 생성한다. **병렬 실행**한다.

#### 서브에이전트 지시 원칙

1. **자연어로 말한다** — 커맨드를 나열하지 않는다
2. **목적을 설명한다** — "Nova 커맨드 써봐"가 아니라 "코드 좀 봐줘"
3. **자유도를 준다** — 구체적 파일/라인을 지정하지 않는다
4. **Nova 사용을 유도하되 강제하지 않는다** — "필요하면 리뷰도 돌려봐" 정도

#### 시나리오별 지시 템플릿

각 시나리오에 대해 아래 템플릿을 **기반으로** 자연어 지시를 생성한다.
그대로 복사하지 말고, 프로젝트 상태에 맞게 변형한다.

**탐색 + 리뷰**:
> "{프로젝트명} 프로젝트를 맡게 됐어. 전체 구조를 파악하고 코드 품질이 어떤지 봐줘.
> 개선할 점이 보이면 리뷰 돌려서 정리해줘. 큰 문제 있으면 알려주고."

**레거시 정리**:
> "이 프로젝트에 오래된 코드가 좀 있을 거야. 훑어보고 레거시 느낌나는 부분 찾아줘.
> 정리할 수 있는 건 정리하고, 큰 건 계획만 세워줘. 끝나면 리뷰 한번 돌려봐."

**기능 구현**:
> "코드에 TODO나 FIXME가 있을 텐데, 하나 골라서 구현해봐.
> 너무 큰 거 말고 적당한 거로. 끝나면 검증까지 해줘."

**검증**:
> "이 프로젝트가 제대로 돌아가는지 확인 좀 해줘. 테스트 있으면 돌려보고,
> 설계 문서가 있으면 실제 코드랑 맞는지도 봐줘."

**설계**:
> "이 프로젝트에 추가하면 좋을 기능 하나 생각해봐.
> 기획부터 설계까지 해보고, 구현은 하지 마. 문서만 만들어줘."

**알아서**:
> "이 프로젝트 처음 보는 거야. 코드 파악하고, 네가 보기에 가장 필요한 작업을 해줘.
> 버그 수정이든, 정리든, 새 기능이든 판단은 네 몫이야."

#### 서브에이전트에 반드시 포함할 컨텍스트

```
작업 디렉토리: {워크트리_경로}
주의사항:
- 이 프로젝트에는 Nova Quality Gate가 설치되어 있어. Nova 커맨드(/plan, /review, /check, /ask 등)를 적극 활용해.
- 작업 완료 시 반드시 아래 형식으로 피드백을 보고하라. 이 보고가 없으면 작업 미완료로 간주한다.

## 피드백 보고 형식 (필수)

### 작업 요약
어떤 작업을 했는지 3~5줄로 요약한다.

### Nova 커맨드 사용 경험
- 잘 된 점: (사용한 커맨드와 효과)
- 불편했던 점: (구체적 상황과 기대와 다른 점)
- 안 먹힌 점: (커맨드가 반응하지 않거나 오작동한 경우)

### 아쉬운 기능
"이런 기능이 있었으면" 하는 점을 구체적으로 기술한다.

### 과잉/부족 개입 순간
Nova가 과도하게 개입하거나 부족했던 구체적 순간을 기술한다.
```

### Phase 4: 결과 수집

각 서브에이전트의 보고를 수집하고, 다음 관점에서 분석한다:

#### 마찰 포인트 분류

| 분류 | 설명 | 예시 |
|------|------|------|
| **Blocker** | Nova가 작업을 방해함 | 불필요한 Plan 강제, 과도한 검증 |
| **Missing** | Nova에 없어서 아쉬운 기능 | 특정 시나리오 미지원 |
| **Friction** | 되긴 하는데 불편함 | 커맨드 출력 과다, 판정 기준 모호 |
| **Positive** | 잘 작동한 부분 | 확인된 강점, 유지할 것 |

#### P-레벨 분류

| 레벨 | 기준 |
|------|------|
| **P0** | 2개+ 프로젝트에서 동일 마찰 발생, 또는 Blocker |
| **P1** | 1개 프로젝트에서 Blocker, 또는 2개+에서 Friction |
| **P2** | 단일 프로젝트 Friction, 또는 Missing 제안 |

### Phase 5: 워크트리 정리

모든 서브에이전트 완료 후:

```bash
# 각 프로젝트별
cd {프로젝트_경로}
git worktree remove /tmp/nova-field-test-{프로젝트명}-{timestamp} --force
git branch -D nova-field-test-{timestamp}
```

정리 실패 시 수동 정리 명령을 사용자에게 안내한다.

### Phase 6: 종합 리포트

```
━━━ Nova Field Test Report ━━━━━━━━━━━━━━━━━

테스트 프로젝트: {개수}개
서브에이전트 파견: {성공}/{총}

## P0 — 즉시 수정
- {마찰 포인트} ({발생 프로젝트들})

## P1 — 다음 릴리스
- {마찰 포인트} ({발생 프로젝트})

## P2 — 백로그
- {마찰 포인트}

## Positive — 유지
- {잘 작동한 점}

## 권장 다음 액션
- {구체적 개선 작업 목록}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

리포트 출력 후, 사용자가 원하면 P0 항목부터 바로 수정 작업에 돌입할 수 있다.

## Input

$ARGUMENTS