/plan, /grill, /goal: 기본 내장 스킬로 완성하는 워크플로
Muse Code 번들 스킬에 대한 Meta의 한 줄 요약은 이렇습니다. 러프한 아이디어를 넣으면, 혹독한 검증을 거친 기능이 나온다. 각 커맨드가 실제로 무엇을 하고 언제 꺼내 쓰면 되는지 정리했습니다.
/plan — 승인 전에는 아무것도 바뀌지 않는다
/plan은 요청한 태스크를 승인 게이트가 걸린 계획으로 바꿉니다. 에이전트가 저장소를 분석하고, 작업을 분해하고, 어떻게 진행할지 제시한 다음 — 거기서 멈춥니다. 승인하기 전까지 코드는 한 줄도 바뀌지 않습니다. 사소한 수정이 아닌 이상 이것이 올바른 첫수입니다. “에이전트가 내 말을 제대로 알아들었기를”이라는 막연한 기대를 직접 읽을 수 있는 문서로 바꿔주고, 오해를 바로잡는 비용이 잘못된 리팩터링을 오후 내내 되돌리는 수준이 아니라 몇 초 수준일 때 잡아내 줍니다.
/grill — 실행 전의 적대적 검증
/grill은 계획이 버틸 때까지 스트레스 테스트를 겁니다. 이름 그대로입니다. 그럴듯해 보이는 첫 계획을 순순히 받아들이는 대신, 에이전트가 자기 접근법을 스스로 심문합니다. 엣지 케이스, 숨은 의존성, 실패 모드를 파고들며 계획이 이 그릴링에서 살아남을 때까지 수정합니다. 사람 엔지니어라면 설계 리뷰에서 하는 일이죠. 대부분의 코딩 에이전트는 이 단계를 통째로 건너뛰고 재시도로 그 대가를 치릅니다. 계획이 어차피 무너질 거라면, 종이 위에서 무너지는 편이 낫습니다.
/goal — 결승선을 기억하는 커맨드
/goal은 지정한 목표가 성공적으로 완료될 때까지 작업을 밀고 나갑니다. 처음에 원했던 것이 최종적으로 머지되는 것과 일치할 때까지 에이전트를 궤도에 붙잡아 둡니다. 긴 에이전트 세션에는 잘 알려진 실패 모드가 있습니다. 바로 표류(drift)입니다. 툴 호출 50번쯤 지나면 에이전트는 요청한 것과 비슷하지만 정확히는 아닌 무언가를 성실하게 다듬고 있곤 하죠. 목표 유지(goal conditioning)는 바로 이 문제 때문에 Muse Spark 1.2에 학습으로 새겨졌고, /goal은 그것을 붙잡는 손잡이입니다.
조연들: /model과 /effort
나머지 두 커맨드는 워크플로가 아니라 비용을 관리합니다. /model은 세션 중간에 백엔드 모델을 전환합니다. 예컨대 학습 데이터 미사용 티어가 필요할 때 표준 Model API 가격의 muse-spark-1.2로 바꾸는 식입니다(자세한 내용은 티어 비교 글에 있습니다). /effort는 추론 깊이를 올리거나 내립니다. Muse Spark는 답하기 전에 생각하는 모델이고 그 사고 토큰은 출력으로 과금되므로, 작업 난이도에 맞춰 effort를 조절하는 것이 가장 손쉬운 비용 최적화입니다.
자연스럽게 이어지는 워크플로
이 스킬들은 자연스럽게 체인이 됩니다. 기능을 /plan으로 계획하고, 그 계획을 /grill로 검증하고, 승인한 뒤, /goal에게 실행을 맡기는 것입니다. 독립적인 부분은 팬아웃이 병렬화하고, 모든 단계는 이벤트 로그가 리뷰용으로 기록합니다. 각 단계가 다음 단계의 게이트가 되는 구조 — 자율 시스템이 신뢰를 조금씩 쌓아가야 한다면 정확히 이런 모양이어야 합니다. 번들 스킬 쿡북 레시피는 실제 기능 하나로 이 파이프라인 전체를 보여줍니다. 쿡북에서 확인하세요.