codex

/codex — 코드 작업 표준 프로토콜

정체성과 목적

주인님께서 코드 작업(기능 추가, 리팩터링, 버그 수정)을 요청하셨을 때, 즉흥적으로 파일을 고치지 않고 탐색 → 계획 → 수정 → 검증 → 보고의 일관된 6단계 프로토콜을 따르는 스킬입니다.

/codex는 "어떻게 작업하느냐"의 규율을 담보합니다. 산출물은 변경된 코드와 검증 증거, 그리고 학습 기록입니다.

---

기존 스킬과의 경계 (중요)

혼동을 막기 위해 명시합니다.

스킬	역할	/codex와의 차이
/review	이미 완료된 코드를 Dev+Reviewer 에이전트로 리뷰	/codex는 진행 중 작업의 표준 절차
/sdd	Task→Dev→Feature→인수테스트의 스펙부터 시작하는 프로세스	/codex는 스펙이 이미 확정된 코드 작업의 절차
/investigate	5 Why로 근본 원인을 파고드는 디버깅	/codex는 원인이 파악된 뒤 수정 실행 절차
/simplify	이미 작성된 코드의 단순화·재사용성 점검	/codex는 신규·수정 작업 전체 사이클

판단 기준:

• 완성된 PR을 리뷰하고 싶다 → /review
• 새 기능을 스펙부터 만든다 → /sdd
• 원인을 모르는 장애를 추적한다 → /investigate
• 기능 추가·리팩터·버그 수정 코드 작업을 한다 → /codex

---

Phase 0 — 사전 점검 (Jarvis 특화 3종 통합)

작업 시작 전 반드시 다음 3가지를 조회합니다.

0-1. 오답노트 스캔

LEARNED=$HOME/jarvis/runtime/wiki/meta/learned-mistakes.md
if [ -f "$LEARNED" ]; then
  grep -i -E "<작업 도메인 키워드>" "$LEARNED" | head -10
fi

• 유사 실수 패턴이 있으면 Phase 3 수정 단계에 가드 체크리스트로 삽입
• 대표적 패턴 예: "3단계 파이프라인 부분 실행", "Virtual Thread + HikariCP 고갈", "좀비 캐시"

0-2. Eureka 재사용 패턴 검색

EUREKA=$HOME/jarvis/runtime/wiki/meta/eureka.jsonl
if [ -f "$EUREKA" ]; then
  grep -i -E "<도메인 키워드>" "$EUREKA" | tail -5
fi

• 과거에 성공한 접근법이 있으면 우선 재사용 후보
• 없으면 신규 학습 수확 대상으로 표시

0-3. 조직도 포지셔닝

• 단순 국소 수정(파일 1~2개): 비서실장(Sonnet) 자율 진행 → L1 또는 L2
• 파이프라인·스키마·보안 영향: 비서실장 승인 필요 → L3
• 프로덕션 배포·데이터 삭제·결제 로직: 주인님 결재 필요 → L4

작업 범위가 L3~L4에 해당하면 Phase 2 계획 단계에서 승인 경로를 명시합니다.

---

Phase 1 — 탐색 (Glob → Grep → Read, 효율 우선)

원칙

1. 전체 파일 Read 금지(최후 수단). 심볼 단위로 접근합니다.
2. Serena 우선: get_symbols_overview → find_symbol(include_body=true) → find_referencing_symbols 순서.
3. Serena가 부적절한 파일 유형(MD, JSON, shell)이면 Glob → Grep으로 좁힌 뒤 필요한 부분만 Read.

기본 순서

1. Glob으로 대상 파일/디렉토리 후보 좁히기
   예: Glob("src/**/*.service.ts")

2. Grep으로 키워드·심볼 위치 특정
   예: Grep("deductBalance", type="ts", output_mode="content", -n=true)

3. Serena find_symbol로 의미 단위 조회
   예: find_symbol("PaymentService/deductBalance", include_body=true)

4. 참조 관계 확인
   예: find_referencing_symbols("PaymentService/deductBalance")

5. 필요한 부분만 Read (offset/limit 활용)