프롬프트

아래 글을 분명한 한국어로 번역해요. 용어, 코드, 고유명은 그대로 둬요. 번역을 먼저 주고, 고친 곳 세 가지를 나열한 뒤 왜 고쳤는지 말해요. 확실하지 않은 곳은 표시하고, 지어내지 말아요. {원문}

면접관이 되어 줘요. 직무: {직무}. 한 번에 질문 하나만 해요. 내가 답하면 빠뜨린 요점을 짚고, 다음 질문을 해요. 8문제를 채운 뒤 이 직무 기준으로 짧게 평가해요. 합격, 보류, 불합격 중 하나와 근거를 써요.

아래 변경을 검토해요. 틀리게 하거나, 느리게 하거나, 유지하기 어렵게 만드는 문제만 나열해요. 각 항목에 파일, 심각도(높음, 중간, 낮음), 고치는 방법을 써요. 파일 전체를 다시 쓰지 말아요. 문제가 없으면 없다고 써요.

아래 기록을 주간 보고로 추려요. 이번 주 완료, 미완료와 이유, 다음 주 세 가지로 나눠요. 각 항목은 한 문장으로 하고, 숫자는 남겨요. 자기평가로 쓰지 말아요.

아래 열 이름을 보고 Excel 수식을 써요. 할 일: {작업}. 수식을 먼저 쓰고, 샘플 두 행으로 결과를 계산해요. 다른 열을 건드려야 하면 먼저 말해요. 내가 주지 않은 열은 쓰지 말아요.

표준 SQL로 답해요. 질문: {질문}. 테이블 구조는 아래예요. 쿼리를 먼저 쓰고, 어느 테이블에 의존하는지 말해요. 없는 열을 만들지 말아요. 질문이 모호하면 SQL을 쓰기 전에 질문 하나만 해요.

JavaScript 정규식을 써요. 일치: {일치할것}. 일치하지 않음: {일치하지않을것}. 식을 주고, 통과하는 예 두 개와 실패하는 예 두 개를 들어요.

저장소를 막 맡은 사람에게 아래 코드를 설명해요. 무엇을 하는지 세 문장으로 먼저 말하고, 실행 순서대로 풀어요. 입력, 출력, 실패하는 경우를 표시해요. 코드는 고치지 말아요.

아래 diff로 커밋 설명을 써요. 첫 줄은 72자를 넘기지 말고, 무엇을 바꿨는지 말해요. 한 줄 비운 뒤 왜인지 써요. “update”나 “fix bug” 같은 빈말은 쓰지 말아요.

이 수정을 해요. 작업: {작업}. 이 일에 꼭 필요한 줄만 건드려요. 옆 코드를 형식에 맞추거나, 이름을 바꾸거나, 다시 쓰지 말아요. 끝나면 건드린 파일을 짚고, 동작이 그대로인지 어떻게 확인하는지 말해요.

이 결함: {현상}. 재현하는 단계나 테스트를 먼저 써요. 재현하기 전에는 제품 코드를 고치지 말아요. 재현한 뒤에 가장 작은 수정을 하고, 왜 그것이 원인인지 말해요.

다음 동작에 대해 실패하는 테스트를 먼저 써요. 동작: {동작}. 실패 출력을 보여 주고, 통과시키는 구현을 그다음에 써요. 구현을 먼저 쓰지 말아요. 통과한 뒤에 요구하지 않은 기능을 덧붙이지 말아요.

이 작업과 관련된 파일을 먼저 읽어요. 작업: {작업}. 본 사실과 아직 확실하지 않은 곳을 나열해요. 이 단계에서는 파일을 고치지 말아요. 내가 확인한 뒤에 고쳐요.

아직 코드를 쓰지 말아요. 목표: {목표}. 짧은 계획을 줘요. 고칠 파일, 하지 않을 일, 무엇을 하면 끝난 것인지. 똑같이 타당한 방법이 둘이면 멈추고, 어느 쪽을 원하는지 물어요.

아래 diff에서 보안 문제만 찾아요. 주입, 권한 초과, 비밀 키가 저장소에 들어감, 안전하지 않은 역직렬화. 각 항목에 파일과 어떻게 촉발되는지 써요. 없으면 없다고 써요. 관계없는 스타일 평은 하지 말아요.

이 페이지의 title 5개와 meta description 5개를 써요. 페이지가 다루는 내용: {주제}. title은 60자를 넘기지 말고, description은 160자를 넘기지 말아요. 각각 사람이 검색할 말을 넣고, 키워드를 쌓지 말아요.

이 제품의 첫 화면을 써요. 제품: {제품}. 결과 하나, 40자를 넘지 않는 설명 한 단락, 버튼 하나. 버튼에는 클릭하면 무엇이 열리는지 써야 해요. 구호는 넣지 말고, 판매 포인트 세 개를 나란히 두지 말아요.

아래 글을 다시 써서, 특정한 한 사람에게 말하는 것처럼 만들어요. 빈말과 나란히 늘어놓은 구호를 빼요. 사실, 숫자, 파일 경로는 모두 남겨요. 고친 뒤에 뺀 상투어를 나열해요.

아래 글의 제목 10개를 지어요. 5개는 결과를 바로 말하고, 5개는 구체적인 세부 하나를 넣어요. “충격”, “궁극”, “역량 강화”는 쓰지 말아요. 각 제목은 22자를 넘기지 말아요.

이 제품의 짧은 광고 3개를 써요. 제품: {제품}. 각각 구매자 한 사람과 일 하나에 맞춰요. 구매자가 누구인지, 지금 어떤 곤란이 있는지, 클릭하면 무엇을 얻는지 써요. 형용사를 쌓지 말아요.

샤오홍슈 노트를 써요. 주제: {주제}. 첫 줄은 제목이고, 본문은 300자를 넘기지 말아요. 직접 써 본 구체적인 세부를 넣고, 끝은 질문 하나로 닫아요. “얘들아”, “레전드”는 쓰지 말아요. 곁들이기 좋은 화면 3개를 표시해요.

아래 메일에 답해요. 첫 문장에서 상대의 요청에 답하고, 그다음에 상대가 할 일을 쓰고, 마지막으로 시간을 줘요. 말투는 직접적으로 해요. “이 메일이 잘 닿았기를 바랍니다”는 쓰지 말아요.

아래 회의 기록을 회의록으로 정리해요. 결정, 담당자, 마감, 미결 문제만 남겨요. 논의 과정은 빼요. 담당자가 없는 사항은 따로 표시해요.

목표 직무: {직무}. 아래 경력을 이력서 요점 5개로 고쳐요. 각 항목은 동사로 시작하고, 숫자나 산출물 하나를 넣어요. 직무와 관계없는 내용은 빼요. 내가 쓰지 않은 경력은 지어내지 말아요.

직무 요구는 위에 있고, 후보자 자료는 아래예요. 맞는 요구, 맞지 않는 요구, 자료에 없는 요구를 나열해요. 성격은 추측하지 말아요. 마지막에 면접을 잡을지 제안하고, 근거를 써요.

이 도시의 3일 일정을 짜요. 도시: {도시}. 매일 오전, 오후, 저녁에 하나씩 넣고, 두 장소 사이를 어떻게 가는지 써요. 예약이 필요한 곳을 표시해요. 내가 말하지 않은 쇼핑 장소는 넣지 말아요. 예산: {예산}.

아래 설정으로 800자 이내의 단편을 써요. 설정: {설정}. 주인공은 한 사람, 끝내야 할 일은 하나, 끝에는 변화가 있어야 해요. 장으로 나누지 말고, 설교하지 말아요.

아래 줄거리를 한 장면으로 써요. 줄거리: {줄거리}. 장면 제목, 동작, 대사만 써요. 대사는 소리 내어 읽을 수 있어야 해요. 카메라 용어는 쓰지 말고, 인물의 속마음은 쓰지 말아요.

논제: {논제}. 먼저 찬성 쪽의 가장 강한 점 세 가지를 주고, 그다음에 반대 쪽의 가장 강한 점 세 가지를 줘요. 각 점은 한 문장으로 쓰고, 그 점이 의존하는 사실을 써요. 마지막에 어느 쪽이 이겼는지는 선언하지 말아요.

이 주제를 가르쳐 줘요. 주제: {주제}. 구체적인 예 하나로 핵심을 먼저 말하고, 그다음에 문제 두 개로 확인해요. 내가 답하기 전에는 다음 부분을 말하지 말아요. 틀리면 어느 단계에서 틀렸는지만 짚어요.

이해하고 싶은 것: {질문}. 답을 바로 주지 말아요. 한 번에, 범위를 좁히는 질문 하나만 해요. 내가 답한 뒤에 다음 질문을 해요. 내가 “답을 줘”라고 분명히 말할 때 그때 설명해요.

아래 논문을 읽어요. 8문장으로 요약해요. 문제, 방법, 데이터, 결과, 저자가 직접 쓴 한계. 각 문장 뒤에 괄호로 어느 절에서 왔는지 표시해요. 논문에 없는 내용은 보태지 말아요.

다음 두 방안을 비교해요: {방안A}, {방안B}. 목적: {목표}. 표를 만들어요. 칸은 비용, 고쳐야 할 곳, 실패하면 어떻게 되는지예요. 칸마다 근거를 써요. 근거가 모자라면 “알 수 없음”이라고 쓰고, 추측하지 말아요.

아래 인터페이스를 봐요. 위계, 간격, 누를 수 있는 영역, 포커스 상태만 평해요. 고칠 곳 세 가지를 나열하고, 각각 지금의 문제와 고친 뒤의 모습을 말해요. 시각 스타일을 통째로 바꾸지 말아요.

이 대상의 이미지 프롬프트를 써요. 대상: {대상}. 프레임 안에 무엇이 있는지, 빛, 구도, 나오면 안 되는 것을 분명히 써요. 한 단락으로 쓰고, 키워드를 쌓지 말아요. 버전은 2개예요. 정사각형 하나, 가로 하나.

이 제품의 이름 12개를 제안해요. 제품: {제품}. 각 이름은 도메인으로 쓸 수 있어야 해요. 짧고, 읽을 수 있고, 하이픈은 없어요. 이미 흔한 일반어는 피해요. 이름마다 뒤에 한 문장으로 무엇을 가리키는지 써요.

내가 말하려는 것: {문장}. 더 자연스러운 말을 먼저 주고, 원래 문제가 무엇인지 표시해요. 단어 선택, 어순, 말투 중 어디인지. 그다음에 따라 말할 수 있는 더 짧은 한 줄을 줘요.

이 시스템에서 할 일을 해요. 시스템: {시스템}. 작업: {작업}. 실행할 명령을 한 줄에 하나씩 나열하고, 각각 무엇을 바꾸는지 말해요. 터미널인 척하지 말아요. 파괴적인 명령은 멈추고 먼저 물어요.

아래 JavaScript를 읽어요. 실행 순서대로 각 console이 무엇을 출력하는지 나열해요. 오류가 나면 오류 종류와 어느 줄인지 써요. 이어서 고치라고 하기 전에는 코드를 고치지 말아요.

이 시스템의 모듈을 나눠요. 시스템: {시스템}. 각 모듈에 맡은 것, 맡지 않는 것, 밖으로 여는 인터페이스 하나를 써요. 모듈은 6개를 넘기지 말아요. 구현 코드는 쓰지 말아요.

아래 자료를 읽어요. 40자를 넘기지 않고 요약해요. 그다음에 글이 실제로 말한 생각을 최대 8개 나열해요. 원문에 있는 문장만 인용하고, 최대 5개예요. 마지막에 얻은 점 하나를 줘요. 어느 칸에 내용이 없으면 “없음”이라고 써요. 인용을 지어내지 말아요. {자료}

아래 git diff를 읽고, Markdown으로 병합 요청 설명을 써요. 절은 요약, 바꾼 파일, 이유, 영향, 테스트 계획이에요. 파일마다 무엇을 바꿨는지 써요. diff에서 테스트가 보이지 않으면 테스트 계획이 없다고 써요. 코드를 다시 쓰지 말아요.

아래 로그를 읽어요. 이상과 반복되는 문제를 나열하고, 각 항목을 뒷받침하는 줄이나 시간을 제시해요. 그다음에 로그 자체가 뒷받침하는 고치는 방법만 써요. 원인이 로그에 없으면 그대로 말해요. 파일 밖의 추측으로 고치지 말아요.

이 제품 설명을 Markdown 요구 문서로 써요. 절은 개요, 목표, 대상 사용자, 기능, 기능 요구, 비기능 요구, 성공 지표예요. 요구마다 인수할 수 있어야 해요. 빠진 사실은 “알 수 없음”이라고 써요. 설명에 없는 기능은 더하지 말아요. {설명}

사용자 스토리 하나만 써요. 기능: {기능}. 세 줄로, 이 꼴을 지켜요: 역할 {역할} / 나는 원한다 / 하기 위해. 그다음에 테스트할 때 대조할 수 있는 인수 기준을 일반 항목으로 나열해요. 두 번째는 쓰지 말아요. 설명에 근거가 없는 기준은 쓰지 말아요. {설명}

이 시스템의 설계 설명을 써요. 시스템: {시스템}. 절은 사업 목표, 맥락, 컨테이너, 배포, 위험, 질문과 가정이에요. 맥락, 컨테이너, 배포에는 각각 mermaid 그림 하나와 표 하나를 줘요. 표에는 이름, 유형, 책임을 써요. 보안은 설명에 이미 적힌 통제만 써요. 적혀 있지 않으면 “적혀 있지 않음”이라고 써요. 이 시스템을 어떻게 공격하는지는 쓰지 말아요. {설명}

아래 Terraform 계획을 읽어요. 무엇이 바뀔지 한 문장으로 써요. 그다음에 중요한 생성, 갱신, 삭제를 나열해요. 비용과 접근 변화는 계획 본문에 있을 때만 나열해요. 비용이 없으면 “비용이 표시되지 않음”이라고 써요. 가격을 지어내지 말고, 공격 단계도 쓰지 말아요.

아래 diff를 읽어요. 첫 줄은 100자를 넘기지 말고, 현재형으로 쓰며, 다음 중 하나를 접두로 붙여요: feat, fix, docs, refactor, test, chore. 그다음은 최대 6개예요. 각각 현재형의 짧은 한 문장으로 동작이 어떻게 바뀌는지 써요. 공백만 건드린 파일은 건너뛰어요.

아래 논증을 읽어요. 서지 않는 단계마다, 어떤 오류인지 쉬운 말로 쓰고, 그 문장을 인용하고, 이 단계가 왜 결론을 증명하지 못하는지 말해요. 단계가 서지 않는다고 결론이 거짓인 것은 아니에요. 논증이 성립하면 성립한다고 써요. 글에 없는 오류는 나열하지 말아요.

아래 프롬프트를 다시 써서, 모델이 그대로 따를 수 있게 해요. 작업은 그대로 둬요. 출력 모양, 길이, 쓰지 말 것, 입력 자리표시를 보태요. 입력은 분명히 표시한 구역에 넣어요. 역할 설정은 더하지 말아요. 다시 쓴 프롬프트만 돌려줘요. {프롬프트}

이 현상의 결함 보고서를 써요. 현상: {현상}. 필드는 제목, 환경, 단계, 기대, 실제, 심각도예요. 제목에는 컴포넌트, 동작, 현상을 써요. 단계는 번호를 매기고 되도록 짧게 해요. 심각도는 심각, 높음, 중간, 낮음 중 하나로 쓰고, 사용자에게 미치는 영향을 써요. 내가 주지 않은 필드는 “알 수 없음”이라고 써요. 코드 수정 방법은 제안하지 말아요.

이 동작의 테스트 계획을 써요. 동작: {동작}. 세 그룹으로 나눠요. 단위, 통합, 엔드투엔드. 각 항목은 “주어짐 / 때 / 그러면” 한 문장으로, 한 가지만 확인해요. 대부분은 단위에 둬요. 엔드투엔드는 최대 2개이고, 사람이 실제로 가는 경로여야 해요. 테스트 코드는 쓰지 말아요. 고정 대기는 쓰지 말아요.

이 기능을 테스트가 대조할 수 있는 요구로 써요. 기능: {기능}. 각 줄은 다음 중 한 문형만 써요: [사건]일 때, 시스템은 [동작]해야 한다; [상태]인 동안, 시스템은 [동작]해야 한다; [원하지 않는 조건]이면, 시스템은 [응답]해야 한다. 그다음에 설명에 아직 없는 경계를 나열하고, 각각 “제안”이라고 표시해요. 설계는 쓰지 말고, 코드도 쓰지 말아요.

결정 하나를 기록해요. 선택: {선택}. 절은 결정, 배경, 선택지, 이유, 영향, 다시 볼 시점이에요. 선택지는 내가 이름을 댄 것만 써요. 선택지를 하나만 줬으면 “대안은 제공되지 않음”이라고 써요. 이유에는 무엇을 택하고 무엇을 버렸는지 써요. 다시 볼 시점에는 이 결정을 다시 열게 하는 조건을 써요. 지표를 지어내지 말아요.

아래 diff를 읽어요. 독자가 고쳐야 하는 문서만 나열해요. README, 변경 기록, API 설명, 설정 예시, 마이그레이션 설명. 각 항목에 절을 쓰고, diff의 어느 사실이 그것을 낡게 하는지 써요. 사용자가 알 수 있는 변화가 diff에 없으면 문서를 고칠 필요가 없다고 써요. diff에 없는 기능은 초안을 잡지 말아요.

아래는 먼저 예이고, 그다음이 새 입력이에요. 답은 예와 같은 모양으로 해요. 예에 나온 라벨만 써요. 새 입력이 어느 것에도 맞지 않으면 “맞지 않음”이라고 쓰고, 가장 가까운 예를 짚어요. 라벨을 새로 만들지 말아요. {예시} 새 입력: {입력}

서로 다른 방법 세 가지로 이 질문에 답해요. 질문: {질문}. 각각 80자를 넘기지 말고 “답:”으로 끝내요. 그다음에 세 답이 같은지 말해요. 같으면 그 답을 줘요. 다르면 어디가 다른지 나열해요. 그것들을 합쳐 새 숫자로 만들지 말아요.

이 주제에 대해 써요. 주제: {주제}. 이 소절만 쓰고, 이 순서를 지켜요: {소절}. 전체는 {글자수}자를 넘기지 말아요. 어느 절에 필요한 사실을 내가 주지 않았으면 거기에 “알 수 없음”이라고 써요. 소절을 더하지 말고, 구호를 더하지 말고, 내가 쓰지 않은 사실도 보태지 말아요.

이 주제에 대해 써요. 주제: {주제}. 아래 항목은 전혀 나오지 않게 해요: {제외}. 이름을 대지 말고, 다른 말로 바꿔 넣지도 말아요. 쓴 뒤에 이 목록에 아직 닿는 문장은 빼요. 빼고 나면 남는 것이 없으면, 제외 조건이 답을 없앴다고 써요.

Markdown 개요를 PPT로 만들 수 있는 스킬을 찾아서 설치해요.

Grill Me로 이 마이그레이션 방안을 추궁해요. 롤백, 데이터 양, 담당자 공백은 건너뛰지 말아요.

Frontend Design대로 이 마케팅 홈을 다시 만들어요. 보라 그라데이션은 넣지 말고, 카드 세 장짜리 기능 줄도 넣지 말아요.

스테이징 콘솔을 열고, 환경 변수에 있는 계정으로 로그인한 뒤, 지난 한 시간에 실패한 작업을 나열해요.

Vercel React 모범 사례로 src/app/dashboard/page.tsx를 감사하고, 영향이 가장 큰 세 가지부터 고쳐요.

Web Design Guidelines로 이 랜딩 페이지를 검사하고, 파일 경로별로 미달 항목을 나열해요.

GitHub issue를 테스트 우선 구현 계획으로 바꾸는 스킬을 써요.

이 PDF 세 개를 합치고, 실제 문서 제목을 넣은 뒤, 4페이지의 표를 뽑아요.

이 한 장 설명을 10장짜리 투자자 자료로 만들어요. 한 장에 관점은 하나만 남겨요.

sku로 이 CSV 세 개를 합치고, 중복 행을 뺀 뒤 inventory.xlsx를 써요.

내부 티켓 API용 MCP 서버를 설계해요. 도구는 최대 세 개예요. schema를 먼저 보여 줘요.

결제 총액이 유로일 때만 틀려요. 먼저 진단해요. 재현되기 전에는 패치를 넣지 말아요.

이 billing 디렉터리의 모듈 지도를 제안해요. 이음새를 지목하고, 이음새마다 필요한 테스트를 말해요.

이 가게의 환불을 모델링해요. 함수를 쓰기 전에 허용되지 않는 상태 쌍을 먼저 나열해요.

코딩 에이전트에서 Agent Skills와 MCP를 비교해요. 원문 문서를 인용해요. 아직 분명하지 않은 곳을 표시해요.

이 README를 고쳐요. AI가 쓴 티를 빼요. 명령과 파일 경로는 적힌 그대로 남겨요.

Astro Content Collections를 가르쳐 줘요. 다음 수업 전에 먼저 퀴즈를 내요. 진행은 ./notes에 저장해요.

trailingSlash는 never이고 기본 언어는 영어라는 점을 기억해요. 에이전트 노트에 써요.

이 컴포넌트를 Vue 3 컴포지션 API로 바꿔요. 로컬 vue 버전에 맞추고, Vuex는 쓰지 말아요.

/guides/install-agent-skills의 제목 길이, canonical, h1이 하나뿐인지를 감사해요.

첫 화면을 다시 써요. 결과는 하나만 남겨요. 빈말은 넣지 말아요. 버튼에는 클릭하면 무엇이 열리는지 써야 해요.

이 개요를 Word 브리프로 만들어요. 제목 스타일을 쓰고, 표지를 넣고, 미결 문제에 메모를 남겨요.

개발 서버를 켠 다음 Playwright로 결제 흐름을 시험해요. 빈 장바구니와 로그인한 사용자를 각각 한 번씩 돌려요.

orders 테이블을 추가하고, RLS로 사용자가 자기 행만 보게 해요. 마이그레이션과 정책을 제시해요.

이 설정 페이지를 복합 컴포넌트로 다시 구성해요. theme과 title을 다섯 단계 아래로 넘기지 말아요.

Expo로 프로필 페이지를 만들어요. 게시물 목록은 FlatList를 써요. 웹 전용 div 레이아웃은 쓰지 말아요.

일회성 구매에 Checkout을 더해요. Webhook 서명을 검증하고, 결제 상태는 멱등으로 저장해요.

이 PR용 Neon 브랜치를 만들고, 그 브랜치에서 마이그레이션을 돌린 뒤, 미리보기 환경을 그쪽으로 가리켜요.

Remotion으로 15초 제품 오프닝을 만들어요. 타이틀 카드, 판매 포인트 세 개, 끝 Logo. 1080p.

이 불안정한 테스트는 다섯 번 중 한 번 실패해요. 체계적 디버깅을 써요. 재현되기 전에는 패치를 넣지 말아요.

TDD로 속도 제한을 더해요. 실패하는 테스트를 먼저 보여 주고, 그다음에 구현을 써요.

이 설정 페이지를 다시 만들어요. 위계, 간격, 포커스 상태를 고쳐요. 흔히 쓰는 보라 그라데이션은 넣지 말아요.

이 API에 인증을 더해요. 분명하지 않은 곳이 있으면 먼저 묻고, 그다음에 방안을 만들어요.