1. 업무를 작은 약속으로 바꾸기

“제안서를 잘 써줘”에는 판단할 여지가 너무 많습니다. 어떤 공고인지, 어떤 자료를 근거로 쓸지, 어떤 형식으로 끝낼지가 모두 빠져 있습니다. Skill을 만들기 전에 무엇을 받아 무엇을 내놓을지부터 적습니다.

1.1 다섯 칸 설계서

samples/starter/workflow-design.md를 열고 다음 다섯 칸을 채워보세요.

모든 입력을 필수로 만들 필요는 없습니다. 프로그램명과 일정이 있어야 초안을 시작할 수 있지만, 장소가 미정이어도 “장소 미정”인 계획서는 만들 수 있습니다. 반면 견적에서 단가가 빠지면 정확한 총액을 낼 수 없습니다. 누락됐을 때 전체를 멈출지, 해당 항목만 비우고 진행할지를 항목마다 정해 두세요.

1.2 설명문을 세 번 고치기

“문서를 만든다”는 너무 넓습니다. “교육 문서를 만든다”는 조금 낫지만 시작 전 계획과 종료 후 결과를 구분하지 못합니다. “교육 과정 개요로 시작 전 운영 계획서를 작성한다”라고 쓰면 어떤 요청에 골라야 하는지가 분명해집니다.

이 책에서 program-plan과 training-report를 나눈 이유도 같습니다. 전자는 앞으로 할 일을 예정 시제로 쓰고 후자는 실제 기록에서 수치를 가져옵니다. 하나의 긴 지침으로 합칠 수도 있지만, 입력과 판정 기준이 다르다면 나누는 편이 검토하기 쉽습니다.

1.3 요청 예시를 먼저 세 개 적기

사용해야 할 요청 두 개와 쓰지 않아야 할 요청 하나를 적습니다.

사용: 다음 달 교육의 회차별 운영 계획을 만들어줘.
사용: 과정 개요를 계획서 형식으로 정리해줘.
비대상: 끝난 교육의 실제 수료율을 계산해줘.

비대상 요청을 지침에 모두 나열할 필요는 없습니다. 설계 단계에서 경계를 확인하는 데 쓰세요. 종료 후 보고 요청에 자꾸 계획 Skill이 선택된다면 설명문에 “시작 전”이 충분히 드러나 있는지 먼저 봅니다.

1.4 출력을 검토 가능하게 만들기

HTML만 받으면 내용을 비교하기 불편합니다. 원고 Markdown과 읽기용 HTML을 함께 남기면 내용 수정과 서식 검토를 나눌 수 있습니다. 다만 모든 업무에 파일 두 개를 강제할 필요는 없습니다. 회의록은 Markdown 하나로 충분하고, 견적은 계산 근거를 담은 JSON과 표 CSV가 있으면 검산이 편합니다.

연습으로 자신의 업무 하나를 다섯 칸 설계서로 정리하세요. “좋게”, “전문적으로”, “완벽하게”를 지우고 무엇을 확인하면 통과인지 적으면 그것이 다음 절에서 쓸 SKILL.md 초안이 됩니다.