cotato-doc-writer

name	cotato-doc-writer
description	COTATO 프로젝트 문서 작성 워크플로우. "문서 만들어줘", "README 써줘" 입력 시 사용. README/설계문서/ADR 구조, Why 중심 서술.
license	MIT
metadata	{"author":"cotato","version":"1.0.0"}

doc-writer 스킬

트리거

다음 요청이 오면 이 스킬을 사용한다:

• "README 써줘", "문서 만들어줘", "설계 문서 작성"
• "이 코드 설명하는 문서 만들어줘"
• "회의록 / 의사결정 기록 정리해줘"

---

핵심 원칙

1. 독자 기준으로 쓴다: 이 문서를 처음 보는 사람이 이해할 수 있어야 한다.
2. What보다 Why를 더 쓴다: 코드를 보면 알 수 있는 것은 문서로 쓰지 않는다.
3. 짧게: 필요한 것만. 긴 문서는 읽히지 않는다.
4. 현재 상태를 반영: 과거 계획이나 미래 희망이 아닌 지금 실제 동작을 기준으로 쓴다.

---

문서 종류별 구조

README.md

# 프로젝트 이름

한 줄 설명.

## 시작하기

(설치 및 실행 명령)

## 사용 방법

(핵심 사용 예시)

## 구조

(중요한 디렉토리/파일만)

## 기여

(기여 방법 또는 PR 규칙)

설계 문서 (design.md)

# 기능명 설계

## 배경과 목적

(왜 이 기능이 필요한가)

## 결정 사항

(무엇을 어떻게 만들 것인가)

## 고려한 대안

(왜 이 방법을 선택했는가)

## 미해결 질문

(아직 결정 안 된 것들)

의사결정 기록 (ADR)

# ADR-001: 결정 제목

날짜: YYYY-MM-DD
상태: 수락됨 / 폐기됨 / 제안됨

## 맥락

(왜 이 결정이 필요했나)

## 결정

(무엇을 결정했나)

## 결과

(이 결정으로 생기는 트레이드오프)

---

워크플로우

1. 대상(코드, 기능, 결정)을 먼저 파악한다
2. 독자가 누구인지 확인한다 (개발자 / 외부 사용자 / 팀 내부)
3. 문서 종류를 결정하고 구조를 잡는다
4. 초안 작성 후 사용자에게 확인
5. 필요하면 실제 코드에서 예시를 가져온다

---

금지

• 존재하지 않는 기능을 있는 것처럼 쓰지 않는다
• 코드를 그대로 복사해서 설명으로 쓰지 않는다
• 마케팅 문구처럼 과장하지 않는다 ("강력한", "혁신적인" 등)