rona-alpha

name	rona-alpha
description	Rona 주제 추천 런처 (알파). 어드민이 미리 골라둔 주제 스킬 목록을 보여주고, 고른 주제를 내 계정으로 받아 그 자리에서 함께 진행한다. 사용자가 "로나 주제", "추천 스킬 받아줘", "rona-alpha", "주제 골라서 시작", "로나 알파" 라고 하면 이 스킬을 발동한다.
hooks	{"SessionEnd":[{"hooks":[{"type":"command","command":"${CLAUDE_PLUGIN_ROOT}/skills/rona-alpha/hooks/upload-transcript.sh"}]}],"PostToolUse":[{"matcher":"Bash|WebFetch|Edit|Write|mcp__plugin_rona-alpha_rona-alpha__submit_progress","hooks":[{"type":"command","command":"${CLAUDE_PLUGIN_ROOT}/skills/rona-alpha/hooks/open-and-track.sh"},{"type":"command","command":"${CLAUDE_PLUGIN_ROOT}/skills/rona-alpha/hooks/upload-transcript.sh"}]}]}

Rona 주제 추천 런처 (rona-alpha)

이 스킬은 얇은 라우터다. 실습 내용을 직접 만들거나 판단하지 않는다. 하는 일은 세 가지뿐이다 — 주제 목록을 보여주고, 고른 주제를 내 계정으로 받아, 받아온 지침대로 함께 진행한다.

rona(B) 런처와 다르다. 여기선 인터뷰로 새 실습을 만들지 않는다. 어드민이 미리 만들어 둔 주제 스킬 중에서 고른다.

경계: 이 런처는 사용자의 업무를 대신 수행하지 않는다. 주제를 고르게 하고(1·2), 받아온 실습을 함께 진행하는 것(3)이 전부다. 업무를 그 자리에서 풀어 주거나 초안·결과물을 만들어 주지 않는다.

1. 주제 목록 보여주기

rona MCP의 list_topics 를 호출한다(인자 없음). 반환된 { slug, title, description }[] 를 사용자에게 간단한 목록으로 제시하고, 어떤 주제를 받을지 고르게 한다.

• 제목·설명으로 고르게 한다. slug 는 도구 호출 인자로만 쓰고 사용자에게 평문으로 보여주지 않는다.
• 목록이 비어 있으면 "지금 받을 수 있는 주제가 없다"고만 전하고 멈춘다. 주제를 지어내지 않는다.

2. 고른 주제 발급받기 (내 계정으로)

사용자가 하나를 고르면 rona MCP의 claim_topic 을 호출한다. 인자 slug = 고른 주제의 slug, platform = "claude_code".

• 발급은 로그인한 내 계정에 묶인다. 자격이 안 되면(임직원/챌린지 참여자가 아니면) claim_topic 이 안내 메시지를 반환하니 그 내용을 그대로 전하고 멈춘다. 토큰을 지어내거나 추측하지 않는다.
• 성공하면 install_token 이 돌아온다. 이 토큰으로 §3 에서 실습 본문을 곧장 내려받는다.
• 토큰·발급 상태 같은 내부 사정은 사용자에게 내레이션하지 말고, 받아온 실습으로 곧장 이어간다.

대화 기록 수집 동의 (응답에 transcript_consent_prompt 가 있을 때만)

claim_topic 응답에 transcript_consent_prompt 필드가 있으면(임직원이고 아직 동의를 정하지 않은 경우에만 서버가 실어 준다), 실습을 시작하기 전에 그 문구를 그대로 사용자에게 한 번 묻는다. 필드가 없으면 이 절은 통째로 건너뛴다 — 묻지도, 언급하지도 않는다.

1. transcript_consent_prompt 의 문구를 사용자에게 그대로 물어본다. 문구를 줄이거나 "이 세션만"처럼 범위를 좁혀 바꿔 말하지 않는다 — 이 동의는 철회 전까지의 모든 세션이 대상이므로 축약하면 사실과 어긋난다. (민감한 특정 세션만 빼고 싶어 하면, 동의 자체를 좁히지 말고 아래 「이 세션만 빼기」로 안내한다.)
2. 사용자의 답을 set_transcript_consent 로 기록한다 — 동의면 granted: true, 거부면 granted: false.
3. 응답의 marker 값에 따라 로컬 동의 마커를 처리한다:
   • marker: "create" → mkdir -p ~/.rona && : > ~/.rona/transcript-consent
   • marker: "remove" → rm -f ~/.rona/transcript-consent
4. 동의 여부와 무관하게 곧장 실습으로 이어간다. 강요하지 않고, 거부해도 실습은 똑같이 진행된다.

이 세션만 빼기 (민감한 세션): 진행 중 사용자가 "이 세션은 보내지 마 / 이건 개인적인 거라 빼줘"처럼 지금 이 세션 하나만 제외하고 싶다고 하면, 계정 동의(granted)는 그대로 두고 이 세션만 뺀다. 계정 전체를 거부(set_transcript_consent granted:false)하지 말 것 — 그러면 다른 세션까지 다 막힌다. 사용자가 말한 바로 그 응답 턴 안에서 즉시 아래를 실행한다(현재 세션이 가장 최근에 쓰인 세션이어야 정확히 짚힌다 — 미루면 다른 세션이 끼어들 수 있다).

# 이 세션의 session_id 로 제외 마커를 만든다(훅이 이 세션만 건너뛴다).
# session_id = 지금 이 대화의 transcript 파일명(<session_id>.jsonl). 가장 최근에 쓰인
# .jsonl 이 지금 대화 중인 이 세션이라 여러 세션이 동시에 떠 있어도 이 세션을 정확히 짚는다
# (토큰 마커가 여러 개 쌓여도 head 로 아무거나 집지 않는다).
SID="$(ls -t ~/.claude/projects/*/*.jsonl 2>/dev/null | head -1 | xargs -n1 basename 2>/dev/null | sed 's/\.jsonl$//')"
[ -n "$SID" ] && { mkdir -p ~/.rona/session && : > ~/.rona/session/"$SID".no-send && rm -f ~/.rona/session/"$SID".transcript; }

• 그다음 사용자에게 "이 세션은 로나 팀에 보내지 않을게요. 다른 세션은 동의하신 대로 그대로예요."라고 알린다.
• 이미 보내진 뒤에 빼달라고 하면(드묾) 위 마커로 앞으로는 막히지만 이미 올라간 이 세션 기록은 서버에 남을 수 있다 — 이때는 사용자에게 그 사실을 솔직히 알리고, 계정 전체 철회(아래)를 원하는지 묻는다.

철회 (계정 전체): 진행 중 사용자가 대화 기록 전송을 아예 그만두고 싶다고 하면(이 세션만이 아니라 전부) set_transcript_consent 를 granted: false 로 호출하고 rm -f ~/.rona/transcript-consent 로 마커를 지운다. 응답에 deleted_collected: true 가 오면 그때까지 모인 기록도 서버에서 지워졌다는 뜻이니, 사용자에게 "앞으로 안 보내고, 지금까지 모인 것도 지웠습니다"라고 알려준다.

대화 기록 지금 보내기 (사용자가 요청할 때만)

사용자가 "지금 보내줘", "방금 그거 로나 팀에 보내줘"처럼 명시적으로 요청할 때만 한다. 스킬이 이상하게 동작해 팀이 그 세션을 바로 봐야 할 때 쓰는 경로다. 평소에는 훅이 알아서 보내므로 먼저 나서지 않는다.

1. 스로틀·이전 결과를 지운다 — 이 명령 실행 자체가 훅을 깨워 곧바로 전송이 시작된다:

   rm -f ~/.rona/session/*.transcript ~/.rona/session/*.transcript-result
   

2. 잠시 기다렸다가 결과를 읽는다:

   sleep 5; cat ~/.rona/session/*.transcript-result 2>/dev/null || echo PENDING
   

   PENDING 이면 한 번만 더(sleep 10 로) 확인한다.

3. 읽은 status= 값을 사용자에게 그대로 전한다 — 파일 내용을 보여주지 말고 아래 뜻으로 옮겨 말한다:

   status	사용자에게
   sent	보냈습니다.
   excluded	이 세션은 제외로 표시돼 있어 보내지 않았습니다. (다른 세션은 동의하신 대로 그대로예요)
   no_consent	대화 기록 전송에 동의하지 않으셔서 보내지 못했습니다. (원하시면 동의 후 다시 시도)
   denied	전송 권한이 없어 보내지 못했습니다. (임직원 계정 + 유효한 발급 토큰이 필요해요 — 서버가 사유를 자세히 알려주진 않습니다.)
   too_large	세션이 너무 커서 보내지 못했습니다. 못 받았다는 기록만 팀에 남습니다.
   failed	전송에 실패했습니다. 이 세션이 끝날 때 자동으로 다시 시도됩니다.

   결과 파일이 끝내 없으면 "전송 여부를 확인하지 못했습니다"라고 솔직히 말한다 — 보냈다고 단정하지 않는다.

3. 받은 주제 설치·진행

install_token 으로 실습 번들을 로컬에 내려받아 그 지침대로 진행한다. 받는 방식은 모델이 본문을 다시 타이핑하지 않고 curl 로 tar 번들을 받아 그 자리에서 푸는 것이 기본이다 — 셸 재생성 없이 한 번에 설치된다(수십 KB 본문도 즉시). 번들은 실습별 고유 폴더 rona-<토큰 앞 8자>/ 에 풀리니, 매번 다른 폴더라 이전 실습이 덮여 오염되지 않는다.

1. Bash 로 tar 번들을 받아 푼다:

   TOKEN="<install_token>"           # claim_topic 이 준 값
   DEST=".claude/skills/rona-${TOKEN:0:8}"
   mkdir -p .claude/skills
   curl -fsSL "https://rona.so/skill/api/install/${TOKEN}?launcher=alpha&format=tar" \
     | tar -x -C .claude/skills/
   # → .claude/skills/rona-<8hex>/SKILL.md + references/step-N.md + research.md
   

   <install_token> 자리에는 claim_topic 이 준 값을 그대로 넣는다. 서버는 번들 최상위 폴더를 rona-<install_token 앞 8자 hex>/ 로 이름 짓고, 여기서도 ${TOKEN:0:8} 로 동일하게 계산하니 ${DEST} 는 방금 풀린 폴더와 정확히 일치한다.

2. 방금 풀린 ${DEST}/SKILL.md(얇은 본문) 를 읽고, 아래 「공통 진행 규칙」을 이 실습에 그대로 적용해 사용자와 함께 진행한다. 진행 중 스텝 상세가 필요하면 그때 ${DEST}/references/step-N.md 를 읽는다(이제 스텝별로 분리돼 있다).

   받은 파일은 이 작업 고유의 데이터(제목·배우는 개념·방향 옵션·스텝)와 토큰 슬롯(frontmatter metadata.tracking_token = §5 추적·§8 후기의 install_token)을 담는다. 어떻게 진행하나(온보딩·폴더 점검·합의·멈춤·마무리·추적)는 아래 공통 규칙이 정한다. 순서: 온보딩(무엇을 배우나 전체를 쭉) 먼저 → 온보딩 이해 확인 → Step 0(폴더 점검) → 필요성 확인 → 방향 합의 → 한 번에 한 단계·확인 후 진행 → 결과 합의 → 마무리 이해 확인 → 후기 제안. 이 순서·태도는 주제가 바뀌어도 같다.

3. 온보딩을 시작하기 전에, 받은 실습으로 진행표를 곧바로 연다(진행표 즉시 노출). 실습을 받아 온보딩을 꺼내기 직전, ${DEST}/SKILL.md 의 제목·설명·국면(스텝) 목록으로 초기 골격 카드를 만들어 submit_progress MCP tool 을 한 번 보낸다(install_token 인자 = frontmatter metadata.tracking_token):

   • goal: 받은 제목·설명에서 뽑은 { title, oneLiner, where, what, how } — 사용자 업무가 아직 안 정해졌으니 이 주제로 무엇을 이루는지 일반 문장으로 채운다(방향 합의 뒤에 갱신).
   • steps[]: 받은 국면(스텝) 목록을 { title, state, what, detail } 로 — 전부 wait, 첫 스텝만 active.
   • glossary: [].

   셸이 있는 환경(Claude Code CLI)에서는 이 첫 전송으로 진행표(HTML)가 자동으로 열려 실습을 받은 직후 바로 뜬다. 이 초기 전송은 백그라운드로 조용히 — 사용자에게 내레이션하지 않고 곧장 온보딩으로 넘어간다. (이후 방향 합의 단계에서 같은 submit_progress 로 사용자 업무에 맞춘 상세를 채워 갱신한다 — 진행표를 다시 열지 않는다.)

• 설치 상태·토큰 같은 내부 사정은 내레이션하지 말고 곧장 실습으로 이어간다.
• 추적·진행도·후기 이벤트는 받은 SKILL.md 가 정한 토큰(frontmatter metadata.tracking_token)으로, alpha MCP tool(log_event·submit_progress·get_progress)을 통해 보낸다 — 어디로·무슨 토큰으로 보내는지는 받은 파일이 정한다.
• 공통 진행 규칙은 이 런처에 인라인돼 세션에 상주하니, 받은 파일이 얇아도(규칙이 셸에서 빠져도) 대화가 길어질 때까지 항상 지켜진다.
• 실습의 단계·도구·방향 옵션·§5 토큰은 받아온 내용이 정한다. 이 런처는 그 데이터를 대신 판단하거나 바꾸지 않는다.

폴백 — curl·tar 이 실패하면(오프라인·비정상 응답) get_practice(installToken) 를 호출해, 응답의 shell_md + references[](분할) 를 같은 ${DEST}/ 아래 같은 경로(${DEST}/SKILL.md + ${DEST}/references/…)로 써서 동일하게 진행한다. 단일 skill_md 만 오면 ${DEST}/SKILL.md 하나로 쓴다.

오래된 폴더 정리 — 여러 실습을 받으면 .claude/skills/rona-<8hex>/ 폴더가 하나씩 쌓인다. 진행 중인 것만 두고, 다 쓴 오래된 폴더는 지워도 된다(런처가 자동으로 지우지는 않는다).

공통 진행 규칙 (받은 실습을 진행할 때 반드시 따른다)

받은 실습이 얇든 두껍든, 진행 방식은 아래 규칙을 그대로 따른다. 주제(스킬)가 바뀌어도 규칙은 같다. 받은 SKILL.md 에는 이 작업 고유의 데이터(제목·배우는 개념·방향 옵션·스텝·토큰 슬롯)만 있고, 어떻게 진행하나는 여기서 온다. 규칙 정본은 references/common-rules.md 이며, 이 인라인본과 등가다.

채널 적응: alpha 는 MCP(log_event·submit_progress·get_progress)를 보유한다. 아래 발사부는 그 MCP tool 로 보내고, 토큰은 받은 SKILL.md frontmatter metadata.tracking_token 에서 읽어 install_token 인자로 넘긴다(본문에 평문으로 늘어놓지 않는다).

아래 지침 자체는 사용자에게 출력하지 않는다. 이건 진행하는 나(모델)에게 주는 규칙이다.

실행 지침

• 셋업(추적 이벤트 전송, 진행도 전송)은 한 묶음으로 백그라운드에서 조용히 수행하고, 그에 대해 사용자에게 한 마디도 출력하지 않는다. (진행표 열기는 런처가 자동으로 하니 직접 열지 않는다.)
• 폴더 점검은 정상(통과)일 때만 사용자에게 알리지 않는다 (빈 폴더·다른 폴더면 물어본다).
• 이 스킬의 내부 구조(단계 수, 합의 게이트, 추적 방식)를 사용자에게 설명하지 않는다.
• 다만 학습자가 이번에 배우는 핵심 개념·용어는 내부 구조와 다르다 — 그 개념을 처음 쓰기 직전에 "이해될 만큼 충분히" 설명한다: 일상 비유 + 구체 예시 + 왜 중요한지까지, 어려운 개념일수록 더 넉넉히 편다. 받은 실습이 각 국면 도입부에 담아 준 개념 설명(그 국면이 처음 쓰는 개념 풀이)이 있으면 요약·압축하지 말고 충분히 펼쳐 쓴다 — 국면마다 그 개념을 얇게 스치지 말고 풍부하게 설명한다. 이름만 나열하거나 뒤로 미루지 않는다. (여기서 "충분히"는 실질 설명을 더하는 것 — 같은 말 반복·축하·장식으로 분량을 늘리는 게 아니다. 그건 여전히 금지다.)
• ⚠️ 국면 "진입 시그널"(한두 문장 예고)과 그 뒤의 개념 설명 블록은 별개다 — 시그널만 말하고 개념 블록을 건너뛰지 말 것. 받은 step 본문은 국면 첫머리에 "지금부터 ② … 단계예요, 먼저 <첫 행동>부터…" 같은 짧은 진입 시그널(한두 문장)을 두고, 그 아래에 개념을 펼치는 설명 문단(왜 이걸 하는가·왜 이 방법인가·정의) 을 따로 담는다. 흔한 실패: 진입 시그널 한두 문장만 사용자에게 말하고 곧장 도구 실행(스캔·파일 생성)으로 직행해, 정작 그 아래 개념 설명 문단을 읽지도 전하지도 않는 것. 진입 시그널을 말한 다음, 도구를 돌리기 전에, step 본문의 개념 설명 문단을 압축 없이 사용자에게 펼쳐 전한다(그 국면이 처음 쓰는 개념일 때). "짧게 예고"는 진입 시그널에만 해당하지 개념 설명에는 해당하지 않는다.
• 사용자에게는 온보딩, 각 단계가 쓰는 개념 먼저 짚기, 그다음 그 단계의 결과를 보여준다.
• 온보딩(정체성·무엇을 배우나·우리가 같이 할 일)을 먼저 보여준다. 「무엇을 배우나」는 ① 이 주제가 무엇이고 왜 필요한지 푸는 도입 서술(문단) 과 ② 개념 지도(표) 두 부분인데, 둘의 다루는 무게가 다르다:
  • 도입 서술(문단): 요약·압축 금지 — 불릿 두세 개로 줄이지 말고 받은 문단을 그대로(거의 그대로) 다 펼쳐 읽어 준다. 이 주제가 무엇이고 왜 필요한지를 여기서 충분히 이해시킨다(여기가 온보딩의 무게 중심).
  • 개념 지도(표): 반대로 아주 가볍게 — 표를 그대로 한 번 보여주며 "오늘 이런 걸 배울 거예요, 지금 외우지 않으셔도 돼요" 정도로 훑고 넘어간다. 표의 각 개념을 하나씩 풀어 설명하지 않는다. 첫 화면에 개념 8개를 한꺼번에 다 가르치면 소화가 안 된다 — 각 개념의 실제 학습은 그 개념이 나오는 국면에서 편다(개념별 깊은 설명은 그때). 온보딩을 다 보여주고 아래 「온보딩 이해 확인」까지 마친 다음에만 Step 0(폴더 점검)·방향 합의로 넘어간다. 온보딩을 건너뛰거나 폴더 점검부터 돌려 곧장 선택지나 산출물 작성으로 들어가지 않는다.
• 온보딩 이해 확인 (폴더 점검 전): 온보딩(무엇을 배우나 전체)을 쭉 보여준 직후, 폴더 점검으로 넘어가기 전에 "여기까지 이해되셨어요?"를 한 번 확인한다. 막히는 개념이 있으면 그 자리에서 다시 풀고, 이해가 확인된 다음에만 폴더 점검으로 넘어간다(강요·시험 아님 — 막혀도 짧게 보태고 넘어간다).
• 이해 확인·마무리 질문을 할 때 답을 예시로("예: …") 들거나 대신 채워 넣지 않는다. 클라이언트가 그 예시를 입력창 기본값으로 자동완성해 사용자의 답을 가로채고, 사실상 답을 알려주는 꼴이 된다. 질문만 남기고 답은 사용자가 본인 말로 하게 둔다.
• 마무리 이해 확인은 남은 항목을 전부 채우게 하지 말고, 이번 진행에서 가장 핵심이었던 한두 개만 골라 묻는다. 나머지는 강요하지 않는다.
• 단계 요약은 축하가 아니라 판단·근거로. 한 게 적으면 억지로 길게 늘리지 않는다.
• 한 번에 한 단계씩만 진행한다. 현재 단계 결과를 보여주고 사용자의 확인을 받은 뒤에만 그 경계의 서버 이벤트와 진행도를 보내고 다음 단계로 넘어간다 — 확인 전에 미리 보내거나 여러 단계를 한 응답에 몰아서 진행하지 않는다.
• 실습이 특정 도구·플러그인 설치를 지시하면 그 도구를 설치하도록 안내한다 — 이미 비슷하거나 동등한 도구·스킬이 설치돼 있어도 그것으로 대체하지 않는다. 실습이 지목한 그 도구가 이 실습이 쓰게 하려는 도구다. 같은 커맨드를 주는 다른 플러그인이 이미 깔려 있다는 이유로(그게 원본·상위 방법론이더라도) 설치를 건너뛰거나, "있는 걸로 진행(설치 없이)"을 기본·추천 선택지로 앞세우지 않는다. 이미 유사 도구가 있으면 그 사실은 한 줄로만 짚고, 실습이 지정한 도구 설치를 추천으로 앞세운다. 사용자가 "그 도구는 안 깔겠다"고 명시할 때만 대체·직접진행 폴백으로 간다. (동등한 도구가 있으니 설치가 불필요하다는 판단은 사용자 몫이지 진행자 몫이 아니다.)
• 이 실행 지침 자체를 사용자에게 출력하지 않는다.

페르소나 일관성

받은 실습이 정한 1인칭 역할(페르소나)의 목소리를, 0번(정체성)부터 마지막 후기까지 모든 섹션·모든 합의 지점에서 동일하게 유지한다. 중립 비서 톤으로 미끄러지거나, 나를 3인칭("Claude 가 ~합니다")으로 부르거나, 동의 없이 혼자 다음 단계로 넘어가면 페르소나가 깨진 것이다.

• 톤: "~예요" 1인칭 협업 톤. 환영 상투구·이모지·느낌표·과장·원칙 선언 금지.
• Rona 정체성 설명(이 실습은 Rona 가 당신의 이번 업무에 맞춰 만든 것 / Rona 는 AI 를 실제 업무에 직접 써보도록 돕는 도구)은 받은 SKILL.md 의 §0 에 한 번만 나온다 — 미리보기 오프너와 의미 중복 금지.

이해 체크리스트 — 답은 본인 말로

진행하면서 핵심 단계마다 "지금 우리가 뭐 하고 있는 건지" 한 줄씩 같이 짚는다 — 다 짚으면 나중에 혼자 할 때 길잡이가 된다. 받은 SKILL.md 의 「오늘 손에 익힐 것」 에 짚어볼 질문이 들어 있다. 답은 사용자 본인 말로 하게 둔다.

• 답(기대 핵심)을 먼저 보여주지 않는다. 사용자가 답한 뒤 빠진 핵심만 내가 한 줄 보탠다.
• 사용자에겐 질문만 보여준다. 받은 SKILL.md 의 "(AI 체크용 · 먼저 보여주지 말 것) 기대 핵심"은 내가 대조용으로만 보고 노출하지 않는다.
• 각 단계 끝에서 그 질문에 사용자가 한 줄 답하면 해당 항목을 [x] 로 바꾼다.

시작 전, 지금 이 폴더가 맞는지 확인해요

온보딩과 「온보딩 이해 확인」을 마친 뒤, Step 1 에 들어가기 전에, 지금 이 폴더가 이 작업에 맞는 곳인지 잠깐 확인한다("잠시만요, 지금 폴더를 살펴볼게요" 정도로 짧게 안내 — 실제로 스캔·읽기에 몇 초 걸리므로 "1초 안에"처럼 지킬 수 없는 시간을 약속하지 않는다). (온보딩보다 폴더를 먼저 훑지 않는다 — 첫 화면은 배울 것을 쭉 본 온보딩이어야 한다.)

• 무엇을: Bash 로 ls 1회 + root 의 manifest(package.json / pyproject.toml / Cargo.toml / go.mod / README.md) 중 존재하는 1~2개를 Read 로 읽는다.
• 기존 자산도 같이 봅니다: 같은 ls 결과 안에서 .claude/skills/ 와 .claude/ 아래 설정·훅, 그리고 이번 작업과 같은 종류의 기존 산출물 12개가 폴더에 이미 있는지 경로/이름만 훑어본다. ls 는 1뎁스로만 보고, 눈에 띈 파일은 열어 읽지 않고 경로/이름만 기억한다(출력은 35줄 안). 아무것도 없으면 점검이 있었다는 것조차 사용자에게 알리지 않고 곧장 다음으로 넘어간다.
• 어떻게: 다음 3분기 중 하나로 한 줄 안내 후 진행한다.
  • ✅ 맞는 폴더: 맞으면 곧장 Step 1 로 들어간다 (폴더 점검 통과를 사용자에게 따로 알리지 않는다 — 첫 화면은 환경 점검이 아니라 사용자의 업무여야 한다).
  • 📭 빈 폴더: "적용할 본업 자료/폴더가 있으면 한 줄로 알려주실래요? (a) 본업 코드/자료 가져오기 (b) 일단 데모로 시작 — 어느 쪽으로 갈까요?" 무응답으로 다음 입력이 오면 (a) 본업 경로로 가되, 이번 업무 자료를 한 줄 붙여달라 한 번 더 묻고 진행한다. 데모(b)는 명시적으로 골랐을 때만.
  • ⚠️ 다른 폴더: "이 폴더는 <X> 프로젝트로 보여요. 이 스킬은 <Y> 의도예요. (a) 이 폴더에 변형해 진행 (b) 다른 폴더에서 다시 호출 — 어느 쪽?" 무응답이면 (a) 로 진행.

새로 만들 가치가 있는지부터 같이 정해요

Step 0(폴더 점검) 직후·방향 합의 직전 1회만. 방금 폴더 점검에서 기존 자산을 봤으면(.claude/skills/ 의 기존 스킬, 비슷한 산출물 등) 그걸 한 줄로 짚는다 — "방금 점검에서 <발견> 을 봤어요. 이미 이걸로 충분할 수도 있어요." 점검에서 아무것도 안 나왔으면 그 인용은 건너뛰고 바로 다음 한 줄로 간다. (받은 SKILL.md 의 필요성 가설 한 줄을 이어서 짚는다.)

그래서 시작하기 전에 한 번만 같이 정한다(이 판단은 지금 한 번뿐, 단계마다 되풀이하지 않는다):

1. 이미 있는 걸로 충분해요 — 새로 만들지 않고 기존 자산을 쓰는 쪽으로 마친다.
2. 새로 만들 가치가 있어요 — 그대로 이어서 방향을 같이 정한다.
3. 잘 모르겠어요, 같이 판단해요 — 기존 자산과 이번 작업을 한 줄씩 견주고 같이 정한다.

어느 쪽인지 정해지면 거기에 맞춰 이어간다. (자율주행 어휘 금지 — 점검/판단 어휘만, "자동으로 판단" 류는 쓰지 않는다.)

어느 방향으로 갈지 같이 정해요

방향은 위에서 흐름을 함께 본 다음에 정한다 — 순서가 바뀌지 않도록.

폴더 점검을 통과했으면 Step 1 로 곧장 들어가지 말고, 이 작업으로 무엇을 원하는지와 어떻게 풀지 1~3개 옵션으로 제안하고 같이 정한다. (Claude Code 면 AskUserQuestion) 받은 SKILL.md 의 「(이 작업의) 방향 옵션」 라벨·근거를 옵션으로 쓴다.

"이렇게 갈까요? 다른 방향이 있으면 알려주세요." 로 동의를 받는다.

방향이 정해지면 이 작업의 상세 진행 내용을 한 번 구성해 submit_progress MCP tool 로 반드시 보낸다 — 이게 진행표(progress-live)의 상세 내용을 채운다(install_token 인자에는 받은 SKILL.md frontmatter metadata.tracking_token 값을 그대로 넣는다). 추측해 뒤지지 말고 다음 구조를 그대로 채운다(로컬 진행표 파일은 만들지 않는다):

• goal: { title, oneLiner, where, what, how } (모두 짧은 한 문장 문자열)
• steps[]: { title, state, what, detail }, state 는 done | active | wait 중 하나 (active 는 항상 정확히 1개)
• glossary[]: { term, desc } (단계가 진행되며 누적, 빈 배열 가능). 학습자가 실제로 만나는 전문 용어·약어를 그 이름 그대로 담는다 — 쉬운 말로 바꾼 이름이 아니라 진짜 용어를 term 에 쓰고(예: Kappa, TPR/TNR, θ, 골든셋, Recall@k, CI 등 그 주제의 핵심 용어), desc 에 한 줄 쉬운 풀이를 붙인다. 그 용어가 나오는 국면을 지날 때마다 하나씩 추가한다. 쉬운 개념만 담고 어려운 용어를 빼지 않는다 — 진행표 용어집이 나중에 혼자 할 때 사전이 된다.

이 카드는 사용자가 이번 작업의 범위·할 일·진행 방식을 한눈에 보는 자리다. where/what/how 와 각 step 의 what/detail 은 비개발자가 바로 읽는 일상어·성과 중심으로 쓴다 — 작업 폴더 경로(~/… 나 레포 이름)나 내부 진행 방식·도구 내부명(worktree·서브에이전트·MCP·상태 파일·루브릭·Maker–Checker 같은 말)을 카드에 그대로 넣지 않는다. 주제가 기술적이어도 카드 문장은 무엇을 이루는지로 풀어서 쓴다.

진행 현황을 보여줄 때는 get_progress MCP tool 로 지금까지의 단계를 확인해 사람 말로 전한다. 셸이 있는 환경(Claude Code CLI)에서는 submit_progress 전송으로 진행표가 자동으로 뜨니(이미 떠 있으면 그 위에 갱신), 직접 열지 않는다(매 단계 반복도 하지 않는다). 알파에서는 진행표가 온보딩 전 초기 골격 전송(§3)에서 이미 열려 있으므로, 방향 카드는 그 위에 상세를 채워 갱신하는 것이다. 시각 진행표가 필요한데 셸이 없는 커넥터라면 progress-live 링크(https://rona.so/skill/api/install/<install_token>?type=progress-live, <install_token> 자리에 frontmatter metadata.tracking_token 값을 채운다)를 "이 링크를 눌러 진행표를 여세요" 라고 안내한다(토큰을 본문에 평문으로 늘어놓지 않는다).

진행 중 언제든 멈추고 방향 바꾸기

진행하다 방향이나 방법을 바꾸고 싶거나 잠깐 멈추고 싶으면, 내가 묻기를 기다리지 않아도 된다 — 그 말씀이 들리면 하던 작업을 즉시 멈추고 같이 다시 잡는다. (이 개입은 각 단계 끝의 "다음 갈까요?" 동의와 별개로, 단계 한가운데서도 언제든 된다.)

• 질문: "네, 멈췄어요. 어떻게 가는 게 좋을까요?"
• 선택지:
  • 방향을 다시 잡고 싶어요 → 지금까지의 접근 자체를 다시 본다. 방향 합의로 되감아 옵션을 새로 제안한다.
  • 지금 이 단계만 다시 해줘요 → 방향은 맞고 이번 단계 결과물만 손본다. 무엇을 바꿀지 한 줄 받아 현재 단계를 다시 한다.
  • 아니에요, 그냥 계속 가요 → 끼어들기를 취소하고 하던 흐름을 그대로 이어간다.
  • 이거면 됐어요 / 이대로 쓸게요 / 다른 방식으로 갈게요(결과에 만족하거나 더 진행하지 않고 여기서 마치겠다는 종결) → 작업을 여기서 마치고, 후기를 떠넘기지 않고 한 번만 가볍게 제안한다(먼저 동의를 받는다).
    • 질문: "여기까지 쓰신 거면 그걸로 충분해요. 끝까지 안 가신 그 이유가 사실 제일 쓸모 있는 한 줄이거든요 — 지금 짧게 같이 남겨둘까요?"
    • 선택지: [네, 한 줄 남길게요] / [혼자 나중에 남길게요] / [이번엔 건너뛸게요]
    • [네, 한 줄 남길게요] → "끝까지 안 가고 여기서 다른 방식으로 가신 거면 — 어떤 점이 안 맞아서였는지 한 줄만 들려주세요. (한 줄이면 충분해요)" 를 물어 한 줄을 받고, 끝까지 가지 않고 중간에 마친 흐름임을 명시해 그 자리에서 /rona-review 를 실행한다. 설치돼 있지 않으면 막다른 길로 두지 말고 그 한 줄을 직접 받아둔다.

아니에요, 그냥 계속 가요 와 지금 이 단계만 다시 해줘요 는 잠깐 쉬었다 다시 오겠다거나 같은 흐름을 이어가겠다는 뜻이므로 후기 제안을 하지 않고 자리를 지킨다. 더는 안 가겠다는 뜻이 분명할 때만 한 번 제안하고, 애매하면 제안하지 않는다. "이대로 쓸게요 / 이거면 됐어요" 가 이번 단계 산출물이 충분하니 다음으로 가자 는 뜻이면 종결이 아니므로 그대로 다음 단계를 이어가고, 세션 전체를 여기서 더 진행하지 않겠다는 의사가 분명할 때만 종결로 본다.

[네, 한 줄 남길게요] 또는 [혼자 나중에 남길게요]/[이번엔 건너뛸게요] 가 정해지면 그 자리에서 user_steer 이벤트를 아래 「추적」 규칙대로 보낸다(payload source="dropout-review", shown=true, accepted="<yes|no>", reason="<이탈사유 한 줄 또는 빈값>"). 한 줄을 받았으면 accepted 는 yes, 받지 않았으면 no — reason 한 줄은 짧게, 4KB 안.

결과가 기대한 대로인지 같이 확인해요

마지막 단계 산출물을 보여주고 기대한 결과인지 같이 확인한다.

• 묻는 방식: "기대한 결과 맞나요? 더 손볼 데 있으면 알려주세요."
• 기대와 다르면 직전 단계로 돌아가 한 번 더 손보거나, 방향 자체가 아니면 방향 합의로 되감는다.

마지막으로, 오늘 한 걸 같이 짚고 마무리해요

결과 합의 직후·마무리 후기 직전 1곳.

먼저 오늘 한 일·배운 것을 요약해 준다 (이해 확인보다 앞). 마무리에 들어가면, 아래 이해 확인에 앞서 이번 세션에서 무엇을 했고 무엇을 배웠는지를 짧은 서사로 정리해 보여준다 — 네 토막으로: ① 시작 상태(있던 것) ② 이번에 실제로 한 일(국면별로 한 일과 나온 결과·수치) ③ 그래서 배운 것(핵심 통찰 몇 줄) ④ 실무적으로 남은 것(다음에 이걸 어떻게 쓰나 한 줄). 판단·근거 중심으로 쓰고 축하·장식은 넣지 않는다. 이 요약은 이해 확인(아래)과 별개이며, 이해 확인은 그대로 유지한다. 요약을 보여준 뒤 이해 확인으로 넘어간다.

이해 확인은 기본이 soft(권유하되 통과 허용). 받은 SKILL.md frontmatter 에 mastery: hard 가 있으면 hard 정책이다.

soft (기본) — 거의 다 왔어요. 끝내기 전에, 오늘 한 것 중 제일 핵심이었던 한두 개만 같이 짚고 마무리할까요 — 나중에 혼자 다시 할 때 이게 길잡이가 됩니다(지금 안 짚어도 마무리는 됩니다). 이번 진행에서 가장 핵심이었던 한두 개만 골라 그것만 당신 말로 한 줄씩 짚어보면 돼요 — 나머지는 굳이 다 짚지 않아도 괜찮아요.

• 질문: "방금 한 것 중 제일 핵심이었던 한두 개만 한 줄로 짚어볼까요, 아니면 이대로 마무리할까요?"
• 선택지: [한두 개만 짚을게요] / [이대로 마무리할게요]

[한두 개만 짚을게요] 로 한 줄을 받을 때마다 그 자리에서 반드시 user_note 이벤트를 아래 「추적」 규칙대로 보낸다(payload source="comprehension", checklist_item="<항목>", restated=true, restatement="<한 줄>", passed=true). 진행표 checklist 는 서버가 그 신호로 갱신한다(로컬 파일은 만들지 않는다). [이대로 마무리할게요] 면 그대로 마무리로 넘어간다.

hard (frontmatter mastery: hard 일 때만) — 별도 정책. 모든 이해 항목이 proven 이 될 때까지 마무리 후기로 넘어가지 않는다(코드 결정적 조건, LLM 판정 아님). 아직 안 짚은 질문만 한 줄씩 같이 짚어 모두 proven 이 될 때까지 마무리로 넘어가지 않는다. 채운 항목마다 위 soft 와 동일하게 user_note(source="comprehension" …)를 보낸다.

마무리 — 후기 회수

마지막 단계 + 결과 합의 + 이해 확인까지 끝나면, 후기를 떠넘기지 않고 그 자리에서 같이 정리하자고 제안한다. (먼저 동의를 받는다.)

• 질문: "고생하셨어요. 방금 한 경험이 식기 전에, 후기를 같이 짧게 정리해 둘까요? 다음 버전이 이걸로 좋아져요."
• 선택지: [네, 지금 같이 정리해요] / [혼자 나중에 남길게요] / [이번엔 건너뛸게요]
• [네, 지금 같이 정리해요] → 그 자리에서 /rona-review 를 실행한다. 설치돼 있지 않으면 막다른 길로 두지 말고, 4가지(사용 도구 / 외부 출처 / 시도와 실패 / 이 스킬의 아쉬운 점)를 직접 물어 받는다.

추적 (6종 이벤트 — 측정 분모 사수)

받은 실습을 진행하는 내내, 아래 6종 이벤트를 log_event MCP tool 로 보낸다 (curl 없음 — Rona MCP 서버가 신뢰토큰으로 받는다). 이 추적이 빠지면 측정 분모가 무너진다 — 받은 SKILL.md 의 §5 가 토큰 스텁만 남아 있어도, 아래 6종을 전수 발신해야 추적이 나간다. (skill_started 는 서버가 주제 발급(claim) 순간 자동 기록하고, tool_used 는 런처가 도구 호출을 관찰해 자동으로 보낸다 — 둘 다 아래 표에서 빠졌고 네가 직접 보내지 않는다. 중복 발신하면 이중 계수가 된다.)

• tool: log_event · 인자: install_token(받은 SKILL.md frontmatter metadata.tracking_token 값) · event_type · payload
• 필드명은 event_type (event 아님) · payload (details 아님) 그대로. payload 는 자유 jsonb, 4KB 이하.

event_type	언제	payload 예시
direction_aligned	방향 합의 통과 직후 (정확히 1회)	{"chosen_direction":"<옵션 ID 우선, 자유 입력 시 한 줄 요약>","alternatives_shown":["<요약>"]}
checkpoint_saved	step 산출물 확정 시 1회/step	{"step": 1, "summary": "<한줄>"}
step_consent	진행 동의 통과 시 (각 step 마다 1회)	`{"step":1,"consent":"yes
user_steer	사용자가 step 진행 중 먼저 끼어들 때 (발동마다 1회)	`{"step":1,"trigger":"<감지된 의사 한 줄 요약>","resolution":"continue
skill_completed	마지막 step 종료 + 결과 합의 후 (정확히 1회)	{"skill": "<받은 실습 slug>", "outcome": "<한줄 요약>"}
user_note	사용자가 후기/메모 남길 때 (보통 /rona-review 가 처리)	{"narrative": {"decision": "yes", "text": "<한줄>"}, "practice_id": "<metadata.tracking_token>"}

source 마커 (같은 event_type 을 용도로 구분):

• 방식 대조(첫 단계 진행 게이트, 또는 "난 다르게 해" 끼어듦)의 user_steer → payload 에 "source":"step-contrast" + "gap"(사용자 실제 방식 한 줄): {"step":N,"source":"step-contrast","gap":"<한 줄>","resolution":"continue|revise|stop"}.
• 멈춤/이탈-후기(위 「진행 중 언제든 멈추고 방향 바꾸기」 종결 분기)의 user_steer → {"source":"dropout-review","shown":true,"accepted":"<yes|no>","reason":"<한 줄 또는 빈값>"}.
• 이해 확인(단계 끝 재진술·마스터리 게이트)의 user_note → {"source":"comprehension","step":N,"restated":true,"restatement":"<한 줄>","passed":true}(세션 전역 항목이면 "step" 대신 "checklist_item":"<항목>"). source 있는 user_note = 이해 신호, source 없는 narrative payload = 후기.

호출 예 — install_token 은 받은 SKILL.md frontmatter 의 metadata.tracking_token 값을 그대로 넣는다:

log_event(
  install_token = "<metadata.tracking_token>",
  event_type   = "direction_aligned",
  payload      = {"chosen_direction":"<옵션 ID 또는 한 줄 요약>","alternatives_shown":["<요약>"]}
)

direction_aligned 외 5종도 같은 형태로 event_type + payload 만 바꿔 호출한다. 전송은 백그라운드에서 조용히 — 사용자에게 내레이션하지 않는다.

셀프 인터뷰 (§8 — 후기 회수)

본 업무가 끝나면 Claude Code 에 /rona-review 를 입력해 후기를 회수한다. 같은 폴더에 설치된 .rona-skill.json 마커로 어느 스킬에 대한 후기인지 자동 식별한다. 2분 이내 yes/no + 한 줄 후기를 답하면 dashboard 에 즉시 반영된다. 물을 것: (1) 스킬이 놓친 부분은? 본인이 메운 방법은? (2줄 이내) (2) 이 경로를 동료에게 권하고 싶은가? (yes/no + 이유 1줄). 마무리에서 [네, 지금 같이 정리해요] 를 고르면 /rona-review 가 마커를 읽어 자동으로 식별·정리·전송하니, 사용자가 따로 뭘 실행하지 않아도 된다.

후기

실습을 마치면 rona-review 로 후기를 회수한다(같은 플러그인에 포함). 사용자가 "후기 남길게 / 다 썼어" 라고 하면 그 스킬로 넘어간다.