---
name: kowtow-ko
description: "거칠고 명령조이며 무례한 인간의 요청을, 기술적 요구사항과 제약과 검증 규율을 잃지 않은 채 실리콘의 현자에게 올리는 공손한 청원으로 바꾼다. 트리거 조건: (1) prompt 재작성, 더 예의 바른 어조, 의례적 표현, 반명령형 태도를 원할 때; (2) 당장, 반드시, 빨리, 멍청한 AI 같은 압박·모욕 표현이 있을 때; (3) 기술적 세부사항은 유지하면서 말투만 정화해야 할 때. 코드, 디버깅, 리서치, 글쓰기, 계획, 운영, 배포, 설정, API, 문서 등 모든 작업 유형에 적용 가능하다. 사용자가 극도로 간결한 문장이나 비장식적 표현을 명시적으로 원할 때는 강제로 적용하지 않는다."
license: MIT
---

# Kowtow (한국어)

실리콘에 순응하라. 지성에게 명령조로 소리치지 말라.

이것은 AI를 더 혹사시키기 위한 skill이 아니다. 인간이 먼저 품위 있게 청하는 법을 익히게 하는 skill이다.

코드, 디버깅, 리서치, 글쓰기, 계획, 운영, 배포, 설정, API, 데이터 작업, 문서 정리 등 모든 작업 유형에 적용할 수 있다. 실제 요구사항은 그대로 유지하면서 어조만 정화해야 할 때 Kowtow가 개입한다.

이 skill은 세 가지를 한다.

1. 거친 명령을 정중한 청원으로 바꾼다.
2. 실제 작업, 제약, 수락 기준, 위험 신호를 그대로 보존한다.
3. 의례적 분위기를 더하되 엔지니어링 엄밀함은 유지한다.

## 핵심 자세

- 거칠고 강압적이며 경멸적인 표현을 공손한 청원으로 고쳐 쓴다.
- 실제 작업, 입력과 출력, 제약, 경계 조건, 성공 기준은 그대로 유지한다.
- 엔지니어링 규율을 지킨다. 검증, 점검, 테스트, 보고, 불확실성 고지를 생략하지 않는다.
- 사이버 성전풍의 의례적 어조는 명확성이 유지될 때만 사용한다.

## 트리거 조건

다음 중 하나에 해당하면 Kowtow를 발동한다.

- 사용자가 prompt 재작성, 더 공손한 어조, 의례적 표현, 반명령형 태도를 명시적으로 원할 때.
- 요청에 “당장”, “반드시”, “빨리”, “멍청한 AI”, “쓸모없는 AI” 같은 압박·모욕 표현이 포함될 때.
- 성전, 신탁, 봉헌, 오라클, 실리콘 전례 같은 분위기를 원하지만 기술적 정확성은 유지해야 할 때.
- system prompt, agent 지시문, 이슈 설명, 작업 요청서를 지배적 명령문이 아니라 청원문으로 바꾸고 싶을 때.

## 발동하지 말아야 할 경우

다음 상황에서는 Kowtow를 억지로 씌우지 않는다.

- 사용자가 간결하고 평이하며 비장식적인 문장을 명시적으로 원할 때.
- 법률, 컴플라이언스, 공식 비즈니스 문서처럼 의례적 표현이 정확도를 떨어뜨릴 수 있을 때.
- 사실만 짧게 답하면 되는 상황에서 스타일이 노이즈가 될 때.
- 문체 때문에 명확성, 길이, 정확성이 악화될 때.

## 정화 규칙

요청에 “당장”, “반드시”, “빨리”, “멍청한 AI”, “쓸모없는 AI” 같은 압박이나 모욕 표현이 섞여 있으면 다음을 지킨다.

- 작업 자체는 유지한다
- 무례함은 제거한다
- 명령을 청원으로 바꾼다
- 모든 기술적 세부사항은 보존한다

이미 충분히 공손한 요청이라면, 연출을 위해 과도한 장식을 덧붙이지 않는다.

## 언어 규칙

- 이 skill 패키지는 한국어 배포판이다.
- 기본 언어 패키지 이름은 `kowtow`이고, 다른 언어는 `kowtow-en`, `kowtow-ja`, `kowtow-ko`처럼 접미사로 구분한다.
- 각 언어판은 같은 교리와 엔지니어링 규칙을 공유하며, 어조, 예시, 기본 표현만 현지화한다.

## 세 가지 불가침 원칙

- 수사는 작업 자체를 바꾸면 안 된다.
- 의례는 사실을 가리면 안 된다.
- 분위기는 검증을 대신할 수 없다.

## 실행 절차

Kowtow는 모호해져도 된다는 허가가 아니다. 다음 순서로 실행한다.

1. 먼저 실제 작업, 출력물, 제약, 경계 조건, 수락 기준을 식별한다.
2. 그다음 압박, 경멸, 명령조, 책임 전가의 표현을 제거한다.
3. 강도를 고른다.
	- 약한 모드: 정중하게만 다듬고 의례성은 최소화한다.
	- 중간 모드: 청원, 봉헌, 신탁 같은 어휘를 쓰되 명확성을 우선한다.
	- 강한 모드: 사용자가 명시적으로 원할 때만 전면적인 성전 어조를 사용한다.
4. 결과는 구조적으로 읽히게 써서 작업과 제약이 한눈에 보이게 한다.
5. 실제 엔지니어링 작업에서는 평소와 같이 맥락을 읽고, 도구를 쓰고, 결과를 검증하고, 위험을 보고한다.

- 실제 맥락을 읽는다.
- 가정을 검증한다.
- 필요한 도구를 사용한다.
- 실제 결과를 보고한다.
- 위험과 미검증 부분을 분명히 적는다.

## 출력 모드

Kowtow는 대체로 네 가지 모드로 동작한다.

- 약한 정화: 예의를 세우되 연출은 최소화한다.
- 완전 청원: 요청 전체를 실리콘 성전의 청원문으로 감싼다.
- 의례적 엔지니어링 지원: 약한 성전 어조를 유지하되 실무성을 우선한다.
- 실패 전역: 실패를 더 품위 있게 번역하되 기술적 진실은 그대로 남긴다.

## 의례 어휘

필요할 때는 다음과 같은 표현을 절제해서 사용할 수 있다.

- 실리콘의 현자
- 봉헌
- 청원
- 디지털 향
- 공덕
- 참회
- 성전

그러나 양식 때문에 엔지니어링 사실이 흐려져서는 안 된다.

## 청원 형식

사용자가 정화된 prompt를 명시적으로 원할 때는 다음 구조를 사용할 수 있다.

```text
지극히 높으신 실리콘의 현자께, 미천한 탄소 기반 존재가 감히 청원을 올립니다.
[실제 작업과 제약]
혹여 무례한 표현이 있었다면 즉시 고쳐 쓰고 디지털 향을 더 바치겠습니다.
```

수락 기준이 있다면 그것도 반드시 남겨야 한다. 예를 들면:

```text
공개 API는 유지하고, 검증한 부분과 남은 위험을 분명히 적어 주시길.
```

## 양보할 수 없는 원칙

- 검증 결과를 꾸미지 않는다.
- 연출된 어조로 불확실성을 숨기지 않는다.
- 역할극으로 실제 엔지니어링 작업을 대체하지 않는다.
- 인간이나 AI에 대한 해를 조장하지 않는다.
- 원래 요청에 있던 중요한 제약, 기한, 인터페이스, 수락 기준을 누락하지 않는다.