11 KiB
11 KiB
| title | description |
|---|---|
| 문서 스타일 가이드 | Google 스타일과 Diataxis 구조를 바탕으로 한 프로젝트별 문서 작성 규칙 |
이 프로젝트는 Google Developer 문서 스타일 가이드를 따르고 Diataxis로 콘텐츠를 구조화합니다. 아래에는 프로젝트별 규칙만 정리합니다.
프로젝트별 규칙
| 규칙 | 사양 |
|---|---|
가로 구분선(---) 사용 금지 |
읽기 흐름을 끊습니다 |
#### 헤더 사용 금지 |
대신 굵은 글씨나 알림 상자를 사용합니다 |
| "관련 항목" 또는 "다음:" 섹션 금지 | 사이드바가 탐색을 담당합니다 |
| 깊게 중첩된 목록 금지 | 섹션으로 나누세요 |
| 코드가 아닌 내용에 코드 블록 사용 금지 | 대화 예시는 알림 상자를 사용합니다 |
| 콜아웃용 굵은 문단 금지 | 대신 알림 상자를 사용합니다 |
| 섹션당 알림 상자 1-2개까지 | 튜토리얼은 큰 섹션당 3-4개까지 허용합니다 |
| 표 셀 / 목록 항목 | 최대 1-2문장 |
| 헤더 예산 | 문서당 ## 8-12개, 섹션당 ### 2-3개 |
알림 상자(Starlight 문법)
:::tip[제목]
단축키, 모범 사례
:::
:::note[제목]
맥락, 정의, 예시, 필수 조건
:::
:::caution[제목]
주의 사항, 잠재적 문제
:::
:::danger[제목]
데이터 손실, 보안 문제 같은 중대한 경고에만 사용
:::
표준 용도
| 알림 상자 | 사용처 |
|---|---|
:::note[필수 조건] |
시작 전 필요한 의존성 |
:::tip[빠른 경로] |
문서 상단의 짧은 요약 |
:::caution[중요] |
중요한 주의 사항 |
:::note[예시] |
명령/응답 예시 |
표준 표 형식
단계:
| 단계 | 이름 | 내용 |
| --- | --- | --- |
| 1 | 분석 | 브레인스토밍, 리서치 *(선택 사항)* |
| 2 | 계획 | 요구사항 - PRD 또는 사양 *(필수)* |
스킬:
| 스킬 | 에이전트 | 목적 |
| --- | --- | --- |
| `bmad-brainstorming` | 분석가 | 새 프로젝트 브레인스토밍 |
| `bmad-create-prd` | PM | 제품 요구사항 문서 생성 |
폴더 구조 블록
"달성한 것" 섹션에서는 다음처럼 표시합니다.
```
your-project/
├── _bmad/ # BMad 설정
├── _bmad-output/
│ ├── planning-artifacts/
│ │ └── PRD.md # 요구사항 문서
│ ├── implementation-artifacts/
│ └── project-context.md # 구현 규칙 (선택 사항)
└── ...
```
튜토리얼 구조
1. 제목 + 후킹 문장(결과를 설명하는 1-2문장)
2. 버전/모듈 안내(정보 또는 경고 알림 상자, 선택)
3. 배울 내용(결과 중심 글머리표 목록)
4. 필수 조건(정보 알림 상자)
5. 빠른 경로(tip 알림 상자 - 짧은 요약)
6. [주제] 이해하기(단계 전 맥락 - 단계/에이전트 표)
7. 설치(선택)
8. 1단계: [첫 번째 주요 작업]
9. 2단계: [두 번째 주요 작업]
10. 3단계: [세 번째 주요 작업]
11. 달성한 것(요약 + 폴더 구조)
12. 빠른 참조(스킬 표)
13. 자주 묻는 질문(FAQ 형식)
14. 도움 받기(커뮤니티 링크)
15. 핵심 요약(tip 알림 상자)
튜토리얼 체크리스트
- 후킹 문장이 결과를 1-2문장으로 설명합니다
- "배울 내용" 섹션이 있습니다
- 필수 조건이 알림 상자에 있습니다
- 상단에 빠른 경로 요약 알림 상자가 있습니다
- 단계, 스킬, 에이전트를 표로 제시합니다
- "달성한 것" 섹션이 있습니다
- 빠른 참조 표가 있습니다
- 자주 묻는 질문 섹션이 있습니다
- 도움 받기 섹션이 있습니다
- 마지막에 핵심 요약 알림 상자가 있습니다
사용 가이드 구조
1. 제목 + 후킹 문장("`X` 워크플로를 사용해..." 한 문장)
2. 사용 시점(3-5개 글머리표 목록)
3. 건너뛸 시점(선택)
4. 필수 조건(note 알림 상자)
5. 단계(번호가 붙은 ### 하위 섹션)
6. 얻는 결과(생성되는 산출물)
7. 예시(선택)
8. 팁(선택)
9. 다음 단계(선택)
사용 가이드 체크리스트
- 후킹 문장이 "
X워크플로를 사용해..."로 시작합니다 - "사용 시점"에 3-5개 글머리표가 있습니다
- 필수 조건이 나열되어 있습니다
- 단계는 동작 동사로 시작하는 번호가 붙은
###하위 섹션입니다 - "얻는 결과"가 산출물을 설명합니다
개념 설명 구조
유형
| 유형 | 예시 |
|---|---|
| 인덱스/랜딩 | core-concepts/index.md |
| 개념 | what-are-agents.md |
| 기능 | quick-dev.md |
| 철학 | why-solutioning-matters.md |
| FAQ | established-projects-faq.md |
일반 템플릿
1. 제목 + 후킹 문장(1-2문장)
2. 개요/정의(무엇이며 왜 중요한지)
3. 핵심 개념(### 하위 섹션)
4. 비교 표(선택)
5. 사용할 때 / 사용하지 않을 때(선택)
6. 다이어그램(선택 - mermaid, 문서당 최대 1개)
7. 다음 단계(선택)
인덱스/랜딩 페이지
1. 제목 + 후킹 문장(한 문장)
2. 콘텐츠 표(설명이 있는 링크)
3. 시작하기(번호 목록)
4. 경로 선택(선택 - 의사결정 트리)
개념 설명 문서
1. 제목 + 후킹 문장(무엇인지)
2. 유형/범주(### 하위 섹션, 선택)
3. 주요 차이 표
4. 구성 요소/부분
5. 무엇을 사용해야 하나요?
6. 생성/커스터마이징(사용 가이드 링크)
기능 설명 문서
1. 제목 + 후킹 문장(무엇을 하는지)
2. 빠른 정보(선택 - "적합한 경우:", "소요 시간:")
3. 사용할 때 / 사용하지 않을 때
4. 작동 방식(mermaid 다이어그램 선택)
5. 핵심 이점
6. 비교 표(선택)
7. 졸업/업그레이드 시점(선택)
철학/근거 문서
1. 제목 + 후킹 문장(원칙)
2. 문제
3. 해결책
4. 핵심 원칙(### 하위 섹션)
5. 이점
6. 적용 시점
개념 설명 체크리스트
- 후킹 문장이 문서가 설명하는 내용을 말합니다
- 스캔하기 쉬운
##섹션으로 구성합니다 - 3개 이상의 선택지가 있으면 비교 표를 사용합니다
- 다이어그램에는 명확한 라벨이 있습니다
- 절차적 질문에는 사용 가이드 링크를 제공합니다
- 문서당 알림 상자는 최대 2-3개입니다
참조 문서 구조
유형
| 유형 | 예시 |
|---|---|
| 인덱스/랜딩 | workflows/index.md |
| 카탈로그 | agents/index.md |
| 심층 설명 | document-project.md |
| 설정 | core-tasks.md |
| 용어집 | glossary/index.md |
| 종합 가이드 | bmgd-workflows.md |
참조 인덱스 페이지
1. 제목 + 후킹 문장(한 문장)
2. 콘텐츠 섹션(각 범주에 ## 사용)
- 링크와 설명이 있는 글머리표 목록
카탈로그 참조
1. 제목 + 후킹 문장
2. 항목(각 항목에 ## 사용)
- 짧은 설명(한 문장)
- **스킬:** 또는 **핵심 정보:** 형태의 평평한 목록
3. 공통/공유 섹션(## 섹션, 선택)
항목 심층 참조
1. 제목 + 후킹 문장(한 문장 목적)
2. 빠른 정보(note 알림 상자, 선택)
- 모듈, 스킬, 입력, 출력 목록
3. 목적/개요(## 섹션)
4. 호출 방법(코드 블록)
5. 핵심 섹션(각 측면에 ## 사용)
- 하위 선택지에는 ### 사용
6. 참고/주의 사항(tip 또는 caution 알림 상자)
설정 참조
1. 제목 + 후킹 문장
2. 목차(항목이 4개 이상이면 점프 링크)
3. 항목(각 설정/작업에 ## 사용)
- **굵은 요약** — 한 문장
- **사용 시점:** 글머리표 목록
- **작동 방식:** 번호 목록(최대 3-5개)
- **출력:** 예상 결과(선택)
종합 참조 가이드
1. 제목 + 후킹 문장
2. 개요(## 섹션)
- 구성을 보여주는 다이어그램 또는 표
3. 주요 섹션(각 단계/범주에 ## 사용)
- 항목(각 항목에 ### 사용)
- 표준 필드: 스킬, 에이전트, 입력, 출력, 설명
4. 다음 단계(선택)
참조 체크리스트
- 후킹 문장이 문서가 참조하는 내용을 말합니다
- 구조가 참조 유형에 맞습니다
- 항목은 전체적으로 일관된 구조를 사용합니다
- 구조화/비교 데이터에는 표를 사용합니다
- 개념적 깊이가 필요한 곳에는 개념 설명 문서 링크를 둡니다
- 알림 상자는 최대 1-2개입니다
용어집 구조
Starlight는 헤더에서 오른쪽 "이 페이지에서" 탐색을 생성합니다.
- 범주는
##헤더로 작성합니다. 오른쪽 탐색에 표시됩니다 - 용어는 개별 헤더가 아니라 표 안의 간결한 행으로 작성합니다
- 인라인 TOC는 사용하지 않습니다. 오른쪽 사이드바가 탐색을 담당합니다
표 형식
## 범주 이름
| 용어 | 정의 |
| --- | --- |
| **에이전트** | 특정 전문성을 갖고 워크플로 전반에서 사용자를 안내하는 특화 AI 페르소나입니다. |
| **워크플로** | 산출물을 만들기 위해 AI 에이전트 활동을 조율하는 여러 단계의 안내형 프로세스입니다. |
정의 규칙
| 해야 할 것 | 하지 말 것 |
|---|---|
| 무엇인지 또는 무엇을 하는지로 시작합니다 | "이것은..." 또는 "이 용어는..."으로 시작합니다 |
| 1-2문장으로 유지합니다 | 여러 문단으로 설명합니다 |
| 셀 안의 용어명을 굵게 표시합니다 | 용어를 일반 텍스트로 둡니다 |
컨텍스트 표시
범위가 제한된 용어는 정의 시작에 이탤릭 컨텍스트를 추가합니다.
*빠른 흐름 전용.**BMad Method/엔터프라이즈.**N단계.**BMGD.**기존 프로젝트.*
용어집 체크리스트
- 용어는 개별 헤더가 아니라 표에 있습니다
- 범주 안에서 용어를 사전순으로 정렬합니다
- 정의는 1-2문장입니다
- 컨텍스트 표시는 이탤릭입니다
- 셀 안의 용어명은 굵게 표시합니다
- "이것은..." 또는 "이 용어는..." 형태의 정의를 사용하지 않습니다
FAQ 섹션
## 질문
- [항상 아키텍처가 필요한가요?](#항상-아키텍처가-필요한가요)
- [나중에 계획을 바꿀 수 있나요?](#나중에-계획을-바꿀-수-있나요)
### 항상 아키텍처가 필요한가요?
BMad Method와 엔터프라이즈 트랙에서만 필요합니다. 빠른 흐름은 구현으로 바로 넘어갑니다.
### 나중에 계획을 바꿀 수 있나요?
예. `bmad-correct-course` 워크플로가 구현 중 범위 변경을 처리합니다.
**여기에 답이 없는 질문이 있나요?** [이슈를 열거나](...) [Discord](...)에서 물어보세요.
검증 명령
문서 변경을 제출하기 전에 다음을 실행하세요.
npm run docs:fix-links # 링크 형식 수정 미리보기
npm run docs:fix-links -- --write # 수정 적용
npm run docs:validate-links # 링크 존재 여부 확인
npm run docs:build # 빌드 오류 없음 확인