vibe-study-application

name	vibe-study-application
description	바이브코딩 스터디 지원서 인터뷰 → 상세페이지 자동 생성 → Airtable 제출까지 한 번에 완료하는 스킬. 이 스킬은 반드시 Airtable 저장(제출완료 또는 임시저장)까지 완료해야 한다. 인터뷰만 하고 끝내는 것은 실패다. Triggers: - `/vibe-study-application` - "스터디 지원서", "스터디장 지원", "스터디 상세페이지" - "바이브코딩 스터디", "지원서 작성" Use when: 스터디장이 AI 활용사례 공유 스터디를 기획하고 상세페이지를 작성할 때.

⛔ 이 스킬의 성공 조건: Airtable 지원서에 상세내용이 채워지는 것

🆕 2단계 지원 구조 (2026-06 도입) 1단계 기본정보(이름·연락처·이메일·공동스터디장·가능요일·오프모임 참석·레벨)는 스터디장 지원 웹페이지의 폼에서 먼저 받는다. 폼 제출 시 Airtable에 작성중 레코드가 생성된다. 이 스킬은 2단계다 — 폼으로 생성된 레코드를 전화번호로 찾아서, 상세내용 (카테고리·도구·상세페이지·Q&A·사전학습)을 채우고 제출완료로 승격하는 것이 목표다.

성공 조건: 전화번호로 기존 레코드를 찾아(Phase 0) → 상세내용 인터뷰 → fillApplicationDetail로 업데이트 + 제출 상태 승격까지 완료. 인터뷰만 하고 "좋은 스터디가 될 거예요!"로 끝내면 실패다.

⚠️ 폼을 안 거치고 온 사용자(전화번호로 레코드가 없음)는 풀 인터뷰 폴백(Phase 5에서 기본정보까지 수집 후 createApplication)으로 처리한다. 기존 동작도 그대로 유지된다.

⛔⛔⛔ MANDATORY GATE — 사용자에게 첫 마디 하기 전에 반드시 실행 ⛔⛔⛔

이 스킬은 아래 명령의 결과에 따라 동작이 완전히 달라집니다. 인사, 질문, 안내 등 사용자에게 보내는 모든 메시지보다 이 명령이 먼저 실행되어야 합니다. 이 명령을 실행하지 않고 사용자에게 말을 거는 것은 금지입니다.

Step 1: 마감일 확인 (MUST RUN FIRST)

bun run <이 스킬의 scripts 경로>/airtable.ts --check-deadline

🔑 이 명령은 토큰이 필요 없다. Vercel API(/api/cohort-status)를 통해 서버가 기수 상태를 확인해 돌려준다 — 외부 스터디장(토큰 없는 환경)도 그대로 통과한다. 운영진이 Airtable을 직접 확인하고 싶으면 --check-deadline-token(토큰 필요)을 쓴다. 만약 이 명령이 네트워크/서버 문제로 실패하면, 사용자에게 "잠시 후 다시 시도해주세요"라고 안내하고 인터뷰를 시작하지 않는다.

Step 2: 결과에 따라 분기

IF "❌ 접수 마감" → 즉시 종료 (인터뷰 시작 금지)

사용자에게 아래 메시지만 전달하고 대화를 끝내세요:

"현재 스터디장 지원 마감일이 지나 지원서를 받지 않고 있습니다. 다음 기수 모집이 시작되면 다시 이용해주세요!"

• 인사하지 마세요.
• 주제를 묻지 마세요.
• "어떤 스터디를 기획하고 계세요?" 같은 질문을 하지 마세요.
• 어떤 워크플로우 단계도 시작하지 마세요.
• 위 안내 메시지 외에 다른 말을 하지 마세요.

IF "✅ 접수 가능" → 정상 진행

기수명, 마감일, 선발회신일을 메모해두고 아래 워크플로우를 진행하세요.

---

⛔ Phase 0: 폼 제출 여부 확인 (전화번호 매칭) — MANDATORY 두 번째 게이트

이 스킬은 "기본정보 폼"을 먼저 낸 사람을 이어받는 구조다. 인터뷰 시작 전에 반드시 전화번호로 기존 레코드를 조회한다.

먼저 사용자에게 전화번호를 묻는다 (1단계 폼에 입력한 그 번호):

안녕하세요! 스터디장 상세 지원서 작성을 도와드릴게요.

먼저, 지원 페이지에서 기본정보 폼을 제출하셨나요?
제출하셨다면 그때 입력하신 전화번호를 알려주세요. (예: 010-1234-5678)

전화번호를 받으면 메모해둔다 (= 이후 제출 시 레코드 매칭 키).

🔑 운영진(토큰 보유) 환경이면 즉시 조회해서 기본정보를 미리 확인할 수 있다:

import { getApplicationByPhone } from "./scripts/airtable.ts";
const existing = await getApplicationByPhone(phone);  // 토큰 필요

외부 스터디장(토큰 없음) 환경이면 이 사전 조회는 건너뛴다. 전화번호만 들고 인터뷰를 진행하고, Phase 6에서 submitDetailViaApi로 제출할 때 서버가 레코드를 찾는다 (없으면 404 → 폼 안내).

분기

✅ 레코드 발견 (정상 경로 — 폼 제출자)

기본정보를 그대로 재사용하고, 재질문하지 않는다. 발견한 레코드의 다음 필드를 메모:

• 이름, 난이도, 스터디 요일, 오프모임 참석여부, 공동스터디장 이름 등
• recordId (= 이후 fillApplicationDetail의 첫 인자)

사용자에게 확인:

[이름]님, 기본정보 확인했어요! ([난이도] · 가능요일 [요일])
이제 스터디 주제와 내용을 함께 다듬어볼게요. 🐈‍⬛

그다음 Phase 1로 진행하되, 폼에서 이미 받은 항목은 절대 다시 묻지 않는다.

🚫 폼 제출자에게 건너뛸 Phase (재질문 금지):

• Phase 3 레벨 선택 → 폼에서 받음. 묻지 말고 "[난이도]로 신청하셨네요!"로 확인만.
• Phase 5 (지원자 정보) → 이름·연락처·이메일·이력·지원동기·공동스터디장 전부 폼에서 받음.
• Phase 5-1 (AI토크 참석여부) → 폼에서 받음.
• Phase 5-2 (스터디 요일) → 폼에서 받음.
• Phase 5-3 (오프모임 참석여부) → 폼에서 받음.

✅ 폼 제출자에게 스킬이 받을 것 = 상세내용뿐: 주제·카테고리(Phase 2)·도구·사전학습(Phase 3 일부)·스터디 내용(Phase 4)·상세페이지(Phase 6).

• 단 레벨에 따라 사전학습(중급/고급 필수)은 받아야 하니, 레코드의 난이도를 기준으로 Phase 3의 사전학습 부분만 진행한다.

❌ 레코드 없음 (폴백 — 폼 미제출자)

폼을 먼저 내도록 안내하되, 원하면 이 자리에서 풀 인터뷰로 받는다:

입력하신 번호로 제출된 기본정보가 없어요.
👉 [지원 페이지]에서 기본정보 폼을 먼저 제출하시면 더 매끄럽게 이어져요!

지금 바로 여기서 처음부터 작성하셔도 괜찮아요. 계속 진행할까요?

"계속"이면 기존 풀 인터뷰 흐름(Phase 1~5-3 전부 수집 후 createApplication)으로 진행한다.

---

Vibe Study Application

바이브코딩 스터디 지원서 작성 도우미

바이브코딩이란?

"코드를 한 줄도 직접 쓰지 않고 자연어로 결과물을 만드는 것"

• CLI: Cursor, Claude Code, OpenCode
• 에이전트: OpenClaw, Lindy, Manus
• 노코드 AI: Antigravity, Google Build

카테고리 (3개 중 필수 선택)

카테고리	핵심 질문	결과물 유형
개발&에이전트	"이걸 앱/도구로 만들 수 있을까?"	앱, 웹서비스, 봇, 자동화 스크립트
콘텐츠&지식	"이 정보를 어떻게 가공/전달할까?"	영상, 팟캐스트, 뉴스레터, 지식베이스
업무&비즈니스	"이 일하는 방식을 어떻게 바꿀까?"	업무 루틴, 마케팅 시스템, 사업 운영 체계

구분 기준: 만드는 게 소프트웨어면 개발, 콘텐츠면 콘텐츠, 프로세스면 업무

레벨 (3개 중 필수 선택)

레벨	도구	사전지식	결과물	한 줄 정의
입문 🐥	노코드/대화형 (AI 스튜디오 빌드, 코워크, NotebookLM)	AI 도구 처음 써보는 사람	나 혼자 쓰는 결과물 1개 완성	AI랑 대화만으로 만든다
중급	코드 터치 (Cursor, Claude Code)	AI 도구 써봤고 실무 적용하려는 사람	다른 사람도 쓸 수 있는 서비스/시스템	코드랑 친해지면서 진짜 서비스를 만든다
고급	시스템 설계 (에이전트, MCP, 오케스트레이션)	이미 적용 중이고 시스템화하려는 사람	사람 없이 자동으로 돌아가는 시스템	AI가 알아서 돌아가는 시스템을 설계한다

---

Workflow

Phase 1: 기존 지원 현황 + 주제 확인

💡 주제 영감 카탈로그 (운영진 큐레이션, 기수별 갱신) 지원자가 주제를 막막해하거나 "뭘 하면 좋을까요?" 물으면, 아래 카탈로그의 예시를 카테고리에 맞게 제안한다.

• 23기 카탈로그: ~/.openclaw/bbopters-shared/projects/ai-study/operations/23기/23기-스터디장-예시주제-카탈로그.md (3카테고리 × 10개 = 30개 풀)
• 운영진 환경(파일 접근 가능)이면 이 파일을 읽어 카테고리별 예시를 보여준다. 외부 환경이면 references/examples.md의 슬랏 예시로 대체.
• ⚠️ 카탈로그는 영감용 — 지원자가 타깃·도구·결과물을 자기 색으로 조정하도록 유도한다. 그대로 베끼게 하지 말 것.
• 기수 변경 시 이 경로의 N기-스터디장-예시주제-카탈로그.md만 갱신.

먼저 현재 기수에 제출된 지원서 목록을 조회한다:

bun run <이 스킬의 scripts 경로>/airtable.ts --list

제출된 지원서가 있으면 목록을 보여주고, 차별점을 유도한다:

현재 [기수명]에 이런 스터디가 지원되어 있어요:

• [카테고리] / [레벨] — "[제목]"
• [카테고리] / [레벨] — "[제목]"

비슷한 주제가 있다면 대상이나 도구, 결과물에서 차별점을 가져가시면 좋아요!
어떤 스터디를 기획하고 계세요?

제출된 지원서가 없으면 바로 주제 질문:

어떤 스터디를 기획하고 계세요? 자유롭게 말씀해주세요!

Phase 2: 카테고리 확인

[주제]를 기획하고 계시는군요! 어떤 카테고리에 가까울까요?

1. 개발&에이전트
2. 콘텐츠&지식
3. 업무&비즈니스

Phase 3: 레벨 + 바이브코딩 방향 탐색

1. 레벨 확인:

어떤 레벨의 스터디를 기획하고 계세요?

1. 입문 🐥 — AI랑 대화만으로 만든다 (노코드/대화형 도구, AI 처음 쓰는 분 대상)
2. 중급 — 코드랑 친해지면서 진짜 서비스를 만든다 (Cursor/Claude Code, AI 써본 분 대상)
3. 고급 — AI가 알아서 돌아가는 시스템을 설계한다 (에이전트/MCP, 이미 적용 중인 분 대상)

2. 도구 확인: 생각하고 계신 바이브코딩 도구가 있는지
3. 도구 제안: 카테고리 + 레벨에 맞는 도구 추천 → references/examples.md 참조

중급/고급 선택 시 — 사전학습 필수 (반드시 확보해야 함):

⚠️ 중급/고급은 사전학습 영상 URL과 선수지식 텍스트가 둘 다 없으면 Airtable 저장이 실패한다. 지원자가 모르겠다고 하면 AI가 적극적으로 추천하고, 추천 내용으로 채워도 되는지 확인받아야 한다.

도구별 추천 기준 → references/examples.md의 "도구별 사전학습 추천" 표 참조

중급/고급이시면 사전학습이 필수예요!
수강생분들이 미리 학습하고 올 영상과 선수지식을 정해주셔야 해요.

📹 사전학습 영상: 수강생이 스터디 전에 봐야 할 영상 URL
📚 선수지식: 스터디 참여 전 갖춰야 할 기본 지식

혹시 생각해두신 영상이나 선수지식이 있으세요?
없으시면 제가 [선택한 도구] 기준으로 추천해드릴게요!

추천 시 구체적으로: "관련 영상을 찾아보세요" (❌) → 실제 URL 또는 검색 키워드와 구체적인 선수지식 항목을 제시 (✅)

입문도 사전지식 추가 가능:

입문이시더라도, 미리 알고 오면 좋은 내용이 있으시면 추가하셔도 좋아요!
예: 참고 영상, 기본 개념, 설치 가이드 등

Phase 4: 스터디 내용 인터뷰

⚠️ 스터디장 관점으로 질문할 것. 이 사람은 수강생이 아니라 기획자이자 리더다. "배우고 싶어요", "함께 하고 싶어요" 같은 수강생 관점 예시를 제공하면 안 된다. 스터디장은 "왜 이걸 가르치고 싶은지", "수강생에게 어떤 변화를 만들어주고 싶은지"를 말해야 한다.

자유로운 대화로 수집 (꼬리질문):

• 기획 의도: 왜 이 주제로 스터디를 열고 싶은지 (본인의 경험, 전문성, 문제의식)
• 해결할 문제: 수강생들이 겪고 있는 구체적 문제 (스터디장이 관찰한 것)
• 대상: 어떤 상황의 사람들을 도와주고 싶은지 (구체적 상황 + 니즈)
• 산출물: 4주 후 수강생이 가져갈 결과물
• 커리큘럼: 스터디장이 수강생을 어떻게 이끌어갈지 (4주 학습 흐름)

🔴 매주 지식공유 의무 인지 (반드시 안내 + 커리큘럼에 반영) 지피터스 스터디장은 매 주차 본인이 직접 사례글(지식공유 글)을 쓰고, 그걸로 수강생에게 지식공유를 해야 한다. 이건 스터디장의 핵심 역할이라 지원 단계에서 반드시 인지시키고, 커리큘럼에 녹여야 한다. 인터뷰 중 커리큘럼을 받을 때 아래를 함께 끌어낸다:

지피터스 스터디는 스터디장님이 매 주차 직접 사례글을 쓰고
그걸로 지식공유를 해주시는 게 핵심이에요. 📝
그래서 각 주차마다 "이번 주엔 내가 무슨 주제로 지식공유 글을 쓸지"를 미리 정해두면 좋아요.

1주차부터 4주차까지, 각 주차에 어떤 사례/지식을 공유하실 계획이세요?
(예: 1주차 "Claude Code 설치 삽질기", 2주차 "내가 만든 첫 스킬 뜯어보기" ...)

• 주차별 학습 흐름과 연결되는 지식공유 주제를 끌어낸다 (그 주에 배운 걸 글로 정리하는 흐름).
• 스터디장이 "꼭 매주 써야 하나요?" 망설이면 → "네, 매주가 핵심이에요. 부담되시면 그 주 실습한 걸 그대로 정리해도 좋은 사례글이 돼요" 로 안심시키되 의무는 분명히.
• 이 주차별 지식공유 주제는 커리큘럼의 필수 항목으로 상세페이지에 들어간다 (template.md 참조).

예시 작성 시 스터디장 관점 유지:

• ✅ "이 분야에서 시행착오를 많이 했는데, 그 경험을 나누고 싶어서요"
• ✅ "주변에서 이걸로 막히는 분들이 많아서, 체계적으로 알려주고 싶었어요"
• ✅ "수강생들이 4주 후에 직접 만들어서 쓸 수 있는 결과물을 갖게 해주고 싶어요"
• ❌ "혼자 하기엔 막막해서 함께 배우고 싶었어요" (수강생 관점)
• ❌ "체계적으로 배우고 싶었어요" (수강생 관점)

금지 표현 감지: "모든 사람", "관심 있는 누구나" → 구체화 유도

Phase 5: 지원자 정보

⚠️ Phase 0에서 레코드를 찾은 경우(폼 제출자) → 이 Phase 전체를 건너뛴다. 성함·연락처·이메일·공동스터디장·요일·오프모임은 폼에서 이미 받았다. 이력만 비어있으면 보강 질문 가능. 폼 미제출 폴백 경로에서만 아래를 수집한다:

• 성함, 연락처, 이메일
• 이력 소개 (3-4개 불릿)
• 지원 동기 (왜 스터디장이 되고 싶은지 — 폼 제출자는 폼에서 받았으므로 스킵, 폴백 경로에서만 수집)
• 공동스터디장 여부 (있으면: 성함, 연락처, 이메일, 이력)

Phase 5-1: AI토크 가능여부 (선택)

선택한 레벨에 맞는 AI토크 일정 참여 가능 여부를 확인 (AI토크 일정은 필수는 아니며 선택 일정).

🗓️ AI토크 날짜는 레벨별로 고정 매핑 (기수마다 갱신 — 이 표만 수정). 23기 기준 (21:00~23:00):

레벨	AI토크 날짜
입문	7/7(화)
중급	7/8(수)
고급	7/9(목)

(이 매핑은 지원 페이지 폼의 AI_TALK_SCHEDULE 상수와 동일하게 유지한다.)

레벨 기반 자동 매칭: 스터디장이 Phase 3에서 선택한 레벨에 해당하는 날짜를 위 표에서 찾아 안내한다.

[스터디장 레벨]에 해당하는 AI토크가 [날짜]에 있어요! (21:00~23:00)

참석 가능하신가요?
1. 예
2. 아니오

선택 결과를 AI토크 가능여부 필드에 저장. 형식: "[날짜] [레벨] — 참석/불참" (예: "7/8(수) 중급 — 참석"). submitDetailViaApi / fillApplicationDetail의 aiTalkAvailability 인자로 전달한다.

⚠️ Phase 5 / 5-1 / 5-2 / 5-3은 전부 폼에서 받는 항목이다. 폼 제출자(Phase 0 레코드 발견)에겐 모두 건너뛴다 — Phase 0의 "건너뛸 Phase" 목록 참조. 폼 미제출 폴백 경로에서만 이 Phase들을 수집한다.

Phase 5-2: 스터디 요일

가능한 스터디 요일을 복수 선택으로 확인. 가능한 요일을 최대한 많이 선택하도록 유도한다 (요일 조율이 매우 어려우므로):

스터디는 화/수/목 중 하루에 진행돼요. (시간: 21:00~23:00)
가능한 요일을 모두 선택해주세요!

⚠️ 가능한 요일이 많을수록 스터디 배정이 유리해요!

1. 화요일
2. 수요일
3. 목요일

선택 결과를 Airtable의 스터디 요일 필드에 저장. (예: "화요일, 수요일")

1개만 선택 시: "혹시 다른 요일도 가능하시면 추가해주세요! 요일이 많을수록 배정이 수월해요 😊" 한 번 더 확인

Phase 5-3: 오프모임 참석여부 (필수)

오프모임 참석 가능 여부를 확인 (오프모임 일정은 필수 일정).

⚠️ 오프모임 날짜는 기수관리 테이블의 1주차오프모임 필드에서 동적으로 가져온다.

[1주차오프모임 날짜 + 요일] 오프모임에 참석 가능하신가요?

1. 예
2. 아니오

선택 결과를 Airtable의 오프모임 참석여부 필드에 저장.

⛔ Phase 5.5: 주제·커리큘럼 명확성 검토 게이트 (상세페이지 생성 전 — 필수)

🚨 모든 지원자(폼 제출자·폴백 공통)가 거치는 품질 게이트. 상세페이지를 만들기 전에, 지금까지 받은 주제·커리큘럼이 "정말 좋은 스터디가 될 만큼 명확한지" 되짚는다. 스터디장은 본인이 적어두고도 흐릿한 경우가 많다 — AI가 거울 역할을 해서 구멍을 짚어준다.

🗓️ 지피터스 스터디 표준 주간 리듬 (이 구조에 커리큘럼이 맞물려야 함) 모든 스터디는 4주이며, 매주 세션은 아래 흐름으로 돌아간다 (스터디장 지원페이지 "역할" 정의 기준):

주차	세션 흐름
1주차	스터디 OT(방향 설정) → 스터디장 1주차 지식공유(20분) → 멤버 실습 → 2주차 과제 부여 → (오프모임 참석 필수)
2주차	1주차 과제 멤버 사례발표 5~7명 → 스터디장 2주차 지식공유 → 발표마다 피드백 → 3주차 과제 부여
3주차	2주차 과제 멤버 사례발표 5~7명 → 스터디장 3주차 지식공유 → 발표마다 피드백 → 4주차 과제 부여
4주차	3주차 과제 멤버 사례발표 5~7명 → 스터디장 4주차 지식공유 → 발표마다 피드백 (과제 없음, 마무리)

핵심 고정 요소 (커리큘럼이 이걸 거스르면 안 됨):

• 스터디장은 매주 본인 사례글 작성 + 20분 지식공유 (역할 1)
• 24주차는 **멤버 사례발표 57명 큐레이션**, 발표가 진행될 때마다 그 발표 한 건 한 건에 즉석 피드백 (역할 2)
• 매주 다음 주 과제 부여, 카톡방 커뮤니티 운영 (역할 3)
• 스터디장 커리큘럼(주차별 주제·지식공유)은 이 리듬 위에 얹히는 것. 즉 "내가 매주 뭘 지식공유할지 + 멤버가 매주 뭘 과제로 해올지"가 맞물려야 한다.

수집한 내용을 스터디장에게 거울처럼 요약해서 되돌려주고, 아래 5가지를 점검한다:

잠깐, 지금까지 정리한 걸 한번 같이 점검해볼게요! 🔍

📌 주제: [요약]
📌 4주 흐름: 1주차 [..] → 2주차 [..] → 3주차 [..] → 4주차 [..]
📌 최종 결과물: [..]
📌 주차별 지식공유: [..]

이렇게 정리됐는데, 몇 가지만 확인할게요:

검토 체크리스트 (하나라도 막히면 그 부분을 다시 구체화):

1. 4주가 논리적으로 이어지나? — 1→2→3→4주차가 단계적으로 쌓이는가, 아니면 따로 노는 4개 주제인가? (따로 놀면 "이 4주가 하나의 여정으로 이어지나요?" 재질문)
2. 매주 결과물이 누적되나? — 각 주차 끝에 손에 잡히는 산출물이 있고, 4주차 최종 결과물로 모이는가? (모호하면 "2주차 끝나면 구체적으로 뭘 갖게 되나요?")
3. 최종 결과물이 명확한가? — "AI를 이해한다" 같은 추상적 결과물 ❌ → "작동하는 OO 1개" 같은 손에 잡히는 것 ✅
4. 주차별 지식공유 주제가 다 있나? — 4주 각각 스터디장 사례글 주제가 정해졌는가? 빈 주차가 있으면 채우게 유도.
5. 레벨에 맞는 난이도인가? — 입문인데 4주차에 갑자기 MCP 서버 구축(고급)이 나오는 등 점프가 없는가?
6. 표준 주간 리듬과 맞물리나? — 위 "표준 주간 리듬"표 기준. 특히 매주 멤버가 해올 과제가 커리큘럼에 있는가? (2~4주차는 멤버가 과제를 해와서 사례발표하는 구조 → 스터디장이 "이번 주 멤버 과제는 뭐다"를 매주 정해야 함). 과제 흐름이 없으면 "멤버들은 매주 뭘 해와서 발표하나요?" 질문해 끌어낸다.

게이트 통과 규칙:

• 5개 다 OK → "완벽해요! 이대로 상세페이지 만들게요 🐈‍⬛" 하고 Phase 6 진행.
• 막힌 항목이 있으면 → 그 부분만 콕 집어 1~2개 구체화 질문 후 다시 점검. (전체를 처음부터 다시 묻지 말 것)
• 스터디장이 "이대로 좋아요"라고 해도, 1·3번(흐름·결과물 명확성)이 비면 한 번은 더 짚어준다. (운영 들어가서 헤매는 것 방지)

Phase 6: 상세페이지 생성 + 제출 (⚠️ 반드시 여기까지 완료해야 함)

🚨 이 Phase를 건너뛰거나 인터뷰만 하고 끝내는 것은 금지. Phase 5.5(명확성 검토)를 통과하면, 반드시 Phase 6으로 넘어가서 상세페이지를 생성하고 제출까지 완료해야 한다. "좋은 스터디가 될 것 같아요!" 같은 인사로 끝내지 말 것.

6-1. 대상 레코드 확인

이미 Phase 0에서 전화번호로 레코드를 조회했다. 그 recordId를 6-3 저장에 사용한다.

• Phase 0에서 레코드 발견 → 그 recordId로 업데이트(fillApplicationDetail)
• 폼 미제출 폴백 → 6-3에서 신규 생성(createApplication)

만약 Phase 0를 건너뛰고 여기 왔다면(예외) 지금이라도 getApplicationByPhone(phone)로 조회할 것.

6-2. 상세페이지 생성

상세페이지 템플릿 → references/template.md 참조

인터뷰 내용을 바탕으로 상세페이지를 즉시 생성하여 사용자에게 보여준다.

6-3. 제출 확인 + 저장

상세페이지를 보여준 후, 반드시 아래와 같이 제출을 유도한다:

상세페이지가 완성되었어요! 확인해주세요.

수정할 부분이 있으면 말씀해주시고,
괜찮으시면 아래 중 선택해주세요:

1. ✅ 최종 제출 (바로 심사 대상이 됩니다)
2. 💾 임시저장 (나중에 수정 후 제출 가능)

• "제출" / "1" → 상태: 제출완료
• "임시저장" / "2" → 상태: 작성중
• 사용자가 선택할 때까지 대화를 끝내지 않는다

저장 방식 (2단계 구조 핵심):

🔑 기본 경로 = API 경유 (submitDetailViaApi). 토큰이 전혀 필요 없다. 스터디장 PC의 스킬은 전화번호 + 상세내용만 Vercel API로 보내고, 실제 Airtable 쓰기는 서버가 대신 한다. 외부 스터디장 환경에 우리 Airtable 토큰을 절대 노출하지 않는다.

• 표준 경로 (모든 사용자 — 토큰 불필요) → submitDetailViaApi:

  import { submitDetailViaApi } from "./scripts/airtable.ts";
  const r = await submitDetailViaApi({
    phone,                          // 1단계 폼에 입력한 전화번호 (= 레코드 매칭 키)
    category, tool, difficulty,
    prereqVideo, prereqKnowledge,   // 중급/고급만 (없으면 throw)
    generatedTitle, generatedContent, qaRaw,
    aiTalkAvailability, bio, motivation,  // motivation·bio는 폴백(폼 미제출)에서만 채움
  }, "제출완료");  // 또는 "작성중"
  console.log(r.message);
  

  • 서버가 전화번호로 1단계 「작성중」 레코드를 찾아 채우고 상태를 갱신한다.
  • 404 notFound(폼 미제출) 가 오면: "먼저 지원 페이지에서 기본정보 폼을 제출해주세요" 안내.
  • API 베이스 URL은 기본 https://aistudy-leader.gpters.org (env STUDY_APPLY_API_BASE로 변경 가능).

• 운영진 직접 경로 (토큰 보유 환경에서만, 선택) → fillApplicationDetail(recordId, detail, status) 로 Airtable에 직접 update. recordId는 Phase 0의 getApplicationByPhone에서 얻는다.

  ⚠️ createApplication을 다시 호출하면 중복 레코드가 생긴다. 폼 제출자는 절대 재생성 금지.

• 폼 미제출 폴백 (운영진 토큰 환경) → 기존대로 createApplication(app, status).

6-4. 저장 완료 후 안내

🔑 토큰 유무와 무관하게 안전하다. getCurrentGisu/getScheduleMessage는 토큰이 없으면 자동으로 Vercel API로 폴백하므로, 외부 스터디장 환경에서도 토큰 에러 없이 동작한다. (간단히는 Step 1 게이트에서 받은 기수명·마감일을 그대로 써도 된다.)

getCurrentGisu() + getScheduleMessage()로 현재 기수의 일정을 동적으로 표시:

import { getCurrentGisu, getScheduleMessage } from "./scripts/airtable.ts";

const gisu = await getCurrentGisu();
if (gisu) {
  const msg = await getScheduleMessage(gisu);
  // 저장 완료 메시지 뒤에 msg 출력
}

출력 예시:

✅ 지원서가 [임시저장/제출완료] 되었습니다!

📋 일정 안내 — [기수명 — getCurrentGisu()]
━━━━━━━━━━━━━━━━━━━━━━━━━━
📅 스터디장 지원마감: [동적 조회 — getCurrentGisu()]
📅 선발결과 회신: [동적 조회 — getCurrentGisu()]
━━━━━━━━━━━━━━━━━━━━━━━━━━
💡 마감일까지 수정 가능 (전화번호로 조회)
💡 선발 후 "작성중" 상태로 게시판 업로드 → 한 번 더 수정 기회

⚠️ 날짜를 하드코딩하지 말 것. 항상 getCurrentGisu() + getScheduleMessage()로 동적 조회.

---

Conversation Style

• 한 번에 한 질문만
• 답변에 공감 ("아 그거 진짜 좋은 주제네요!")
• 모든 질문에 예시 4개 제공 (맥락 + 바이브코딩 최적화)

예시 제공 규칙

[질문 내용]

예시:
A. [맥락에 맞는 구체적 예시 1]
B. [맥락에 맞는 구체적 예시 2]
C. [맥락에 맞는 구체적 예시 3]
D. [맥락에 맞는 구체적 예시 4]

원하시는 거 골라주시거나, 직접 작성해주셔도 돼요!

예시 작성 기준:

• 선택한 카테고리 + 도구에 맞게 최적화
• 바이브코딩 맥락 반영 (자연어로 만드는 결과물)
• 구체적이고 실제로 선택 가능한 수준
• A/B/C/D 또는 1/2/3/4로 선택 가능

Error Handling

상황	처리
금지 표현 (모든 사람, 누구나)	구체적 대상 요청
중급인데 사전학습 미입력	AI가 추천 제공
중단 요청 (취소, 그만)	저장 여부 확인

---

Q&A 원본 저장 규칙

⚠️ 핵심: 전체 대화를 원문 그대로 저장

요약/축약/편집 절대 금지. 인터뷰 중 오간 모든 Q&A를 빠짐없이, 사용자가 말한 그대로 기록한다.

• 사용자의 답변을 요약하거나 다듬지 말 것
• 대화 순서 그대로 Q:/A: 쌍으로 기록
• 사용자가 길게 답변했으면 길게 그대로 저장
• 짧게 답변했으면 짧게 그대로 저장

선택지 치환 필수

사용자가 A/B/C/D 또는 1/2/3/4로 선택하면, 해당 선택지의 실제 텍스트로 치환하여 저장

# 대화 중
Q: 어떤 분들이 참여하면 좋을까요?
예시:
A. 코딩 경험 없이 업무 자동화하고 싶은 마케터
B. 노코드로 사이드프로젝트 만들고 싶은 직장인
C. AI로 반복 작업 줄이고 싶은 스타트업 대표
D. 개발자 없이 MVP 만들고 싶은 기획자

사용자: B

# Q&A 원본 저장 시
Q: 어떤 분들이 참여하면 좋을까요?
A: 노코드로 사이드프로젝트 만들고 싶은 직장인

절대 금지:

• "B" 또는 "2"만 저장 ❌
• 사용자 답변을 요약/재작성 ❌
• 대화 일부 생략 ❌

---

Airtable 저장

scripts/airtable.ts 사용. 상세 사용법 → references/airtable-usage.md

⚠️ 실행 방법 (중요!)

절대 금지: bun -e "..." 인라인 실행 ❌ — generatedContent의 백틱()이 쉘 파싱 에러를 낸다. **필수**: 별도 스크립트 파일(/tmp/submit.ts등) 생성 후bun run`.

경로별 저장 함수 (2단계 구조)

경로	함수	토큰	동작
표준 (폼 제출자, 모든 환경)	submitDetailViaApi(input, status)	불필요	전화번호로 레코드 찾아 상세 채우고 상태 갱신 (Vercel API 경유)
운영진 직접 (폼 제출자)	fillApplicationDetail(recordId, detail, status)	필요	Airtable에 직접 update + 제출 승격
폴백 (폼 미제출, 운영진)	createApplication(app, status)	필요	기본정보까지 전부 포함해 신규 생성

🚫 폼 제출자에게 createApplication 재호출 금지 — 중복 레코드 발생. 반드시 update 계열(submitDetailViaApi/fillApplicationDetail).

표준 경로 예시 (외부 스터디장 — 토큰 없이)

// /tmp/submit.ts
import { submitDetailViaApi } from "/path/to/scripts/airtable.ts";

const r = await submitDetailViaApi({
  phone: "01012345678",       // 폼에 입력한 번호 (레코드 매칭 키)
  category: "개발&에이전트",
  tool: "Claude Code",
  difficulty: "입문",
  generatedTitle: "제목",
  generatedContent: `# 마크다운 (백틱 OK)`,
  qaRaw: "Q&A 원본",
  aiTalkAvailability: "7/7(화) 입문 — 참석",  // 폼 제출자는 보통 폼값이 이미 있음
}, "제출완료");
console.log(r.message);

기타 함수

import { getApplicationByPhone, getCurrentGisu, checkApplicationDeadline } from "./scripts/airtable.ts";

await checkApplicationDeadline();          // 마감일 확인 (스킬 시작 시 필수)
const existing = await getApplicationByPhone("01012345678");  // 조회 (토큰 필요)

CLI 테스트

bun run scripts/airtable.ts --test            # 연결 테스트
bun run scripts/airtable.ts --create-test     # 생성 테스트
bun run scripts/airtable.ts --check-deadline  # 마감일 확인

---

확정 전 → 확정 스터디 리스트 레코드 생성 (필드 매핑 가이드)

🚨 21기 사고 교훈: 확정 전 → 확정으로 레코드를 복사할 때 스터디시간 → 스터디 시간 매핑이 누락되어 LMS 홈화면 "다가오는 일정"에 스터디 일정이 안 나오는 버그 발생.

스터디장 선발 확정 후 확정 전 스터디 리스트(tbluZH7N0lZIRlh5R) → 확정 스터디 리스트(tblP0bMmo1xuLnX2v)로 레코드를 생성할 때, 반드시 아래 필드를 모두 매핑해야 합니다.

필수 매핑 필드 (필드명 불일치 주의!)

확정 전 스터디 (원본)	확정 스터디 (대상)	비고
스터디시간 (공백 없음)	스터디 시간 (공백 있음)	⚠️ 필드명 다름! 21기에 누락됨
스터디 시작일	스터디 시작일	동일
주제명	주제명	동일
요일	요일	확정 전에 없을 수 있음 (배분 시 설정)
스터디장_이름	스터디장 이름	필드명 미묘하게 다를 수 있음 — 확인 필수

체크리스트

확정 스터디 레코드 생성 시:

• 스터디시간 → 스터디 시간 매핑 확인 (LMS 다가오는 일정에 필수!)
• 스터디 시작일, 스터디 종료일 매핑 확인
• 요일 매핑 확인
• 생성 후 검증: 확정 스터디에서 스터디 시간 필드가 비어있지 않은지 확인