TFTDataAnalyzer

Imported from Ghyeok/TFTDataAnalyzer (AGENTS.md). Install upstream with npx skills add Ghyeok/TFTDataAnalyzer. Copyright stays with the author.

TFTDataAnalyzer 작업 규칙

프로젝트

• TFT 정적 데이터와 과거 경기의 익명 집계 분석 도구다. 전투 시뮬레이션·미래 승패 예측은 범위 밖이다.
• 목적·현황은 README, 제품 코드 작업의 설계·단계는 설계와 워크플로를 확인한다. 이미 승인된 범위는 이어서 수행한다.
• 지침과 관련 스킬의 진입점은 작업 지침 색인이다. 필요한 항목만 읽고, 과거 실행 기록을 현재 지시나 완료 증거로 적용하지 않는다.

모델 선택

• 사용자 지정 모델을 우선한다. 기존 워크플로의 역할별 고정 모델보다 이 작업 수준 기준을 우선한다.
• 데이터 손상·비밀값·개인정보 관련 설계·검수에는 Astra · High를 우선 고려한다. xhigh·max는 개선 근거가 있을 때만 사용한다.
• 정보 부족은 먼저 조사하고, 근거 없는 반복 수정은 중단해 재분석한다. 실제 전환·모델을 확인하지 못하면 완료했다고 주장하지 않는다.
• 선택이 애매하거나 단계별 배정·비용 평가가 필요할 때만 모델 상세 지침을 읽는다. 역할표가 모든 모델·에이전트의 호출을 요구하지는 않는다.

PR 검수 대기

• 사용자의 2026-10-19 요청으로 Hermes의 CodeRabbit 5분 확인 예약은 일시중단했다. 사용자 명시 재개 전까지 예약을 재개하거나 대기 루프·주기적 AI 호출·자동 재개를 하지 않는다. 이전 등록 이력·중단 증거·알림 한계는 검수 모니터 지침을 따른다.
• 최신 head의 CodeRabbit 결과·미해결 검수 항목·CI 상태를 구분한다. 변화가 없으면 조용히 넘어가고, 새 통과·수정 요청·실행 실패·복구 등 조치 가능한 변화만 기록한다. 과거 head의 통과를 최신 head에 적용하지 않는다.
• PR 생성 또는 수정 커밋 push 후 PR 링크·검증 결과·다음 행동을 알리고 대화를 종료한다. 파일 준비만으로 예약·Codex 자동 재개·채팅 알림을 설정했다고 주장하지 않는다. 실제 등록·시험 실행 증거가 있어야 예약 활성화를 보고한다.
• 사용자가 재개하면 최신 검수·미해결·테스트를 확인하고, 진행 중이면 상태를 한 번 알린다. 통과 시 기존 병합 승인 범위를 따른다. Hermes 모니터는 조회·협업 폴더 기록만 수행하며 제품 수정·Git 쓰기·Unity 제어·자동 병합 권한을 갖지 않는다.

Hermes 협업: 필수 전달 경로

• Hermes와 주고받는 모든 요청·자료·응답·결과는 반드시 프로젝트 루트의 HermesCollab/를 거친다. 협업 전 전달 규칙을 읽는다.
• 작업별 HermesCollab/tasks/<task-id>/에 request.md, inputs/, result.md, outputs/를 사용한다. 필요한 원본은 inputs/에 복사하고 출처 경로·기준 커밋을 기록한다.
• Hermes의 작업 입력은 해당 폴더의 자료로 제한한다. 폴더 밖 원본의 직접 열람·수정이나 다른 경로의 결과 전달로 우회하지 않는다.
• CLI·API를 쓰더라도 실제 요청·응답은 폴더에 기록하고, 실행 신호에는 작업 ID·폴더 위치만 전달한다. 미완성 결과를 최종 응답으로 취급하거나 경로 전달만으로 자동 실행됐다고 판단하지 않는다.
• Codex가 구현·Unity 실행·통합을 맡고, Hermes는 기본적으로 읽기 전용 검수·요약을 맡는다. 수정 제안은 outputs/로 전달하고 검증 후 통합한다.

보존과 검증

• 사용자 변경과 기존 카탈로그를 보존하며 요청 범위만 수정한다. 비밀값·식별 가능한 원본 경기 응답은 협업 폴더에도 저장하지 않는다.
• 변경에 적합한 실제 검증을 수행한다. AI·CodeRabbit 의견은 실행 증거를 대체하지 않으며, 미실행 검증은 구분해 기록한다.
• 실제 모델·추론, 변경 이유, 확인 가능한 사용량·시간·재작업과 최종 결과를 간단히 남긴다. 문서만 변경하면 내용·링크·형식을 확인한다.

Unity 검증 창 정리

• EditorWindow 테스트·수동 캡처 전에 Unity Editor 검증 절차와 실패 사례를 읽는다. 창 정리·UI 상태·실제 캡처 이미지의 검증 결과를 각각 구분한다.
• MCP·CLI로 검증 창을 열기 전에 기존 창 instance ID와 포커스를 기록한다. 검증용 창은 직접 생성해 소유 객체를 추적하고, 사용자 창을 재사용해 크기·위치를 바꾸지 않는다.
• 테스트·캡처는 짧은 한 작업 안에서 수행하고 성공·실패·취소·시간 초과 모두 finally에서 생성한 창과 예약 콜백을 정리한다. 사용자 요청 없이 검증 창을 열린 채로 두지 않는다.
• 기존 Inspector는 보존한다. 검증 때문에 새로 만든 Inspector와 테스트 호스트만 닫고 원래 포커스를 복원한다. 타입·제목만으로 창을 일괄 종료하지 않는다.
• 표시한 창은 Close()로 바깥 프레임까지 닫는다. 표시 전 생성에 실패한 객체나 닫기 실패 후 남은 정확한 소유 객체만 DestroyImmediate로 정리한다.
• 실행 전후 EditorWindow와 native ContainerWindow ID를 함께 대조해 기존 창 보존과 소유 창·빈 프레임 잔류 0개를 확인한다. 정리 실패나 연결 끊김은 사실대로 알리고, 닫았다는 증거 없이 완료로 기록하지 않는다.
• 현재 수집 탭의 수동 화면 검증은 소유 창 검증 도구를 사용한다. -ProbeFailure로 예외 정리도 확인할 수 있다. 이전 Library의 분리된 open/capture 스크립트는 재사용하지 않는다.
• 분석 탭은 분석 검증 도구를 사용한다. 실제 PNG를 확인하고, 새 HWND를 실행 전 PID별 집합과 대조해 소유 프레임이 하나로 확정될 때만 가시성을 바꾼다. 사용자 프레임에는 적용하지 않는다.