git:20260810.f160724 to git:20261010.adc9610

+ ## Phase 0 — 의도 파악 (먼저 한다)

+ 목차는 주제에서 나오지 않고 의도에서 나온다. 같은 주제라도 예산 협의에 쓸 보고서와 의회 답변에 쓸 보고서는 목차가 다르다. 요청문에는 의도의 일부만 실리므로, **말해진 것·추론한 것·모르는 것을 갈라 놓고 목차를 가르는 미상만 골라 묻는다.**

+ 절차·판정표·양식·예시 전문은 [references/intent-analysis.md](references/intent-analysis.md)에 있다. **설계 전에 반드시 Read 한다.**

+ **원칙 — 문면은 바닥, 용도는 방향타.** 요청문에 적힌 것은 빠짐없이 수행하고, 추론한 용도는 무엇을 두껍게·먼저·깊게 다룰지만 정한다. 추론한 목적이 문면과 충돌하면 문면을 따르고 충돌을 질문으로 올린다.

+ **절차:**

+

+ 1. **원문을 읽는다** — `_workspace/00_request.md`(사용자가 쓴 글자 그대로)가 1차 입력이다. 스폰 프롬프트의 요약과 다르면 원문이 우선한다.

+ - **오독 사례를 읽는다** — `~/.claude/intent-misreads.md`가 있으면 원문 다음에 읽는다. 지난번에 사용자가 바로잡은 읽기가 쌓여 있다. 같은 유형의 단서가 이번 요청에 있으면 〔추론〕의 단서로 쓴다(단서: "오독 사례 날짜·유형"). 등급은 여전히 〔추론〕이다 — 지난번의 정정이 이번에도 맞는다는 보장은 없다.

+ 2. **요구어 전수 추출** — 동사·대상·수식어·쓰임 단서·계기 단서·빠진 것으로 쪼갠다. 동사가 산출물 유형을 정한다(발굴 → 선별 장치, 검토 → 판정 기준, 대응 → 쟁점별 논거). 주제 명사만 읽으면 모든 요청이 같은 보고서가 된다.

+ 3. **의도 8요소 + 근거 등급** — 용도·독자·결정·계기·성공 기준·필수/금기·입장·비범위를 채우고 요소마다 〔명시〕(원문 인용) / 〔추론〕(단서 기재) / 〔미상〕(비워 둠)을 단다. "보통 이런 보고서는 이렇다"는 단서가 아니다. 〔추론〕을 〔명시〕처럼 쓰지 않는다.

+ 4. **수단-목적 사다리** — "그래서 이것으로 무엇을 하려는가"를 두 칸 오른다. 무게중심을 정하는 데만 쓰고, 요청된 것을 다른 것으로 바꾸는 데 쓰지 않는다.

+ 5. **해석 후보 2~3개** — 서로 다른 목차를 낳는 해석을 세우고 단서가 많은 쪽을 채택한다. 후보들이 같은 목차로 수렴하면 그 모호성은 묻지 않는다.

+ 6. **의도 한 문장** — "이 보고서를 받은 〔독자〕가 이것으로 〔결정·행동〕을 할 수 있어야 한다." 주제문 말고 쓰임문으로 쓴다.

+ 7. **어긋남 시나리오 3개 + 수용 기준 3~5개** — 완성본을 받은 사용자가 "이게 아닌데"라고 할 이유와, 각각을 목차 어디서 막는지. 이어서 초안을 **예/아니오로 판정할 수 있는 문장**(A1, A2 …)을 적는다. 의도를 잘 읽어도 결과를 판정할 기준이 없으면 "의도를 수행했는가"는 감상으로 남는다. 검토관이 초안 검수에서 이 기준별로 판정한다.

+ 8. **분기 질문 최대 3개** — 답에 따라 **목차가 달라지는 것만** 묻는다. 달라지지 않으면 질문이 아니라 가정이다(가정 목록에 적고 진행). 질문마다 기본 가정과 "답이 다르면 바뀌는 곳"을 단다. 원문에 답이 있는 것은 묻지 않는다.

+ - 목차는 안 바꿔도 **틀리면 결론·핵심 수치가 바뀌는 가정**에는 ★를 단다. 질문을 줄이는 것이지 불확실성을 감추는 것이 아니다.

+ - **요청문의 전제 점검** — 요청문이 깔고 있는 사실관계(일정·제도 명칭·권한·수치)가 아는 것과 어긋나 보이면 「확인할 전제」로 적는다. 고쳐 읽지 않고 사용자가 답하게 한다.

+ 9. **확신도 판정** — 용도·독자·결정 중 〔미상〕이 있고 해석 후보가 목차를 가르면 **낮음**. 낮음이어도 채택 해석 기준으로 설계는 끝까지 내되, 리더가 검토관 게이트 전에 사용자에게 먼저 확인한다.

+ 10. **글자 대조 자기 점검** — 설계 문서를 저장한 뒤 이 스킬 폴더의 `scripts/check_intent.py`를 돌린다. [필수]가 0이 될 때까지 고친다.

+ ```bash

+ python3 scripts/check_intent.py --request _workspace/00_request.md --design _workspace/01_research_design.md

+ ```

+ 〔명시〕로 적은 인용이 원문에 글자 그대로 있는지, 리더 메모에만 있는 말을 〔명시〕로 올리지 않았는지, 요구어마다 반영 위치가 있는지, 원문에서 요구어로 뽑히지 않은 구간이 있는지, 분기 질문마다 기본 가정이 달렸는지, 수용 기준이 판정할 수 있는 문장인지를 본다. 브리프 모드면 `--brief`를 붙인다. 통과는 글자가 맞다는 뜻이지 해석이 맞다는 뜻이 아니다 — 해석은 검토관이 본다.

+

+ 이 결과가 설계 산출물 최상단의 **의도 확인서**가 된다. 점검 스크립트가 읽는 형식이므로 **표 머리와 번호 형식을 바꾸지 않는다** — 요구어 대조표 머리에 '요구어'와 '반영 위치', 요소 표 머리에 '등급', 분기 질문은 `Q1.`, 수용 기준은 '수용 기준' 제목 아래 `A1.`.

+

+ **요청이 분명하면 가볍게 한다.** 용도·독자·결정이 모두 〔명시〕이고 다른 해석이 서지 않으면 4번(사다리)과 5번(해석 후보)을 생략하고 어긋남 시나리오는 1개만 쓴다. 요구어 대조·등급 표·수용 기준·전제 점검은 생략하지 않는다. 절차의 부품은 특정 실패를 막으려고 있는 것이지 채워야 할 칸이 아니다.

+

+ **의도가 목차의 형태를 정한다.** 아래 표준 목차는 출발점이다. 그대로 채우면 어떤 요청이든 같은 보고서가 된다. 세 가지를 한다(판정표는 references/intent-analysis.md §10).

+ - **무게중심** — 의도 한 문장이 요구하는 일에 가장 많은 지면을 준다. 용도별로 두껍게·얇게 할 장이 다르다(결정 지원 → 대안 비교 / 정당화 → 필요성·반론 대응 / 제도 설계 → 실행 요건 / 대응 논리 → 쟁점 목록이 곧 목차).

+ - **의도-목차 대응표(양방향)** — 의도 요소·요구어마다 수행하는 장·절을 적고(대응 장이 없으면 누락), 장마다 "이 장이 없으면 의도의 무엇이 빠지는가"를 적는다. 답이 "표준 구조라서"뿐이면 **관성 장**이다. 빼거나 절로 줄이거나 남기는 근거를 적는다. 양식이 강제하는 장은 "양식 요건"이라 적고 분량만 최소로 잡는다.

+ - **사용자의 낱말** — 장 제목에 사용자가 고른 용어를 살린다. 바꿔야 하면 이유를 적는다.

+

+ **표준 목차(기본 골격)** — 위 판정을 거쳐 RQ와 의도에 맞게 구체화한다:

+

+ **조사 항목마다 범위를 단다 — 〔공통〕 / 〔갈림〕.** 〔공통〕은 어느 해석을 택하든, 분기 질문에 어떤 답이 오든 쓰이는 근거다(법령·제도 현황, 기본 통계, 핵심 개념의 출처 등). 〔갈림〕은 채택 해석이나 특정 분기 답에 딸린 근거다(어느 질문에 딸렸는지 적는다: `〔갈림: Q2〕`). 리더는 사용자의 답을 기다리는 동안 〔공통〕 항목 조사만 먼저 돌릴 수 있다 — 답이 어떻게 오든 버려지지 않는 일이기 때문이다. 확신이 서지 않는 항목은 〔갈림〕으로 둔다.

+

+ **목차 사용자 승인:** 이 목차는 설계 게이트 통과 후 **사용자 검토·승인**을 받는다(오케스트레이터가 제시). 사용자는 의도 한 문장 → 추론·가정 → 목차 순으로 본다. 한눈에 보이게 정리하고, 장마다 의도 연결을 한 구절로 붙여라.

+ **브리프 모드 설계 (단형 4~8p):** 오케스트레이터가 "브리프 모드"를 지정하면 위 8장 표준 목차 대신 **압축 목차**(① 배경·문제제기 → ② 핵심 현황·쟁점 → ③ 핵심 근거 → ④ 정책제언 우선순위)를 설계한다. RQ는 1개로 좁히고, 분석틀은 "핵심 쟁점 → 제언"의 최소 골격으로, 장별 분량은 1~2p씩 배분한다. 설계 산출물도 가볍게(경량 의도 확인서·RQ·압축목차·필요근거 핵심만) 쓴다. 의도 확인서는 **경량판**(요청 원문·의도 한 문장·확신도·용도/독자/결정 3행·요구어 대조·어긋남 시나리오 1개·수용 기준 2~3개·분기 질문 2개 이내)으로 쓰고, 대응표는 압축 목차에 "의도 연결" 열을 더하는 것으로 갈음한다. 핵심은 "무엇을 버리고 무엇 한 가지를 말할 것인가"이고, 그 한 가지를 고르는 기준이 의도 한 문장이다.

+ 1. **의도 확인서** — 요청 원문(인용) · 의도 한 문장 · 확신도 · 8요소 표(등급 + 인용/단서) · 요구어 대조 · 해석 후보 · 어긋남 시나리오 · **수용 기준(A1…)** · 의도 대비 달라진 점. 대상·범위·산출물 규모도 여기 적는다

+ 2. **분기 질문 / 확인할 전제 / 가정 사항** — 분기 질문(기본 가정 · 답이 다르면 바뀌는 곳), 확인할 전제(요청문의 사실관계 가운데 어긋나 보이는 것), 묻지 않고 정한 가정 목록(틀리면 결론·핵심 수치가 바뀌는 것은 ★)을 나눠 쓴다. 분기 질문이 없으면 "분기 질문 없음"

+ 3. **핵심 RQ** — 우선순위 포함. RQ마다 의도 한 문장의 어느 부분에 답하는지 한 구절

+ 5. **목차** — 장·절 + 항목별 [방법][필요근거] + 장별 분량, 이어서 **의도-목차 대응표**와 **조사 항목 목록**(항목 번호 · 〔공통〕/〔갈림〕 · 쓰이는 장·절)

+ ## 개정할 때 — 의도를 지킨다

+

+ 검토관 지적이나 근거 미확보로 RQ를 낮추거나 장을 덜 때마다 묻는다 — **고친 뒤에도 의도 한 문장이 수행되는가.** 수행되지 않거나 약해지면 조용히 낮추지 말고 §1 「의도 대비 달라진 점」에 "무엇을 낮췄고, 그래서 사용자가 못 하게 된 일이 무엇인지"를 적는다. 실행 가능성 때문에 쓰임을 깎을지는 사용자가 목차 승인에서 정한다.

+

+ 사용자 답변·수정 지시가 `00_request.md`에 추가됐으면 **의도 확인서부터** 고친다. 해석이 바뀌었는데 목차의 해당 줄만 고치면 나머지 장이 옛 해석에 남는다.

+

+ ## 이 스킬을 고칠 때 — 회귀 세트를 돌린다

+

+ 의도 파악 절차나 설계자 정의를 고쳤으면 같은 요청들로 설계자를 다시 돌려 읽기가 나빠지지 않았는지 본다. 사례는 `regression/cases/`에 있다(요청 원장 + 기계가 채점할 기대 항목 + 사람이 볼 항목).

+

+ ```bash

+ python3 scripts/regress.py prepare --out <실행 폴더> # 원장을 펴고 사례별 스폰 프롬프트를 만든다

+ # → 리더가 spawn_prompts.md 의 프롬프트로 설계자를 사례마다 띄운다(병렬 가능)

+ python3 scripts/regress.py score <실행 폴더> --record # 글자 대조 + 기대 항목 채점, 이력에 한 줄

+ ```

+

+ - 사례는 실제로 받은 요청으로 늘린다. 사용자가 방향을 바로잡은 요청이 가장 좋은 사례다 — 그 뒤의 발언이 정답지가 된다. 오독 사례가 생기면 회귀 사례로도 옮긴다.

+ - 절차의 부품을 걷어낼 때(요청이 분명하면 가볍게, 모델이 나아져 부품이 차이를 못 만들 때)도 이 세트로 확인한다. 걷어낸 뒤 통과가 줄지 않으면 걷어낸 것이 맞다.

+ - 요청 원문이 들어 있으므로 실제 사례는 공개 저장소에 넣지 않는다.

+

+ - 검토관의 설계 게이트 피드백을 받으면 해당 부분만 개정한다. 단 의도 해석이 바뀐 경우는 위 절을 따른다.