| disable-model-invocation | true |
| name | logseq-write |
| description | [DEPRECATED — use obsidian-write] Writes Logseq pages (legacy `key:: value` properties + `___` namespace). 본 vault는 2026-04-29 Obsidian으로 마이그레이션됨. 별도 logseq vault에 작업 시에만 사용. |
Deprecated: 본 글로벌 환경은 obsidian-write를 표준으로 사용한다. 이 스킬은 다른 logseq vault 작업 호환을 위해 보존되며, 일반 작업에서는 obsidian-write + documentation 참조.
Atomic Notes 원칙
- 하나의 개념 = 하나의 페이지. 프로젝트에 종속되지 않는 범용 개념으로 작성
- 프로젝트 특이사항은 같은 페이지에
#pj-{name} 태그와 함께 한 줄로 기술
- 구현 디테일(코드 위치, 엔티티, API)은 개념 페이지가 아닌 프로젝트 도메인 페이지에 작성
- 본문에 등장하는 도메인 용어는
[[링크]]로 연결 — 페이지가 없으면 생성 검토
- 편집 중 개념 페이지에 구현 디테일이 섞여 있으면 분리 제안
기존 패턴 (건드리지 않는다)
- 개념 페이지:
alias:: + description:: 최상단, 내용은 outliner
- 본문에서 개념화된 용어는
[[링크]]로 그래프 연결 — #태그는 저널 TODO 행에서만 사용
- alias 값에 띄어쓰기 포함 시
[[]]로 감싼다 (예: alias:: [[Single Page Application]])
- block reference:
((block-uuid)) — 원본 블록 인라인 참조
- block embed:
{{embed ((block-uuid))}} — 원본 + 하위 자식 펼침
- 블록에
id:: 프로퍼티(UUID v4) 부여하면 참조 대상
- 중복 내용 발견 시 block ref/embed 전환 제안
- 저널:
- TODO/DONE {설명} #pj-{프로젝트}, 회의 메모
- 프로젝트 허브:
pj-{name}.md에 {{query}}로 TODO 집계
#thought 태그: 사람 전용. AI는 이 태그를 사용하지 않으며, #thought가 붙은 블록을 편집하지 않는다
연결 원칙
- 모든 문서는 최소 하나의 다른 문서와 연결되어야 한다
- namespace 페이지 작성 시
ir search로 관련 기존 페이지를 찾아 [[링크]]로 연결
- namespace 페이지 생성 시 반드시 당일 저널에 링크 남기기
- 관련 저널 TODO가 있으면 DONE으로 변경하고 하위에
-> [[{type}/{제목}]] 링크 추가
- 관련 TODO가 없으면 새 항목:
- DONE {설명} #pj-{project} + -> [[링크]]
- namespace 페이지 간에도 관련 있으면 서로 링크
project::, date:: 프로퍼티 자체가 프로젝트 허브와 저널로의 연결
- 프로퍼티 값은
[[link]] 형태로 — plain text는 그래프 엣지를 만들지 않는다
TODO 관리
라이프사이클
TODO → DOING → DONE
- 우선순위:
[#A] / [#B] / [#C] (예: TODO [#A] 긴급 수정)
- 스케줄링:
SCHEDULED: <YYYY-MM-DD> / DEADLINE: <YYYY-MM-DD>
- DOING 전환 — 저널 하단 NOW 쿼리에 자동 노출
- 취소:
DONE (취소: {사유})
{{query}} 문법
Simple query (Logseq 내장). Datalog 기반 advanced query와 별개.
{{query (and (task TODO DOING) [[pj-{name}]])}}
논리 연산자: and, or, not — 중첩 가능
필터:
(task TODO DOING DONE) — 태스크 상태 (공백 구분, 쉼표 아님)
(priority A B) — 우선순위
(page <이름>) — 특정 페이지 내 블록
(namespace <이름>) — 네임스페이스 하위 페이지
(property <키> <값>) — 프로퍼티 필터
(between <시작> <끝>) — 날짜 범위 (저널 기준)
[[페이지]] — 백링크/태그 필터 (쿼리 내에서는 [[]]만 사용)
자주 쓰는 패턴:
;; 프로젝트 TODO 집계
{{query (and (task TODO DOING) [[pj-{name}]])}}
;; 우선순위별
{{query (and (task TODO DOING) (priority A) [[pj-{name}]])}}
;; 네임스페이스 하위 전체
{{query (namespace sphere)}}
;; 프로퍼티 필터
{{query (and (property status draft) [[pj-{name}]])}}
;; 최근 7일 저널
{{query (between -7d today)}}
주의: 텍스트 검색은 대소문자 구분
기록 규칙
언제, 어디에
| 상황 | 위치 |
|---|
| TODO, 간단한 메모, 회의 메모 | 당일 저널 |
| 트러블슈팅 완료 (조사+결론 있음) | pages/pj-{name}___troubleshoot___{제목}.md |
| 중요 결정 확정 | pages/pj-{name}___decision___{제목}.md |
| QA 체크리스트/결과 | pages/pj-{name}___qa___{제목}.md |
| 기능 스펙/요구사항 정리 | pages/pj-{name}___spec___{제목}.md |
| 배포 실패/인프라 이슈 | pages/pj-{name}___incident___{제목}.md |
| 장기 추적 이슈 (외부 의존, 커뮤니케이션 축적) | pages/pj-{name}___issue___{제목}.md |
| 새 도메인 개념 | pages/{개념명}.md (기존 방식) |
| 기타 필요 시 | 새 namespace 자유 생성 |
저널 → 페이지 승격
저널에서 시작한 이슈가 깊어지면 별도 페이지로 승격하고 저널에서 링크:
- DONE {설명} #pj-{project}
- -> [[{type}/{제목}]]
승격 시 기존 TODO를 DONE으로 변경한다.
회의/슬랙 대화 → 문서화
회의록이나 슬랙 대화가 붙여넣어지거나 Slack 채널을 조회한 결과를 기록할 때:
저널에 남기는 것 (휘발적, 1줄 요약 + 링크):
- 단순 행정 (도메인 후보, 일정 조율, 확인 요청)
- 이미 namespace 페이지가 있는 주제의 상태 업데이트
namespace 페이지로 승격하는 것 (구조화된 지식):
- 아키텍처/설계 흐름이 정리된 내용 →
spec/
- 결정사항이 포함된 내용 →
decision/
- 새로운 기술적 제안/비교 →
reference/ 또는 spec/
판단 기준: 이 내용이 1주일 뒤에도 다시 참조될 가능성이 있는가?
- Yes → namespace 페이지로 승격. 저널에는 DONE +
-> [[링크]]만 남긴다
- No → 저널에 1줄 요약 + Slack 딥링크
namespace 페이지 작성 규격
namespace 소속 판단
| 기준 | namespace | 예시 |
|---|
| 특정 프로젝트에 종속 | pj-{name}/{type}/{제목} | pj-sphere/decision/배포 전략 |
| 프로젝트 무관 범용 | {type}/{제목} | decision/Git worktree 운용 원칙 |
| 순수 개념 | 루트 {개념명} | 스테이블코인, 온오프램프 |
판단 기준: 이 문서가 특정 프로젝트 없이 의미가 있는가?
- No →
pj-{name}/{type}/{제목} (대부분의 decision, troubleshoot, debrief, qa, spec, incident)
- Yes →
{type}/{제목} (루트)
문서 간 의존 방향
안정도: 개념(L0) > 결정/스펙(L1) > 이벤트(L2) > 저널/세션(L3)
- 의존은 항상 안정한 쪽을 향한다 — L3→L2→L1→L0
- 저널/세션이 decision이나 concept을
[[링크]]로 참조 → OK
- concept이 session을 참조 → NG
- 같은 계층 간 참조 → OK (decision ↔ decision)
깊이 제한
- 최대 2단:
pj-{name}/{type}/{제목} (3 segment)
pj-{name}/{type}/{sub-type}/{제목} 같은 4단 이상 금지
- 프로젝트 허브 페이지
pj-{name}.md는 {{query (namespace pj-{name})}} 로 하위 집계
파일 네이밍
- 프로젝트 종속:
pages/pj-{name}___{type}___{제목}.md → Logseq에서 pj-{name}/{type}/{제목}로 표시
- 프로젝트 무관:
pages/{type}___{제목}.md → Logseq에서 {type}/{제목}로 표시
- 제목: 한국어 설명적 제목, 간결하게
- 모든 콘텐츠는 outliner 형식 (
- prefix) 으로 작성
- 체크리스트는
TODO/DONE 키워드 사용. [ ]/[x] 마크다운 체크박스 사용 금지 (Logseq TODO 시스템과 통합되지 않음)
필수 프로퍼티
페이지 최상단에 Logseq 네이티브 문법:
project:: [[pj-{name}]]
date:: [[YYYY-MM-DD]]
status:: {상태}
type은 namespace로 이미 구분되므로 별도 프로퍼티 불필요
date가 저널 링크 역할을 겸함 — 본문에서 저널 중복 참조하지 않는다
선택 프로퍼티 (freshness)
last-verified:: [[YYYY-MM-DD]]
next-check:: [[YYYY-MM-DD]]
last-verified: 이 문서의 내용이 마지막으로 정확하다고 확인된 날짜
next-check: 다음 확인이 필요한 날짜
- 적용 대상: issue, troubleshoot(investigating), incident(open) 등 status가 open/in-progress/waiting/blocked인 모든 namespace 페이지
- resolved/closed/done이면 불필요
- issue 페이지에서는
next-check 기본 7일 후 설정
카테고리별 템플릿
헤딩 규칙: - # 섹션명 은 최상위 구분에만 사용. 하위 그룹핑은 평문 라벨 + 들여쓰기. ## 이상의 중첩 헤딩, 볼드 라벨 등 불필요한 마크업은 쓰지 않는다.
troubleshoot
status: open / investigating / resolved / wontfix
- # 상황
- # 조사
- # 근본 원인
- # 결정
- # 관련 자료
decision
status: proposed / accepted / rejected / superseded
- # 맥락
- # 선택지
- # 결정
- # 근거
qa
status: draft / in-progress / done
- # 대상
- # 체크리스트
- 그룹명
- TODO 항목
- # 결과
spec
status: draft / agreed / implemented / deprecated
- # 배경
- # 요구사항
- # 범위
incident
status: open / resolved / recurring
- # 상황
- # 타임라인
- # 원인
- # 대응
- # 재발 방지
issue
status: open / in-progress / waiting / blocked / resolved / closed
선택 프로퍼티: owner::, stakeholders::, last-verified::, next-check::
- # 상황
- # 커뮤니케이션 로그
- # 진행 상황
- # 관련 자료
커뮤니케이션 로그 형식:
- # 커뮤니케이션 로그
- YYYY-MM-DD {채널: slack/email/meeting/call/github} {상대방}
- 질문/요청 내용
- 응답/결과
- → 상태 변화: {이전} → {이후}
troubleshoot과의 차이: troubleshoot은 한 번의 조사→해결 사이클. issue는 장기 추적 — 복수 사이클, 커뮤니케이션 축적, 상태 변화 이력.
새 카테고리
템플릿 없이 namespace만 만들어도 됨. 공통 프로퍼티 + 자유 형식.
작업 산출물 저장
- raw 데이터 (JSON, 스크린샷, 로그 등) → Logseq
assets/ 디렉토리에 저장
- namespace 페이지에서
 또는 경로 텍스트로 참조
작성 후 필수 작업
페이지 작성이 완료되면 아래 3단계를 순서대로 수행한다.
예외: 자동화 hook(session sync 등)에서 호출되는 경우 Step 1, 2는 생략하고 Step 3만 실행한다. 사용자가 직접 /logseq-write를 호출하거나 /debrief 등 사용자 initiated skill에서 호출할 때만 Step 1, 2를 수행한다.
Step 1: 미생성 키워드 제안
작성한 페이지에서 [[링크]]로 감싼 키워드를 모두 추출하고, 실제 Logseq 페이지가 없는 것을 식별한다.
추출 대상에서 제외:
- 프로퍼티 값:
project::, date:: 등의 값으로 쓰인 링크
- 저널 날짜:
[[YYYY-MM-DD]] 패턴
- 프로젝트 태그:
[[pj-*]] 패턴
- namespace 자기 참조: 작성 중인 페이지 자신
페이지 존재 확인:
test -f ~/Documents/logseq/pages/{키워드}.md
test -f ~/Documents/logseq/pages/{type}___{제목}.md
미생성 키워드가 있으면 사용자에게 목록을 보여주고 확인을 요청한다:
다음 키워드가 아직 Logseq 페이지로 존재하지 않습니다:
- [[키워드A]] — 본문에서 {사용 맥락 한 줄}
- [[키워드B]] — 본문에서 {사용 맥락 한 줄}
생성할 키워드를 선택해주세요 (전체/일부/스킵).
사용자가 선택하면 개념 페이지를 Atomic Notes 원칙에 따라 생성한다:
alias:: {영문 또는 대체 표현이 있으면}
description:: {한 줄 설명 — 작성한 페이지의 맥락에서 추론}
- {원래 페이지에서의 사용 맥락을 기반으로 1-2줄 기본 내용}
- 관련: [[원래 작성한 페이지]]
Step 2: 관련 개념 능동 탐색
작성된 페이지의 핵심 키워드 3-5개를 추출하여 ir search로 관련 기존 페이지를 탐색한다.
키워드 추출 기준:
- 페이지 제목의 핵심어
- 본문에서 반복 등장하는 도메인 용어
- 이미
[[링크]]로 연결한 것은 제외 (이미 연결됨)
탐색 실행:
ir search "{키워드}" -n 5 --files
결과 필터링:
- 이미 본문에서
[[링크]]로 연결한 페이지는 제외
- 자기 자신, 저널 페이지(
journals/) 제외
관련 페이지가 있으면 사용자에게 연결을 제안한다:
작성한 내용과 관련될 수 있는 기존 페이지:
- [[페이지A]] — {페이지 설명 또는 첫 줄}
- [[페이지B]] — {페이지 설명 또는 첫 줄}
본문에 연결을 추가할까요?
사용자가 선택하면 작성한 페이지의 적절한 위치에 [[링크]]를 추가한다.
Step 3: 인덱스 갱신
ir update
ir embed
Step 1에서 새 페이지가 생성되었을 수 있으므로, 반드시 모든 작업 완료 후 마지막에 실행한다.
Step 4: 학습 질문 생성
작성한 내용에 도메인 개념이 포함되어 있으면 사용자에게 2-3개의 학습 질문을 제시한다. soul.md의 능동 학습 원칙 실행 단계.
트리거 조건 (하나 이상 해당):
- 새 도메인 개념이 등장 (미생성 키워드, 또는 기존 개념의 새로운 맥락)
- spec, decision 등 판단이 수반되는 내용
- 외부 산출물(Slack, 문서, 기사)을 정리한 경우
스킵 조건:
- 단순 TODO 상태 변경, 저널 행정 기록
- 자동화 hook에서 호출된 경우 (session sync 등)
- 사용자가 "바로 해"라고 지시한 경우
질문 설계 원칙:
- 개념 확인: "X가 이 맥락에서 어떤 역할을 하는지 감이 오세요?"
- 연결: "X와 기존에 알던 Y의 관계가 보이시나요?"
- 판단: "이 결정/제안의 trade-off가 뭘까요?"
- 실무 적용: "이게 우리 프로젝트의 Z에 어떻게 영향을 줄까요?"
형식: 질문 2-3개를 번호로 제시. 사용자가 답하면 보완/확장하고, 개념 페이지에 사용자의 이해를 반영. "스킵"하면 넘어간다.