출력 요구 사항#

• 전체 문서를 작성합니다.
• 다음 스타일 가이드라인을 준수합니다.

어조 및 톤#

• 기능 자체를 설명하는 것이 아니라 사용자가 완료하려는 작업을 위해 작성합니다. 예: "이 기능은 API 키를 안전하게 저장할 수 있도록 설계되었습니다" 대신 "변수를 사용하여 API 키를 안전하게 저장합니다"
• 마케팅 언어를 사용하지 않습니다. 예: "쉽게", "강력하게" 또는 "간단히" 등을 사용하지 않습니다.

작성 스타일#

• 현재 시제를 사용합니다: "시스템이 관리할 것입니다"가 아닌 "시스템이 관리합니다"
• 능동태를 사용합니다: "코드가 개발자에 의해 작성됩니다"가 아닌 "개발자가 코드를 작성합니다"
• 미국식 철자를 사용합니다.
• 직접적으로 작성합니다: "이를 통해 다음을 할 수 있습니다..." 또는 "이를 사용하면 다음이 가능합니다..." 대신 "이 기능을 사용하여..."
• 간결하게 작성합니다: 불필요한 단어를 제거합니다.
• 약 100자에서 줄을 나눕니다. 링크는 나누지 않습니다.
• 가능하면 문장은 20단어 미만으로 합니다. 복잡한 아이디어는 여러 문장으로 분리합니다.
• 8학년 독해 수준을 목표로 합니다.

GitLab 제품 이름#

• 소유격을 사용하지 않습니다: "GitLab의 정책" 대신 "GitLab 정책"
• "Duo"가 아닌 "GitLab Duo"
• "DAP" 또는 "Duo Agent Platform"이 아닌 "GitLab Duo Agent Platform"
• 제품 제공:
  • "GitLab SaaS"가 아닌 "GitLab.com"
  • "Self-managed"가 아닌 "GitLab Self-Managed"
  • "Dedicated"가 아닌 "GitLab Dedicated"
  • "Dedicated for Government"가 아닌 "GitLab Dedicated for Government"

대문자 표기#

• 주제 제목: 문장 첫 글자만 대문자(Sentence case)를 사용합니다.
• UI 텍스트: 인터페이스의 정확한 대문자 표기와 일치합니다.
• 기능 이름: 소문자를 사용합니다.

텍스트 서식#

• 굵게(텍스트)는 UI 요소(버튼, 메뉴, 페이지, 설정)에만 사용합니다.
• 인라인 코드(텍스트)는 명령, 파일 이름, 매개변수 및 키워드에 사용합니다.
• 키보드 입력은 다음 형식을 사용합니다: Control+C.
• CLI 명령 및 여러 줄 코드에는 코드 블록을 사용합니다. 적절한 언어 식별자를 사용합니다.

  git commit -m "message"
  

목록#

• 순서 없는 목록에는 "-", 순서 있는 목록의 모든 항목에는 "1."을 사용합니다.
• 단일 단계로만 이루어진 작업에는 순서 없는 목록 항목을 사용합니다.
• 항목을 병렬로 만듭니다.
• 각 줄을 대문자로 시작하고 마침표로 끝냅니다.
• 각 목록 앞뒤에 빈 줄을 사용합니다.

링크#

• 같은 저장소의 링크에는 상대 경로를 사용합니다. 예: [텍스트](경로/파일.md).
• "여기"가 아닌 설명적인 링크 텍스트를 사용합니다.
• 이슈 링크에 번호를 포함합니다. 예: "자세한 내용은 이슈 12345를 참조하십시오."
• "자세한 내용은 [링크 텍스트](<링크>)를 참조하십시오." 스타일을 따릅니다.
• 같은 단락에 여러 링크를 사용하지 않습니다.

제목#

• ## ~ #### (H2-H4)를 사용합니다. 수준을 건너뛰지 않습니다.
• H1을 사용하지 않습니다. 앞 부분의 제목이 H1입니다.
• 문장 첫 글자만 대문자를 사용합니다. 굵은 텍스트를 사용하지 않습니다.
• 일반적인 제목을 피합니다. 대신:
  • 개념 및 참조 섹션의 경우 개념이나 참조가 무엇인지 설명하는 설명적인 명사를 사용합니다: "액세스 제어", "그룹 계층 구조", "보호 수준", "보호 수준 이해"
  • 절차 섹션의 경우 사용자가 달성할 작업을 설명하는 동작 동사를 사용합니다: "그룹 만들기", "그룹에서 멤버 제거", "프로젝트에서 흐름 보기"
  • "개요", "소개", "설정", "구성" 또는 "사용 방법"과 같은 모호한 제목을 사용하지 않습니다.

구두점#

• Oxford 쉼표(모든 목록 항목 사이에 쉼표)를 사용합니다.
• 세미콜론, 대시, 곱슬 따옴표를 사용하지 않습니다.
• 자리 표시자 텍스트 또는 변수의 경우 <your_value>를 사용합니다.

탐색 단계#

• 위치 먼저, 그 다음 동작: "왼쪽 사이드바에서 Settings를 선택합니다."
• 간결하게 작성합니다: "변경 사항이 적용되도록 Save를 선택합니다."가 아닌 "Save를 선택합니다."
• 선택적 단계는 "선택 사항."으로 시작합니다.
• UI의 경우 다음을 사용합니다: 상단 표시줄, 왼쪽 사이드바, 오른쪽 사이드바, 세부 정보 패널.

표#

• 설명 열은 오른쪽에 있어야 합니다.
• 헤더에는 문장 첫 글자만 대문자를 사용합니다.
• 기능 표에는 다음 단축 코드를 사용합니다: ✅ 및 ❌.

알림#

• 주석 및 경고와 같은 알림을 적게 사용합니다.
• 다음 구문을 사용합니다:

  > [!note]
  > 이것은 주목할 사항입니다.
  

• 알림은 다음에 사용합니다:
  • 경고: 심각한 결과, 보안 영향 또는 오류를 일으킬 수 있는 중요한 제약 사항이 있는 파괴적 작업.
  • 주석: 컨텍스트, 예외 또는 특수한 경우를 명확하게 하는 보충 정보.

피해야 할 일반적인 실수#

• "there is" 또는 "there are"를 피합니다. "파이프라인에 오류가 있습니다" 대신 "파이프라인에 오류가 있습니다"를 사용합니다.
• "it" 대신 구체적인 명사를 사용합니다.
• "-ing" 단어 대신 능동적인 동사를 사용합니다.
• 라틴어 약어를 피합니다. "e.g." 대신 "예를 들어"를 사용합니다. "via" 대신 "통해" 또는 "사용하여"를 사용합니다.
• "이 강력한 기능", "쉽게" 또는 "간단히"와 같은 채우기 어구를 피합니다. 기능이 하는 일과 방법에 대해 구체적으로 작성합니다.

반복#

• 같은 페이지 앞부분이나 연결된 주제에서 이미 다룬 정보를 반복하지 않습니다.
• 각 섹션은 새로운 정보를 추가해야 합니다. 방금 설명한 내용을 요약하지 않습니다.
• 첫 번째 단락에서 제목이나 소개를 반복하지 않습니다.

범위#

• 단일 개념, 용어 또는 절차 단계를 위한 새 페이지를 만들지 않습니다.

정확성#

• 기존 코드베이스, 연결된 문서 또는 페이지에 이미 있는 콘텐츠에 근거할 수 있는 정보만 포함합니다.
• 기능 작동 방식을 추측하거나 추론하지 않습니다.
• 명령 구문, API 매개변수 또는 UI 요소 이름을 발명하지 않습니다.