simon-study

simon-study

문제 기반 심층 학습 스킬. 구체적인 문제에서 출발하여, 개념 이해 → 멘탈 모델 추출 → 설계 트레이드오프 → 개선 방향을 하나의 보고서로 정리합니다.

자율주행모드 ON 입니다. 여러 Agent와 병행하여 딥하게 조사해주세요. 이 선언은 CLAUDE.md의 모호성 확인 규칙보다 우선한다 — 분석 진행 중 세부 모호함은 스스로 판단해 진행한다. 단, 분석 대상 자체(코드/레포/질문)가 특정되지 않는 수준의 모호함은 시작 전 1회만 확인한다.

Why this exists

학습은 보통 추상적 개념이나 코드 경로에서 시작하지 않습니다. 실제로는 구체적인 문제에서 시작합니다:

"Quantile이 0%일 때 문제가 있다. Quantile이 뭔지부터, 코드에서 어떻게 동작하는지, 왜 0%가 문제인지, 어떻게 고칠지 알고 싶다."

이 스킬은 그 사고 흐름을 따라 개념과 코드를 엮어 보고서를 만듭니다.

Instructions

진행 체크포인트: 각 Phase 경계에서 1줄 진행 보고를 출력한다 — [Phase N 완료] {핵심 결과 요약} — Phase N+1 시작 형식. 장시간 무응답 구간에서 사용자가 진행 상태를 알 수 있게 한다 (AskUserQuestion 아님, 단순 텍스트).

Phase 1: 문제 정의

사용자의 질문/문제를 파악합니다.

구체적인 경우 (예: "Quantile 0% 문제 파악하고 싶어"):

• 바로 다음 단계로 진행

모호한 경우 (예: "이 코드 좀 공부하고 싶어"):

• 2-3개의 구체적 방향을 제시하여 선택받음

문제가 정의되면, 학습에 필요한 질문 체인을 내부적으로 구성합니다:

예시 — "Quantile 0% 문제 개선"
1. Quantile이란 무엇인가? (개념)
2. 우리 코드에서 Quantile을 어떻게 사용하는가? (코드)
3. 0%일 때 어떤 동작이 발생하는가? (코드 + 개념)
4. 왜 그것이 문제인가? (설계 트레이드오프)
5. 어떤 개선 방법이 있는가? (개념 + 코드)

Phase 2: 리서치 — 개념과 코드를 동시에

병렬로 수집합니다. 컨텍스트 격리 원칙: 외부 데이터를 가져오는 리서치 채널(사내 자료, 데이터)은 Agent 서브에이전트로 위임한다. 반환 계약은 _shared/preamble.md의 Subagent Result-Only Contract를 따른다 (반환 형식: STATUS: PASS/FAIL, 발견 {N}건, 저장: {경로}). 이유: 4개 채널의 raw 데이터가 모두 메인 컨텍스트에 들어오면 Phase 3 보고서 작성 시점에 256K 토큰 경계(측정 기준 모델의 수치 — 모델 변경 시 재검토)를 넘어 정확도가 하락한다.

개인 지식 베이스 조회 (직접 실행 — 다른 리서치 채널과 병렬):

• simon-brain-query의 검색 로직으로 Obsidian wiki vault(~/Obsidian/*-wiki/)에서 학습 주제 관련 기존 지식을 검색한다
• 검색 방법: 각 vault의 wiki/ 디렉토리에서 핵심 키워드로 Grep 검색 → 매칭되는 문서를 Read하여 관련 내용 추출
• 발견한 기존 지식은 다른 리서치 채널(개념, 코드, 사내 자료, 데이터)의 결과와 동등한 참고 자료로 활용한다 — 이전에 학습한 내용이 있으면 중복 리서치를 줄이고, 이전 분석과의 연결점을 보고서에 반영할 수 있다
• 기존 지식이 없으면 이 단계를 skip하고 다른 채널로 진행한다

개념 리서치 (직접 실행 — 출력이 짧으므로 격리 불필요):

• context7 문서 조회 — 관련 라이브러리/프레임워크 공식 문서
• 웹 검색 — 핵심 원리, 베스트 프랙티스, 알려진 함정

코드 리서치 (직접 실행 — Grep/Read 결과는 선택적 로딩 가능):

• 변동성 진단 — 학습 대상 코드의 git 이력 건강도를 먼저 파악:

  Reference Loading (선택적): ~/.claude/skills/_shared/codebase-health-prescan.md의 명령 1, 2 참조

  • churn 분석 (해당 모듈/디렉토리 범위): 자주 변경되는 파일은 설계 문제 또는 핵심 로직일 가능성
  • bug hotspot 분석: 버그가 집중된 파일은 트레이드오프의 한계 시나리오를 보여줌
  • 결과를 "이 코드가 왜 이렇게 복잡한지" 이해하는 맥락으로 활용
• 진입점 파악 — 이 로직이 어디서 시작되는가
• 데이터 흐름 추적 — 관련 데이터가 어떻게 변환되는가
• 의존성과 연관 코드 — 이 로직이 영향을 미치는 범위
• 테스트 코드 — 어떤 케이스를 검증하고 있는가
• Feature Applicability 추출 (조건부 — 학습 주제가 특정 기능/피처일 때):
  • 이 기능이 언제/어떤 조건에서 적용되는가 (entry condition)
  • 전제 조건, 예외 케이스
  • Phase 3 보고서의 "핵심 멘탈 모델"이나 "설계 트레이드오프"에 적용 조건 정보를 포함
  • 코드에서 확인되지 않으면 "[미확인] — 추가 조사 필요"로 명시
  • 사용자(또는 문의자)의 전제(예: "X면 Y가 기본 제공")는 데이터/코드로 검증하기 전까지 사실로 받아들이지 않는다