--- name: recall description: "자신의 채팅 기록, 라이브 상태 및 공유 기록 (사용자 보고서, 이전 수정, 인시던트)에서 최근 작업 컨텍스트를 재구성한 다음 지금 상황과 다음에 해야 할 일에 대한 간결한 현재 상태 브리프를 반환하세요. 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', 작업 시작 또는 재개 전에 사용하세요." disable-model-invocation: true --- # Recall **작업을 시작하거나 재개하기 전에 사용자의 최근 작업 컨텍스트를 재구축하고 지금 상황과 다음에 해야 할 일에 대한 간결한 캡슐을 반환합니다.** 간결하고 주제에 맞게 유지하세요. 범위 내 스레드가 필요로 하는 것만 읽은 다음 멈추세요. 컨텍스트는 두 개의 기록에 있습니다. 자신의 채팅 기록은 무엇을 했고 결정했는지를 보유합니다. 공유 기록은 다른 이름으로 동일한 코드 주변에서 일어난 모든 것을 보유합니다: 사용자가 계속 보고하는 증상, 배송되고 되돌려진 수정, 프로덕션에서 여전히 발생하는 오류. 그 두 번째 기록은 **why** 스킬이 소스 제어, 이슈 트래커, 채팅 및 이슈 채널, 장문 문서, 오류 추적 전체에 걸쳐 검색하는 것입니다. 긴 버그 테일이 있는 기능은 대부분의 이야기를 거기에 보관하므로 트랜스크립트만으로 재구성하지 마세요. 트랜스크립트는 `~/.cursor/projects//agent-transcripts//.jsonl`에 있으며, 여기서 ``는 선행 슬래시가 삭제되고 각 "/"가 "-"로 변환된 워크스페이스 경로입니다 (따라서 `/Users/you/proj`는 `Users-you-proj`가 됩니다). 모든 줄은 하나의 채팅 메시지입니다. 1. 분류한 다음 라우팅하세요. 재개할 특정 이전 채팅은 이것이 아니라 `session-pickup` playbook입니다. 습관을 내구성 있는 스킬로 전환하는 것은 `automate-me`입니다. 작업에 대한 인간이 읽을 수 있는 요약은 다른 작업입니다. Recall은 행동하기 전에 최근 채팅 전체에 걸쳐 작업 컨텍스트를 로드합니다. 사용자가 이미 전체 상태 캡슐 (경로, 브랜치, 변경)을 제공했다면 그것을 사용하고 마이닝을 건너뛰세요. 2. 검색하기 전에 범위를 고정하세요. 창을 고정하세요 ("recent"는 실제 범위입니다. 기본값은 지난 7일), 명명된 경우 주제, 그리고 워크스페이스 (기본값은 활성 것. 요청받지 않고는 다른 프로젝트의 트랜스크립트를 절대 읽지 마세요). 범위를 되돌려 진술하세요. "all"을 조용히 "recent N"으로 절대 전환하지 마세요. 3. 채팅 기록 전체에 걸쳐 팬 아웃하세요. 빠르고 저렴한 모델에서 병렬 서브에이전트를 생성하고, 각각 코퍼스의 슬라이스를 취합니다. 모든 서브에이전트에게 후보를 UUID 이름이 아니라 실제 수정 시간 (`ls -t`)으로 정렬하고, 주제를 먼저 grep한 다음 일치하는 채팅과 관련 영역만 읽고, 현재 채팅과 명백한 노이즈 (서브에이전트, eval 및 테스트 채팅)를 건너뛰라고 말하세요. 각각은 동일한 스키마를 반환합니다. 채팅당 하나의 블록: 주제, 사용자의 목표, 결정, 열린 스레드, 투쟁과 수정, 아티팩트 (PR, 티켓, 브랜치), 각각 채팅 UUID를 인용합니다. 한두 개의 채팅의 경우 팬 아웃을 건너뛰고 직접 검색하세요. 원시 트랜스크립트는 서브에이전트에 남습니다. 메인 스레드는 그들의 발견 사항만 받습니다. **poteto-mode** 스킬의 Subagents 섹션에 따라 작업에 대한 각 서브에이전트의 추론 수준과 빠른 또는 표준 속도를 선택하세요. 4. 주제가 기능, 파일, 하위 시스템, 영역 또는 버그를 명명할 때마다 공유 기록을 스윕하세요. 이것은 판단 호출이 아니라 기본값이며, "my work on X"는 면제하지 않습니다. **why** 스킬의 소스 조사자에게 넘기되, 질문을 "why was this built this way"에서 "what's the current state, what's been tried and didn't hold, and what are users still reporting"으로 조종하세요. 소스별 playbook을 재사용하고, 조사자를 채팅 기록 마이닝과 병렬로 실행하고, 자세를 상속하세요: 소스당 하나의 조사자, null 결과는 발견 사항, 사용 불가능한 MCP를 건너뛰고 그렇게 말하세요. 돌아온 것을 브리프에 접으세요. 명명된 대상이 없는 순수 활동 recall ("what did I do this week")에 대해서만 이 단계를 건너뛰세요. 여기서 자신의 기록과 라이브 상태가 전체 답입니다. 5. 라이브 상태에 대해 검증하세요. 마이닝과 스윕이 표면화한 PR, 브랜치 및 티켓을 `git`와 `gh`로 확인하세요. 답이 에이전트가 실제로 한 것 (실행한 도구, 읽은 파일, 히트한 오류)에 달려 있을 때 트리밍된 로컬 사본이 아니라 전체 트랜스크립트를 읽으세요. 6. 아래 계약에 브리프를 작성하세요. 스레드로 그룹화하세요. 명명된 주제에 머물러 있으세요. ## 출력 계약 캡슐로 이끌고, 그 다음 스레드 상태, 그 다음 문제, 그 다음 다음 이동. 더 깊은 세부 사항은 아래로 가거나 잘립니다. - **Capsule (캡슐).** 최대 5개의 글머리 기호. 이 작업이 무엇이고 전체적으로 어디에 있는지. - **Threads (스레드).** 각각 한 줄, 정확히 하나의 상태 태그로 접두사: `[merged #N]`, `[open PR #N]`, `[in flight ]`, `[verified, uncommitted]`, `[reverted #N]`, 또는 `[planned, not started]`. 태그가 없는 스레드는 아직 완료되지 않았으므로 태그를 붙이세요. - **Problems (문제).** 최대 5개, 반복되는 것들. 사용자가 계속 보고하는 증상과 배송되고 되돌려진 모든 수정을 포함하여 다음 시도가 마지막 시도가 실패한 곳에서 시작하도록 하세요. - **Next move (다음 이동).** 가장 유용한 다음 액션 하나, 구체적. 인접한 기능이나 티켓은 이것을 차단하지 않는 한 빠집니다. 캡슐과 스레드 라인이 화면을 넘어서면 스레드를 자르기 전에 세부 사항을 자르세요. **unslop** 스킬을 통해 브리프를 작성하고, 채팅 발견 사항을 UUID로 인용하고 공유 기록 발견 사항을 소스 (PR #, 티켓 ID, 채팅 퍼머링크, 오류 트래커 이슈)로 인용하고, 공개 출력 전에 비공개 컨텍스트를 삭제하세요. **Reply:** 위의 계약에 대한 브리프.