| name | memo |
| description | 사용자가 강의/세미나/학습 메모를 정리해달라고 할 때 사용. "메모 정리", "강의 내용 정리", "세미나 내용 정리", "학습 내용 정리", "이거 정리해줘" 등의 요청에 트리거. 텍스트 붙여넣기뿐 아니라 URL 입력도 지원. |
| argument-hint | ["메모 내용 또는 URL"] |
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash","WebFetch","WebSearch"] |
메모 정리 스킬
사용자가 강의, 세미나, 학습 메모를 공유하면 기존 카테고리 구조에 맞춰 지식 문서로 정리한다.
처리 순서
0단계: 입력 형태 판별
- 입력이 URL(http/https로 시작)인 경우:
WebFetch로 본문을 가져와 핵심 주제, 개념, 코드 예시를 요약 파악
- 추출이 부실하면
WebSearch로 보조 정보 확보
- YouTube, 로그인 필요 페이지처럼 본문 추출이 불가능한 경우 사용자에게 원본 텍스트를 요청
- 가져온 내용이 어떤 주제인지 한 문장으로 사용자에게 먼저 확인받은 뒤 1단계로 진행
- 입력이 텍스트인 경우: 바로 1단계로 진행
1단계: 메모 분석
- 공유된 메모(텍스트 또는 URL에서 가져온 본문)를 주제별로 분류
- 바탕화면(
~/Desktop/)에 관련 이미지가 있을 수 있으므로  문자가 있으면 이미지 파일 확인
- 기존 카테고리 인덱스 파일들을 확인하여 어떤 카테고리에 해당하는지 판단
2단계: 기존 카테고리 확인
프로젝트의 카테고리 구조:
tech/computer-science/ # CS & 프로그래밍
tech/web/ # 웹 & 네트워크
tech/os-runtime/ # OS & 런타임 (Node.js, NestJS, Spring)
tech/database/ # 데이터 & 저장소
tech/messaging-data-pipeline/ # 메시징 & 파이프라인
tech/architecture-design/ # 아키텍처 & 설계
tech/performance-scalability/ # 성능 & 확장성
tech/infrastructure-cloud/ # 인프라 & 클라우드
tech/ci-cd/ # CI/CD & 배포
tech/observability/ # 관측가능성
tech/reliability/ # 안정성 엔지니어링
tech/testing-quality/ # 테스트 & 품질
tech/security/ # 보안
tech/fin-ops/ # 비용 & 운영
tech/senior/ # 시니어 역량
fit/ # 커리어 & 면접 Fit
각 카테고리의 인덱스 파일(*({영문명}).md)을 Read하여 현재 체크리스트와 기존 문서 목록을 파악한다.
3단계: 지식 문서 생성/업데이트
- 기존 파일이 있으면 내용 보강 (Edit 사용)
- 없으면 새 파일 생성 (Write 사용)
- 여러 카테고리에 걸치는 내용은 각 카테고리에 분산 배치
- 프론트매터 형식:
---
tags: [관련태그]
status: done
category: "카테고리명"
aliases: ["영문명", "한글명"]
---
본문 작성 원칙 (중요)
블로그/원문 글은 "트리거"일 뿐, 정리 대상이 아니다. 본문은 그 주제(개념, 패턴, 용어, 기술) 자체의 정리된 레퍼런스 노트로 쓴다. 나중에 같은 주제를 검색해서 찾았을 때, 출처 글을 다시 읽지 않고도 본문만으로 완결되어 보여야 한다.
- 금지: "원문에 따르면…", "저자는 이렇게 주장한다…", "원문의 핵심 주장", "이 글은 …를 다룬다", "필자가 강조한 것" 같은 메타 표현
- 금지: "원문 요약 → 내 입장 → 면접 답변 탄약" 같은 블로그 종속 구조 (단,
fit/ 카테고리의 면접 탄약 문서는 예외)
- 권장: 주제(예: "Hexagonal Architecture", "iowait", "모나드 법칙") 자체를 정의, 구조, 예시, 트레이드오프, 면접 체크포인트 순으로 서술
- 출처: 본문 첫 줄 인트로에 박지 말고 문서 하단에
## 출처 섹션을 만들어 한 줄로 (- [제목 — 저자/매체](URL))
- 저자 일화, 회사명, 연도 같은 일회성 디테일은 본문 핵심으로 끌어오지 않는다 (필요하면 "사례" 섹션에 짧게)
- 동일한 주제를 다른 출처로 다시 정리할 때, 출처 섹션에 줄만 추가하면 되도록 본문이 출처 중립적이어야 한다
좋은 예 / 나쁜 예
나쁜 예 (블로그 종속):
"appkr이 부릉 7년 경험을 정리한 이 글은 DDD와 Hexagonal의 시너지를 설명한다. 저자는 다음과 같이 주장한다…"
좋은 예 (주제 중심):
"DDD와 Hexagonal은 서로 다른 문제를 해결하므로 함께 쓰면 보완된다. DDD는 도메인 복잡성을, Hexagonal은 외부 기술과의 경계를 다룬다."
4단계: 인덱스 연결
- 카테고리 인덱스의 체크리스트 업데이트:
[ ] -> [x]
- 새 항목이면 체크리스트에 추가
- 지식 문서의 하단에
## 관련 문서 섹션으로 상호 링크
- Obsidian 위키링크 문법 사용:
[[파일명|표시명]]
5단계: README.md 업데이트
- 카테고리 인덱스의 진행률 숫자 업데이트 (예:
(2/10) -> (3/10))
세미나 vs 강의 구분
세미나 (원본 보존)
사용자가 "세미나"라고 표현한 경우:
- 지식 문서를 각 카테고리에 생성/보강 (위 3~5단계)
- 추가로
fit/ 폴더에 세미나 원본 파일 생성 (예: fit/TS-Backend-Meetup-3.md)
- 프론트매터:
status: seminar
- 세션별로 구조화하여 원본 맥락 보존
README.md의 세미나 섹션에 원본 파일 링크 추가
- 카테고리 인덱스의 현장사례 섹션에서 세미나 원본 파일의 해당 섹션으로 링크
강의/학습 (원본 없음)
사용자가 "강의", "학습", "공부" 등으로 표현한 경우:
- 지식 문서만 생성/보강 (원본 파일 만들지 않음)
주의사항
- 기존 파일과 중복되는 내용은 기존 파일에 보강한다
- 코드블록(
```) 안에 내용을 넣지 말고 일반 텍스트로 작성한다
- 출처(블로그, 아티클)는 본문에 인용, 요약하지 말고 하단
## 출처 섹션에 한 줄로. 본문은 출처 중립적인 주제 정리여야 한다 (위 "본문 작성 원칙" 참조)