# Bohoja Note Seven Step Writing

> 보호자 노트의 요양병원·요양원·호스피스·장기요양·비용·보호자 결정 글을 공식 원천과 원천 우위에 근거해 기획, 초안, 원천 대조, 가치·밀도 개선, 편집, 이중검수, Astro 정본으로 완성한다. 보호자 노트 글을 새로 쓰거나 큰 폭으로 다시 쓸 때 사용한다.

- Skill: `formars0309-cloud/bohoja-note-seven-step-writing` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds@latest add formars0309-cloud/bohoja-note-seven-step-writing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/formars0309-cloud/bohoja-note-seven-step-writing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: formars0309-cloud (https://skillmd.com/u/formars0309-cloud)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/formars0309-cloud/bohoja-note-seven-step-writing

---


## 조율 대기 — 2026-09-10 토큰 반복 방지

작업자를 실행하기 전에 `~/.claude/skills/task-wait/SKILL.md`를 읽고 작업 ID·결과 경로·완료 신호·마감을 인계서에 명시한다. 기존 실행기/유효한 Orca Dispatch의 완료 대기를 사용하며 `sleep → terminal read`와 전체 원고·상태 재조회로 진행을 감시하지 않는다. 대기 상한은 검수 45분·집필 90분이고, 기존 실행기의 더 짧은 상한을 우선한다. 타임아웃이면 한 번 진단하고 같은 실행의 재개 지점을 남기며 자동으로 대기 창을 연장하지 않는다. 살아 있는 작업자의 소유권과 기존 검수 기준은 유지한다.

# 보호자 노트 글쓰기 7단계

## 목표

보호자가 공식 문서를 직접 읽는 것보다 더 빨리 정확한 결정을 내릴 수 있는 글을 만든다. 완성된 문장보다 `원천 확보 → 주장 추적 → 가치 감사 → 의료인 승인`의 기록이 먼저다.

## 시작 전에

1. 저장소의 `AGENTS.md`가 있으면 읽고, `HANDOFF.md`, `docs/article-charter.md`, `docs/content-automation.md`, `src/content.config.ts`를 읽는다.
2. 공개된 형제 원고와 백로그를 확인한다. 사용자가 주제를 지정하지 않았다면 `npm run content:next`로 다음 주제를 확인한다.
3. 조사 전에 [근거·경계 규칙](references/evidence-and-boundary-rules.md)을 읽는다.
4. `node <이 스킬 경로>/scripts/init-workflow.mjs <slug> "<제목>"`로 단계 파일을 만든다. 기존 파일은 덮어쓰지 않는다.
5. 각 파일의 필수 내용은 [단계별 산출물 계약](references/stage-contracts.md)을 따른다. 3단계와 6단계에 들어갈 때는 [감사·승인 규칙](references/review-and-approval-rules.md)을 읽는다.

## 2026-09-07 사용자 지정 필수 절차

1단계에서 `blueocean` 스킬을 반드시 읽고 실행해 후보 키워드의 수요·공급·상업성·추세를 실측한다. 사용자 지정 주제도 실측하며, 백로그 순위나 과거 등급만으로 대체하지 않는다. 실행일·명령·키워드·결과 JSON 경로·주요 수치·채택/제외 이유를 1단계에 남긴다. 조회 실패나 미측정 축은 명시하고, 필수 실측을 완료하지 못하면 주제 확정과 2단계 진행을 보류한다. 네이버 지표는 구글 검색 성과 보장이 아닌 후보 간 상대 비교로 해석하며, 공식 원천 확보와 원천 우위 판단은 별도로 수행한다.

3단계 초안 감사와 6단계 최종 내용 검수는 각각 반드시 새 Orca 터미널에서 이전 대화를 받지 않는 새 세션으로 실행한다. 기존 터미널·세션 재사용, resume/continue, 작성 대화의 요약·자기평가·통과 예상 전달은 금지한다. 같은 대화에서 분기한 서브에이전트는 새 터미널 검수를 대체하지 못한다. 검수자는 원고를 수정하지 않고 지적과 판정만 반환하며, 작성자가 공식 원천으로 재확인해 수정한다. 수정본 재검수도 또 다른 새 터미널·새 세션에서 수행한다.

각 검수 기록에 실제 터미널 ID, 세션 ID(도구가 발급하지 않으면 비저장 프로세스 실행 ID/PID), 모델·CLI 버전, 시작·종료 시각, 입력 파일과 SHA-256, 전달 프롬프트·원출력 경로, 종료 코드와 판정을 남긴다. 입력을 고정한 뒤 원고를 수정하지 않으며, 결과 회수 시 입력 SHA를 다시 대조한다. 실행 실패·증거 누락·입력 변경은 보류이며 작성자의 자체 검수로 통과 처리하지 않는다.

이번에 작성 중인 원고부터 적용한다. 종전 자체 감사·서브에이전트 기록은 이력으로 보존하되 새 터미널 검수 완료의 증거로 재사용하지 않는다.

## 작성자에 따른 교차 검수 — 2026-09-07 사용자 지정

사용자가 글쓰기를 지시한 현재 에이전트가 메인 작성자다. Claude Code와 Codex 모두 동등하게 시작할 수 있으며, 다른 쪽 세션의 존재 여부를 조건으로 삼거나 별도 인계 승인을 요구하지 않는다. 1단계에 실제 `메인 작성자`, `작성 참여 에이전트`, `검수 에이전트`와 역할별 터미널/세션을 기록한다. 초기화 도구가 특정 모델명을 미리 채웠다면 감사 전에 실제 역할로 교정한다. 양식의 기본값은 실행 증거가 아니다.

| 메인 작성자 | 3단계 초안 감사 | 6단계 최종 내용 검수 | 별도 최종 검토가 있는 경우(내차공략 7단계) |
|---|---|---|---|
| Codex | 새 Claude Code 세션 | 또 다른 새 Claude Code 세션 | 또 다른 새 Claude Code 세션 |
| Claude Code | 새 Codex 세션 | 또 다른 새 Codex 세션 | 또 다른 새 Codex 세션 |

‘다른 에이전트’는 같은 모델의 다른 세션만을 뜻하지 않는다. 해당 원고의 기획·초안·개선·편집에 참여하지 않은 반대쪽 에이전트 제품(Codex ↔ Claude Code)을 사용한다. 작성은 한쪽이 맡고 검수자는 원고를 수정하지 않는다. 검수 의견을 받은 작성자가 원천을 대조해 수정하는 것은 허용한다. 양쪽 모두 작성에 참여한 경우 그 사실을 보존하고 독립 검수자를 확보할 때까지 보류한다. 작성자를 바꿔 기록하거나 참여 이력을 지우지 않는다.

모든 감사·검수·재검토는 매번 새 Orca 터미널의 새 세션에서 수행한다. 기존 세션 재사용, resume/continue, 대화 이력·요약·자기평가·통과 예상·이전 감사 판정 전달은 금지한다. 보호자 노트 6단계의 사실 감사와 가치·밀도 감사도 반대쪽 에이전트를 사용하되 각각 별도 새 터미널·새 세션을 연다. 이전 검수만 수행했고 작성하지 않은 같은 제품은 다음 검수에도 사용할 수 있지만 세션은 새로 만든다.

검수자에게는 해당 단계 원고, 독자 질문·범위, 공식 근거·계산 명세와 검수 기준만 제공한다. 필요한 원문 조회·실제 브라우저 관측·자동 검사는 허용하되 원고 쓰기는 금지한다. 3단계는 초안, 6단계는 최종 편집 후보, 별도 최종 검토는 사이트 정본을 대상으로 한다. 모델 선택과 무관하게 기존 사실·계산·가치·모바일·해시·실행 증거·승인 기준을 유지한다. 검사 통과를 위해 실제 실행 주체와 다른 모델명을 기록하지 않는다.

반대쪽 CLI·인증을 사용할 수 없으면 작성과 근거 정리까지 진행하고 해당 검수는 보류한다. 같은 작성 에이전트의 새 세션이나 자체 검수로 대체하지 않는다. 이 규칙은 이번 작성 중 원고부터 적용하며 과거 실행 기록은 보존한다.

## 공통 원칙

- 한 편은 보호자가 실제로 던지는 질문 하나에 답한다.
- 조사 전에 원천 우위 테스트를 한다. 독자가 원천 대신 이 글을 읽을 이유를 말할 수 없으면 집필하지 않는다.
- 핵심 주장과 모든 수치는 근거 ID를 가진다. `sources` 목록만 채우는 것은 주장 추적이 아니다.
- 원천에 없는 친절을 만들지 않는다. 더 찾지 못하면 문장을 줄이거나 삭제하고 보류를 남긴다.
- `사실`, `원천의 해석`, `편집적 판단 기준`, `미정`을 구분한다.
- 진단·치료 지침, 개별 예후 판단, 약 조절 지시는 쓰지 않는다. 보호자가 관찰할 것과 의료진·기관에 물을 질문으로 바꾼다.
- 특정 시설·업체·중개 서비스는 추천하지 않는다. 효·불효나 죄책감으로 독자를 채점하지 않는다.
- 감사 단계에서는 원고를 고치지 않는다. 번호형 지적과 판정만 남기고 개선 단계로 돌려보낸다.
- 실제로 수행하지 않은 모델·에이전트·사람을 검수자로 기록하지 않는다.
- 의료 콘텐츠의 의학적 승인과 외부 공개의 최종 동작은 사용자 몫이다. 그 전에는 `draft: true`를 유지한다.

## 산출물 위치

1~6단계는 `content-work/<slug>/`에 둔다.

1. `01-question-and-evidence.md`
2. `02-evidence-bound-draft.md`
3. `03-source-trace-audit.md`
4. `04-improved-draft.md`
5. `05-final-edited.md`
6. `06-prepublish-audit.md`

7단계 사이트 정본은 `src/content/guides/<slug>.md` 하나다. 같은 최종본을 다른 이름으로 복제하지 않는다.

## 1단계: 질문·근거·경계 설계

먼저 `blueocean` 스킬을 실행하고 위 필수 절차에 따라 실측 결과와 주제 선정 이유를 이 단계 기록에 남긴다.

독자 상황, `readerQuestion`, `addedValue`, `decision`, 글이 답하지 않을 범위를 먼저 정한다. 공개 원고와 질문이 겹치는지 확인하고, 현재 공식 원문을 직접 열어 주장별 근거표를 만든다.

다음 중 하나면 초안으로 넘기지 않는다.

- 원천 우위를 한 문장으로 말할 수 없다.
- 핵심 결론을 지탱하는 공식 원천을 찾지 못했다.
- 진단·치료 지침을 써야만 질문에 답할 수 있다.
- 기존 글과 같은 질문을 다른 검색어로 반복한다.

## 2단계: 근거 한정 초안

1단계 파일과 현재 원고 스키마만 재료로 전체 초안을 쓴다. 현재 메인 작성자가 작성하며 반대쪽 에이전트는 검수에만 사용한다. 근거표 밖의 사실을 추가하지 않는다.

- `quickAnswer`와 첫 문단에서 답을 먼저 말한다.
- 작업 원고의 사실 문장에는 근거 ID를 연결한다.
- 조건이 다른 값을 표 한 칸에 합치지 않는다.
- 비용·대상·기간·절차는 적용 시점과 제외 조건을 함께 쓴다.
- 보호자가 글을 읽고 할 수 있는 행동이나 질문이 남아야 한다.

## 3단계: 원천 대조 감사

새 터미널의 반대쪽 에이전트 새 세션에 1단계의 질문·범위·근거표, 2단계 초안과 감사 기준만 전달한다. 기존 작성 대화·자기평가·잠정 결론은 전달하지 않는다. 감사자는 초안보다 원천을 먼저 읽고 문장별 주장을 역추적한다. `추적됨 / 미추적 / 불일치 / 과대`로 추적하고, 지적은 `차단 / 필수 수정 / 권고`와 `내용 / 기계 대조`로 나눈다. 차단이 하나라도 있으면 반려, 필수 수정만 있으면 수정 후 확인, 둘 다 없으면 통과다([감사·승인 규칙](references/review-and-approval-rules.md)의 심각도·판정 표).

이 단계에서는 원고를 수정하지 않는다. 정확한 원문 위치와 짧은 원문 대조를 붙인 번호형 수정 과제만 만든다.

실행은 `scripts/run-audit.mjs <slug> --kind stage3 --input <입력 폴더>`로 한다(아래 ‘검수 실행기’). 재검수는 최대 2회이며 상한 소진 시 보류로 반환한다.

## 4단계: 근거 기반 개선

3단계 과제를 반영한 완결 원고를 다시 쓴다. 각 과제는 `반영 / 부분 반영 / 미반영`과 이유를 기록한다. 감사 의견에 새 사실이 들어 있으면 공식 원문으로 다시 확인하기 전에는 반영하지 않는다.

반려 원인이 근거 부족이면 표현을 매끄럽게 고치는 것으로 덮지 않는다. 원천을 추가하거나 주장을 삭제한다.

## 5단계: 보호자 언어 최종 편집

1~4단계를 대조해 제목, 첫 답변, 문단 흐름, 표, 질문 목록, 출처 연결을 정돈한 완결 원고를 만든다.

- 행정·의학 용어를 보호자의 말로 번역하되 조건을 지우지 않는다.
- 결론을 늦추는 도입, 요약 반복, 누구에게나 붙는 조언을 삭제한다.
- 모바일에서 문단과 표가 끊겨도 의미가 유지되게 한다.
- 사실을 바꾸거나 새 사실을 넣지 않는다. 필요하면 1단계로 돌아간다.

## 6단계: 발행 전 이중감사

5단계 원고와 1단계 근거표를 분리된 두 관점으로 검수한다.

1. **사실 감사**: 수치·대상·절차·법령·기관·인과·일반화를 원천에 재추적한다.
2. **가치·밀도 감사**: 원천 우위, 질문 정렬, 결정 가능성, 문단 삭제 테스트, 형제 글 자기잠식을 본다.

사실 감사와 가치·밀도 감사는 각각 별도의 새 터미널·반대쪽 에이전트의 새 세션으로 실행한다. 3단계 세션과 서로의 판정은 재사용·전달하지 않는다. 두 세션에는 5단계 원고와 1단계 질문·범위·근거표 및 해당 감사 기준만 제공하고, 가치 감사에는 비교할 공개 형제 원고도 제공한다. 실패·생략 시 해당 감사와 전체 최종 판정을 보류한다. 작성자는 모든 지적을 현재 원문으로 재검증해 `반영 / 기각 / 보류`로 판정한다.

자동 감사의 차단·필수 수정이 0건이어야(권고는 남아도 됨) `자동 감사 최종 판정: 통과`다. 필수 수정이 모두 `기계 대조` 종류면 수정 뒤 `confirm-findings.mjs`로 대조 증거를 남겨 종결하고 전체 내용 감사를 재시작하지 않는다. 사실의 의미가 달라지는 수정은 새 독립 검수를 받는다. 실행은 `run-audit.mjs --kind final-fact`와 `--kind final-value`로 각각 새 세션에서 한다. 의료인 승인과 공개 승인은 별도이며 기본값은 `대기`다.

## 검수 실행기 — 2026-09-08 판정·종료 방식 개선

3·6단계의 반대쪽 검수는 스킬의 실행기로만 띄운다. 세션마다 즉석 스크립트를 만들지 않는다.

```text
node <스킬>/scripts/run-audit.mjs <slug> --kind stage3|final-fact|final-value --input <입력 폴더> [--focus "<중립 점검 범위>"] [--timeout-min 45]
node <스킬>/scripts/audit-status.mjs <slug> [--wait <실행 폴더> --timeout-min N]
node <스킬>/scripts/confirm-findings.mjs <slug> --run <실행 폴더> --input <수정된 입력 폴더> --method "<대조 방법>"
```

- 입력 폴더는 `brief.md`, `draft.md`, `prompt.txt`, `sources/manifest.json`과 원천 파일만 담는다. 최종 검수의 `draft.md`는 사이트 정본과 같아야 한다(draft 상태만 제외).
- 실행기는 시작 전에 스키마 상한(quickAnswer 400자 등)·필수 입력·manifest를 검증해 실패하면 Codex를 시작하지 않는다(종료 코드 5). 실행마다 `content-work/<slug>/audits/<감사>-r<N>/`에 프롬프트·원출력·판정·`execution.json`을 남기고, 판정은 `BEGIN_BOHOJA_AUDIT_JSON` 블록으로 회수한다.
- 종료 코드: 0 통과 · 2 수정 후 확인 · 3 반려 · 4 반복 상한 소진(`audits/<감사>-hold.md`에 보류 반환) · 5 입력 검증 실패 · 6 실행 보류(타임아웃·신호·CLI 실패·출력 계약 위반·입력 변경).
- 실행기를 백그라운드로 돌렸다면 `audit-status.mjs --wait`로 기다린다. `until`/`grep` 무한 루프와 별도 terminal read 감시는 금지다. `--timeout-min`은 0 초과 45 이하이며 기록된 마감이 잘못되면 실행 보류로 종료한다. 대기 종료 코드 0은 실행 종료일 뿐, 판정 통과를 뜻하지 않는다. runner가 사라지면 `lost`로 확정되며 그 기록으로 통과 처리하지 않는다.
- 재검수 프롬프트에는 현행 원고 전체·현재 근거·`--focus`의 중립적 점검 범위만 넣고 이전 판정·대화·통과 예상은 넣지 않는다.
- `validate-workflow.mjs`는 감사 종류별 마지막 실행기 기록이 `통과` 또는 기계 대조 종결인지, 검수한 원고 SHA가 현재 정본과 같은지, 상한을 넘기지 않았는지 검사한다. 실행기 이전의 즉석 기록은 이력으로만 남기고 재분류하지 않는다.

## 7단계: 사이트 정본·검증

`src/content/guides/<slug>.md`를 완성한다.

- 작업용 근거 ID는 제거하고 실제 원문 URL을 `sources`에 넣는다.
- `readerQuestion`, `addedValue`, `decision`, `verifiedOn`, `verificationMethod`를 실제 수행 내용과 맞춘다.
- 사용자 의학적 승인 전에는 `draft: true`로 둔다.
- `npm run content:check`, `npm test`, `npm run build`를 실행한다.
- 마지막으로 `node <이 스킬 경로>/scripts/validate-workflow.mjs <slug>`를 실행한다.

의료인 승인과 공개 승인을 모두 받은 뒤 발행 준비 상태를 확인할 때만 `--ready-to-publish`를 붙인다. 검증 스크립트는 기록과 구조를 확인할 뿐, 의학적 판단이나 공개 승인을 대신하지 않는다.

## 발행 후 필수 마무리 — 색인 요청·터미널 종료

사용자가 승인한 글이 운영 사이트에 실제 발행되면 아래 절차까지 이어서 수행한다. 이번 사용자 지시로 발행 후 색인 요청과 해당 작업의 터미널 종료는 별도 승인 없이 진행한다. 이 규칙이 초안의 공개 발행이나 의료인 승인을 대신하지는 않는다.

1. **운영 URL 확인:** 발행된 글의 최종 canonical URL에서 HTTP 200, 올바른 본문, robots/noindex 차단 없음, 사이트맵 포함 여부를 확인한다. 프리뷰·초안·리디렉션 전 URL을 색인 요청하지 않는다. 문제가 있으면 수정·검증 후 진행한다.
2. **Google 색인 생성 요청:** Aside MCP/repl과 해당 사이트 가이드를 우선 사용해 Google Search Console의 올바른 속성에서 운영 URL을 검사하고 ‘색인 생성 요청’을 실행한다. 요청 접수 화면까지 확인한다. 사이트맵 갱신만으로 개별 URL 요청을 완료 처리하지 않는다. 일반 블로그 글에는 JobPosting/방송용 Google Indexing API를 쓰지 않는다. 동일 발행본·URL의 접수 기록이 있으면 중복 요청하지 않는다.
3. **결과·미완 사항 기록:** `harness/publication/<slug>.md`에 운영 URL·배포 식별자/커밋, 운영 확인 결과, Search Console 속성·요청 시각·접수 결과·증거 경로를 기록하고 `harness/PROGRESS.md`에 연결한다. 인증정보와 개인정보는 남기지 않는다. 요청 접수는 ‘색인 요청 완료’이며 실제 검색 반영 확인 전에는 ‘색인 완료’로 쓰지 않는다. 로그인·소유권 확인·권한 부여가 필요하면 사용자가 직접 할 동작과 정확한 URL을 남기고 ‘대기’로 기록한다. 한도·서버 오류는 원인과 다음 조치를 기록하고 반복 제출하지 않는다. 후속 기록은 검토 해시가 동결된 `content-work/<slug>/`에 추가하지 않는다.
4. **작업 터미널 전체 종료:** 결과와 로그를 저장한 뒤 `orca-cli` 스킬과 현재 CLI 가이드에 따라 터미널 목록을 조회한다. 이 글의 작성·3단계 감사·6단계 검수·7단계 검토·미리보기·빌드·배포·색인 요청에 사용한 모든 터미널의 ID와 소속을 확인하고, 작업용 서버·CLI 프로세스를 정상 종료한 다음 터미널 세션을 닫는다. 남은 해당 작업 세션이 0개인지 다시 조회하고 종료 수와 유지/실패 사유를 기록·보고한다. 작성/조율 터미널은 발행 기록·PROGRESS 커밋과 푸시까지 마친 뒤 **자기 자신을 마지막 명령으로 닫는다**: `orca terminal close --terminal "$(orca terminal show --json | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>console.log(JSON.parse(s).result.terminal.handle))')" --tab`. 이 명령 뒤에는 아무 동작도 두지 않는다(외부 제어에 맡기지 않는다). 남은 터미널은 다음 자동 회차 precheck의 `close-stale-terminals.mjs`가 유휴 상태일 때만 닫는 안전망으로 처리된다. 다른 글·다른 프로젝트의 작업 중 세션, 소속이 확인되지 않는 세션은 닫지 않는다. 색인 요청이 대기·실패해도 미완 기록을 보존한 뒤 불필요한 해당 작업 터미널은 정리한다. 강제 일괄 종료나 로그·미저장 작업의 유실은 금지한다.

발행 후 마무리 완료 기준은 **운영 확인 통과 + 색인 요청 접수 확인 + 해당 작업의 열린 터미널 0개**다. 요청 실패·대기 또는 종료 실패가 남으면 부분 완료로 보고한다. 실제 Google 색인 반영까지 터미널을 열어 기다리지는 않는다.

공식 근거: [Google 재크롤링 요청 안내](https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl), [Indexing API 적용 대상](https://developers.google.com/search/apis/indexing-api/v3/using-api) — 2026-09-07 확인.

## 실행 모드

- 기본은 전체 자동 모드다. 안전한 범위에서 1~7단계를 이어서 수행하고, 의학적 승인 직전에서 멈춘다.
- 사용자가 단계별 진행을 명시하면 해당 단계 산출물을 만든 뒤 멈춘다.
- 반려된 기존 초안을 다시 쓸 때는 그 파일을 덮어 고치는 대신 1단계부터 새 근거와 경계를 확정한다.
- 미리보기 업로드까지는 준비할 수 있지만 운영 공개는 사용자가 수행한다.

## 2026-09-07 사용자 상시 지시: 글쓰기 요청은 발행까지
사용자 원문: “내가 글쓰기를 지시하면 항상 발행까지 완료해줘”. 앞으로 글쓰기 요청에는 검증 후 운영 발행, 운영 확인, 색인 생성 요청과 작업 세션 정리까지 포함한다. 초안 저장이나 별도 공개 승인 대기에서 멈추지 않는다. 사용자가 초안만 요청하거나 발행 보류를 명시하면 그 지시를 따른다. 기존 자동 사실·가치 감사와 테스트·빌드는 유지한다. 이 상시 발행 지시는 개별 원고를 사용자가 임상 검토했다고 기록할 근거는 아니므로 실제 검토 여부는 구분해 남긴다. 계정 로그인·권한 부여·결제 등 사용자가 직접 해야 하는 동작은 대기로 정확히 보고한다.