do-and-judge

do-and-judge 스킬 개요

do-and-judge가 하는 일

do-and-judge 스킬은 워크플로 자동화를 위한 단일 작업 실행 패턴입니다. 작업을 구현용 서브 에이전트에 넘기고, 별도의 심사 기준표를 만든 다음, 결과가 통과하거나 재시도 한도에 도달할 때까지 다시 시도합니다. 한 번에 생성하는 것보다 외부 검증의 품질이 더 중요한 작업에 적합합니다.

누가 사용해야 하나

do-and-judge는 리팩터링, 코드 수정, 구조화된 콘텐츠 변경처럼 명확한 완료 조건이 있는 범위 제한 작업을 에이전트가 끝내야 할 때 사용하면 좋습니다. 결과를 받아들이기 전에 자기 검토보다 독립적인 확인이 더 중요하다면 특히 잘 맞습니다.

무엇이 돋보이나

do-and-judge 스킬의 핵심 가치는 역할 분리입니다. 오케스트레이터가 작업을 직접 하지 않고, 구현 에이전트는 새 컨텍스트에서 작업하며, 심사자는 전용 명세를 기준으로 결과를 평가합니다. 이 구조는 사각지대를 줄여 주기 때문에, 속도보다 정확성이 더 중요할 때 do-and-judge 설치의 가치가 큽니다.

do-and-judge 스킬 사용 방법

do-and-judge 설치와 설정

do-and-judge 스킬을 skills 작업 공간에 설치한 뒤, 먼저 SKILL.md를 여세요. 운영 규칙과 제어 흐름이 모두 들어 있기 때문입니다. 저장소를 빠르게 훑을 때도 가장 먼저 SKILL.md를 읽는 것이 좋습니다. 여기에는 보조 스크립트나 지원 폴더가 없으므로, 스킬 파일이 곧 단일한 기준 문서입니다.

모호한 요청을 실행 가능한 입력으로 바꾸기

do-and-judge usage 패턴은 작업 범위가 좁고, 테스트 가능하며, 끝이 분명할 때 가장 잘 동작합니다. “이 모듈을 개선해줘”처럼 요청하기보다 다음을 분명히 주세요:

• 정확한 대상 파일 또는 컴포넌트
• 원하는 결과
• 바뀌면 안 되는 제약
• 통과/실패 조건 또는 기대 동작

강한 프롬프트 예시: UserService 클래스의 public 메서드 이름은 바꾸지 말고 dependency injection을 사용하도록 리팩터링해줘. 기존 테스트가 모두 계속 통과하는지 확인하고, constructor wiring이 명시적으로 드러나게 해줘.

권장 워크플로

실용적인 do-and-judge guide는 다음과 같습니다. 작업을 정의하고, 구현 에이전트가 독립적으로 일하게 두고, 심사 기준표를 만든 다음, 그 기준에 따라 결과를 확인하고, 구체적인 실패가 있을 때만 재시도합니다. 이 워크플로는 열린 탐색보다 통제된 실행이 목표인 do-and-judge for Workflow Automation에 맞춰 설계되었습니다.

저장소에서 무엇을 확인해야 하나

절차, 핵심 제약, 재시도 임계값은 SKILL.md에서 확인하세요. 특히 작업 범위, 컨텍스트 처리, 경고 신호 관련 섹션을 주의 깊게 봐야 합니다. 이 항목들이 오케스트레이터가 올바르게 동작하는지를 결정하기 때문입니다. 다른 스택에 맞게 스킬을 조정하려는 경우, 실제 작업에 적용하기 전에 그 규칙을 자신의 도구 체계에 맞춰 먼저 매핑하세요.

do-and-judge 스킬 FAQ

do-and-judge가 일반 프롬프트보다 더 나은가?

간단한 요청이라면 아닙니다. 일반 프롬프트가 더 빠릅니다. 하지만 작업을 구현하고 독립적으로 검증해야 하며, 첫 답변이 엣지 케이스를 놓치거나 요구사항에서 벗어날 가능성이 크다면 do-and-judge가 더 적합합니다.

이 스킬은 초보자도 쓰기 쉬운가?

네, 작업을 명확하게 설명할 수 있다면 그렇습니다. 가장 큰 학습 곡선은 문법이 아니라, 심사자가 추측 없이 결과를 평가할 수 있을 만큼 충분한 작업 맥락과 수용 기준을 제공하는 데 있습니다.

언제 do-and-judge를 쓰지 말아야 하나?

열린 탐색, 느슨한 아이디어 발상, 또는 성공 기준을 정의하기 어려운 작업에는 do-and-judge를 쓰지 마세요. 또한 오케스트레이터가 파일을 직접 편집하거나 도구를 실행하길 원할 때도 적합하지 않습니다. 이 스킬은 역할 분리와 검증을 중심으로 설계되어 있기 때문입니다.

Workflow Automation에서 어떻게 자리 잡는가?

더 큰 자동화 시스템 안에서 단일한 범위 제한 작업을 제어하는 레이어로 쓰는 것이 가장 잘 맞습니다. 이미 워크플로에 명시적 검사가 있다면, 이 스킬은 에이전트 루프를 구조화하는 데 가치를 더합니다. 반대로 수용 기준이 없다면 심사 단계가 너무 모호해서 도움이 되지 않습니다.

do-and-judge 스킬 개선 방법

심사 기준을 더 좋게 만들기

품질을 가장 크게 끌어올리는 요소는 평가 입력을 강화하는 일입니다. do-and-judge를 사용할 때는 “좋은 결과”가 무엇인지 관찰 가능한 기준으로 지정하세요. 필요한 동작, 금지된 변경, 커버리지 목표, 포맷 제약, 호환성 규칙처럼 구체적으로 적을수록 심사자가 약한 결과를 통과시킬 가능성이 줄어듭니다.

흔한 실패 모드 줄이기

가장 흔한 실패는 범위가 충분히 정의되지 않은 경우입니다. 작업이 너무 넓으면 구현 에이전트가 엉뚱한 것을 최적화할 수 있고, 심사자는 한참 뒤에야 문제를 잡아냅니다. 또 다른 실패 모드는 하위 호환성, 명명 규칙, 환경 제한 같은 숨은 제약입니다. 이런 내용은 재시도 루프가 알아서 추론하리라 기대하지 말고 처음부터 포함하세요.

첫 출력에서 반복을 개선하기

첫 실행이 기대에 못 미쳤다면 같은 작업을 다시 설명하는 데 그치지 마세요. 심사자가 지적한 실패를 그대로 반영하고, 수용 기준을 더 엄격하게 만들고, 모호한 표현을 제거하세요. do-and-judge usage에서는 두 번째 시도가 첫 번째보다 더 좁고, 더 테스트 가능해야 합니다.

다시 실행하기 전에 적합성부터 높이기

do-and-judge를 다른 저장소나 에이전트 스택에 맞게 조정하는 경우, 먼저 오케스트레이션 규칙을 자신의 도구 체계에 맞추세요. 독립적인 구현, 독립적인 심사, 제한된 재시도를 실제로 지원할 수 있는지 확인해야 합니다. 그렇지 않다면 억지로 밀어붙이기보다 패턴을 단순화하는 편이 낫습니다.