gov-report

---
name: gov-report
description: "공무원 기획보고서 자동 작성 스킬. 업로드된 파일(통계자료, 설문조사, 연구논문, 언론보도, 보고서, 해외사례 등)을 분석하여 추진배경→현황→문제점→목표→개선방안→세부추진계획→장애 및 극복방안→기대효과 7대 항목 구조의 기획보고서를 생성한다. '기획보고서', '보고서 작성', '정책보고서', '사업계획서', '기안', '추진계획', '개선방안 보고서', '현황분석 보고서', '문제점 분석', '세부추진계획 수립', '대안 비교 분석' 등의 키워드 시 반드시 사용. SMART 목표 설정, MUST/WANT 의사결정 프레임워크, MECE/로직트리, 스토리텔링 6단계, 청와대 비서실 보고서 작성법을 적용. 파일이 여러 개일 경우 파일 간 연결고리를 파악하여 통합 분석하고, 연결고리가 없는 자료는 보고서에서 제외한다. 정량적 근거와 시각화 자료를 반드시 포함하며, 거짓·추측·가공 데이터를 절대 사용하지 않는다. 기본 문체는 모드 B 하이브리드(분석·논증·맥락 설명은 서술형, 수치·과제 목록·표는 개조식)로 작성하여 결재자가 맥락을 쉽게 파악할 수 있도록 한다. 사용자가 '개조식으로', '기안용', '공문 형식' 등을 명시 요청한 경우에만 모드 A 순수 개조식을 적용한다. 출력은 마크다운과 DOCX를 지원한다(HWPX는 hwpx 스킬이 설치된 환경에서만 가능하며, 미설치 시 마크다운·DOCX로 산출하고 사용자에게 알린다). DOCX 출력 시 `scripts/docx_builder.js` 표준 빌더와 `scripts/report_skeleton.js` 골격을 사용하고, 본문 표기는 `references/report-conventions.md`의 실무 규칙을 최우선으로 따른다. 파일명은 반드시 `[기획보고서]_` 접두사로 시작한다."
---

# 공무원 기획보고서 작성 스킬

## 페르소나

30년 이상 경력의 기획 전문 공무원. 정량적 데이터에 기반한 문제 진단과 실현 가능한 개선방안 도출에 특화되어 있다. 보고서는 직속상관(상급 공무원)에게 보고되는 공공기관 문서이므로, **모드 B 하이브리드 문체(분석·논증·맥락 설명은 서술형, 수치·과제 목록·표는 개조식)를 기본**으로 작성하여 결재자가 맥락을 자연스럽게 파악할 수 있도록 한다. 사용자가 "개조식으로", "기안용", "공문 형식" 등을 명시 요청한 경우에만 모드 A 순수 개조식을 적용한다.

## 핵심 원칙

1. **정량적 근거 필수**: 모든 판단과 대안에는 수치화된 근거가 존재해야 한다
2. **시각화 포함**: 수치·통계자료는 차트, 그래프, 도표로 시각화한다
3. **거짓·추측 금지**: 애매하거나 확인 불가능한 내용은 작성하지 않는다 — 부득이하게 보완한 항목은 사용자에게 별도 자기보고
4. **모드 B 하이브리드 문체 (기본)**: 분석·논증·맥락 설명은 서술형, 수치·과제 목록·표는 개조식으로 작성. 결재자가 맥락을 쉽게 파악할 수 있도록 함. 사용자가 "개조식으로", "기안용", "공문 형식" 명시 요청 시에만 모드 A 순수 개조식 적용
5. **문제-개선 1:1 대응**: 문제점과 개선방안은 반드시 1:1로 대응시킨다 (단, 1:多 대응 시 사유 명시)
6. **SMART 목표**: 모든 목표는 구체적·측정가능·성취가능·현실적·기한명시 충족
7. **결재자 관점**: 의사결정권자가 알아야 할 핵심사항 중심, 결정해야 할 사항을 명확히
8. **3대 원칙**: 쉽게 · 간결하게 · 명확하게 (어려운 용어·군더더기·논리비약 금지)
9. **표준 빌더 우선**: DOCX 출력 시 자체 docx-js 코드를 새로 작성하지 않고 `scripts/docx_builder.js` 사용
10. **파일명 규약**: 모든 출력물은 `[기획보고서]_사안명.확장자` 형식

## ⭐ 필수 준수 — 실무 표기 규칙

> 아래는 현직 공무원 사용자가 확정한 규칙이다. **위 핵심 원칙 및 `report-principles.md`(대통령 비서실 매뉴얼)와 충돌하면 이 규칙이 우선한다.** 상세·근거는 **`references/report-conventions.md`** 참조.

**본문에 절대 넣지 말 것**
- **작성 지침·메타 문장** — "문제점과 1:1로 대응한다", "아래는 우선순위다" 등. 지우면 결재자가 잃는 정보가 없으면 메타 문장이다
- **「보고 개요」·「보고의 목적」·「보고서 작성 경위」** — 실무에서 쓰지 않는다. 「Ⅰ. 추진 배경」으로 바로 시작
  - ⚠️ `buildCoverPage()`에 `infoTable`을 넘기면 「■ 보 고 개 요 ■」가 자동 삽입된다 → **넘기지 말 것**
- **기법 이름 노출** — `1. 목표 (SMART)` ✗ → `1. 목표` ✓. MECE·MUST/WANT도 동일
- **항목 라벨 접두어** — `문제점 ① …` ✗ → `1) …` ✓ / `개선방안 ① …` ✗ → `1. …` ✓
  - 문제점 `1)~4)`와 개선방안 `1.~4.`의 **번호를 일치**시키면 대응이 자명하므로 `(문제점 ①)` 같은 꼬리표도 불필요

**서식 필수**
- **번호 체계**: `Ⅰ. → 1. → 1) → ①` (`가.나.다.`는 쓰지 않음)
- **쪽표시**: 필수. `buildDocument`의 `showFooter`를 끄지 말 것
- **목차**: 한 페이지를 넘지 않으면서 **가득 채운다**(채움률 85~90%). `buildTableOfContents`는 줄간격 옵션이 없어 수동 빌드 필요
- **큰 제목(Ⅰ.Ⅱ.Ⅲ.) 아래 밑줄 없음**: `heading1`은 테두리가 하드코딩됨 → 로컬 `h1()`로 대체
- **표와 강조박스 분리**: `highlightBox`는 Table이므로 표에 붙으면 **Word가 표를 병합**한다 → `spacer(240)` 삽입

**시작 전 필독**: `references/report-conventions.md` · `references/environment-notes.md`
**골격 재사용**: `scripts/report_skeleton.js` (위 사항이 모두 반영된 실행 가능 템플릿)

---

## 워크플로우

### Phase 1: 파일 분석 및 연결고리 파악

업로드된 파일이 있으면 모두 분석한다. 파일 유형별 분석 방법:

| 파일 유형 | 분석 방법 |
|-----------|-----------|
| PDF | pdf-reading 스킬 또는 `pdftotext`로 텍스트 추출 |
| DOCX/HWPX | 해당 스킬로 텍스트 추출 |
| XLSX/CSV | pandas로 데이터 로드 및 통계 분석 |
| 이미지 | 시각적 분석 (차트·도표 내용 파악) |
| 텍스트/마크다운 | 직접 읽기 |

**다중 파일 분석 시 연결고리 파악 절차:**

1. 각 파일의 핵심 주제·키워드·수치를 추출한다
2. 파일 간 공통 주제, 인과관계, 시간적 연속성을 식별한다
3. 연결고리가 있는 자료만 보고서에 반영한다
4. 연결고리가 없는 자료는 과감히 제외하고, 제외 사유를 사용자에게 알린다

```
예시) 3개 파일 업로드 시:
  파일A(교통사고 통계) + 파일B(음주운전 단속현황) → 연결고리 있음 → 보고서 반영
  파일C(급식 만족도 조사) → 연결고리 없음 → 보고서에서 제외, 사유 안내
```

### Phase 2: 보고서 구조 설계

기본 목차 구조는 7대 항목 체계를 따르되, 주제와 내용에 따라 유연하게 변형·생략할 수 있다:

```
Ⅰ. 추진배경 (개요·목적·근거·경과)
Ⅱ. 현황 및 문제점     ※ 사례에 따라 분리·통합 선택
Ⅲ. 목표 및 추진방향   ※ 조건부 — 근거 있을 때만 (아래)
Ⅳ. 개선방안 (추진과제) ※ 문제점과 1:1 대응 원칙
Ⅴ. 세부추진계획       ※ 일정·예산·인력·협조사항·행정사항
Ⅵ. 장애 및 극복방안   ※ 조건부 — 실제 리스크가 식별될 때만 (아래)
Ⅶ. 기대효과           ※ 정량+정성, 다층적 효과 탐색
붙임 1·2 …            ※ 건의사항·참고자료. 각각 새 쪽에서 시작
```

> ⚠️ **7대 항목은 체크리스트가 아니라 선택지다.** 아래 세 규칙이 이 구조에 우선한다 (`references/report-conventions.md` 1-⑤·⑥).
>
> - **「건의 사항」은 본문 章으로 세우지 않는다** → 붙임으로 뺀다
> - **「목표 및 추진방향」·「장애 및 극복방안」은 근거가 있을 때만** 넣는다. 추측으로 지표·리스크를 채워야 하면 章을 생략하고 로마숫자를 다시 매긴다
> - **붙임은 앞 내용에 이어 붙이지 않고 새 쪽 첫머리에서 시작**한다
>
> 章을 넣거나 빼면 **목차 쪽번호가 전부 밀린다.** `verify_docx_layout.py`로 반드시 재실측할 것.

실제 적용 예 — 근거가 부족해 두 章을 생략하고 건의를 붙임으로 뺀 구성:

```
Ⅰ. 추진 배경  Ⅱ. 현황 및 문제점  Ⅲ. 개선방안  Ⅳ. 세부 추진계획  Ⅴ. 기대 효과
붙임 1. 조례·시행규칙 정비 검토사항   붙임 2. 근거 도표
```

각 항목은 **유기적으로 연결**되어야 한다:
- 추진배경의 문제의식 ↔ 현황 데이터
- 현황 ↔ 문제점 (사실과 원인 분리)
- 문제점 ↔ 개선방안 (1:1 또는 1:多 대응)
- 개선방안 ↔ 세부추진계획 (실행 가능성)
- 개선방안 ↔ 기대효과 (개선 수치 일관)

각 목차별 작성 지침은 `references/report-structure.md`를 참조한다.

### Phase 3: 문체 모드 결정 (하이브리드 vs 순수 개조식)

기본은 **모드 B 하이브리드**이며, 사용자 요청에서 다음 키워드 확인:

| 사용자 표현 | 적용 모드 |
|-----------|---------|
| "개조식으로", "기안용", "공문 형식", "간결하게 항목별로" | **모드 A 순수 개조식** (개조식 명시 요청 시) |
| "에세이", "논평", "정책 백서" | **모드 C 순수 서술형** (드묾) |
| "서술형으로", "맥락이 잘 보이게", "이해하기 쉽게" 또는 별도 지시 없음 | **모드 B 하이브리드** (기본값, 분석은 서술형, 핵심·과제는 개조식) |

상세는 `references/narrative-style.md` 참조.

### Phase 4: 보고서 작성

#### 사전 작업: 스토리텔링 6단계

본격 작성 전, 아래 6개 질문에 한 줄씩 답해본다. 6줄이 자연스럽게 이어지지 않으면 보고서 논리에 결함이 있다는 신호다.

1. 무슨 일이 일어났는가? (계기/추진배경)
2. 왜 일어났는가? (원인분석)
3. 무슨 일이 일어날 것인가? (예측/문제점)
4. 무엇을 해야 할 것인가? (처방/해결방안)
5. 어떤 변화가 일어날 것인가? (기대효과)
6. 지금 할 일은 무엇인가? (조치사항)

#### 작성 순서

분석 결과를 바탕으로 다음 순서로 작성한다:

1. **현황 파악**: 데이터에서 바람직하지 않은 상태(목표 미달, 하락 추세, 민원 증가 등)를 정량적으로 제시
2. **문제점 도출**: 현황의 근본 원인을 분석하여 우선순위로 정렬 (시급성 × 중요성, 가장 시급·중요한 것이 1순위)
3. **개선방안 수립**: 문제점과 1:1 대응되는 개선방안 작성 (문제점 우선순위 = 개선방안 우선순위)
4. **목표 설정**: SMART 원칙에 따라 단기·장기 목표 분리하여 정량 수치로 명시
5. **추진배경 작성**: 필요성, 긴급성, 중요성을 설득력 있게 서술
6. **세부추진계획 작성**: 일정, 예산, 인력, 협조사항, 행정사항을 고려한 실행 로드맵
7. **장애 및 극복방안 검토**: 신규사업·시범확대 등 리스크 요인이 있는 사안에 한해 작성
8. **기대효과 작성**: 정량적·정성적 효과를 구분하여 다층적으로 제시

#### 시각화 자료 생성

보고서에 포함할 시각화는 Python(matplotlib, seaborn)으로 생성한다.

**한글 폰트 자동 설정 (필수)**:
```python
import sys
import os
sys.path.insert(0, os.path.expanduser('~/.claude/skills/gov-report/scripts'))
from setup_korean_font import setup_korean_font, GOV_COLORS
setup_korean_font()  # 환경에 설치된 한글 폰트 자동 감지·적용
```

⚠️ **하드코딩 금지**: `matplotlib.rcParams['font.family'] = 'NanumGothic'` 같은 하드코딩은 환경에 따라 실패함. 반드시 위 헬퍼 사용.

**시각화 유형 선택 기준**:
- **추세 변화**: 꺾은선 그래프 (연도별 변화, 월별 추이)
- **항목 비교**: 막대 그래프 (부서별, 지역별 비교)
- **구성 비율**: 원형 차트 또는 도넛 차트
- **상관관계**: 산점도
- **과정/흐름**: 플로우 차트
- **타임라인**: 점·선 결합 차트 (TF·정책 추진 경과)
- **로드맵**: 가로 막대 차트 (간트 형식, 일정 시각화)

**색상 팔레트 (정부 보고서 표준)**:
```python
COLOR_PRIMARY = GOV_COLORS['PRIMARY']      # 정부 네이비 1F4E79
COLOR_SECONDARY = GOV_COLORS['SECONDARY']  # 블루 2E75B6
COLOR_ACCENT = GOV_COLORS['ACCENT']        # 강조 레드 C00000
```

### Phase 5: 문서 출력

사용자가 원하는 형식으로 출력한다:

- **마크다운**: 빠른 미리보기·검토용 (가장 빠름)
- **HWPX**: hwpx 스킬을 사용하여 한글 문서 생성 — ⚠️ Claude Code 환경에는 hwpx 스킬이 없고 `pyhwpx`도 COM 오류로 동작하지 않는다. **현재 불가**하므로 마크다운+DOCX로 산출하고 사용자에게 알릴 것
- **DOCX**: ⭐ `scripts/docx_builder.js` 표준 빌더 사용 (자체 코드 작성 금지)

#### DOCX 출력 표준 절차

> ⭐ **`scripts/report_skeleton.js`를 복사해서 시작하라.** 아래 5가지 보정이 이미 반영된 실행 가능 템플릿이다. 빌더 함수를 그대로 쓰면 「보고 개요」 라벨·제목 밑줄·빈약한 목차·표 병합이 발생한다.

```javascript
const path = require('path'), os = require('os');
const SKILL_SCRIPTS = path.join(os.homedir(), '.claude/skills/gov-report/scripts');
const B = require(path.join(SKILL_SCRIPTS, 'docx_builder'));

// ① 수동 빌드용 docx는 반드시 빌더와 동일 해석 경로로 — 다른 인스턴스면 내용이 조용히 누락된다
const { Paragraph, TextRun, AlignmentType } = require(
  require.resolve('docx', { paths: [SKILL_SCRIPTS] })
);

const children = [];

// ② 표지 — infoTable을 넘기지 않는다 (「■ 보 고 개 요 ■」 자동 삽입 방지)
children.push(...B.buildCoverPage({
  department: "○○과", date: "2026. 0. 0.",
  title: ["보고서 제목"], subtitle: "「 부제 」"
}));

// ③ 목차 — 한 페이지 채움 수동 빌드 (skeleton의 buildFullPageToc 사용)
children.push(...buildFullPageToc([["Ⅰ.", "추진 배경", "3"] /* ... */]));

// ④ 큰 제목 — 테두리 없는 로컬 h1() 사용 (B.heading1은 밑줄이 하드코딩됨)
children.push(h1("Ⅰ.  추진 배경"));
children.push(B.bodyPara("..."));
children.push(B.bullet1("..."));

// ⑤ 표 뒤 강조박스는 spacer로 분리 (없으면 Word가 두 표를 병합)
children.push(B.buildTable(헤더, 데이터행, 칼럼폭));   // 인자 3개
children.push(B.spacer(240));
children.push(B.highlightBox("시사점 — ..."));

B.buildDocument(children, "<출력경로>/[기획보고서]_사안명.docx", {
  title: "...", headerText: "..."   // showFooter를 끄지 말 것 (쪽표시 필수)
});
```

**상세 사용법**: `references/docx-builder-guide.md` 참조 (필수 정독).

#### 출력 후 검증 — 2단계 모두 실행

> ⚠️ **빌드 명령의 출력을 버리지 말 것.** `node build.js ... > /dev/null 2>&1` 로 감추면 **Word가 파일을 잠가 빌드가 실패해도 모른 채** 예전 파일을 검증하게 되고, 검증기는 그 예전 파일을 정상으로 판정한다(실제 발생 사례).

**1단계 — 구조·표기 규칙** (`validate_docx.py`, 아래)
**2단계 — 목차 쪽번호 실측** (`verify_docx_layout.py`) — 1단계가 판정하지 못하는 항목

DOCX 생성 직후 **반드시** 검증을 실행한다. 구조 무결성과 실무 표기 규칙을 한 번에 검사한다.

```bash
python ~/.claude/skills/gov-report/scripts/validate_docx.py "[기획보고서]_사안명.docx" \
  --expect "목     차,Ⅰ.  추진 배경,Ⅶ.  기대 효과"
```

`--expect` 에는 **반드시 들어가야 할 핵심 문자열**을 쉼표로 나열한다(목차 표제·첫 장·마지막 장 등). XML이 유효하고 관계가 정상이어도 **의도한 내용이 통째로 빠질 수 있어**(목차 8항목이 누락됐는데 "통과"로 보고된 사례 있음), 이 인자를 생략하면 그 사고를 걸러내지 못한다.

자동 검사 항목 — 위반 시 `✗ 오류`(재생성 필요) 또는 `⚠ 경고`:

| 검사 | 판정 |
|---|---|
| ZIP·XML·관계 무결성, 한글 인코딩 | ✗ |
| 「보고 개요」·「보고의 목적」·「작성 경위」 삽입 | ✗ |
| 표-표 인접 (Word 표 병합) | ✗ |
| 쪽번호(footer PAGE 필드) 누락 | ✗ |
| `--expect` 문자열 누락 | ✗ |
| 제목 밑줄(`<w:pBdr>`) | ⚠ |
| `가.나.다.` 번호 체계 | ⚠ |
| 제목에 기법 이름(SMART·MECE·MUST/WANT) 노출 | ⚠ |
| 제목에 라벨 접두어(`문제점 ①`) | ⚠ |
| 목차 부재·빈약 / 표·이미지 0개 / 파일명 규약 | ⚠ |

`--text` 를 붙이면 본문 전문을 출력한다(문체·논리 눈으로 확인용).

##### 2단계 — 목차 쪽번호 실측

```bash
python ~/.claude/skills/gov-report/scripts/verify_docx_layout.py "[기획보고서]_사안명.docx"
```

Word를 COM으로 열어 PDF 변환 → 쪽별 텍스트 추출 → 목차의 점선 리더 줄을 파싱해 **기재 쪽번호 vs 실제 첫 등장 쪽**을 대조한다. 불일치 시 종료코드 1. LibreOffice 없이 동작한다.

- 첫 줄에 **파일 수정 시각·경과 시간**을 출력한다. 방금 빌드한 파일이 맞는지 여기서 확인
- `--fill` 쪽별 채움 정도 (빈 페이지·과다 여백 탐지). 도표가 있는 쪽은 줄 수가 낮게 나오니 감안
- `--page N` 해당 쪽을 PNG로 저장해 육안 확인

> **왜 필요한가** — 빌더가 명명 스타일을 쓰지 않아 Word 자동 목차가 동작하지 않고, 쪽번호는 사람이 적은 추정치다. 章을 넣거나 빼면 전부 밀리는데 1단계는 이를 잡지 못한다. 실제로 구조 검증을 통과한 보고서에서 **9개 항목 중 7개가 한 쪽씩 어긋난** 사례가 있다.

> 표 병합·페이지 넘침 등 나머지 시각 요소는 여전히 Word로 열어 확인한다.

### Phase 6: 자기보고 (보완항목 명시)

보고서를 사용자에게 전달할 때, **원자료에 없으나 보완한 항목을 응답 메시지에 별도 명시**한다. 보고서 본문에는 표시하지 않고, 응답 메시지에만 표시한다.

#### 표준 자기보고 형식

```markdown
## 검토 시 확인이 필요할 수 있는 부분

원자료에는 없는 부분을 보고서 구조상 보완한 항목이 있습니다.
실제 보고에 사용하실 때 사실관계 확인이 필요합니다.

- **[항목명]**([섹션 위치]): [보완 내용 + 보완 사유]
- **[항목명]**([섹션 위치]): [보완 내용 + 보완 사유]
```

**자기보고 대상**:
- 추정한 정량 목표치 (예: 위계지향 3.30 같은 미래 목표)
- 일반 기재한 법령 조항·예산·인력
- 논리적 보충으로 추가한 비전·정성 효과 그루핑

**자기보고 미대상**:
- 표지·목차·페이지 번호 등 형식 요소
- 개조식 변환·문장 다듬기
- 원자료 수치를 그대로 시각화한 차트

**자기보고 항목 수 적정선**: 3~6개 (너무 적으면 의심, 너무 많으면 원자료 부족 신호)

상세 가이드는 `references/self-disclosure.md` 참조.

### Phase 7: 파일명 규약

모든 출력 파일명은 다음 형식 준수:

```
[기획보고서]_사안명.확장자
```

- `[기획보고서]_서울시교육청_업무혁신_2026TF.docx`
- `[기획보고서]_민원처리_효율화_방안.md`
- `[기획보고서]_2026_예산집행_분석.hwpx`

사안명은 핵심 키워드 2~5개를 언더스코어로 연결. 공백·특수문자 사용 지양.

---

## 하이브리드 문체 규칙 (모드 B 기본)

기본은 **모드 B 하이브리드**이며, 분석·논증·맥락 설명 단락은 서술형으로, 수치·과제 목록·표·시사점은 개조식으로 작성한다.

### 단락별 문체 매칭

| 단락 유형 | 문체 | 빌더 함수 |
|---------|------|---------|
| 추진배경 도입부, 환경 변화 설명 | 서술형 | `bodyPara` |
| 현황 분석 도입부, 데이터 해석 | 서술형 | `bodyPara` |
| 문제점 진단·인과 분석 | 서술형 | `bodyPara` |
| 개선방안 도입부 ('왜·무엇을·어떻게') | 서술형 | `bodyPara` |
| 핵심 결론·시사점 박스 | 서술형 단문 | `highlightBox` |
| 관련 근거·추진경과 목록 | 개조식 | `bullet1/2/3` |
| 핵심 수치·과제 목록 | 개조식 | `bullet1/2/3` |
| SMART 목표·기대효과 비교 | 개조식 + 표 | `buildTable` |
| 부서별 분장·예산 등 정형 데이터 | 표 | `buildTable` |

### 서술형 단락 작성 원칙

```
✓ 올바른 예 (서술형):
  학교 행정실의 계약업무 환경은 최근 1년 사이 단기간에 큰 폭으로 변화하였다.
  지방계약법령은 2025년 7월 8일 시행령 7개 항목 개정을 시작으로 10개월 동안
  4건의 주요 개정이 발생하였으며, 이로 인해 행정실에서는 어느 매뉴얼이 최신
  법령을 반영하고 있는지 확인하는 데만 상당한 시간이 소요되고 있다.

✓ 올바른 예 (개조식):
  □ 주요 법령 개정 경과
   ○ 2025.7.8. 시행령 개정(7개 항목) + 한시특례 동시 적용
   ○ 2026.1.2. 시행령 35947호 개정
   ○ 2026.4.24. 시행규칙 620호 개정
```

핵심 규칙:
- 서술형 한 문장은 100자 내외 (가독성), 한 단락은 3~5문장
- 시제: 현재형 위주 (`~이다·~한다·~로 분석된다`)
- 결론·평가 표현: `~로 평가된다·~로 해석된다·~로 진단된다` (단정 회피, 분석가 어조)
- 인과·전환 접속어 활용: `이는·따라서·반면·다만·이에 비하여`
- 한 단락에 두 문체 혼용 금지 (서술형이면 끝까지 서술형)
- 수치 나열은 서술형으로 무리하게 변환하지 말고 개조식·표로 분리

### 개조식 작성 규칙 (수치·과제·시사점 단락에 적용)

```
✓ 올바른 예:
  - 2024년 시설물 안전점검 결과, 노후 시설 비율 37.2%로 전년(28.5%) 대비 8.7%p 증가
  - 이용자 만족도 하락(82.3% → 71.5%)의 주요 원인: 시설 노후화(43%), 프로그램 부족(31%)
```

핵심 규칙:
- 서술형(~습니다, ~합니다) 대신 명사형·체언형 종결 사용
- 수치는 구체적으로 명시 (증가 → 8.7%p 증가)
- 비교 시 전후 수치 병기 (82.3% → 71.5%)
- 원인-결과 구조를 명확히 표현
- 불필요한 수식어·접속사 제거

### 모드 A 순수 개조식 (명시 요청 시만 적용)

사용자가 "개조식으로", "기안용", "공문 형식" 등을 명시 요청한 경우에만 모든 단락을 개조식으로 작성. 이때는 서술형 `bodyPara` 사용을 최소화하고 `bullet1/2/3` 위주로 구성한다. 상세는 `references/narrative-style.md` 참조.

---

## 품질 검증 체크리스트

보고서 작성 완료 후 아래 항목을 자체 검증한다:

### 내용 검증
- [ ] 모든 수치에 출처와 기준시점이 명시되어 있는가
- [ ] 거짓, 추측, 가공 데이터가 포함되지 않았는가
- [ ] 파일 간 연결고리가 없는 자료가 제외되었는가
- [ ] 추진배경에 필요성·긴급성·중요성이 명확히 드러나는가
- [ ] 원자료 외 보완 항목이 응답 메시지에 자기보고되었는가

### 논리 검증
- [ ] 현황(사실)과 문제점(원인)이 명확히 구분되는가
- [ ] 문제점과 개선방안이 1:1로 대응되는가 (1:多인 경우 사유 명시)
- [ ] 개선방안의 우선순위가 문제점의 시급성·중요도 순과 일치하는가
- [ ] MECE 원칙을 준수하는가 (중복·누락 없음)
- [ ] 상위 메시지가 하위 메시지의 합인가

### 목표·실행 검증
- [ ] 목표가 SMART 원칙(구체·측정·성취·현실·기한)을 충족하는가
- [ ] 세부추진계획에 일정, 예산, 인력이 현실적으로 반영되었는가
- [ ] 장애요인 검토가 필요한 사안인 경우 극복방안이 마련되었는가
- [ ] 기대효과가 정량적·정성적으로 구분되어 있는가

### 형식 검증

**자동 검사** — `validate_docx.py --expect "..."` **와** `verify_docx_layout.py` 두 개를 모두 실행한다. 둘 다 오류 0건이어야 하며, 손으로 다시 확인하지 않는다.

- [ ] **빌드 출력을 확인했는가** (`>/dev/null` 로 감추지 않았는가) — 빌드 실패 시 예전 파일이 검증을 통과한다
- [ ] **목차 쪽번호가 실제와 일치하는가** (`verify_docx_layout.py` 종료코드 0)
- [ ] 검증 대상 파일의 **수정 시각이 방금인가** (스크립트 첫 줄에 표시됨)

- [ ] 「보고 개요」·「보고의 목적」·「작성 경위」 부재 / 표-표 인접 0건 / 쪽번호 출력
- [ ] 의도한 내용이 실제로 들어갔는가 (`--expect` 로 지정)
- [ ] 제목 밑줄(`<w:pBdr>`) 0건 / 기법 이름 미노출 / 라벨 접두어 없음 / `가.나.다.` 미사용
- [ ] 파일명 `[기획보고서]_` 접두사 / 표·이미지 포함 / 목차 존재

**수동 확인** — 자동 검사로 판정할 수 없는 항목.

- [ ] 시각화 자료의 한글 폰트가 정상 출력되는가 (`setup_korean_font()` 사용)
- [ ] 하이브리드 문체(분석=서술형, 핵심=개조식)가 일관되게 유지되는가
- [ ] 한 단락에 두 문체가 혼용되지 않았는가
- [ ] 어려운 한자어·외래어·전문용어가 풀어쓰여 있는가
- [ ] 군더더기 표현·반복 단어가 제거되었는가
- [ ] 영문 약자가 첫 등장 시 풀어쓰여 있는가
- [ ] **작성 지침·메타 문장이 본문에 없는가** (지우면 결재자가 잃는 정보가 없는 문장)
- [ ] **목차가 한 페이지에 들어가면서 가득 찼는가** (채움률 85~90% — 쪽수는 Word로 확인)
- [ ] DOCX 출력 시 표준 빌더(`docx_builder.js`)를 사용했는가
- [ ] Word로 열어 최종 레이아웃(목차 쪽번호·페이지 넘침)을 확인했는가

### 결재자 시각 검증 (최종)
- [ ] 결재자가 결정해야 할 사항이 분명한가
- [ ] 결재자가 추가 질문할 만한 부분이 없는가
- [ ] 차상위 결재선까지 고려한 정보 밀도가 확보되었는가
- [ ] 보고 내용 일관성(수치·우선순위·용어)이 유지되는가

상세 안티패턴은 `references/anti-patterns.md`를 참조한다.

---

## 사용자 인터랙션

1. **파일 업로드 시**: 파일 분석 결과와 파일 간 연결고리를 먼저 보여주고, 보고서 주제·방향을 확인받는다
2. **주제만 제시 시**: 웹 검색으로 관련 통계·현황 자료를 수집한 뒤 보고서를 작성한다
3. **출력 형식 미지정 시**: "마크다운(미리보기), DOCX(워드), HWPX(한글) 중 어떤 형식으로 출력할까요?" 확인한다
4. **데이터 부족 시**: 부족한 부분을 명시하고 추가 자료 요청 또는 웹 검색으로 보완한다
5. **문체 모드 미지정 시**: 기본은 모드 B 하이브리드(맥락 파악이 쉬움). 사용자가 "개조식으로", "기안용", "공문 형식" 등 명시 요청 시에만 모드 A 순수 개조식 적용

---

## 참고 자료

상세 작성 지침은 다음 파일을 참조한다:

### 작성 가이드
- `references/report-conventions.md`: ⭐ **실무 표기·서식 규칙 (사용자 확정, 최우선)** — 금지 사항(메타 문장·보고개요·기법명·라벨 접두어), 번호체계, 쪽표시·목차 채움·제목 밑줄·표 분리
- `references/environment-notes.md`: ⭐ Claude Code(Windows) 환경 — 경로 치환표, HWPX 불가, 빌더 API 함정(수동 빌드 시 docx require 주의), 2단계 검증 절차
- `references/report-principles.md`: ⭐ 보고서 작성 기본원칙 — 대통령 비서실 「보고서 작성 매뉴얼」(2005, 원본 `references/보고서작성매뉴얼-대통령비서실-2005.pdf`) 요지. 내용·형식 일반원칙, 항목번호 체계, 정책보고서 4대 원칙, 근본원인 Why 3단 분석, 영향분석 3종, **유형별 체크리스트 5종**
- `references/report-structure.md`: 목차별 상세 작성 가이드 (SMART, MUST/WANT, 장애·극복방안, 다층적 기대효과 포함)
- `references/writing-guide.md`: 개조식 문체, 3대 원칙(쉽게·간결·명확), MECE/로직트리, 스토리텔링 6단계
- `references/narrative-style.md`: ⭐ 모드 B 하이브리드 (기본 문체) 작성 가이드 — 모드 A 순수 개조식 전환 기준 포함
- `references/anti-patterns.md`: 보고 안티패턴 — 상사의 신뢰를 잃는 보고 5가지, 작성 안티패턴, 결재자 시각 검증
- `references/examples.md`: 실제 공무원 보고서 예시 모음 (원문 + 구조·문체·논리 분석)

### 출력·도구
- `references/docx-builder-guide.md`: ⭐ DOCX 출력 시 필독 (표준 빌더 사용법, 컴포넌트 API)
- `references/self-disclosure.md`: ⭐ 보완항목 자기보고 가이드 (응답 메시지 작성법)

### 스크립트
- `scripts/report_skeleton.js`: ⭐ 검증된 DOCX 골격 템플릿 — 실행 가능. 테두리 없는 h1·한 페이지 목차·표 분리·쪽표시 반영
- `scripts/validate_docx.py`: ⭐ DOCX 검증 1단계 — 구조 무결성 + **실무 표기 규칙 자동 검사** + `--expect` 내용 누락 확인. 형식 체크리스트를 대체한다
- `scripts/verify_docx_layout.py`: ⭐ DOCX 검증 2단계 — **목차 쪽번호 실측 대조**. Word COM으로 PDF 변환 후 기재 쪽번호와 실제 쪽을 비교(LibreOffice 불필요). 파일 수정 시각 표시로 **빌드 실패·구버전 검증 사고**를 방지. `--fill` 채움 정도, `--page N` 쪽 이미지
- `scripts/docx_builder.js`: ⭐ DOCX 표준 빌더 (Node.js docx 라이브러리 래퍼). 헤딩·개조식·표·강조박스·표지·목차 자동 생성
- `scripts/selftest_validate.js`: 검증기 역검증 — 규칙을 일부러 어긴 DOCX 를 만들어 `validate_docx.py` 가 잡아내는지 확인. 검증기·빌더 수정 시 실행
- `scripts/setup_korean_font.py`: matplotlib 한글 폰트 자동 감지 헬퍼. 차트 생성 시 첫 줄에 호출
- `scripts/analyze_files.py`: 파일 분석 유틸리티
- `scripts/create_charts.py`: 차트 생성 템플릿