야광봉 (14誠鉉)을 참고하자.
아무튼 선생님의 지도 아래 여름 파티를 기획하고 있었고,
물총싸움을 하자는 아이디어를 낸다.
아마도 낮에 물총싸움을 하고 삼겹살을 구워먹은 후 저녁에 영화를 보러 모이는 일정이었나... 그랬을거다.
그래서 물총을 각자 들고 오기로 했다.
그때 물총 하나를 공짜로 얻게 됐는데, 출력이 장난 아니었다.
대포에 가깝다고 해도 될 정도로, 물은 2L 가까이 들어가는데, 몇 발 사이에 물을 다 쓴다.
스플래툰의 'Trizooka'의 현실판이라 하면 정확할 정도로, 완벽한 물벼락이었다.
우리는 서바이벌 혹은 헝거게임 식으로 게임을 진행하기로 했고, 끝까지 물에 젖지 않은 사람에게는 무슨 상?을 주기로 했던 기억이 난다.
나는 그 말을 너무도 진지하게 받아들였고, 정말 수풀 속에 완벽하게 숨어서 끝까지 전혀 안 젖은 채로 다시 짠 하고 나타났다.
그러자 선생님께서 개탄하시며 말씀하시길,
반장인 네가 악착같이 이기자고 반나절 숨어있다 나타나면 어떡하니... 그 대단한 물벼락을 가지고... 애들 좀 맞추고 뛰어다니고 네가 먼저 그랬어야지.
야광봉 (14誠鉉)을 참고하자.
아무튼 선생님의 지도 아래 여름 파티를 기획하고 있었고,
물총싸움을 하자는 아이디어를 낸다.
아마도 낮에 물총싸움을 하고 삼겹살을 구워먹은 후 저녁에 영화를 보러 모이는 일정이었나... 그랬을거다.
그래서 물총을 각자 들고 오기로 했다.
그때 물총 하나를 공짜로 얻게 됐는데, 출력이 장난 아니었다.
대포에 가깝다고 해도 될 정도로, 물은 2L 가까이 들어가는데, 몇 발 사이에 물을 다 쓴다.
스플래툰의 'Trizooka'의 현실판이라 하면 정확할 정도로, 완벽한 물벼락이었다.
우리는 서바이벌 혹은 헝거게임 식으로 게임을 진행하기로 했고, 끝까지 물에 젖지 않은 사람에게는 무슨 상?을 주기로 했던 기억이 난다.
나는 그 말을 너무도 진지하게 받아들였고, 정말 수풀 속에 완벽하게 숨어서 끝까지 전혀 안 젖은 채로 다시 짠 하고 나타났다.
그러자 선생님께서 개탄하시며 말씀하시길,
반장인 네가 악착같이 이기자고 반나절 숨어있다 나타나면 어떡하니... 그 대단한 물벼락을 가지고... 애들 좀 맞추고 뛰어다니고 네가 먼저 그랬어야지.
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>