루프 시작하기.... 최종 프롬프트는 이렇게 됨..

/schedule 매시간: project-feedback 채널에서 버그 리포트가 있는지 확인할 것.
+
/goal: 이번 실행에서 발견된 모든 리포트가 분류되고, 조치되고, 응답될 때까지 멈추지 말 것. 버그를 수정할 때는 세 가지 해결책을 병렬 워크트리에서 각각 탐색하는 워크플로우를 사용하고, 심사자 역할이 이를 비판적으로 리뷰하게 할 것.

이건 자동 모드와 동적 워크플로우가 조합되어 장시간 실행되는 작업을 위한 루프가 됨.

결론을 먼저 얘기했는데 이 퀄리티 높은 아티클의 4가지 패턴은 꼭 알아두면 좋음.

먼저 턴 기반 루프

• 트리거: 사용자 프롬프트

• 중지 기준: Claude가 작업을 완료했다고 판단하거나, 추가 맥락이 필요하다고 판단할 때

• 가장 적합한 경우: 정기적인 프로세스나 일정의 일부가 아닌 짧은 작업

• 사용량 관리 방법: 구체적인 프롬프트를 작성하고, 스킬을 사용해 검증을 개선하여 턴 수를 줄이자

↓

목표 기반 루프 = /goal

• 트리거: 실시간 수동 프롬프트

• 중지 기준: 목표 달성 또는 최대 턴 수 도달

• 가장 적합한 경우: 검증 가능한 종료 기준이 있는 작업

• 사용량 관리 방법: 구체적인 완료 기준과 명시적인 턴 제한을 설정하자 ("5번 시도 후 중지")

↓

시간 기반 루프 = /loop와 /schedule

• 트리거: 지정된 시간 간격

• 중지 기준: 사용자가 취소하거나 작업이 완료될 때

• 가장 적합한 경우: 반복 작업 또는 외부 환경·시스템과 상호작용하는 작업

• 사용량 관리 방법: 더 긴 간격을 설정하거나, 시간보다는 이벤트에 반응하도록 하자

↓

프로액티브 루프

• 트리거: 이벤트 또는 일정. 실시간으로 사람이 개입하지 않음

• 중지 기준: 각 작업은 목표가 충족되면 종료됩니다. 루틴 자체는 사용자가 끌 때까지 실행됨

• 가장 적합한 경우: 버그 리포트, 이슈 분류, 마이그레이션, 의존성 업그레이드처럼 반복적이고 잘 정의된 작업 흐름

• 사용량 관리 방법: 루틴은 더 작고 빠른 모델로 라우팅하고, 판단이 필요한 경우에 가장 강력한 모델 사용

좋은 아티클이다....