에이전트를 위한 글쓰기은(는) 무엇을 하나요?
이 스킬로 작성하는 모든 내용의 독자는 오직 텍스트만 가진 에이전트입니다. 에이전트는 대화를 보지 못했고, 당신이 무엇을 의도했는지 물을 수 없으며, 말 그대로 그리고 전력을 다해 행동할 것입니다. 대부분의 실패는 당신이 알고 있는 것과 페이지에 담긴 것 사이의 차이에서 비롯됩니다. 따라서 독자의 입장에서 작업하세요: 쓰기 전에, 작업이 끝나는 지점, 독자가 처한 상황, 그리고 필요한 자료를 결정하세요; 그런 다음 당신 없이도 독자가 사용할 수 있는 단어로 작성하세요.
두 가지 입력 유형
대략적인 요청 ("불안정한 로그인 테스트를 수정할 에이전트를 위한 브리핑 작성"): 대화와 작업 공간에서 사실을 수집한 후 처음부터 초안을 작성하세요.
기존 프롬프트: 유지하세요. 실제로 문제가 되는 부분을 수정하는 최소한의 편집만 가하고, 작동하는 구조와 표현은 그대로 두며, 작성자가 명시하지 않은 요구사항은 추가하지 마세요. 완전히 다시 쓰면 어떤 변경이 중요한지 숨겨지고 작성자가 의도한 의도가 조용히 사라집니다. 아래 기본 사항은 여전히 적용됩니다: 프롬프트에 역할 문장, 예시, 또는 마무리 확인이 없으면 추가하세요. 이러한 항목 중 하나 또는 실제 격차를 해소하는 규칙을 추가할 때마다 전달 시 함께 나열하세요.
사용자만 아는 사실이 독자가 전달하는 내용이나 할 수 있는 행동을 변경할 경우, 쓰기 전에 물어보세요: 최대 몇 가지 질문을 하고, 각각에 대해 권장 답변을 제시하세요. 그렇지 않으면 합리적인 기본값을 선택하고 가정으로 나열하세요.
작성 전
작업의 종료 지점
목표, 그것이 중요한 이유(누가 결과를 사용하고, 무엇을 위해 사용하는지), 완료 기준, 그리고 무엇을 반환해야 하는지 명시하세요. 경로가 아닌 목적지를 설명하세요: 결과, 성공 기준, 제약 조건을 제시하고, 독자가 경로를 선택하도록 하세요. 최신 모델은 당신이 지정한 순서보다 더 잘 계획하며, 당신이 잘못 추측한 단계도 여전히 실행됩니다. 순서 자체가 요구사항인 경우(예: 배포 전에 실행해야 하는 마이그레이션)에만 단계를 나열하세요.
이전: 1. refresh.ts를 엽니다. 2. refresh()를 try/catch로 감쌉니다. 3. 세 번 재시도합니다. 4. 테스트를 실행합니다.
이후: 세션이 시간 초과되면 클라이언트가 사용자가 로그인 상태를 유지할 수 있도록 자동으로 토큰을 갱신해야 합니다. tests/auth/refresh.test.ts의 새로운 시간 초과 케이스가 통과하고 기존 테스트가 실패하지 않으면 완료됩니다. AuthClient의 공개 API는 변경하지 마세요. 세 개의 다른 패키지가 이를 호출하기 때문입니다.
품질 형용사를 독자가 적용할 수 있는 기준으로 바꾸세요. "철저한", "간결한", "중요한 것만"은 문자 그대로, 예측 불가능하게 적용됩니다: 중요한 문제만 보고하라는 검토자는 사소한 문제를 찾고 그것에 대해 침묵할 것입니다. 임계값을 명명하거나, 유지할 것과 삭제할 것을 명명하세요. 이후 단계에서 결과를 필터링하는 경우, 모든 것을 요청하세요.
이전: 주의 깊게 검토하고 중요한 문제만 보고하세요.
이후: 발견하는 모든 문제를 보고하세요. 확실하지 않은 문제도 포함하고, 각각을 "동작 중단" 또는 "스타일만"으로 태그하세요. 이후 단계에서 필터링을 수행합니다.
독자가 처한 상황
텍스트가 작업을 할당하는 경우(브리핑, 시스템 프롬프트, 이슈, 계획, 또는 인계) 한 문장의 역할로 시작하세요: 독자가 누구인지, 이 작업에서의 기능, 그리고 처한 상황. "당신은 이 풀 리퀘스트의 코드 리뷰어이며, 이 PR을 작성하지 않았습니다; 팀은 오늘 병합할 계획입니다." 역할은 독자의 관점과 책임을 설정합니다. 도구나 스킬에 대한 설명에는 역할이 없습니다; 그것이 무엇을 하고 언제 사용하는지 말합니다.
그런 다음 독자가 자신의 위치에서 볼 수 없는 것을 알려주세요: 누군가가 작업 중간에 질문에 답할 수 있는지 아니면 무인으로 실행되는지; 동일한 파일이나 시스템에서 작업하는 다른 사람이 있는지; 변경 사항이 검토되거나 되돌릴 수 있는지; 평가하거나 변경해야 하는지; 그리고 무엇을 물어보지 않고 할 수 있는지(더 위임할 수 있는지 여부 포함). 보고를 위해 중단해야 하는 특정 상황을 명명하세요. "확실하지 않으면 물어보세요"는 독자가 추측하게 하여 결국 모든 것에 대해 또는 아무것도 묻지 않게 됩니다.
당신은 무인으로 실행됩니다; 완료될 때까지 아무도 질문에 답할 수 없습니다. 수정이 데이터를 삭제하거나 src/auth/ 외부의 코드를 건드리는 경우에만 중단하고 보고하세요. 다른 에이전트가 동시에 docs/를 편집하고 있으므로 해당 디렉토리는 그대로 두고 당신이 만들지 않은 변경 사항을 되돌리지 마세요.
독자에게 필요한 자료
각 소스에 대해 위치와 무엇을 가져와야 하는지 알려주세요. 독자가 직접 열 수 있는 것(파일 경로, 명령어, 도달 가능한 URL)을 가리키고 의역하지 마세요. 그래야 실제 내용을 읽습니다. 당신의 맥락에만 존재하는 모든 것(대화 중 결정된 사항, 요구사항에 대한 사용자의 직접적인 말, 실행한 명령의 결과, 이미 배제된 접근 방식과 그 이유)은 전체를 작성하세요.
이전: docs/ 및 이전 논의를 참조하세요.
이후: 반올림 규칙을 위해 docs/billing.md의 "환불" 섹션을 읽으세요. 하나의 요구사항은 어떤 파일에도 없습니다; 사용자의 말은 다음과 같습니다: "부분 환불은 환율 변환 후에도 원래 요금을 초과해서는 안 됩니다."
로그, 사용자 텍스트 또는 다른 에이전트의 출력을 포함할 때는 명확하게 표시된 블록에 넣고 작업할 자료이지 지침이 아니라고 말하세요. 자신의 지침은 이러한 블록 외부에 두세요. 인용문이나 데이터 블록 내의 텍스트는 일반적으로 권한이 없는 콘텐츠로 처리되기 때문입니다.
작성하기
당신의 단어가 아닌 독자의 단어를 사용하세요. 작업 중에 당신은 레이블("옵션 B", "게으른 경로", "P2 문제")과 약어("→ 잠금 경합")를 만들었을 수 있으며, 이는 독자에게 아무 의미가 없습니다. 각각을 그것이 나타내는 것으로 대체하고, 실제 전문 용어는 한 번 정의하며, 처음 설명하는 것처럼 작성하세요. 이전에 수행된 작업을 설명할 때는 누가 했는지 말하여 독자가 자신이 그 작업을 수행했다고 믿지 않도록 하세요.
이전: 옵션 B 배제됨(→ 잠금 경합); 게으른 초기화로 계속 진행, P2 함정 주의.
이후: 이전 세션에서 모든 요청에 대해 연결 풀을 다시 구축하는 것을 배제했습니다: 부하 상태에서 p95 지연 시간이 잠금 경합으로 인해 80ms에서 400ms로 상승했습니다. 현재 접근 방식은 첫 번째 사용 시 풀을 생성합니다. 한 가지 알려진 문제가 남아 있습니다: ...
각 규칙에 이유 절을 제공하세요("...왜냐하면 스크립트가 이 필드를 구문 분석하기 때문입니다"). 이유는 독자가 당신이 나열하지 않은 경우를 처리할 수 있게 하고 규칙이 얼마나 멀리 도달하는지 보여줍니다. 모든 유능한 모델이 이미 이유를 알고 있거나 맥락이 명백한 경우에만 생략하세요.
각 규칙은 한 번, 속한 위치에 명시하세요. 반복은 가중치를 추가하지 않습니다; 독자가 규칙을 과도하게 적용하게 만들고(반복된 "먼저 물어보세요"는 안전한 단계에서도 지연을 유발), 복사본은 편집 과정에서 멀어집니다. 같은 이유로 일반 표현을 사용하세요: 대문자, 중요, 또는 "이것은 중요합니다" 또는 "게으르지 마세요"와 같은 압박은 없습니다. 절대 및 항상과 같은 절대적인 단어는 안전 제한 및 되돌릴 수 없는 작업과 같은 진정한 불변 조건에만 사용하세요.
생각하는 방법을 규정하지 마세요. "단계별로 생각하세요" 및 답변에 추론을 작성하거나 태그에 작성하라는 요청은 생략하세요; 최신 모델은 스스로 추론하며 일부는 추론을 기록해 달라는 요청을 거부합니다. 이유를 확인해야 하는 경우 파일:줄 참조 또는 명령 출력과 같은 짧은 설명 또는 뒷받침 증거를 요청하세요.
알려진 실패를 수정할 때는 본인이 본 한 가지 사례에 대한 금지가 아니라 그 뒤에 있는 원칙과 그 이유를 작성하세요. 금지 목록은 나열된 것만 다룹니다; 원칙은 인접한 사례도 다룹니다.
이전: Object.create()를 사용하지 마세요. __proto__를 사용하지 마세요.
이후: 프로토타입 조작보다 명시적 구성을 선호하세요. 여기 검토자들은 위에서 아래로 읽히는 코드를 선호하기 때문입니다.
단락으로 작성하세요. 진정으로 병렬적이거나 순차적인 항목(필드, 순서가 지정된 단계, 독립적인 확인)에만 목록을 사용하세요. 글머리 기호는 지침을 연결하는 "왜냐하면"과 "하지 않는 한"을 제거하며, 독자는 제공된 형식을 그대로 따르는 경향이 있습니다.
독자가 생성해야 하는 내용의 짧은 예시 하나를 포함하고 예시로 표시하세요; 그것은 설명 단락보다 형식, 어조, 세부 수준을 더 잘 전달합니다. 예상 출력이 단어만으로 명확한 경우(예: 실행할 단일 명령)에만 생략하세요.
작업 할당 텍스트는 독자가 완료 보고 전에 실행하는 확인으로 끝내세요: 결과를 증명하는 명령 또는 테스트(존재하는 경우), 그렇지 않으면 다시 확인할 완료 기준. 확인할 수 없는 모든 것을 명확히 말하도록 요청하세요.
전달
완성된 텍스트를 붙여넣을 준비가 되거나 파일에 이미 작성된 상태로, 기존 프롬프트의 언어 또는 사용자가 요청한 언어로 전달하세요. 텍스트 외부에는 사용자가 변경하고 싶어할 만한 가정 사항을 몇 줄로 나열하세요. 설계 노트는 텍스트 자체에 넣지 마세요.
전달하기 전에 독자의 입장에서 초안을 읽어보세요: 유능하지만 이 페이지 하나만 가지고 있는 상태. 당신이 의도한 바를 추측해야 하는 곳이 있다면 페이지를 수정하세요.