submit-insight

name	submit-insight
description	오늘 회차의 학습 기록을 교육팀에 제출한다. "오늘 인사이트 제출해줘", "인사이트 제출", "회차 인사이트 보내줘", "오늘 배운 거 제출할게", "/submit-insight" 같은 요청에서 반드시 이 스킬을 사용할 것. "세션 로그 보내줘", "로그 전송" 같은 표현으로 들어와도 같은 작업이다. 회차 시작 시 "제출 준비 됐는지 확인해줘", "환경 점검해줘", "제대로 설치됐는지 봐줘" 같은 요청에도 이 스킬을 쓴다 (점검 모드). 코드 작성/디버깅과 무관한, 교육 회차 절차임에 유의.

인사이트 제출

교육 회차가 끝날 때 참가자가 오늘의 학습 기록을 교육팀에 제출하는 스킬. 제출된 기록은 다음 회차를 개선하는 데만 쓰인다.

무엇이 제출되는가

제출되는 것은 **오늘 세션의 대화 기록 전체(원본)**다. 참가자가 요약을 쓰거나 Claude가 인사이트를 정리해서 보내는 것이 아니다.

참가자가 "무엇이 제출되나요?"라고 물으면 이 점을 분명하게 답한다 — 오늘 주고받은 대화와 실행 기록이 그대로 전달되며, 교육팀은 이를 통해 참가자가 말로 표현하지 못한 막힘이나 진행자가 놓친 지점을 되짚는다. 참가자가 제출을 원치 않으면 그대로 존중하고 중단한다.

왜 인터뷰 방식인가

참가자는 인증코드 외에 아무것도 사전에 설정하지 않는다. 필요한 정보는 대화로 직접 물어봐서 채운다 — 설정 파일이나 커맨드라인 인자를 참가자가 다루게 하면 오탈자와 혼란이 생기기 쉽고, 교육 환경에서는 "대화하듯 답하면 끝"이 훨씬 매끄럽다.

환경 점검 (회차 시작 시)

참가자가 "제출 준비 됐는지 확인해줘", "환경 점검", "제대로 설치됐는지 봐줘"라고 하면 인터뷰 없이 점검만 실행한다:

bash <스킬 디렉토리>/scripts/upload.sh --check

이건 제출하지 않고 기록 파일 위치·크기·서버 연결만 확인한다. 회차 시작 시점에 돌리는 것이 요점이다 — 제출은 회차가 끝난 뒤에 일어나는데 그때 환경 문제로 실패하면 고칠 시간이 없고 기록도 사라진다. 특히 Windows 참가자는 경로·curl 동작이 다를 수 있으므로 시작 시 점검을 권한다.

점검이 실패하면 출력을 그대로 진행자에게 전달하도록 안내한다.

실행 순서

1. 인터뷰 — 아래 네 가지를 순서대로 묻는다. 이미 대화 중에 언급된 정보는 다시 묻지 않는다.
   • 인증코드 (진행자가 알려준 숫자 6자리)
   • 이름
   • 팀 소속 (예: 경영전략팀)
   • 회차 제목
2. 확인 — 받은 값을 요약해 보여주고 맞는지 확인받는다. 오탈자는 이 단계에서 잡는다.
3. 제출 — 확인을 받으면 scripts/upload.sh를 실행한다:

   bash <스킬 디렉토리>/scripts/upload.sh "<인증코드>" "<이름>" "<팀 소속>" "<회차 제목>"
   

   날짜와 기록 파일 위치는 스크립트가 현재 세션 기준으로 알아서 채운다 — 참가자나 Claude가 파일 경로를 직접 지정할 필요 없다.
4. 결과 보고 — 스크립트의 종료 코드와 출력을 그대로 전달한다.
   • 성공: 제출 완료를 알린다.
   • 실패: 실패 메시지를 그대로 보여준다. 인증코드 오타처럼 참가자가 고칠 수 있는 문제면 재시도를 제안하고, 서버 문제로 보이면 진행자에게 문의하도록 안내한다.
   • "다른 세션 기록이 N개 더 있습니다" 안내가 붙으면 반드시 참가자에게 전달한다. 회차 중 Claude Code를 재시작했다면 앞부분이 빠진 채 제출된 것이므로, 참가자가 진행자에게 알려야 교육팀이 기록을 맞출 수 있다. 이 안내는 성공 메시지에 묻히기 쉬우니 따로 짚어준다.

주의사항

• 세션을 요약하거나 분석하지 않는다. 원본 기록을 그대로 전달하는 것이 목적이므로 가공 없이 파일을 통째로 보낸다.
• 같은 회차에 대해 여러 번 제출을 요청받으면 매번 정상적으로 다시 제출한다 (중복 처리는 서버 책임).