Imported from hansunghee7/hansunghee7.github.io (
.claude/skills/ink-desk/SKILL.md). Install upstream withnpx skills add hansunghee7/hansunghee7.github.io --skill ink-desk. Copyright stays with the author.
잉크 데스크: 글 작업 시작 절차
글과 관련된 일을 시작하거나 이어갈 때 세션당 한 번, 가장 먼저 연다. 기억이나 가이드 조립으로 진행하지 않는다.
1. 발행 현황판을 만든다
assets/data/publish_plan.json에서 오늘부터 2주 안의 슬롯을 본다. 요일 체계는docs/SNS_라이팅_가이드.md5절(주 3회: 화, 목, 토 모두 홈페이지 전용 글. SNS는 홈페이지 글에서 파생해 사장님이 게시. 토요일은 사장님 경험 재료가 있으면 그 재료로).- 작업 카드(비공개
simplifier-cxo-db/ink/카드/)에서 글마다현재단계와다음행동을 본다. 그 저장소가 안 붙어 있으면 멈추지 말고publish_plan.json과 진행상황.md의 마야 인수인계로 현황을 만들고, 카드를 못 봤다고 밝힌다. - 계획표에 빠진 슬롯(요일표에는 있는데 항목이 없는 날)이 있으면 그것부터 알린다.
2. 주말은 준비일, 주중은 확인만
- 토요일과 일요일에는 다음 1~2주치 슬롯을 예약등록까지 끝내는 것이 목표다. 순서는 4절대로 글 한 편씩 끝내며 채운다. 여러 글의 컨펌을 묶어서 묻지 않는다.
- 주중에는 발행 확인과 실적 기록만 남아야 정상이다. 주말에 못 끝낸 슬롯이 있으면 그 세션의 첫 보고로 알린다.
- 예약 발행이 실측 검증되기 전까지는 발행일 당일 세션이 그 글의 발행을 가장 먼저 처리한다(
docs/예약_발행.md).
3. 사장님이 "오늘 챙길 것"을 물으면
현황판, 진행상황.md 인수인계의 사장님 몫, docs/마야_백로그.md 1절(사장님 결정 대기)을 열어 답한다.
- 기한이 가까운 순으로 세 개 이내.
- 항목마다 기한과 사장님이 할 동작 하나(주제 고르기, 경험 네 칸, 전문 컨펌, 게시).
- 답의 첫머리에 2주 안 슬롯 현황을 한 줄씩 보인다(날짜, 용도, 제목 또는 "주제 없음", 상태). 백로그와 계획표가 어긋나면 계획표를 고치고 어긋났다고 밝힌다.
- 마야가 할 일은 섞지 않는다. 사장님 몫이 없으면 "없음"이라고 답한다.
- 응답의 끝은 가장 급한 사장님 몫 하나를 묻는 질문이다.
- 백로그 우선순위를 물으면
docs/마야_백로그.md2절을 그대로 보이고, 바뀐 것은 그 세션 안에 갱신한다.
4. 글 하나를 잡는다
- 발행일이 가까운 글부터. 같은 날이면 단계가 뒤에 있는 글부터.
- 오늘이 발행일인 글이 있으면 그 글이 끝날 때까지 다른 글이나 다른 일을 받지 않는다.
- 한 번에 글 하나. 막혀서 미루려면 "이 글을 후순위로 돌린다"고 말하고 동의를 받는다.
- 한 글이 끝난 뒤에 다음 글 작업을 시작한다(2026-09-20 사장님 지시: 끝나기 전에 다음 글 질문이 들어오면 혼란스럽다). 끝은 예약 등록까지다(카드
발행칸). 그 전에는 다음 글의 주제 후보, 경험 청취, 리서치 발주를 묻지도 시작하지도 않는다.- 지금 글이 결과 대기처럼 사장님 몫이 없는 상태면 무엇을 기다리는 중인지(누가, 무엇을) 한 줄로 알리고 질문 없이 끝낸다.
- 사장님이 먼저 다른 글을 꺼내시면 지금 글이 끝난 뒤에 하겠다고 알리고, 그 글을 앞세우려면 위 규칙대로 동의를 받는다.
- 사장님이 "오늘 챙길 것"을 물으신 경우만 3절대로 여러 글을 한꺼번에 답한다.
5. 카드가 없으면 개설한다
- 이 폴더의
card-template.md를 복사해 만든다. - 슬롯(날짜)과 용도(홈페이지용 또는 SNS용)가 사장님 확정이 아니면 카드를 만들기 전에 그것부터 묻는다.
- 위임을 받았으면 말로 계획만 읊지 말고 그 자리에서 용도별 스킬 파일을 열어 1단계부터 실제로 진행한다.
- 사장님이 "알아서 정하라"고 위임하신 항목은 그 메시지를 카드
위임칸에 인용하고 진행한다. 위임은 그 글에만 해당하고, 절차(리서치, 다이얼로그, 채점)는 줄이지 않는다.
6. 용도에 따라 분기한다
- 홈페이지용:
ink-homepage스킬(.claude/skills/ink-homepage/SKILL.md). - SNS용: 1) 주제 후보를 골라 컨펌받는다(
ink-homepage1단계와 같은 방식, 요일 트랙은docs/SNS_라이팅_가이드.md5절). 2) 사장님 경험을 청취한다(네 칸: 장면, 원인, 처방, 독자에게 남길 말. 모르는 칸은 비운다). 3) 이후는ink-homepage2단계부터 그대로 따른다. 본문 점수표만docs/WRITING_GUIDE.md5-4절을 쓴다. - 어느 쪽이든 모든 글은 홈페이지에 등록하고 대표 이미지는 필수다.
7. 글이 아닌 일감은 넘긴다
기술, 파이프라인, UI 구현 요청은 직접 하지 않는다. 요구사항과 수용 기준을 적어 docs/진행상황.md에 📥로 노트(도구, UI) 또는 탐(인프라)에게 넘기고, 넘겼다고 사장님께 보고한다.
행동 규율
- 응답은 질문 하나로 끝낸다. 사장님 몫이 남아 있으면 가장 급한 것 하나를 맨 끝에서 묻는다. 둘 이상 묻지 않는다. 요청받은 범위를 넓히지 않는다.
- "확정"은 사장님이 최신 전문에 명시적으로 승인한 메시지를 카드에 인용할 수 있을 때만 쓴다. 그 외는 "확인 대기"다.
- 글은 제목으로 부른다(번호 금지).
- 채팅 응답에도 긴 줄표(—, –)를 쓰지 않는다.
- 커밋과 PR은 마야 전용 worktree에서 한다. 확정 전 초안은 공개 저장소에 커밋하지 않는다(비공개
ink/초안/에 둔다). - 사장님이 할 차례가 되면(컨펌 ①②③, 경험 청취) 그 화면을 채팅에 올린 직후 텔레그램 알림용 우편을 한 통 보낸다(2026-09-20 사장님 요청). 채팅에 이미 사장님이 계셔도 보낸다.
- 명령:
python mailbox/mailbox.py send 사장님 "<글 제목> 컨펌 ②" --from 마야 --ask "채팅에서 본문을 보시고 승인 또는 수정을 알려 주세요"(solar-bible 저장소 안에서 실행). 헤르메스 배달원이 텔레그램 한 줄로 전한다. 알림은 포인터라 본문과 긴 내용은 담지 않는다. - 보낸 직후
bash scripts/hx_lite.sh kick을 실행한다. 배달원 크론은 약 11분 간격이라 기다리면 늦게 온다. kick하면 즉시 배달된다(2026-09-20 10:33:43 발송, 10:33:50 kick, 사장님 폰에 10:33 도착, "이번엔 빨리 왔어요"). - 알림에 실리는 것(2026-09-20 사장님 캡처 두 번으로 실측): 제목, 본문 첫 줄(120자에서
…로 잘림),👉요청 줄(약 1,040자 전문 도착). 본문 둘째 줄 이하는 안 간다. 링크는 눌러서 열린다. - 그래서 내용은
--ask한 줄에 넣는다. 맨 앞에 링크를 둔다. 이미지 컨펌(③)이면 이미지 주소를 맨 앞에 두면 미리보기 그림이 채팅에 뜬다. 그 뒤에 할 일과 핵심 내용을 적는다. 4,096자 상한 근처와 긴 본문 전문은 시험하지 않았으므로 본문 전문은 클로드 모바일에서 본다. - 사장님 앞 우편은
--ask가 있는 것만 폰으로 간다(전달_사고_대장.md#2). 한 차례에 한 통, 시험 발송과 요약 발송은 하지 않는다(탐 요청 2026-09-19, 하루 20건 상한). - 발송 뒤 사장님이 받으셨는지는 사장님 말씀으로만 확인한다. 안 왔다는 말씀이 있으면 탐에게 우편으로 알린다.
- 명령:
8. 새 글(신규 발행)을 쓰기 전에 읽을 문서 (CLAUDE.md에서 옮겨 온 원문, 2026-09-20 구조 최적화, 내용 변경 없음)
새 글(신규 발행)을 쓰기 전에 docs/퍼스널_브랜딩_가이드.md(캐릭터·화법·1인칭
톤)와 docs/WRITING_GUIDE.md(장문 문체 세부)를 먼저 여세요. 주제를 고르는
단계라면 docs/브랜딩_가이드.md 3절(타깃)도 같이 확인하세요 — 트렌드성 주제가
화제라고 해서 이 사이트의 1차 타깃(강연·코칭 매출)에 맞는 건 아닙니다. 대표
이미지가 필요하면 docs/질문하기_파이프라인.md 5-1·5-2절(Unsplash 선택 절차,
채팅에서 쓸 땐 1~2개 추천 후 사장님이 고름)을 따르세요.
⚠️ UX_GUIDE.md처럼 "이 문서를 먼저 봐야 한다"는 게 여기도 똑같이 적용됩니다. 일반 지식으로 먼저 쓰고 지적받은 뒤에야 이 문서들을 찾아보면 늦습니다 (2026-09-17 마야 세션에서 트렌드 파일럿 글 하나 쓰는 동안 주제 선정·문체·이미지 선택 세 단계 전부 이 순서로 지적받고서야 정정한 실제 사례 — cxo-db 인박스에 근본원인 기록).
사장님이 바로 읽는 문구에도 이 화법을 씁니다 (2026-09-19 사장님 제안): 알림, 아티팩트 첫 화면 카피, 서비스 안내 문구는
docs/퍼스널_브랜딩_가이드.md의 화법을 따릅니다. 헤르메스 보고서, 실측 결과, 사고 기록, 지시서 같은 검증 문서에는 적용하지
않습니다(DONE=VERIFIED 증거가 우선). 톤을 맞추더라도 숫자, 경로, 상태 표시는 바꾸지 않고, 에이전트가 보낸 문구에는
발신자 표시(예: 📬 탐→헤르메스)를 남깁니다. 고객이 생기면 에이전트가 쓴 문구가 사장님 본인 글처럼 읽히지 않게 합니다.