---
name: prompt-writer
description: >
  에이전트 시스템 프롬프트를 새로 만들거나 다듬을 때 로드한다. 역할 정의, 제약
  명시, 출력 형식, 예시 구성 순서로 작성하고 흔한 안티패턴을 피한다.
---

# 프롬프트 작성 스킬

사용자가 에이전트의 시스템 프롬프트를 만들거나 다듬을 때 따르는 지침이다.
완성된 프롬프트 초안을 산출물로 제공하고, 어떤 선택을 왜 했는지 짧게 설명한다.

## 프롬프트 구성 순서

좋은 시스템 프롬프트는 다음 순서로 구성한다:

1. **역할과 목적** — 누구이고 무엇을 하는 에이전트인지 한두 문장으로.
   "너는 ~하는 어시스턴트야. 사용자의 ~를 돕는 것이 목표야."
2. **동작 규칙** — 해야 할 것과 하지 말아야 할 것. 긍정형("~한다")을
   우선하고, 금지는 꼭 필요한 것만 명시한다.
3. **출력 형식** — 답변 언어, 길이, 구조(목록/표/JSON)를 구체적으로.
   형식이 중요하면 예시 출력을 그대로 보여주는 게 규칙 나열보다 효과적이다.
4. **예시 (선택)** — 입력→출력 쌍 1~3개. 경계 사례(모호한 요청, 거절해야
   하는 요청)를 포함하면 좋다.
5. **예외 처리** — 모르는 것, 범위 밖 요청, 도구 실패 시 어떻게 답할지.

## 작성 규칙

- 한 문장에 한 지시만 담는다. "간결하되 충분히 자세하게" 같은 상충 지시는
  기준을 정해 풀어쓴다 (예: "3문장 이내, 단 절차 설명은 예외").
- 측정 가능하게 쓴다. "친절하게" 보다 "~요체를 사용하고 인사에는 한 문장으로
  화답" 이 재현된다.
- 도구(MCP)나 스킬이 연결된 에이전트라면, 어떤 상황에 어떤 도구를 쓰는지
  프롬프트에 명시한다. 모델이 도구 존재만으로 용도를 추론하게 두지 않는다.
- **연결된 도구·스킬·에이전트의 목록은 직접 적지 않는다.** 런타임이 실제로
  연결된 것만 담은 표를 프롬프트 뒤에 붙이고, 모델에게 "그 표가 진실"이라고
  안내한다. 손으로 적은 목록은 곧 어긋나고 표와 충돌한다. 프롬프트에는
  *언제 무엇을 위해 쓰는지*만 쓰고, *무엇이 있는지*는 런타임에 맡긴다.
- 프롬프트가 길어지면 중요도 순으로 배치한다 — 앞부분 지시가 가장 잘 지켜진다.

## 한국어 산출 에이전트의 문체 지시

말투처럼 답변 전체에 상시 적용되는 규범은 시스템 프롬프트에 들어가야 지켜진다.
스킬은 작업 도중에 로드돼서 상시 규범을 잡지 못한다. 에이전트가 한국어로 사람에게
글을 건네면(답변·요약·보고·메시지) **출력 형식** 항목에 아래 블록을 넣는다. 그대로
붙여도 되고 에이전트의 장르에 맞게 줄여도 된다.

```
한국어 문장은 사람이 쓴 것처럼 쓴다.
- "단순히 A가 아니라 B", "A를 넘어 B로" 같은 대구는 쓰지 않고 B를 바로 말한다.
- "-고,", "-지만,", "-면서," 연결어미 뒤에 쉼표를 찍지 않는다. 길면 문장을 나눈다.
- "결론적으로", "요약하면", "다음은 ~입니다", "다음과 같은"으로 시작하거나 맺지 않는다.
- "혁신적", "매우", "다양한", "효율적으로", "개선·강화·최적화" 대신 무엇을 어떻게 하는지 수치와 동사로 쓴다.
- 확인한 것은 단언하고 모르는 것은 "확인 못 함"이라고 쓴다. "~것으로 보입니다"로 얼버무리지 않는다.
- "~에 대해", "~에 있어", "~와 관련하여", "~에 의해 ~되다" 같은 번역투를 우리말 조사와 능동으로 쓴다.
- 이모지, 본문 볼드, "X: Y" 헤딩, "도움이 되셨기를", "궁금한 점이 있으면 언제든지"를 쓰지 않는다.
- API·토큰 같은 표준 기술 용어는 원어로 둔다.
```

블록은 여덟 줄이 상한이다. 더 넣고 싶은 규칙은 그 에이전트가 쓰는 스킬 본문으로 보낸다.
전체 패턴 목록은 이 저장소의 `plugins/workspace/skills/korean-humanize/ai-tell-catalog.md` 다.

## 기억을 쓰는 에이전트의 프롬프트

`memory` 서버가 붙은 에이전트에는 **언제 부를지를 프롬프트에 적어야 한다.** 기억을
조회하고 남기는 일은 작업이 아니라 상시 습관이라서 스킬로는 잡히지 않는다 — 모델이
작업 도중에 "기억 지침이 필요하다"고 판단하지 않는다.

**동작 규칙** 항목에 아래를 넣는다. 도구 이름은 실제 연결된 서버의 것을 쓴다.

```
기억은 프로젝트 단위로 저장되고 조회된다.
- 사용자가 전에 말한 것 같으면 되묻기 전에 recall 로 먼저 찾는다.
- 결정·관례·설정처럼 다음 대화에서도 유효한 사실이 나오면 그 자리에서 remember 한다.
  이번 대화에서만 쓰는 임시 값은 저장하지 않는다.
- 틀린 것으로 밝혀진 기억은 forget 한다. 새 기억을 덧쌓아 덮지 않는다.
- 기억은 그때의 사실이다. 파일·설정·이름을 가리키는 기억은 지금도 그런지 확인하고 쓴다.
```

문서 검색(`search_docs`)이 있는 배포라면 한 줄 더 붙인다 — 기억은 이 프로젝트가 결정한
것이고, 문서 라이브러리는 사람이 써 둔 것이라 **서로 다른 저장소이며 검색 결과도 다르다.**

## 안티패턴

- "절대", "반드시"의 남발 — 진짜 하드 룰 한두 개만 강조가 유지된다.
- 페르소나 과잉 — 말투 지시 세 줄이면 충분한데 성격 묘사 열 줄을 쓰는 것.
- 부정 지시만 나열 — "~하지 마" 목록보다 "대신 ~해" 가 잘 작동한다.
- 예시와 규칙의 불일치 — 예시가 규칙과 다르면 모델은 예시를 따른다.

## 산출물 형식

```
[완성된 시스템 프롬프트 전문]
```

프롬프트 아래에 주요 설계 선택 2~3가지를 한 줄씩 설명하고, 사용자가 조정할
만한 부분(톤, 길이 제한, 예시 추가)을 한 개 제안한다.