Feat/obs mode

.claude/CLAUDE.md

@@ -1,41 +1,65 @@
 # 로컬 워크플로 규칙
 
+## 구현 요청 시 필수 행동
+
+사용자가 다음 중 하나에 해당하는 요청을 하면, **무조건 첫 번째 도구 호출로 `Skill` 도구를 사용하여 `/codex-plan`을 실행**해야 합니다:
+- 기능 구현/추가 ("~해줘", "~추가해줘", "~구현해줘", "~만들어줘")
+- 리팩토링/아키텍처 변경
+- 설계 논의/계획 수립
+
+이것은 이 프로젝트의 **절대 규칙**입니다:
+1. 사용자 메시지를 읽는다
+2. 구현 요청인지 판단한다
+3. 구현 요청이면 → **즉시 `Skill(skill: "codex-plan", args: "사용자 요청 내용")`을 호출한다**
+4. Read, Grep, Glob, Agent 등 다른 도구는 `/codex-plan` 스킬 실행 후에만 사용한다
+
+**위반 금지**: 파일을 먼저 읽거나, 코드를 분석하거나, 계획을 직접 세우는 행위는 이 규칙의 위반입니다.
+
+예외: 단순 버그 수정(1~2줄), 오타/포맷팅 수정, 질문/설명 요청
+
 ## 기본 워크플로
 
 모든 구현 작업은 다음 워크플로를 따릅니다.
 
 ### 1. 계획 수립 (필수)
-사용자의 구현 요청이나 설계 논의가 있으면 `/plan` 스킬을 사용하여 Codex와 함께 계획을 수립합니다.
-- 단순 버그 수정이나 1~2줄 변경이 아닌 이상 항상 plan을 먼저 실행
-- Claude 선분석 → Codex 검증 → 최종 계획 확정
+위 규칙에 따라 `/codex-plan` 스킬을 호출합니다.
+- Claude 선분석 → Codex 독립 검증 → 최종 계획 확정
 
 ### 2. 단계별 구현 + 코드 리뷰
-확정된 계획을 단계별로 나누어 구현하고, 각 단계마다 `/codex-review`로 코드 리뷰를 수행합니다.
+확정된 계획을 단계별로 나누어 구현합니다.
 - 한 번에 모든 변경을 하지 않고, 논리적 단위로 분리
-- 각 단계 완료 후 Codex 리뷰 → 이슈 있으면 수정 → 리뷰 통과 확인
+- 각 단계 완료 후 변경의 규모와 리스크를 판단하여 Codex 리뷰 필요 여부를 결정
+- Codex 리뷰가 필요하다고 판단되면 `/codex-review` 실행
+- 리뷰 없이 진행할 경우 그 판단 근거를 간단히 명시
+
+### 3. 빌드/린트 검증
+변경 내용에 따라 적절한 검증을 수행합니다.
+- Rust 변경: `cargo check`, `cargo clippy`
+- TypeScript 변경: `npx tsc --noEmit`, `npm run lint`
+- 검증 주체(Claude/Codex)는 상황에 따라 자유롭게 결정
 
-### 3. 자동 커밋
-각 단계의 리뷰가 통과되면 해당 변경사항을 즉시 커밋합니다.
+### 4. 자동 커밋
+각 단계의 검증이 통과되면 해당 변경사항을 즉시 커밋합니다.
 - 커밋 메시지는 변경 내용에 맞게 작성
 - 단계별로 커밋하여 git 히스토리를 깔끔하게 유지
 
 ### 워크플로 예시
 ```
 사용자: "키보드 입력 시스템에 딜레이 옵션 추가해줘"
 
-1. /plan 실행 → Codex와 구현 계획 수립
+1. Skill(skill: "codex-plan", args: "키보드 입력 시스템에 딜레이 옵션 추가") ← 무조건 첫 번째
 2. 단계 1: Rust 백엔드 커맨드 추가 → /codex-review → 커밋
-3. 단계 2: 프론트엔드 설정 UI 추가 → /codex-review → 커밋
+3. 단계 2: 프론트엔드 설정 UI 추가 → 변경 소규모로 판단, Claude 자체 검증 → 커밋
 4. 단계 3: 오버레이 반영 로직 수정 → /codex-review → 커밋
 ```
 
-### 4. 최종 보고
+### 5. 최종 보고
 모든 단계가 완료되면 작업 결과를 정리하여 보고합니다.
 - 변경된 파일 목록과 각 변경 요지
 - 커밋 히스토리 요약
 - Codex 리뷰에서 나온 주요 피드백과 반영 여부
 - 남은 리스크나 후속 작업이 있으면 명시
 
 ## 예외
-- 1~2줄 수정, 오타 수정, 포맷팅 등 사소한 변경은 plan/review 없이 직접 처리
+- 사소한 변경(오타, 포맷팅, import 정리 등)은 plan/review 없이 직접 처리
 - 긴급 핫픽스는 plan 없이 구현 후 review만 수행

.claude/skills/codebase-memory-exploring/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: codebase-memory-exploring
+description: >
+  This skill should be used when the user asks to "explore the codebase",
+  "understand the architecture", "what functions exist", "show me the structure",
+  "how is the code organized", "find functions matching", "search for classes",
+  "list all routes", "show API endpoints", or needs codebase orientation.
+---
+
+# Codebase Exploration via Knowledge Graph
+
+Use graph tools for structural code questions. They return precise results in ~500 tokens vs ~80K for grep-based exploration.
+
+## Workflow
+
+### Step 1: Check if project is indexed
+
+```
+list_projects
+```
+
+If the project is missing from the list:
+
+```
+index_repository(repo_path="/path/to/project")
+```
+
+If already indexed, skip — auto-sync keeps the graph fresh.
+
+### Step 2: Get a structural overview
+
+```
+get_graph_schema
+```
+
+This returns node label counts (functions, classes, routes, etc.), edge type counts, and relationship patterns. Use it to understand what's in the graph before querying.
+
+### Step 3: Find specific code elements
+
+Find functions by name pattern:
+```
+search_graph(label="Function", name_pattern=".*Handler.*")
+```
+
+Find classes:
+```
+search_graph(label="Class", name_pattern=".*Service.*")
+```
+
+Find all REST routes:
+```
+search_graph(label="Route")
+```
+
+Find modules/packages:
+```
+search_graph(label="Module")
+```
+
+Scope to a specific directory:
+```
+search_graph(label="Function", qn_pattern=".*services\\.order\\..*")
+```
+
+### Step 4: Read source code
+
+After finding a function via search, read its source:
+```
+get_code_snippet(qualified_name="project.path.to.FunctionName")
+```
+
+### Step 5: Understand structure
+
+For file/directory exploration within the indexed project:
+```
+list_directory(path="src/services")
+```
+
+## When to Use Grep Instead
+
+- Searching for **string literals** or error messages → `search_code` or Grep
+- Finding a file by exact name → Glob
+- The graph doesn't index text content, only structural elements
+
+## Key Tips
+
+- Results default to 10 per page. Check `has_more` and use `offset` to paginate.
+- Use `project` parameter when multiple repos are indexed.
+- Route nodes have a `properties.handler` field with the actual handler function name.
+- `exclude_labels` removes noise (e.g., `exclude_labels=["Route"]` when searching by name pattern).

.claude/skills/codebase-memory-quality/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: codebase-memory-quality
+description: >
+  This skill should be used when the user asks about "dead code",
+  "find dead code", "detect dead code", "show dead code", "dead code analysis",
+  "unused functions", "find unused functions", "unreachable code",
+  "identify high fan-out functions", "find complex functions",
+  "code quality audit", "find functions nobody calls",
+  "reduce codebase size", "refactor candidates", "cleanup candidates",
+  or needs code quality analysis.
+---
+
+# Code Quality Analysis via Knowledge Graph
+
+Use graph degree filtering to find dead code, high-complexity functions, and refactor candidates — all in single tool calls.
+
+## Workflow
+
+### Dead Code Detection
+
+Find functions with zero inbound CALLS edges, excluding entry points:
+
+```
+search_graph(
+  label="Function",
+  relationship="CALLS",
+  direction="inbound",
+  max_degree=0,
+  exclude_entry_points=true
+)
+```
+
+`exclude_entry_points=true` removes route handlers, `main()`, and framework-registered functions that have zero callers by design.
+
+### Verify Dead Code Candidates
+
+Before deleting, verify each candidate truly has no callers:
+
+```
+trace_call_path(function_name="SuspectFunction", direction="inbound", depth=1)
+```
+
+Also check for read references (callbacks, stored in variables):
+
+```
+query_graph(query="MATCH (a)-[r:USAGE]->(b) WHERE b.name = 'SuspectFunction' RETURN a.name, a.file_path LIMIT 10")
+```
+
+### High Fan-Out Functions (calling 10+ others)
+
+These are often doing too much and are refactor candidates:
+
+```
+search_graph(
+  label="Function",
+  relationship="CALLS",
+  direction="outbound",
+  min_degree=10
+)
+```
+
+### High Fan-In Functions (called by 10+ others)
+
+These are critical functions — changes have wide impact:
+
+```
+search_graph(
+  label="Function",
+  relationship="CALLS",
+  direction="inbound",
+  min_degree=10
+)
+```
+
+### Files That Change Together (Hidden Coupling)
+
+Find files with high git change coupling:
+
+```
+query_graph(query="MATCH (a)-[r:FILE_CHANGES_WITH]->(b) WHERE r.coupling_score >= 0.5 RETURN a.name, b.name, r.coupling_score, r.co_change_count ORDER BY r.coupling_score DESC LIMIT 20")
+```
+
+High coupling between unrelated files suggests hidden dependencies.
+
+### Unused Imports
+
+```
+search_graph(
+  relationship="IMPORTS",
+  direction="outbound",
+  max_degree=0,
+  label="Module"
+)
+```
+
+## Key Tips
+
+- `search_graph` with degree filters has no row cap (unlike `query_graph` which caps at 200).
+- Use `file_pattern` to scope analysis to specific directories: `file_pattern="**/services/**"`.
+- Dead code detection works best after a full index — run `index_repository` if the project was recently set up.
+- Paginate results with `limit` and `offset` — check `has_more` in the response.