dev-goraebap/handoff

handoff

지금 세션의 맥락을 다른 작업 환경의 에이전트에 그대로 넘겨주기 위한 brief Markdown을 만드는 스킬. 사용자가 다른 CLI/IDE/에이전트에서 같은 task를 이어가거나 분업하려 할 때, 매번 수작업으로 배경을 다시 쓰는 비용을 줄인다.

사용 시점

• 사용자가 /agent-cowork:handoff 또는 단축 트리거 /handoff 를 입력했을 때. 인자 없음 — 맥락은 에이전트가 알아서 파악.
• 자연어로 "이 내용 다른 에이전트에 전달할 수 있게 정리해줘", "brief 만들어줘", "맥락 정리해서 넘겨줄래" 같은 요청이 있을 때.
• 사용자가 "지금 이 주제를 새 창/다른 도구에서 이어가려고 한다"는 의사를 밝힐 때.

절차

1. 대화 전체를 되돌아보고 지금 사용자가 집중하고 있는 한 가지 task를 식별한다. 여러 주제가 섞여 있으면 가장 최근에 합의된 task 를 기본값으로 선택하고, 필요 시 한 줄로 "이 주제가 맞나요?" 확인.
2. 아래 출력 템플릿으로 정리한다.
3. 결과를 그대로 사용자가 복사할 수 있도록 채팅에 출력한다. 파일로 저장하지 않는다 (사용자가 요청하면 그때).
4. brief 뒤에 한 줄 안내를 덧붙인다: "위 내용을 복사해 다른 에이전트에 붙여넣으세요."

출력 템플릿

# 요청: <한 줄 제목, 동사구로>

## 배경
- <이 task가 왜 필요한지, 지금까지 파악된 제약>
- <관련 수치·사실·환경(언어/버전/OS 등) — 받는 쪽이 cold start로 놓칠 만한 것>

## 목표
- <달성해야 할 것, 3개 이하 bullet>

## 산출물
- <원하는 결과물 형식 — 파일 경로? 코드? 텍스트? 디렉토리 구조?>

## 이미 확보한 것
- <링크, 경로, 기존 결정, 시도한 접근법과 그 결과>

## 주의사항
- <피해야 할 방향, 이미 배제된 옵션과 이유>
- <실패 모드, 합의된 제약>

작성 원칙

길이: 200–400 단어

짧으면 정보 부족으로 받는 에이전트가 재질문, 길면 받는 쪽이 핵심을 못 잡는다. 받는 쪽이 10초 안에 "뭘 해야 하는지" 이해할 수 있어야 한다.

에이전트 독립적

• "Claude", "Codex", "Cursor" 같은 특정 에이전트 이름·기능을 가정하지 않는다.
• Claude Code에만 있는 tool(예: WebFetch, Skill tool, MCP 서버 이름)을 전제로 쓰지 않는다.
• 단, 받는 환경이 명확하면(사용자가 "Codex에 넘길 거야" 라고 말했으면) 해당 환경에서 쉽게 매핑되는 표현으로.

맥락에서 빼야 할 것

• 스킬 이름이나 경로를 고민한 과정 (결정만 적고 과정은 생략)
• 이미 취소되거나 폐기된 옵션 (주의사항에 "X는 배제 — Y 이유"로 한 줄만)
• 일반적인 인사·맥락 점검·에이전트 내부 확인 대화

맥락에서 반드시 남겨야 할 것

• 사용자의 실제 도메인 정보: OS, 언어 버전, 프레임워크, 파일 경로, 도메인 용어
• 이미 내려진 결정과 그 이유 (받는 에이전트가 결정을 뒤집지 않도록)
• 완료된 작업 vs 지금 넘기는 task 구분 (제목·목표는 지금 넘기는 것만)

톤

• 사용자의 평상 언어를 그대로. 한국어 대화면 brief도 한국어.
• 자신감 있는 평서형: "~할 것이다", "~한다". "~같습니다" 류의 불확실 표현은 실제 불확실한 경우에만.

예시

입력

사용자: /handoff

대화 맥락 (요약)

• Angular 21 프론트엔드 프로젝트에서 Feature-Sliced Design 도입 검토 중
• FSD 공식 LLM 문서를 확보 (318KB, 8200줄) — 파일 자체는 hoho-hr-web/docs/fsd-llms-full.md에 저장됨
• 그대로 프로젝트 레포에 두면 대화마다 컨텍스트 과소비
• 해결책: 재사용 가능한 Claude Code 스킬로 패키징, SKILL.md 활성화 시 인덱스만 로드되고 원문은 references/ 분할

출력

# 요청: FSD 공식 문서를 재사용 가능한 에이전트 스킬로 패키징

## 배경
- Angular 21 프론트엔드 프로젝트에서 Feature-Sliced Design(FSD) 도입 검토 중.
- FSD 공식 LLM 문서 확보: 318KB / 8,216줄 / 약 50K+ 토큰.
- 프로젝트 레포에 그대로 두면 대화마다 전문을 로드해 컨텍스트 과소비 발생.

## 목표
- 범용 지식 스킬로 제작 (특정 프로젝트/프레임워크 종속 금지).
- Progressive Disclosure 구조: SKILL.md는 라우팅 인덱스만, 원문은 섹션별 references에서 필요 시 로드.
- FSD v2.0 → v2.1 pages-first 마이그레이션 섹션은 특히 잘 닿을 수 있게.

## 산출물
- 스킬 디렉토리 하나 — `SKILL.md` + `LICENSE.md` + `references/NN-*.md` 7~8개 섹션.
- skills-ref validate 통과.

## 이미 확보한 것
- 원문: https://feature-sliced.design/llms-full.txt
- 라이선스: MIT, © 2018-2026 Feature-Sliced Design core-team.
- 원문 리포: https://github.com/feature-sliced/documentation

## 주의사항
- MIT 재배포 조건(저작권 + 라이선스 고지) 반드시 유지.
- SKILL.md 본문은 500줄 이하, description에 트리거 키워드 3종 이상 포함.
- 전체 원문을 단일 md로 두는 방식은 배제 — Progressive Disclosure 이점이 사라짐.

위 내용을 복사해 다른 에이전트에 붙여넣으세요.

제약 / 안티패턴

• 파일로 저장하지 않는다. 사용자가 /handoff --save <path> 식으로 명시 요청하면 그때만 저장을 고려 (이 스킬 범위 밖, 별도 확장).
• 맥락 전체 요약이 목적이 아니다. 지금 넘기는 하나의 task에 집중. 세션에서 여러 개 task를 다뤘으면 가장 최근 합의된 것만.
• 완벽 지향 금지. brief는 완성품이 아니라 starting point. 받는 에이전트가 추가 질문하는 걸 전제로 한다.