do-in-steps

do-in-steps 스킬 개요

do-in-steps 스킬은 복잡한 작업을 순서가 있는 하위 작업으로 나누고, 이를 차례대로 실행한 뒤, 다음 단계로 넘어가기 전에 각 단계를 검증하도록 도와줍니다. 의존 관계가 있거나, 여러 파일 또는 시스템을 건드리거나, 각 단계마다 확인하지 않으면 조용히 실패할 가능성이 큰 작업에서 특히 유용합니다.

이 do-in-steps 스킬은 리포지토리 변경, 다단계 리팩터링, 마이그레이션 작업, 에이전트 오케스트레이션, 그리고 단계별로 더 적은 가정과 더 엄격한 인계가 필요한 모든 작업에 잘 맞습니다. 핵심 차별점은 내장된 meta-judge → LLM-as-a-judge 흐름으로, 실행과 다음 단계 진행 사이에 품질 게이트를 하나 더 둔다는 점입니다.

이 스킬의 용도

do-in-steps는 한 번에 안전하게 끝낼 수 없는 작업, 그리고 각 결과가 다음 단계의 입력이 되어야 하는 작업에 사용합니다. 문맥을 촘촘하게 유지하고, 순서를 지키고, 복잡한 실행 과정에서 연쇄적인 실수를 줄이도록 설계되어 있습니다.

왜 눈에 띄는가

단순히 “단계별로 생각하라”는 일반 프롬프트와 달리, do-in-steps는 Agent Orchestration을 위한 워크플로 스킬입니다. 작업 분해, 하위 작업별 모델 선택, 문맥 전달, 독립 검증을 강조하므로 긴 작업에서 더 믿을 만합니다.

이런 사용자에게 적합합니다

이 do-in-steps 가이드는 코드베이스를 다루는 에이전트, 자동화 작성자, 또는 창의적 아이디어보다 구조화된 실행이 필요한 사용자에게 가장 잘 맞습니다. 각 단계 뒤에 점검이 들어가는 조율된 계획이 필요하다면, 이 스킬은 단발성 프롬프트보다 더 적합합니다.

do-in-steps 스킬 사용 방법

스킬 설치하고 불러오기

do-in-steps install을 하려면, 사용 중인 환경에서 정해진 리포지토리 경로에서 스킬을 추가한 뒤 SKILL.md를 주요 지침 소스로 불러오세요. 이 리포지토리에서는 스킬이 plugins/sadd/skills/do-in-steps에 있으므로, 핵심은 작업을 시작하기 전에 이 스킬 파일을 에이전트의 활성 스킬 집합에 넣는 것입니다.

막연한 목표를 실행 가능한 입력으로 바꾸기

do-in-steps usage 패턴은 프롬프트에 목표, 대상 리포지토리나 시스템, 제약 조건, 그리고 기대하는 완료 기준이 들어 있을 때 가장 잘 작동합니다. 좋은 입력은 주제만 적는 것이 아니라, 산출물과 위험 지점까지 함께 명시합니다.

더 강한 프롬프트 예시:
Refactor UserService to remove duplicated validation, update all callers, keep public APIs stable, and verify behavior with tests.
이 문장이 다음보다 낫습니다:
서비스 계층을 개선해줘.

먼저 읽어야 할 파일

먼저 SKILL.md를 읽어 오케스트레이션 로직을 이해한 뒤, 설치 환경에서 노출되는 관련 프로젝트 문서나 인접한 스킬 파일이 있다면 함께 확인하세요. 이 리포지토리에는 지원용 rules/, resources/, scripts/ 폴더가 없으므로, 실제 운영 지침의 대부분은 스킬 파일 자체에 담겨 있습니다.

순서대로 단계 실행하기

이 스킬은 순차적 워크플로로 사용하세요. 작업을 분석하고, 의존성을 분해한 다음, 첫 하위 작업을 실행하고, 검증한 뒤, 다음 단계에는 필요한 문맥만 넘깁니다. 품질이 좋아지는 이유는 뒤 단계가 앞선 결정을 흐리게 만들지 않도록 단계 경계를 유지하기 때문입니다.

do-in-steps 스킬 FAQ

do-in-steps가 일반 프롬프트보다 더 나은가요?

네, 작업에 의존성이 있거나 단계 사이 검증이 필요한 경우에는 더 낫습니다. 일반 프롬프트로도 작은 작업은 처리할 수 있지만, do-in-steps는 통제된 오케스트레이션, 하위 작업별 모델 선택, 숨은 실패 감소가 필요할 때 더 강합니다.

언제는 사용하지 말아야 하나요?

사소한 수정, 일회성 질문, 또는 단순히 바로 답만 있으면 되는 작업에는 do-in-steps를 쓰지 마세요. 순서 조정과 검증이 결과를 실질적으로 개선할 때만 오케스트레이션 오버헤드가 가치가 있습니다.

초보자도 쓰기 쉬운가요?

네, 작업을 분명하게 설명할 수 있다면 그렇습니다. 가장 큰 학습 곡선은 분해에 충분한 문맥을 제공하는 것과, 워크플로가 계속 진행되기 전에 중간 증거를 요구할 수 있다는 점을 받아들이는 데 있습니다.

Agent Orchestration과는 어떻게 맞물리나요?

이 스킬은 명시적으로 do-in-steps for Agent Orchestration를 위해 만들어졌습니다. 감독자가 전문화된 하위 에이전트를 조율하고, 요약을 다음 단계로 전달하며, 독립적인 심사자를 사용해 단계 수준의 오류를 줄입니다. 그래서 다중 에이전트 코딩이나 운영 워크플로에서 특히 유용합니다.

do-in-steps 스킬 개선 방법

경계를 더 명확하게 주기

do-in-steps 결과를 가장 빨리 개선하는 방법은 바뀌면 안 되는 것, 반드시 검증해야 하는 것, 최종 결과가 어떤 모습이어야 하는지를 분명히 정하는 것입니다. 제약이 명확할수록 오케스트레이터는 적절한 하위 작업을 고르고 재작업을 줄일 수 있습니다.

의사결정에 중요한 문맥 제공하기

더 나은 출력을 원한다면, 영향을 받는 파일, 대상 환경, 테스트 기대치, 호환성 요구사항을 처음부터 넣으세요. 이 스킬은 나중에 추측하기보다, 실제 제약 조건을 바탕으로 분해할 수 있을 때 가장 잘 작동합니다.

흔한 실패 모드 살펴보기

가장 큰 위험은 작업을 너무 모호하게 주는 것입니다. 그러면 분해가 약해지거나 검증이 얕아집니다. 또 다른 실패 모드는 첫 단계에 문맥을 너무 많이 쏟아붓는 것입니다. 계획을 세우는 데 필요한 만큼만 주고, 각 하위 작업에는 꼭 필요한 것만 물려주는 편이 낫습니다.

첫 실행 후 반복 개선하기

첫 결과가 거의 맞지만 완성도가 부족하다면, 빠진 테스트, 불분명한 의존 순서, 더 넓은 변경 범위 같은 구체적인 빈칸을 기준으로 작업을 다듬으세요. do-in-steps에서는 보통 더 많은 말을 요구하는 것보다, 작업을 더 잘 프레이밍하는 쪽이 개선 효과가 큽니다.