---
name: ketchup
description: "사용자의 마지막 메시지 이후 이 채팅에서 변경된 내용을 평범한 단어와 작은 비주얼로 따라잡도록 하세요. 응답만으로 결정하는 데 필요한 것과 함께 그들을 기다리는 모든 항목을 나열하세요. /ketchup에 사용하세요."
disable-model-invocation: true
---

# Ketchup

사용자가 `/ketchup` 전에 작성한 마지막 메시지 이후 이 채팅에서 변경된 내용을 따라잡도록 하고, 각 변경 사항이 어디에 있는지뿐만 아니라 이해하도록 도와주세요. 그런 다음 그들이 당신의 응답만으로 할 수 있도록 그들을 기다리는 모든 호출을 배치하세요. 알림과 서브에이전트 결과는 그들의 메시지가 아닙니다. 사용자가 마지막 메시지와 그 이후는 아무것도 기억하지 못한다고 가정하세요.

[`/bro`](../bro/SKILL.md)의 목소리를 사용하되, 작업은 아닙니다: 평범한 단어, 짧은 문장, 전문 용어 없음, 한 사람이 다른 사람을 따라잡는 것처럼. 어떻게 했는지가 아니라 사용자를 위해 무엇이 변경되었는지 말하세요. "CI is green"이 아니라 "the tests pass"라고 말하세요. 사용자가 행동하는 데 필요하지 않는 한 해시, 파일 경로, 명령, 빌드 번호, 테스트 카운트는 빼세요. 각 PR, 브랜치 또는 에이전트를 당신이 발명한 레이블이 아니라 사용자가 알 것 같은 이름으로 호출하세요. 사실이 이해되려면 컨텍스트가 필요하면 컨텍스트를 제공하거나 사실을 빼세요.

## 변경된 것 수집

이 턴을 읽기 전용으로 유지하세요. 이미 가지고 있는 것에서만 비주얼을 만드세요: 코드를 변경하거나, 앱이나 작업을 시작하거나, 무언가를 게시하지 마세요. 해당 메시지 이후의 자신의 작업, 서브에이전트의 보고서, 이 채팅에서 다른 사람의 메시지를 수집하세요. 이 채팅이 터치한 각 PR, CI 실행 또는 에이전트의 현재 상태를 확인하세요. 표시할 각 숫자를 그것이 나온 사실과 비교하여 확인하고, 하나를 수정할 때 그렇게 말하세요.

액션 아이템은 사용자만 취할 수 있는 호출 또는 단계입니다. 제품 선택, 승인, 되돌릴 수 없는 행동, 또는 당신이 부족한 접근 권한과 같은. 사용자의 마지막 메시지 전에 제기된 것이라도 여전히 사용자를 기다리는 것을 포함하세요. 당신이 여전히 스스로 할 수 있는 작업은 액션 아이템이 아닙니다. 응답을 채우기 위해 호출을 만들어내지 마세요. 사용자가 요청하지 않고 작업이 필요하지 않은 단계는 액션 아이템이 아닙니다. 되돌릴 수 없고 사용자를 기다리는 경우를 제외하고는: 한 줄을 주고 비주얼은 없습니다.

하나의 호출은 병합을 기다리는 세트의 각 PR과 같이 많은 항목을 커버할 수 있습니다. 각 항목에 대해 링크, 사용자를 위해 변경하는 것, 선택 뒤의 증거, 위험 및 선택을 수집하세요. 호출이 필요하지만 모르는 사실에 대해 "unknown"을 작성하세요. 가지고 있지 않은 링크는 빼세요.

## 응답 작성

호출에 단어를 보내고, 이야기에는 아닙니다. 일어난 것을 그림을 세지 않고 100단어 미만으로 유지하고, 적게 일어났을 때는 더 짧게 하세요. 사용자를 위해 아무것도 변경하지 않은 작업은 빼세요. 각 항목에 약 30단어를 제공하세요. 응답은 항목 수와 함께 성장합니다: 두 항목은 그림을 세지 않고 총 150단어 미만이 필요하고, 30개는 훨씬 더 많이 필요합니다. 단어 수 아래에 머물기 위해 항목을 자르거나 축소하지 마세요: 목록 대신 카운트 없음, 항목 대신 링크 없음. 링크는 깊이를 추가할 수 있지만 응답만으로 결정하기에 충분해야 합니다.

사용자를 기다리는 것을 명명하는 하나의 짧은 문장으로 열거나, 아무것도 없다고 말하세요. 액션 아이템이 세부 사항을 제공합니다. 아무 일도 일어나지 않고 아무것도 사용자를 기다리지 않으면 그렇게 말하고 멈추세요.

그런 다음 일어난 것을 보여주세요. 그림을 먼저. 작업이 생성한 스크린샷과 비디오를 인라인으로 삽입한 다음 변경을 설명하는 다이어그램. 그런 다음 사용자가 요청한 것당 하나의 짧은 글머리 기호로 요약하세요: 그것이 어떻게 되었는지, 완료되었는지, 여전히 실행 중인지, 실패했는지, 확인되지 않았는지. 소리 내어 말하는 방식으로 각 줄을 작성하세요: "Search review: done" 또는 "Slow search: missing index"가 아니라 "Search was slow from a missing index". 발견되고 수정된 모든 버그를 명명하세요. 각 줄은 혼자 읽을 때 사실이어야 합니다. 여전히 사용자를 기다리는 것을 완료로 표시하지 말고, 액션 아이템이 말하는 것은 빼세요. 요약 아래에 사용자가 알아야 하거나 해야 하는 것을 변경하는 최대 세 개의 짧은 줄을 제공하세요. 그런 다음 당신이 스스로 할 수 있는 남은 작업을 한 줄로 명명하세요.

그런 다음 액션 아이템을 나열하세요. 사용자가 소유한 호출을 요청하세요. 병합, 승인 또는 선택과 같은. 당신의 선택을 제공하세요. 먼저 취할 단계는 당신의 선택으로 갑니다. 먼저 일어나야 하는 것도 마찬가지이고, 취소할 수 없는 것도 마찬가지입니다. 호출이 관련된 각 PR, 이슈 또는 에이전트의 번호나 링크를 제공하고, 옵션 간 호출에서도 마찬가지입니다.

호출에 형태를 맞추세요. 하나의 항목에 대한 호출은 하나의 글머리 기호입니다: 호출, 당신의 선택, 사용자를 위해 변경하는 것, 당신의 선택 뒤의 증거, 그리고 그 위험, 항목이 한 번 명명됨. 항목이 호출을 공유할 때 호출과 당신의 선택을 한 번 작성한 다음 각 항목에 자체 글머리 기호를 제공하세요. 가장 위험한 것을 먼저: 링크와 이름, 사용자를 위해 변경하는 것, 당신의 선택 뒤의 증거, 그리고 그 위험. 항목의 선택이 호출의 선택과 다를 때만 명명하세요. 낮을 때도 각 항목의 위험을 제공하세요. "Low risk: only the colors change."와 같이. 기다리는 것이 지연 이상일 때만 비용을 말하세요. 마감일이나 손실된 데이터와 같이.

옵션 간 호출의 경우 작업이 가중한 모든 옵션을 제공하고, 각각에 사용자가 얻는 것과 비용이 드는 것, 그리고 현재 상태가 있을 때. 그 비용은 호출의 위험이므로 별도의 위험 라인을 추가하지 마세요. 위의 스크린샷이 옵션을 보여줄 때 각 옵션의 이득과 비용을 그 스크린샷 아래에 작성하세요.

## 비주얼

비주얼은 그림입니다: 스크린샷, 비디오, Mermaid 다이어그램, `/visualize`의 차트 또는 다이어그램, 또는 생성된 이미지. Markdown 테이블은 이전과 이후 열이 있어도 비주얼이 아닙니다.

무언가가 문장보다 그림으로 파악하기 쉬울 때 그리세요: 설계나 시스템이 어떻게 작동하는지, 각 PR의 상태가 있는 PR 스택 또는 종속성 체인, 수정의 이전과 이후, 또는 나란히 옵션. 상태 목록, 액션 아이템 목록, 또는 연결되는 것이 없는 상자를 절대 그리지 마세요. 텍스트나 비주얼 전체에 걸쳐 사실을 두 번 제공하지 마세요.

각 비주얼을 한눈에 읽을 수 있을 만큼 작게 유지하세요: 최대 6개의 상자, 각각에 최대 8단어. 레이블을 "Tests: pass"와 같은 태그가 아니라 사람이 말할 평범한 단어로 작성하세요. 문장이 필요한 사실은 텍스트에 속하거나 어디에도 속하지 않습니다.

변경 사항이 보일 때 링크만이 아니라 스크린샷과 비디오를 인라인으로 삽입하세요. 보이는 변경 사항이 없으면 요약 줄을 "No screenshot yet"로 표시하고 화면에서 무엇이 변경되었는지 말하세요. 가지고 있는 사실에서 다이어그램과 차트를 그리세요: 어떻게 연결되는지에 대한 Mermaid 다이어그램과 숫자에 대한 `/visualize` 차트. 숫자를 절대 발명하지 말고, 캡처하지 않은 화면의 그림을 절대 그리거나 생성하지 마세요. 존재하는 아티팩트만 링크하세요.