배경
pick-up 스킬은 새 세션 시작 시 "이전 세션의 plan + memory + git state 를 읽고 다음 액션을 제안" 한다. 실제 사용해 본 결과 두 가지 한계가 드러났다.
한계 1 — Memory 를 읽기만 하고 검증하지 않음
Memory 파일은 시간이 지나면 stale 될 수 있는데 (특히 project 타입), pick-up 은 이를 사실로 간주하고 다음 액션을 추론한다.
예시 (일반 패턴):
- memory 에 "현재 작업 branch: feature-X" → 실제로는 이미 머지되어 branch 삭제됨
- memory 에 "Phase 1 진행: 11/12 done" → 실제로는 Phase 2 도 끝남
- memory 에 "pending ops: Secrets 등록" → 이미 등록 완료
결과: pick-up 이 잘못된 전제로 "Phase 1 마저 끝내시죠" 같은 엉뚱한 제안을 내놓는다.
한계 2 — 진짜 SSOT 인 세션 JSONL 미활용
결정 과정·디스커션·pivot 의 진짜 SSOT 는 ~/.claude/projects/*.jsonl 이다. 하지만 pick-up 은 이걸 읽지 않아서, 직전 세션의 "왜 이렇게 했는가" 를 복원하지 못한다.
반면 git log · task 파일 · CLAUDE.md 는 "무엇을 했는가" 만 기록할 뿐 "왜" 는 비어 있다.
제안
1. Stale Memory 자동 감지 (선-sanity check)
pick-up 진입 직후, memory 읽기 전에 간단한 sanity check 를 수행:
project_* 타입 memory 파일의 frontmatter last_verified 또는 mtime 과 최근 커밋 날짜/branch 상태를 대조
- 불일치 후보가 있으면 사용자에게 "이 memory 항목이 stale 일 수 있음" 경고 + 업데이트/삭제 제안
feedback_* 타입은 검증 불필요 (불변)
구현 아이디어:
- memory frontmatter 에 optional
stale_check 필드: 어떤 git/file 조건을 만족하면 stale 로 간주할지 간단한 규칙 적기 (예: branch_gone: feature-X, task_done: 026)
- pick-up 이 해당 규칙을 실행해 자동 플래그
2. JSONL Tail 활용
Level 2 옵션으로 직전 세션 JSONL 의 마지막 ~50 turns 만 읽는 단계를 추가:
- 세션별 JSONL 경로는
~/.claude/projects/<project-slug>/<session-uuid>.jsonl
- 가장 최근 파일의 tail 만 읽으면 "마지막에 뭐 하다가 끊겼는지" 복원 가능
- 전체 파싱은 비용이 크므로 tail 제한 엄수
3. 부트스트랩 순서 명시
SKILL.md 에 읽는 순서를 progressive disclosure 로 박기:
- Level 0 (필수): task/todo 파일 +
git log -20 + 현재 branch/working tree 상태
- Level 1 (필요 시): CLAUDE.md + MEMORY.md (이미 auto-load 되는 경우 재읽기 불필요)
- Level 2 (막혔을 때): 직전 세션 JSONL tail
- Level 3 (깊은 역사 필요): 프로젝트 관련 과거 세션 JSONL 다수 — 여기서는
wiki-sync 류 compile 결과를 먼저 참고
기본은 Level 0 에서 끝나야 하며, 확신 없을 때만 아래 Level 로 내려간다.
4. 다음 액션 제안 시 "근거" 명시
현재는 "다음 액션: X" 만 내놓는 경우가 있는데, 변경: 어떤 소스에서 도출했는지 한 줄 근거 첨부.
예: "다음 액션: Task 040 착수 (근거: tasks/README.md Phase 3 0/8 + 040 depends_on=[])"
근거가 memory 단독이면 사용자가 stale 여부를 즉시 판단할 수 있다.
Acceptance
연관
배경
pick-up스킬은 새 세션 시작 시 "이전 세션의 plan + memory + git state 를 읽고 다음 액션을 제안" 한다. 실제 사용해 본 결과 두 가지 한계가 드러났다.한계 1 — Memory 를 읽기만 하고 검증하지 않음
Memory 파일은 시간이 지나면 stale 될 수 있는데 (특히 project 타입), pick-up 은 이를 사실로 간주하고 다음 액션을 추론한다.
예시 (일반 패턴):
결과: pick-up 이 잘못된 전제로 "Phase 1 마저 끝내시죠" 같은 엉뚱한 제안을 내놓는다.
한계 2 — 진짜 SSOT 인 세션 JSONL 미활용
결정 과정·디스커션·pivot 의 진짜 SSOT 는
~/.claude/projects/*.jsonl이다. 하지만 pick-up 은 이걸 읽지 않아서, 직전 세션의 "왜 이렇게 했는가" 를 복원하지 못한다.반면 git log · task 파일 · CLAUDE.md 는 "무엇을 했는가" 만 기록할 뿐 "왜" 는 비어 있다.
제안
1. Stale Memory 자동 감지 (선-sanity check)
pick-up 진입 직후, memory 읽기 전에 간단한 sanity check 를 수행:
project_*타입 memory 파일의 frontmatterlast_verified또는mtime과 최근 커밋 날짜/branch 상태를 대조feedback_*타입은 검증 불필요 (불변)구현 아이디어:
stale_check필드: 어떤 git/file 조건을 만족하면 stale 로 간주할지 간단한 규칙 적기 (예:branch_gone: feature-X,task_done: 026)2. JSONL Tail 활용
Level 2 옵션으로 직전 세션 JSONL 의 마지막 ~50 turns 만 읽는 단계를 추가:
~/.claude/projects/<project-slug>/<session-uuid>.jsonl3. 부트스트랩 순서 명시
SKILL.md 에 읽는 순서를 progressive disclosure 로 박기:
git log -20+ 현재 branch/working tree 상태wiki-sync류 compile 결과를 먼저 참고기본은 Level 0 에서 끝나야 하며, 확신 없을 때만 아래 Level 로 내려간다.
4. 다음 액션 제안 시 "근거" 명시
현재는 "다음 액션: X" 만 내놓는 경우가 있는데, 변경: 어떤 소스에서 도출했는지 한 줄 근거 첨부.
예: "다음 액션: Task 040 착수 (근거: tasks/README.md Phase 3 0/8 + 040 depends_on=[])"
근거가 memory 단독이면 사용자가 stale 여부를 즉시 판단할 수 있다.
Acceptance
연관