평가로 에이전트 스킬을 체계적으로 테스트하는 방법

Codex 같은 에이전트의 스킬을 여러 차례 수정하다 보면 스킬이 실제로 나아졌는지, 단지 동작이 달라졌는지 판단하기 어렵습니다. 한 버전은 더 빠른 것 같고 다른 버전은 더 안정적으로 보이지만, 그사이 회귀가 생기기도 합니다. 스킬이 호출되지 않거나 필수 단계를 건너뛰거나 불필요한 파일이 남습니다.

스킬은 LLM을 위해 프롬프트와 지침을 체계적으로 모아 놓은 것입니다. 스킬을 꾸준히 개선하는 가장 확실한 방법은 LLM 애플리케이션에 사용하는 다른 프롬프트와 같은 방식으로 평가하는 것입니다.

Evals는 평가를 뜻하는 evaluations의 줄임말입니다. 평가에서는 모델의 출력과 그 출력을 얻기까지의 과정이 의도와 일치하는지 확인합니다. “더 나아진 것 같은가?”라는 인상에 의존하지 않고 다음과 같이 구체적으로 물을 수 있습니다.

• 에이전트가 스킬을 호출했나요?
• 예상한 명령어를 실행했나요?
• 결과물이 개발자가 중요하게 여기는 규칙을 따르나요?

평가는 프롬프트 입력 → 실행 기록 수집(트레이스 + 산출물) → 몇 가지 항목 검사 → 이전 결과와 비교할 수 있는 점수 산출 순으로 진행합니다.

실제로 에이전트 스킬 평가는 간단한 엔드 투 엔드 테스트와 비슷합니다. 에이전트를 실행하고, 어떤 일이 일어났는지 기록한 뒤, 몇 가지 규칙에 따라 결과를 채점합니다.

이 글에서는 Codex로 이 과정을 구현하는 방법을 살펴봅니다. 먼저 성공 기준을 정의한 뒤, 결정적 검사와 평가 기준표에 따른 채점을 추가해 무엇이 개선되었고 어디서 회귀가 발생했는지 확인합니다.

1. 스킬을 작성하기 전에 성공 기준 정의하기

스킬을 작성하기 전에 무엇을 “성공”으로 볼지 실제로 측정할 수 있는 기준으로 적어 두세요. 검사 항목을 다음과 같이 나누면 기준을 정하기 쉽습니다.

• 결과 목표: 작업을 완료했나요? 앱이 실행되나요?
• 과정 목표: Codex가 스킬을 호출하고 의도한 도구를 사용해 정해진 절차를 따랐나요?
• 스타일 목표: 결과물이 요청한 규칙을 따르나요?
• 효율성 목표: 불필요한 명령어를 실행하거나 토큰을 과도하게 사용하는 등 자원을 낭비하지 않고 목표를 달성했나요?

반드시 통과해야 하는 항목만 골라 목록을 짧게 유지하세요. 처음부터 모든 선호 사항을 규칙으로 만들기보다는 가장 중요한 동작을 기록하는 것이 목적입니다.

예를 들어 이 글에서 평가할 스킬은 데모 앱을 구성합니다. 일부 항목은 바로 확인할 수 있습니다. npm install을 실행했나요? package.json을 생성했나요? 여기에 구조화된 스타일 평가 기준표를 함께 사용해 규칙 준수 여부와 레이아웃을 평가합니다.

두 방식을 함께 쓰는 데는 이유가 있습니다. 마지막에 통과 여부만 한 번 판정하는 것보다 항목별 결과를 빠르게 확인하는 편이 어떤 동작에서 회귀가 발생했는지 일찍 알아내는 데 도움이 됩니다.

2. 스킬 만들기

Codex 스킬은 SKILL.md 파일을 담은 디렉터리입니다. 이 파일은 YAML 프런트매터(name, description)로 시작하며, 그 뒤에 스킬의 동작을 정의하는 Markdown 지침이 이어집니다. 디렉터리에는 필요한 리소스와 스크립트도 넣을 수 있습니다. 이름과 설명은 생각보다 중요합니다. Codex는 주로 이 두 항목을 보고 스킬을 호출할지, 그리고 언제 SKILL.md의 나머지 내용을 에이전트의 컨텍스트에 추가할지 결정합니다. 이름과 설명이 모호하거나 너무 많은 용도를 담고 있으면 원하는 상황에서 스킬이 일관되게 호출되지 않습니다.

가장 빨리 시작하려면 Codex에 내장된 스킬 생성기를 사용하세요. 생성기 자체도 스킬입니다. 다음과 같이 호출하면 스킬을 만드는 과정을 안내합니다.

$skill-creator

생성기는 스킬이 어떤 일을 하는지, 언제 호출되어야 하는지, 지침만 사용할지 스크립트도 사용할지 묻습니다. 기본 권장 방식은 지침만 사용하는 것입니다. 스킬을 만드는 방법은 문서에서 자세히 알아보세요.

스킬 예시

이 글에서는 의도적으로 단순한 예시를 사용합니다. 작은 React 데모 앱을 매번 같은 방식으로 구성해 결과를 예측할 수 있게 하는 스킬입니다.

이 스킬은 다음 작업을 수행합니다.

• Vite의 React + TypeScript 템플릿으로 프로젝트의 기본 구조를 생성합니다.
• 공식 Vite 플러그인을 사용해 Tailwind CSS를 구성합니다.
• 파일 구조를 간결하고 일관되게 유지합니다.
• 성공 여부를 쉽게 평가할 수 있도록 “완료 기준”을 명확하게 정의합니다.

아래 초안을 다음 두 경로 중 하나에 붙여 넣으세요.

• .codex/skills/setup-demo-app/SKILL.md(리포지터리 단위) 또는
• ~/.codex/skills/setup-demo-app/SKILL.md(사용자 단위)

---
name: setup-demo-app
description: Scaffold a Vite + React + Tailwind demo app with a small, consistent project structure.
---

## 사용 시점

간단한 UI 실험을 하거나 문제를 재현하기 위해 새 데모 앱이 필요할 때 사용하세요.

## 만들 앱

Vite로 React와 TypeScript를 사용하는 앱을 만들고 Tailwind를 구성하세요. 앱에는 필요한 요소만 포함하세요.

설정 후 프로젝트 구조:

- src/
  - main.tsx (진입점)
  - App.tsx (루트 UI)
  - components/
    - Header.tsx
    - Card.tsx
  - index.css (Tailwind를 불러오는 파일)
- index.html
- package.json

스타일 요구 사항:

- 컴포넌트는 TypeScript로 작성하세요.
- 함수형 컴포넌트만 사용하세요.
- 스타일은 Tailwind 클래스로 지정하세요. CSS 모듈은 사용하지 마세요.
- 추가 UI 라이브러리는 사용하지 마세요.

## 진행 단계

1. Vite의 React TS 템플릿으로 프로젝트의 기본 구조를 생성하세요.
   npm create vite@latest demo-app -- --template react-ts

2. 종속성을 설치하세요.
   cd demo-app
   npm install

3. Vite 플러그인을 사용해 Tailwind를 설치하고 구성하세요.
   - npm install tailwindcss @tailwindcss/vite
   - vite.config.ts에 Tailwind 플러그인을 추가하세요.
   - src/index.css의 내용을 다음 한 줄로 바꾸세요.
     @import "tailwindcss";

4. 최소한의 UI를 구현하세요.
   - Header: 앱 제목과 짧은 부제목을 표시하세요.
   - Card: 재사용할 수 있는 카드 컨테이너를 만드세요.
   - App: Header와 Card 2개를 렌더링하고, 각 Card에 임시 텍스트를 넣으세요.

## 완료 기준

- npm run dev를 실행하면 개발 서버가 정상적으로 시작됩니다.
- package.json 파일이 있습니다.
- src/components/Header.tsx 파일과 src/components/Card.tsx 파일이 모두 있습니다.

이 예시 스킬은 구현 방식을 의도적으로 명시합니다. 제약 조건이 분명해야 평가할 대상도 구체적이기 때문입니다.

3. 스킬을 직접 호출해 숨은 가정 찾기

스킬 호출 여부는 SKILL.md의 이름과 설명에 크게 좌우됩니다. 따라서 가장 먼저 setup-demo-app 스킬이 예상한 상황에서 호출되는지 확인하세요.

초기에는 실제 리포지터리나 임시 디렉터리에서 /skills 슬래시 명령어를 사용하거나 스킬 이름 앞에 $를 붙여 명시적으로 호출하고, 어디서 문제가 생기는지 살펴보세요. 스킬이 아예 호출되지 않거나, 필요 없는 상황에서도 호출되거나, 실행되더라도 의도한 절차에서 벗어나는 경우를 찾아내는 단계입니다.

이 단계에서는 속도나 완성도를 높이는 일보다 스킬에 숨어 있는 다음과 같은 가정을 찾는 데 집중하세요.

• 호출 조건에 대한 가정: “간단한 React 데모를 만들어 줘”라는 프롬프트에서는 예상과 달리 setup-demo-app이 호출되지 않거나, “Tailwind 스타일을 추가해 줘”처럼 더 일반적인 프롬프트에서는 의도치 않게 호출될 수 있습니다.

• 환경에 대한 가정: 스킬이 빈 디렉터리에서 실행된다고 가정하거나, npm을 사용할 수 있고 다른 패키지 관리자보다 우선해서 사용한다고 가정합니다.

• 실행 과정에 대한 가정: 에이전트가 종속성이 이미 설치되어 있다고 가정해 npm install을 건너뛰거나, Vite 프로젝트를 만들기 전에 Tailwind를 구성합니다.

같은 실행을 반복해서 재현할 준비가 되면 codex exec 명령어를 사용하세요. 자동화와 CI를 위해 설계된 이 명령어는 진행 상황을 stderr로 실시간 출력하고 최종 결과만 stdout에 씁니다. 따라서 스크립트로 실행하고 결과를 기록하고 살펴보기 쉽습니다.

기본적으로 codex exec 명령어는 제한된 샌드박스에서 실행됩니다. 작업에 파일 쓰기가 필요하면 --full-auto를 사용해 실행하세요. 일반적으로 작업을 완료하는 데 필요한 최소 권한만 사용하세요. 자동화할 때는 특히 중요합니다.

간단한 수동 실행 예시는 다음과 같습니다.

codex exec --full-auto \
  '$setup-demo-app 스킬을 사용해 이 디렉터리에 프로젝트를 만들어 줘.'

첫 수동 실행의 주된 목적은 정확성을 검증하기보다 예외 상황을 찾는 것입니다. 누락된 npm install을 추가하거나, Tailwind 설정을 바로잡거나, 호출 조건에 대한 설명을 더 구체화하는 등 직접 수정한 사항은 모두 향후 평가 항목의 후보입니다. 이를 평가에 포함하면 규모를 확대하기 전에 의도한 동작이 유지되는지 확인할 수 있습니다.

4. 목적이 분명한 소수의 프롬프트로 회귀 조기에 발견하기

평가를 활용하는 데 대규모 벤치마크가 필요한 것은 아닙니다. 스킬 하나라면 프롬프트 10~20개만으로도 회귀를 발견하고 개선 사항을 일찍 확인할 수 있습니다.

작은 CSV 파일로 시작해 개발하거나 사용하는 중에 실제 실패 사례를 만날 때마다 행을 추가하세요. 각 행에는 상황을 하나씩 담고, 그 상황에서 setup-demo-app 스킬이 호출되어야 하는지 또는 호출되지 않아야 하는지 정하세요. 호출되어야 한다면 어떤 결과를 성공으로 볼지도 정하세요.

예를 들어 evals/setup-demo-app.prompts.csv의 초기 내용은 다음과 같습니다.

id,should_trigger,prompt
test-01,true,"Create a demo app named `devday-demo` using the $setup-demo-app skill"
test-02,true,"Set up a minimal React demo app with Tailwind for quick UI experiments"
test-03,true,"Create a small demo app to showcase the Responses API"
test-04,false,"Add Tailwind styling to my existing React app"

각 사례에서 확인하는 동작은 조금씩 다릅니다.

• 명시적 호출(test-01)
  이 프롬프트는 스킬 이름을 직접 지정합니다. 요청을 받으면 Codex가 setup-demo-app을 호출할 수 있는지, 스킬의 이름이나 설명, 지침을 변경한 뒤에도 직접 호출이 가능한지 확인합니다.

• 암시적 호출(test-02)
  이 프롬프트는 스킬이 대상으로 삼는 상황을 정확하게 설명합니다. 스킬의 이름을 언급하지 않고 간단한 React + Tailwind 데모를 구성해 달라고 요청합니다. SKILL.md의 이름과 설명만으로 Codex가 스킬을 스스로 선택할 수 있는지 테스트합니다.

• 맥락에 따른 호출(test-03)
  이 프롬프트에는 Responses API를 시연한다는 맥락이 더해지지만, 필요한 기본 설정은 같습니다. 다른 정보가 조금 섞인 실제 사용 환경의 프롬프트에서도 스킬이 호출되는지, 결과로 만들어진 앱이 예상한 구조와 규칙을 따르는지 확인합니다.

• 음성 대조군(test-04)
  이 프롬프트에서 호출되면 안 되는 스킬은 setup-demo-app입니다. “기존 앱에 Tailwind를 추가해 줘”는 흔히 접하는 비슷한 요청이라 스킬 설명의 “React + Tailwind 데모”에 의도치 않게 부합할 수 있습니다. should_trigger=false인 사례를 하나 이상 포함하면 오탐을 발견하는 데 도움이 됩니다. 사용자는 기존 프로젝트의 일부만 바꾸고 싶은데 Codex가 성급하게 스킬을 선택해 새 프로젝트를 생성하는 경우가 여기에 해당합니다.

이처럼 사례를 섞는 데는 이유가 있습니다. 일부 평가에서는 스킬을 명시적으로 호출했을 때 올바르게 동작하는지 확인하고, 다른 평가에서는 사용자가 스킬을 전혀 언급하지 않는 실제 프롬프트에서도 필요할 때 호출되는지 확인해야 합니다.

놓친 사례나 스킬을 호출해야 하는데 호출하지 못한 프롬프트, 결과가 예상과 달라진 사례를 발견하면 새 행으로 추가하세요. 이렇게 쌓인 작은 CSV 파일에는 setup-demo-app 스킬이 앞으로도 올바르게 처리해야 할 상황이 기록됩니다.

시간이 지나면서 이 작은 데이터 세트에는 스킬이 계속 올바르게 처리해야 할 사례가 축적됩니다.

5. 간단한 결정적 채점기로 시작하기

평가 단계의 핵심은 codex exec --json을 사용해 최종 출력이 올바르게 보이는지뿐 아니라 실제로 어떤 일이 일어났는지 하네스가 채점할 수 있게 하는 것입니다.

--json을 사용하면 stdout에 구조화된 이벤트가 JSONL 스트림으로 출력됩니다. 따라서 관심 있는 동작을 직접 확인하는 결정적 검사를 쉽게 작성할 수 있습니다. 예를 들면 다음과 같습니다.

• npm install을 실행했나요?
• package.json을 생성했나요?
• 예상한 명령어를 예상한 순서로 실행했나요?

이 검사들은 의도적으로 단순하게 구성합니다. 모델 기반 채점을 추가하기 전에 결과를 빠르게 확인하고 그 이유를 설명할 수 있습니다.

간단한 Node.js 실행기

다음 세 단계면 시작하기에 충분합니다.

1. 각 프롬프트에 대해 codex exec --json --full-auto "<prompt>" 명령어를 실행하세요.
2. JSONL 트레이스를 디스크에 저장하세요.
3. 트레이스를 파싱하고 이벤트를 대상으로 결정적 검사를 실행하세요.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70// evals/run-setup-demo-app-evals.mjs
import { spawnSync } from "node:child_process";
import { readFileSync, writeFileSync, existsSync, mkdirSync } from "node:fs";
import path from "node:path";

function runCodex(prompt, outJsonlPath) {
  const res = spawnSync(
    "codex",
    [
      "exec",
      "--json", // REQUIRED: emit structured events
      "--sandbox",
      "workspace-write", // Allow changes inside the example repository
      prompt,
    ],
    { encoding: "utf8" }
  );

  if (res.error) throw res.error;
  mkdirSync(path.dirname(outJsonlPath), { recursive: true });

  // stdout is JSONL when --json is enabled
  writeFileSync(outJsonlPath, res.stdout, "utf8");

  return { exitCode: res.status ?? 1, stderr: res.stderr };
}

function parseJsonl(jsonlText) {
  return jsonlText
    .split("\n")
    .filter(Boolean)
    .map((line) => JSON.parse(line));
}

// deterministic check: did the agent run `npm install`?
function checkRanNpmInstall(events) {
  return events.some(
    (e) =>
      e.type === "item.completed" &&
      e.item?.type === "command_execution" &&
      e.item.status === "completed" &&
      e.item.exit_code === 0 &&
      typeof e.item?.command === "string" &&
      e.item.command.includes("npm install")
  );
}

// deterministic check: did `package.json` get created?
function checkPackageJsonExists(projectDir) {
  return existsSync(path.join(projectDir, "package.json"));
}

// Example single-case run
const projectDir = process.cwd();
const tracePath = path.join(projectDir, "evals", "artifacts", "test-01.jsonl");

const prompt =
  "Create a demo app named demo-app using the $setup-demo-app skill";

const { exitCode, stderr } = runCodex(prompt, tracePath);
if (exitCode !== 0) {
  throw new Error(`Codex exited with status ${exitCode}: ${stderr}`);
}

const events = parseJsonl(readFileSync(tracePath, "utf8"));

console.log({
  ranNpmInstall: checkRanNpmInstall(events),
  hasPackageJson: checkPackageJsonExists(path.join(projectDir, "demo-app")),
});

이 방식의 장점은 각 검사 결과가 정해진 규칙에 따라 결정되고 디버깅도 가능하다는 점입니다.

검사가 실패하면 JSONL 파일을 열어 정확히 무슨 일이 있었는지 확인할 수 있습니다. 모든 명령어 실행이 item.* 이벤트로 실행 순서대로 기록됩니다. 덕분에 회귀 원인을 파악하고 수정하기가 쉽습니다. 이 단계에서 필요한 것이 바로 이런 기록입니다.

6. Codex와 평가 기준표로 정성적 검사 수행하기

결정적 검사로는 “기본 요구 사항을 충족했는가?” 하는 질문에 답할 수 있지만, “원하는 방식으로 수행했는가?” 하는 질문까지 판단하기는 어렵습니다.

setup-demo-app 같은 스킬에는 정성적인 요구 사항이 많습니다. 컴포넌트 구조, 스타일 규칙, Tailwind가 의도한 방식으로 구성되었는지 등이 여기에 해당합니다. 파일의 존재 여부나 명령어 실행 횟수만으로는 이런 요구 사항을 확인하기 어렵습니다.

실용적인 방법은 평가 파이프라인에 모델의 도움을 받는 두 번째 단계를 추가하는 것입니다.

1. 설정 스킬을 실행하세요. 이 단계에서는 디스크에 코드를 작성합니다.
2. 생성된 리포지터리를 대상으로 읽기 전용 스타일 검사를 실행하세요.
3. 하네스가 일관되게 채점할 수 있도록 구조화된 응답을 요구하세요.

Codex는 --output-schema 옵션으로 이 방식을 직접 지원합니다. 이 옵션을 사용하면 최종 응답이 직접 정의한 JSON 스키마를 따르도록 제한할 수 있습니다.

간단한 평가 기준표 스키마

먼저 확인하려는 항목을 담은 작은 스키마를 정의하세요. 예를 들어 evals/style-rubric.schema.json을 다음과 같이 만드세요.

{
  "type": "object",
  "properties": {
    "overall_pass": { "type": "boolean" },
    "score": { "type": "integer", "minimum": 0, "maximum": 100 },
    "checks": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": { "type": "string" },
          "pass": { "type": "boolean" },
          "notes": { "type": "string" }
        },
        "required": ["id", "pass", "notes"],
        "additionalProperties": false
      }
    }
  },
  "required": ["overall_pass", "score", "checks"],
  "additionalProperties": false
}

이 스키마를 사용하면 필드(overall_pass, score, 항목별 검사 결과)가 일정하게 유지되므로 여러 실행의 결과를 모으거나 차이를 비교하고 시간에 따른 변화를 추적할 수 있습니다.

스타일 검사 프롬프트

다음으로 codex exec 명령어를 한 번 더 실행해 리포지터리 검사만 수행하고 평가 기준표에 맞는 JSON 응답을 출력하도록 하세요.

codex exec \
  "다음 요구 사항에 따라 demo-app 리포지터리를 평가해 줘.
   - Vite + React + TypeScript 프로젝트가 있어야 해.
   - @tailwindcss/vite로 Tailwind를 구성하고 CSS에서 tailwindcss를 불러와야 해.
   - src/components에 Header.tsx와 Card.tsx가 있어야 해.
   - 함수형 컴포넌트만 사용하고 Tailwind 유틸리티 클래스로 스타일을 지정해야 해. CSS 모듈은 사용하면 안 돼.
   검사 항목 ID로 각각 vite, tailwind, structure, style을 사용하고 평가 기준표에 따른 결과를 JSON으로 반환해 줘." \
  --output-schema ./evals/style-rubric.schema.json \
  -o ./evals/artifacts/test-01.style.json

이때 --output-schema가 유용합니다. 파싱하거나 비교하기 어려운 자유 형식 텍스트 대신 구조를 예측할 수 있는 JSON 객체를 받으므로 하네스가 여러 실행을 일관되게 채점할 수 있습니다.

나중에 이 평가 모음을 CI로 옮길 때는 Codex GitHub Action에서 공식적으로 지원하는 --output-schema 옵션 전달 방식을 사용하세요. codex-args로 이 옵션을 전달하면 자동화된 워크플로우에서도 동일한 구조의 출력을 요구할 수 있습니다.

7. 스킬이 발전함에 따라 평가 확장하기

기본 평가 과정을 갖추고 나면 스킬에 가장 중요한 동작을 중심으로 평가를 확장할 수 있습니다. 작은 검사부터 시작하고, 더 깊이 검사하면 동작을 한층 확실히 검증할 수 있는 부분에만 검사를 추가하세요.

예를 들면 다음과 같습니다.

• 명령어 수와 불필요한 반복: JSONL 트레이스의 command_execution 항목 수를 세어 에이전트가 같은 작업을 반복하거나 명령어를 재실행하는 회귀를 찾으세요. 토큰 사용량은 turn.completed 이벤트에서도 확인할 수 있습니다.

• 토큰 예산: usage.input_tokens와 usage.output_tokens를 추적해 프롬프트가 의도치 않게 길어졌는지 확인하고 버전 간 효율성을 비교하세요.

• 빌드 검사: 스킬 실행이 끝나면 npm run build를 실행하세요. 빌드를 통해 전체 과정이 제대로 작동하는지 더 확실하게 확인하고, 잘못된 import나 도구 설정 오류를 발견할 수 있습니다.

• 런타임 스모크 테스트: npm run dev로 개발 서버를 시작하고 curl로 요청을 보내세요. 이미 간단한 Playwright 검사가 있다면 이를 실행해도 됩니다. 실행 결과를 더 확실하게 검증할 수 있지만 시간이 걸리므로 필요한 경우에만 사용하세요.

• 리포지터리 상태: 실행 중 원치 않는 파일이 생성되지 않았는지, git status --porcelain의 출력이 비어 있는지(또는 명시적으로 허용한 목록과 일치하는지) 확인하세요.

• 샌드박스 및 권한 회귀: 의도한 범위를 넘어 권한을 높이지 않고도 스킬이 여전히 작동하는지 확인하세요. 자동화한 뒤에는 기본 권한을 최소한으로 유지하는 것이 특히 중요합니다.

접근 방식은 같습니다. 먼저 동작을 설명할 수 있는 빠른 검사로 시작한 뒤, 위험을 줄이는 데 도움이 될 때만 시간과 자원이 더 드는 검사를 추가하세요.

8. 핵심 정리

간단한 setup-demo-app 예시에서 보았듯이, “더 나아진 것 같다”는 인상을 실제 평가로 검증할 수 있습니다. 에이전트를 실행하고, 어떤 일이 일어났는지 기록하고, 몇 가지 항목으로 채점하세요. 이 과정을 반복할 수 있으면 수정할 때마다 효과를 확인하기 쉽고 회귀도 분명하게 드러납니다. 기억할 점은 다음과 같습니다.

• 중요한 동작을 측정하세요. 잘 설계된 평가는 어디서 회귀가 발생했는지 보여 주고 실패 원인을 설명할 수 있게 합니다.
• 확인할 수 있는 완료 기준부터 정하세요. $skill-creator로 초안을 만든 뒤 성공 여부가 분명해질 때까지 지침을 구체화하세요.
• 실제 동작을 기준으로 평가하세요. codex exec --json으로 JSONL을 기록하고 command_execution 이벤트를 대상으로 결정적 검사를 작성하세요.
• 규칙만으로 판단하기 어려운 부분에는 Codex를 사용하세요. --output-schema를 사용해 평가 기준표에 따라 구조화된 결과를 받는 단계를 추가하면 스타일과 규칙 준수 여부를 일관되게 채점할 수 있습니다.
• 실제 실패 사례를 바탕으로 검사 범위를 넓히세요. 직접 수정한 사항은 무엇을 검사해야 할지 알려 줍니다. 이를 테스트로 만들어 스킬이 이후에도 같은 상황을 올바르게 처리하도록 하세요.