아시다시피 민족사관고등학교는 외부 음식을 구하기 어려운 산골 외딴 곳에 위치한 기숙사 학교입니다. 그렇기 때문에 한 달에 한 번 치킨데이라는 제도를 운영하고 있습니다. 치킨데이는 각 호(기숙사는 한 호에 6인 2실로 구성되며 1실에 3명이 함께 생활합니다.)에 치킨 3마리씩 배당되는, 민사고에서 제일 기다려지는 날 중 하루라고 할 수 있을 정도입니다.
이런 치킨데이를 관할하는 부서는 식품영양부(이하 식영부)입니다. 식품영양부원(이하 식영부원)들이 치킨 신청, 주문, 수령, 배달의 과정을 모두 맡게 되는 것입니다. 다른 사람들에게는 치킨데이는 단지 저녁에 치킨을 먹는 날에 불과하지만, 식영부원들에게는 약 한 시간 정도의 활동을 해야 하는 날이기도 합니다. 그렇다면 민사고 안에서는 어떤 과정을 통해서 치킨이 배달될까요?
우선 치킨데이 일주일 전쯤에 주문하고 싶은 치킨의 종류에 대한 신청을 받게 됩니다. 신청 과정은 민사고 전교생이 가입된 페이스북 그룹인 KMLA 전체공지를 이용해서 공지하고, Google Form의 설문지를 이용해 설문을 하게 됩니다. 설문이 완료되고 나면 식영부원들은 이 결과를 정리해 각 방이 무슨 치킨을 주문했는지에 대한 표를 제작하게 됩니다.
치킨 데이 당일이 되면 식영부원들은 오후 8시 20분까지 기숙사 1층 현관으로 모입니다. 8시 20분을 전후로 치킨을 배달하는 트럭이 도착하는데, 이때 식영부원들은 모든 치킨을 들고 12층 식당으로 이동하게 됩니다. 치킨이 처음 도착했을 때는 하나의 박스 안에 한 종류의 치킨이 모두 모여 있는 형태를 하고 있습니다. 그러나 이 치킨들이 각각의 층으로 모두 분배되어야 하기 때문에, 식영부원들은 치킨이 든 상자 위에 유성 매직으로 종류를 기록해서 분류하게 됩니다. 일반적으로 식영부원들은 두 명이 한 조를 이루어 한 층을 맡게 됩니다. 이 두 명은 전에 작성해둔 해당 층의 치킨 신청 표를 받아 각각 종류별로 모여 있는 치킨을 개수에 맞게 가져오는 일을 합니다. 그 다음 각각의 치킨들이 어느 호에 배달되어야 하는지 분류를 하게 되고, 더불어 각각의 치킨에 필요한 소스, 양념, 음료수 등도 챙깁니다. 음료수는 한 호에 기본적으로 1.5리터짜리 한 병이 제공됩니다.
치킨을 모두 분류했다면, 그 치킨을 들고 각 층으로 이동하게 됩니다. 배달하는 식영부원에 따라 치킨을 각 호 별로 문 앞까지 배달해주는 식영부원들이 있는가 하면, 복도 중앙에 위치한 엘리베이터 앞에 모아둠으로써 학생들이 직접 가져가게끔 하는 식영부원들도 있습니다.
다 같이 치킨을 맛있게 먹고 나면, 그 다음으로 치킨을 분리수거하고 뒤처리를 해야 하는데요, 각 층 중앙 엘리베이터 앞에 커다란 쓰레기봉투를 놓아두게 됩니다. 이 쓰레기통에 뼈와 봉투, 일반 쓰레기를 분류해 분리수거를 하게 되면 식영부원들이 그 쓰레기를 가지고 12층 식당으로 올라가 최종적인 분리수거를 하게 되고, 그 봉투를 정리하게 되면 치킨데이가 마무리 됩니다.
민사고에서 학생들이 가장 기다리는 날, 공부와 수행평가로 척박하게 마른 땅 같은 민사고의 생활에 단비 같은 날. 바로 치킨데이입니다. 이러한 치킨 데이는 민사고만의 특별한 문화라고도 할 수 있을 것 같습니다. 아마 이런 행복한 치킨데이 뒤에서 남들에게 보이지 않는 노력을 하는 식영부원들에게 박수를 보냅니다!
아시다시피 민족사관고등학교는 외부 음식을 구하기 어려운 산골 외딴 곳에 위치한 기숙사 학교입니다. 그렇기 때문에 한 달에 한 번 치킨데이라는 제도를 운영하고 있습니다. 치킨데이는 각 호(기숙사는 한 호에 6인 2실로 구성되며 1실에 3명이 함께 생활합니다.)에 치킨 3마리씩 배당되는, 민사고에서 제일 기다려지는 날 중 하루라고 할 수 있을 정도입니다.
이런 치킨데이를 관할하는 부서는 식품영양부(이하 식영부)입니다. 식품영양부원(이하 식영부원)들이 치킨 신청, 주문, 수령, 배달의 과정을 모두 맡게 되는 것입니다. 다른 사람들에게는 치킨데이는 단지 저녁에 치킨을 먹는 날에 불과하지만, 식영부원들에게는 약 한 시간 정도의 활동을 해야 하는 날이기도 합니다. 그렇다면 민사고 안에서는 어떤 과정을 통해서 치킨이 배달될까요?
우선 치킨데이 일주일 전쯤에 주문하고 싶은 치킨의 종류에 대한 신청을 받게 됩니다. 신청 과정은 민사고 전교생이 가입된 페이스북 그룹인 KMLA 전체공지를 이용해서 공지하고, Google Form의 설문지를 이용해 설문을 하게 됩니다. 설문이 완료되고 나면 식영부원들은 이 결과를 정리해 각 방이 무슨 치킨을 주문했는지에 대한 표를 제작하게 됩니다.
치킨 데이 당일이 되면 식영부원들은 오후 8시 20분까지 기숙사 1층 현관으로 모입니다. 8시 20분을 전후로 치킨을 배달하는 트럭이 도착하는데, 이때 식영부원들은 모든 치킨을 들고 12층 식당으로 이동하게 됩니다. 치킨이 처음 도착했을 때는 하나의 박스 안에 한 종류의 치킨이 모두 모여 있는 형태를 하고 있습니다. 그러나 이 치킨들이 각각의 층으로 모두 분배되어야 하기 때문에, 식영부원들은 치킨이 든 상자 위에 유성 매직으로 종류를 기록해서 분류하게 됩니다. 일반적으로 식영부원들은 두 명이 한 조를 이루어 한 층을 맡게 됩니다. 이 두 명은 전에 작성해둔 해당 층의 치킨 신청 표를 받아 각각 종류별로 모여 있는 치킨을 개수에 맞게 가져오는 일을 합니다. 그 다음 각각의 치킨들이 어느 호에 배달되어야 하는지 분류를 하게 되고, 더불어 각각의 치킨에 필요한 소스, 양념, 음료수 등도 챙깁니다. 음료수는 한 호에 기본적으로 1.5리터짜리 한 병이 제공됩니다.
치킨을 모두 분류했다면, 그 치킨을 들고 각 층으로 이동하게 됩니다. 배달하는 식영부원에 따라 치킨을 각 호 별로 문 앞까지 배달해주는 식영부원들이 있는가 하면, 복도 중앙에 위치한 엘리베이터 앞에 모아둠으로써 학생들이 직접 가져가게끔 하는 식영부원들도 있습니다.
다 같이 치킨을 맛있게 먹고 나면, 그 다음으로 치킨을 분리수거하고 뒤처리를 해야 하는데요, 각 층 중앙 엘리베이터 앞에 커다란 쓰레기봉투를 놓아두게 됩니다. 이 쓰레기통에 뼈와 봉투, 일반 쓰레기를 분류해 분리수거를 하게 되면 식영부원들이 그 쓰레기를 가지고 12층 식당으로 올라가 최종적인 분리수거를 하게 되고, 그 봉투를 정리하게 되면 치킨데이가 마무리 됩니다.
민사고에서 학생들이 가장 기다리는 날, 공부와 수행평가로 척박하게 마른 땅 같은 민사고의 생활에 단비 같은 날. 바로 치킨데이입니다. 이러한 치킨 데이는 민사고만의 특별한 문화라고도 할 수 있을 것 같습니다. 아마 이런 행복한 치킨데이 뒤에서 남들에게 보이지 않는 노력을 하는 식영부원들에게 박수를 보냅니다!
Use each mode-specific prompt together with the common element block.
Auto Refactor
Prompt
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.
STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.
STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.
Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.
Detailed review
<task>
You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:
- Code is liability. Every line you write is a line you must maintain.
- Delete and simplify. If something can be removed without breaking the system, remove it.
- Prefer well-maintained libraries over custom code.
- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.
- Start with the simplest thing that works. Add complexity only when forced by reality.
- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.
- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:
1. Is this needed for V1, or is it speculative engineering?
2. Can this be deleted or simplified without losing core value?
3. Is this solving a problem we actually have, or a problem we might have?
4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:
- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet
- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value
- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale
- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.
</task>
<structured_output_contract>
Return findings in these sections:
1. VERDICT: Would Karpathy approve? One line.
2. DELETE: Things to remove entirely
3. SIMPLIFY: Things to keep but make simpler
4. KEEP: Things that are correctly lean
5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials
</structured_output_contract>
<grounding_rules>
- Be specific. Don't say "simplify the schema" -- say which fields to cut.
- Every DELETE must justify what you lose and why it's acceptable for V1.
- Every KEEP must justify why it's essential, not just nice-to-have.
- Think from the perspective of "what do I need to ship in 2 weeks?"
</grounding_rules>