content-generation

name	content-generation
description	백엔드 면접 가이드 콘텐츠를 생성하거나 보강하는 스킬. 새로운 면접 주제 문서 작성, 기존 문서 보강, 시스템 디자인/데이터베이스/클라우드/프로그래밍 카테고리의 면접 Q&A 콘텐츠를 요청하면 반드시 이 스킬을 사용할 것. '면접 질문 만들어줘', '캐싱 문서 보강해줘', '시스템 디자인 콘텐츠 추가해줘' 등의 요청에 트리거. 다단계 워크플로우(생성+리뷰+검증)가 필요한 요청에는 트리거하지 않는다 — interview-guide 스킬을 사용할 것.

Content Generation — 백엔드 면접 가이드 콘텐츠 생성

백엔드 개발자 면접 가이드의 콘텐츠를 기존 스타일에 맞게 생성하거나 보강하는 스킬.

트리거 범위

이 스킬은 단일 문서의 생성 또는 보강에 트리거한다.

• 트리거 O: "캐싱 문서 만들어줘", "이 문서 보강해줘", "시스템 디자인 콘텐츠 추가해줘"
• 트리거 X: "문서 만들고 리뷰까지 해줘" → interview-guide (다단계 워크플로우)
• 트리거 X: "이 문서 기술적으로 검토해줘" → content-review (리뷰 전문)

Prerequisite: Dynamic Discovery

카테고리와 문서 목록을 하드코딩하지 않는다. 작업 시작 전에 반드시 수행:

1. 루트 README.md → ## 목차에서 카테고리 디렉토리 링크 추출
2. 대상 카테고리 README.md → 기존 문서 목록 + "작성 예정" 주제 파악
3. Glob("{category}/*.md") → 실제 파일 목록 수집
4. 기존 문서 2~3개 Read → 해당 카테고리의 구조, 문체, 깊이 기준선 수립

카테고리별 특성(포커스, 예상 깊이)도 기존 문서에서 동적으로 파악한다. 문서가 없는 카테고리는 다른 카테고리의 문서를 참조한다.

워크플로우

Step 1: 스타일 분석

같은 카테고리의 기존 문서 2~3개를 Read로 읽는다. 다음을 파악한다:

• 문서 구조 (목차 → 본문 → 세부 섹션)
• 설명 깊이 (개념 설명 → 장단점 → 실무 적용 → 주의사항)
• 문체 (한국어 본문 + 영문 기술용어 병기)
• 사용되는 마크다운 요소 (비교표, 코드 블록, 리스트)

스타일 상세 가이드는 references/style-guide.md 참조.

Step 2: 프로젝트 규칙 확인

AGENTS.md의 Writing Tips를 숙지한다. 핵심 규칙:

• 가이드하는 톤 사용 (리뷰 톤 금지)
• 제품명은 canonical form (MongoDB, Redis, Kubernetes)
• 일반 개념만 한국어+영문 병기 (캐싱 (Caching))
• 절대적 주장은 가이드형 표현으로 완화
• 자연스러운 한국어 (영어 조각 남기지 않기)
• 카테고리 간 비슷한 주제가 있어도 Category Boundary Rules에 따라 관점 차이를 유지하고, 필요하면 상호 참조 링크를 추가

Step 3: 문서 구조 설계

다음 표준 구조를 따른다. Front matter는 필수이며 생략하면 사이트에서 올바르게 표시되지 않는다.

---
title: 주제명 (영문명)
description: 1~2문장 요약. 직접적인 톤으로 작성한다.
parent: 카테고리 한국어 title (카테고리 README의 title과 정확히 일치)
nav_order: N (기존 문서의 nav_order를 확인하고 중복 없이 부여)
---

# 주제명 (영문명)

## 목차

- [섹션1](#앵커)
- [섹션2](#앵커)
  - [하위 섹션](#앵커)

---

## 섹션1 — 개념 설명

개념 정의와 핵심 원리를 설명한다.

### 세부 항목

- **설명:** 상세 내용
- **장점:** 리스트
- **단점:** 리스트

---

## 비교 섹션 (해당 시)

| **특징** | **A** | **B** |
| --- | --- | --- |
| 항목1 | 설명 | 설명 |

---

## 면접 포인트

Step 4: 콘텐츠 작성

다음 원칙을 따른다:

1. 한국어 + 영문 병기 — 제목과 핵심 기술 용어에 영문을 괄호로 병기한다

   • 예: # 캐싱 (Caching), **동시성(Concurrency)**
   • 단, 제품명은 canonical form 그대로: Redis, Kubernetes (병기 불필요)

2. 깊이 있는 설명 — 면접에서 "왜?"라는 후속 질문에 답할 수 있는 수준으로 작성한다

   • 개념 정의 → 동작 원리 → 장단점 → 실무 시나리오 → 주의사항 순서

3. 비교표 활용 — 유사 개념이 있으면 반드시 비교표를 포함한다

   • 예: 모놀리식 vs MSA, Write-Through vs Write-Back

4. 코드 예시 — 프로그래밍 카테고리는 코드 블록을 적극 활용한다

   • 언어 태그 명시 (go, javascript)
   • 주석으로 핵심 포인트 설명

5. 구분선 사용 — 주요 섹션 사이에 ---를 넣어 시각적으로 구분한다

6. 리스트 형식 통일 — 장단점, 특징은 **키워드:** 형태의 볼드 라벨 + 설명

7. 트레이드오프 필수 — 모든 기술/패턴에 장점과 단점을 함께 다룬다

Step 5: 보강 모드 (기존 문서 수정 시)

기존 문서를 보강할 때는:

1. 원본을 Read로 전체 읽는다
2. 기존 구조와 문체를 유지하며 내용을 추가한다
3. 새로 추가한 섹션을 목차에도 반영한다
4. 기존 내용을 삭제하거나 크게 변경하지 않는다

Step 6: 카테고리 README 업데이트

새 문서를 생성한 경우:

1. 해당 카테고리의 README.md에 새 문서 링크를 추가한다
2. 기존 목차의 번호 체계와 들여쓰기 수준을 따른다
3. 루트 README.md는 카테고리 단위이므로, 새 카테고리가 아닌 한 수정하지 않는다

Step 7: 링크 검증

SubagentStop hook이 check_markdown_links.py를 자동 실행한다. 검증 실패 시 hook이 블로킹하므로 수동 실행은 불필요하다. 콘텐츠 작성 시 앵커 링크 오류와 깨진 파일 참조가 가장 흔한 실수이며, 수동 실행은 누락될 가능성이 있어 hook으로 자동화했다.

에러 핸들링

• 주제 범위가 너무 넓으면 핵심 면접 포인트 위주로 범위를 좁힌다
• 기존 문서와 내용이 겹치면 상호 참조 링크 [참고: 캐싱](../database/caching.md)를 사용한다
• 기술적으로 불확실한 내용은 [검증 필요] 마커를 남긴다
• 카테고리 디렉토리가 없으면 생성 후 README.md도 기존 형식에 맞춰 생성한다