SNU Now: Iteration 1 – Prompt Log

The full prompt log behind the AI Collaboration Report – Iteration 1.

Prompts sent to Claude Code during Iteration 1 (2026-09-28 ~ 2026-10-09), quoted verbatim, tagged with author and date, and grouped by purpose. Within each group, entries are in date order.

Spec, scoping and working rules

• [윤유상, 09-28] (session lost; reconstructed from memory, not the exact wording) "/wayfinder [final proposal 첨부] [Iteration 1 schedule 표 첨부] SNU Now라는 앱을 만들 것이고, schedule 표에 의거하여 스펙을 완성하도록 grilling 하자." → after grilling, "/to-spec" → for each spec, "/to-tickets"

• [안진영, 10-03] "이거 틈틈히 팀원이 와이어프레임도 계속 수정하고있어. 내가 뭔가를 요구할때 마다 아티팩트에 업데이트된게있는지확인하는 rule을 추가해"

• [안진영, 10-04] "그릴링 하지말고 일단 내 말들어봐. 일단 스케줄표에 있는 p06만 할거고 순서는 앱 켰을때 나오는 로딩창, 로그인화면, 메인화면(map) 만 구현할거야. 이때 필요한 데이터는 mock데이터로 프론트단에서 구현해두고 필요한 벡엔드가 구현이 안되있으면 따로 알려주면 내가 벡엔드팀에 전달할게. (구현이 되있어도 일단 mock으로 구현해둬 연결은 나중에 할테니) 다만 map을 받아오는 kakao sdk를 이용한 네이티브 모듈은 구현해야함. kotlin으로 구현하고 확인하고 잘 되면 swift로는 mac을 가진 함재현이 짤거야. 카카오맵 api key는 저번에 준거 그대로 쓰면됨. 이제 /grill-me 너가 필요한 p06에 대한 추가정보에 대해 물어보고 spec을 작성해보자"

• [함재현, 10-08] (asking /ask-matt to shape the prompt for a new session) "/ask-matt p27에 있는 모든 티켓 한 번의 프롬프트로 구현시키고 싶고, 각 티켓에서 what to build를 확인한 후에 '그럼 지금은 어떻게 되어있는지'를 코드 상으로 클로드가 확인한 다음에 아 이걸 what to build 내용으로 바꾸면 되겠구나 생각하도록 만들고 싶음. 그렇게 코드를 완성하고서 test는 돌리되, 빌드해서 에뮬레이팅하는 과정은 생략하는 걸로. 빌드는 pr올린 후에 다른 개발자가 직접 빌드 후 사용해보고 검토 후 다시 수정하는 절차를 밟을 거라 괜찮아."

Implementation and design

• [윤유상, 09-28] "/implement .scratch/iteration-1/P04-repo-setup/issues/13-mobile-app-placeholder.md

  • /karpathy-guidelines 스킬을 따라 작업해줘.
  • 1.0/P04-repo-setup 최신에서 1.0/P04-13-mobile-app-placeholder 브랜치를 만들어 작업해.
  • oxlint/Prettier/pnpm 버전은 main server(01, PR #2) 설정을 기준으로 맞춰줘.
  • 개발 서버를 띄운 뒤 Android 에뮬레이터에서 placeholder 화면이 보이는지 확인해줘. SDK는 ~/Library/Android/sdk에 있고 adb/emulator가 PATH에 없으니 ANDROID_HOME을 잡아서 써. AVD는 Medium_Phone_API_36.
  • 끝나면 PR 템플릿대로 base를 1.0/P04-repo-setup으로 PR을 열고, 머지하지 말고 리뷰 대기 상태로 둬."

• [안진영, 10-04] (first run of P06 ticket 01; its pull requests #33 and #34 were closed unmerged) "p06 1번 티켓 구현해줘. 이미 정해둔 디자인시스템이 (artifact link)"

• [안진영, 10-05] "/implement P06 1번 티켓. 닫은 PR #34의 디자인 시스템 코드를 가져와서 시작해. 새 티켓에 맞게 안 쓰는 컴포넌트는 빼고 빠진 건 추가하고, 웹 스크린샷을 찍어서 디자인 시스템 미리보기와 비교해서 고쳐."

• [안진영, 10-05] "로그인페이지는 다시 만들어야할거같아. 1. 서울대를 눌렀을때 google 로 로그인하는 내가 준 [Image #5] 사진처럼 떠야하고 눌러서 로그인했을때 도메인이@snu.ac.kr 인지 확인하고 아니면 저 로그인 실패했단 문구가 뜨도록 해야해. 2. 약관 동의는 완전 로그인 끝나고 메인페이지 넘어가기전에 처음 한번만 뜨는걸로 해. 3. 와이어프레임이 아티팩트가 왜 맥북에서 볼때랑 윈도우에서 볼때랑 다른지 모르겠는데 맥북에서 보면 마크 주변에 일렁거리는 원형 이펙트와 마스코트가 있고, 저 서울대 주변 이펙트가 오른쪽에 잘린것처럼보이지 않도록 되어있어. 이부분 수정해야해"

• [윤유상, 10-06] (orchestration of the remaining P12–P20 tickets) "## 목표 Iteration 1의 남은 구현 티켓(.scratch/iteration-1/ 의 P12~P20)을 이 세션에서 전부 마무리한다. 백엔드(P04, P07, P08)와 프론트엔드(P06)가 스펙 변경 때문에 완전히 맞물리지 않으므로, 아래 와이어프레임(아티팩트)을 직접 열어 interactive하게 동작을 확인하고, 그 동작을 백엔드와 프론트엔드를 함께 구현해 재현한다. 와이어프레임: [링크]

  ## 역할

  • 너(오케스트레이터)는 와이어프레임을 먼저 직접 훑어보고, 화면별 동작 요약을 만들어 서브에이전트에게 넘긴다. 서브에이전트는 이 아티팩트를 못 볼 수 있다.
  • 실제 작업은 전부 서브에이전트가 한다. 너는 결과물을 확인하고 조율한다.
  • 모든 서브에이전트는 opus 5.5 extra를 쓴다.
  • 구현은 karpathy-guidelines와 /implement(/tdd 포함)를 따른다.

  ## 우선순위와 결정

  • 티켓은 기본 범위로 삼는다. 와이어프레임과 어긋나는 부분만 와이어프레임에 맞춰 고치고(티켓 문서도 함께 수정), 어긋나지 않는 부분은 티켓의 범위와 완료 조건대로 구현한다.
  • 티켓에 없는 큰 기능을 추가하거나, 티켓을 통째로 다시 쓰거나 범위를 크게 늘리거나 줄여야 하면 나에게 묻는다.
  • 와이어프레임 자체가 틀려 보이거나 제품·구조 결정이 필요하면 임의로 정하지 말고 나에게 묻는다.
  • 와이어프레임(아티팩트)을 수정해야 하는 경우(틀린 부분을 고치는 경우와 빠진 화면·상태를 보완하는 경우 모두)에는 수정하기 전에 나에게 묻는다. 서브에이전트가 와이어프레임 수정을 제안하면 오케스트레이터가 모아서 한 번에 묻는다. 승인 없이 아티팩트를 수정하거나 재발행하지 않는다.
  • 그 외에는 묻지 말고 진행한다. PR별 상태 보고도 하지 않는다. 내가 결정해야 할 때만 알려라.

  ## 작업 방식

  1. development 브랜치에서 작업한다. 시작 전에 최신 1.0/Main을 포함하는지 확인한다.
  2. P19(와이어프레임 적응)를 먼저 하고, 그 결과로 나머지 티켓을 정리한다.
  3. 서브에이전트는 순차로 돌리거나, development에서 딴 worktree에서 돌리고 네가 순서대로 합친다. 같은 브랜치에서 동시에 수정하지 않는다.
  4. 커밋은 티켓 단위로 쌓고, 각 커밋은 빌드와 테스트가 통과해야 한다. 내가 승인한 와이어프레임 수정은 별도 커밋으로 남긴다.
  5. DB 마이그레이션은 마지막에 대상 브랜치(1.0/Main) 스키마 기준 하나로 정리한다.
  6. 티켓이 끝날 때마다 각 티켓의 Comments에 Agent usage를 기록한다(CLAUDE.md 규칙).

  ## PR

  • 전부 끝나면 PR 분할안을 먼저 보여준다. PR 수, 순서, 어떤 커밋이 어디로 가는지를 적는다.
  • PR은 10개 미만으로 하고, DB → 백엔드 모듈 → 프론트 순으로 나눈다. 티켓당 PR 하나가 자연스러우면 그렇게 한다. 합칠 수 있는 티켓은 합친다.
  • 승인하면 대상 1.0/Main으로 PR을 올린다. 각 PR은 단독으로 CI 전체(모바일 포함)를 통과해야 한다. 본문은 /pr로 쓴다.
  • 나는 PR을 바로 머지하고, 머지된 뒤에 기능·모듈·DB 단위로 순차 리뷰할 것이다. 그래서 PR 경계는 그 리뷰 단위와 맞춘다."

• [함재현, 10-08] (first /implement-spec of P27; the session was later force-quit when background agents overloaded the laptop) "/implement-spec .scratch/iteration-1/P27-usage-fixes

  • 통합 브랜치는 새로 만들지 말고 현재 브랜치 1.0/P27-usage-fixes를 쓴다. push와 PR은 하지 않는다.
  • 각 worktree에서는 작업 전에 건드릴 프로젝트(mobile, main-server)에서 pnpm install을 한다.
  • 각 티켓은 구현 전에 다음을 먼저 한다: 티켓의 "What to build"를 읽고, 지금 코드가 실제로 어떻게 동작하는지 해당 코드를 찾아 확인한 뒤, "현재 동작 → 바꿀 동작 → 고칠 곳"을 짧게 정리한다. 이 정리를 티켓 파일 맨 아래 ## Comments에 남기고, 그다음 /tdd로 구현한다.
  • 검증:
    • 각 티켓: 건드린 프로젝트(mobile, main-server)에서 pnpm lint, pnpm format:check, pnpm typecheck, pnpm test를 모두 통과시킨다.
    • 04, 06, 07, 09가 모두 통합 브랜치에 합쳐진 뒤, 코드 리뷰 전에 통합 브랜치에서 flow-tests의 pnpm test를 한 번 돌린다(Docker 필요).
    • 건드리지 않은 프로젝트(socket, worker, match, admin)는 CI에 맡긴다.
    • 앱 빌드, 에뮬레이터/시뮬레이터 실행, Gradle·Xcode 빌드는 하지 않는다.
  • 기존 테스트는 티켓이 바꿔도 된다고 한 것만 바꾼다(이름이 적힌 것, 또는 02·03처럼 조건이 적힌 것). 바꾼 테스트는 그 티켓의 ## Comments에 무엇을 왜 바꿨는지 적는다.
  • 완료한 티켓은 완료 기준을 [x]로 체크한다. "Check on a phone" 항목은 체크하지 않고 리뷰어 몫으로 남긴다.
  • 끝나면 CLAUDE.md의 규칙대로 각 티켓의 ## Comments에 Agent usage를 기록하고, 로컬 커밋만 한다."

• [함재현, 10-08] (resuming P27 after the force quit, with a cap on concurrent implementers) "/implement-spec P27 spec(.scratch/iteration-1/P27-usage-fixes/)을 이어서 진행해. 이전 세션이 force quit으로 죽었고, 살아 있는 subagent는 없어.

  01, 08은 각 worktree에 커밋까지 끝났어. 먼저 merger로 통합 브랜치에 merge해. 02, 04, 06은 worktree에 커밋 안 된 작업이 남아 있어. 새로 시작하지 말고 같은 worktree에서 이어가는 implementer를 띄워. 먼저 git diff와 테스트로 어디까지 됐는지 확인하게 해. TDD 도중이라 red 상태일 수 있어. 03, 05, 07, 09는 blocker가 merge되면 시작해. node_modules가 없으니 먼저 설치해. 동시에 돌리는 implementer는 최대 2–3개로 제한해. 깃허브에 push 및 pr은 하지마."

Verification, build and environment

• [윤유상, 10-06] "너가 직접 로그인이나 플레이를 직접 해보면서 테스트 해보지는 않는 상황인가?"
• [윤유상, 10-06] "subagent를 통해서 앱을 실제로 에뮬레이터로 띄워서 QA 해보도록 해줘."
• [김태현, 10-08] "ㅇㅋ 지금 로컬의 1.0/Main으로 안드로이드 빌드 다시할거야, 이전에 했던 것처럼 동일하게 release apk로 만들거고, 터널도 새로 받아와서 그걸로 만들어줘. 서버 띄우고, 실제 폰에서 동작할 수 있게 세팅하면 돼. 빌드는 내가 직접 할테니 커맨드 알려주고 나머진 알아서 해줘"

Documentation

• [김태현, 09-28] (wiki session) "Daily standup meeting log를 살짝 수정할거야, 일단 지금은 매일매일의 로그만 남기게 되어있잖아? [링크] 여기서 schedule을 보면 team meeting이 iter마다 kickoff, mid-iteration, review 이렇게 세번이 기본적으로 잡혀있지? 이 세 항목도 각 iter마다 미팅로그를 만들어서 해당 문서에 추가할거야, 적당히 너가 틀을 만들어놓고 iter1의 kickoff meeting은 (slack 파일 링크) 이게 미팅로그거든? 이거 기반으로 채워봐. 주의할 점은 미팅로그지 자세한 스펙 설명, 등등.. 불필요한 데이터는 다 버려도 돼, 실제로 회의를 통해 결정한 것들, 알아야 하는 것들, 얘기를 나눈 것들에 대한 정보를 작성해줘. 푸쉬는 하지말고 일단 작성만 해"