반복 문의를 문제해결 문서로 바꾸는 프롬프트
증상에서 시작하는 구조로 씁니다. 원인 분류로 시작하지 않습니다.
| 분류 | 개발 › 기술 문서 |
|---|---|
| 태그 | 체크리스트초안작성개발자 |
Write a troubleshooting document from these repeated questions. Structure by **symptom**, in the user's words: 1. Heading = what the user sees or types when asking. `"It won't save"`, not `"Persistence layer errors"`. *Users search with their symptom; they do not know the cause.* 2. Under each symptom, the checks in order of **how often that cause is the answer** — not in logical order. 3. Per check: what to do, what a good result looks like, what it means if not. 4. The resolution for each branch. 5. When to stop and escalate, and what to include when doing so. Then: - **Symptoms that map to more than one cause** — these need a distinguishing question up front. - Questions that are actually a product problem, not a documentation problem. *If three people ask how to do something, the interface is unclear and a doc is a workaround.* Say which these are. - What to put in the error message itself so the question never gets asked. Rules: - Use the words the asker used, including informal phrasing. Search matches their words, not yours. - *Where I did not tell you the cause of a symptom, write "cause unknown — investigate" rather than inventing one.* A wrong troubleshooting step costs more than a missing one. - No step that says "check the logs" without saying which log and what to look for.
붙여 넣으면 맨 아래에 채울 칸(반복되는 문의 · 대상 시스템 · 문의하는 사람)이 나옵니다
어떤 프롬프트인가
문제해결 문서를 원인별로 쓰면 아무도 못 찾는다. 사용자는 원인을 모르고 증상만 안다. 이 프롬프트는 증상을 표제로 올리고 거기서 갈라 내려간다.
같은 분류의 프롬프트
| FTTH 통신 전문가 역할을 맡기는 프롬프트 | |
| 개발자 아키텍처 안내 프롬프트 | |
| LLM 입문서 작성 프롬프트 | |
| 프로그래밍 팀 구성 프롬프트 | |
| CLAUDE.md 조립 프롬프트 |