| 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
cd "$EXISTING"
else
cd {프로젝트_경로}
git worktree add /tmp/nova-field-test-{프로젝트명}-{timestamp} -b nova-field-test-{timestamp}
fi
워크트리 생성 실패 시 해당 프로젝트는 건너뛰고 사유를 기록한다.
Phase 3: 서브에이전트 파견
각 프로젝트별로 서브에이전트를 생성한다. 병렬 실행한다.
서브에이전트 지시 원칙
- 자연어로 말한다 — 커맨드를 나열하지 않는다
- 목적을 설명한다 — "Nova 커맨드 써봐"가 아니라 "코드 좀 봐줘"
- 자유도를 준다 — 구체적 파일/라인을 지정하지 않는다
- 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
