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 파라미터를 활용하여, 이전 필드 테스트에서 생성한 워크트리가 남아있으면 새로 생성하지 않고 재사용한다.

# 기존 워크트리 확인
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: 워크트리 정리

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

# 각 프로젝트별
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