AI에게 같은 작업을 반복해서 맡긴다면 작업 절차를 스킬로 정리하고, 끝난 뒤 확인한 실수를 기록해 지침을 개선할 수 있습니다. 다만 기록을 남기는 것과 모델 자체가 학습하는 것은 다릅니다. 수정된 지침을 다음 작업에서 읽고 실제로 도움이 되는지 검증하는 과정이 필요합니다.
스킬을 어떻게 나누나요?
Agent Skills 명세는 스킬을 SKILL.md가 들어 있는 폴더로 설명합니다. 필요하면 실행 스크립트, 참고 문서, 템플릿도 함께 둘 수 있습니다. 도구마다 스킬을 발견하고 실행하는 방식이나 지원 기능은 다르므로 사용 중인 제품의 설명서를 확인해야 합니다.
SKILL.md: 스킬을 언제 쓰고 어떤 절차로 작업할지 정리합니다.references/: 작업할 때 필요한 상세 설명과 기준을 둡니다.scripts/: 반복 실행하는 코드를 둘 수 있습니다.assets/: 결과물에 사용할 템플릿 등을 둘 수 있습니다.
폴더 구분은 필요한 자료를 찾고 유지하는 데 도움이 됩니다. 복잡한 내용을 무조건 다른 파일에 옮긴다고 성능이 보장되거나 모든 도구에서 완벽하게 호환되는 것은 아닙니다. 기존의 스킬 설계 가이드에서는 반복 작업과 검증 기준을 정하는 방법을 자세히 다룹니다.
작업 후 피드백은 어떻게 기록할까요?
영상은 작업이 끝날 때 오류와 사용자 피드백을 돌아보고 다음 작업에 반영하는 방식을 제안합니다. 예를 들어 블로그 검토 스킬이 출처 날짜를 여러 번 놓쳤다면, 언제 발생했고 어떤 문제가 있었는지 작업 기록에 적습니다. 기록은 오류의 단서이지 자동으로 검증된 원인은 아닙니다.
작업: [무엇을 했는지]
관찰한 문제: [실제로 확인한 결과]
근거: [관련 결과물이나 사용자 피드백]
개선 후보: [다음에 확인할 변경]
검증 방법: [변경 전후에 비교할 사례]
위 형식은 적용을 돕는 예시입니다. 민감정보나 다른 사람의 개인 정보는 기록에 불필요하게 남기지 마세요.
반복된 피드백을 지침으로 옮기는 기준
같은 피드백이 반복됐다는 사실만으로 원본 스킬을 자동 수정하기보다 먼저 기존 규칙과 충돌하는지, 해당 작업 전체에 적용할 기준인지 확인합니다. 예를 들어 한 글에서만 800자 제한이 필요했다면 모든 글에 같은 제한을 적용하면 안 됩니다. 작업별 조건은 해당 요청에 남기고, 반복되는 공통 검수 기준은 스킬에 넣는 식으로 구분합니다.
수정 전 파일을 보존하고, 성공했던 사례와 실패했던 사례를 모두 사용해 비교하세요. 에이전트에게 변경 후보를 작성하게 할 수 있지만 실제 파일을 고치거나 명령을 실행할 권한은 사용하는 환경에서 정한 범위에 따라야 합니다.
스킬을 연결할 때도 중간 결과를 확인합니다
자료 조사 스킬이 만든 문서를 글쓰기 스킬에 전달하는 식으로 단계를 연결할 수 있습니다. 이때 조사 결과의 출처와 작성 시점, 다음 단계에 넘기는 파일을 명시하세요. 이전 단계의 잘못된 정보가 다음 단계로 전파될 수 있으므로 최종 결과뿐 아니라 중간 산출물도 확인해야 합니다.
작업 기록을 쌓는 목적은 파일을 많이 만드는 것이 아니라 다음 판단을 개선하는 것입니다. 쓸모없는 기록은 정리하고, 새 규칙이 기존 작업을 망가뜨리지 않는지 주기적으로 점검하세요.
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.