마크다운연습

💡 이 페이지 보는 법
왼쪽은 CLAUDE.md 파일에 실제로 입력된 마크다운 원문이고, 오른쪽은 깃허브나 AI 도구처럼 마크다운을 지원하는 환경에서 그 원문이 보이는 모습입니다. 이 위키는 마크다운을 직접 해석하지 않기 때문에, 오른쪽 화면은 같은 모양을 HTML로 재현한 것입니다. <a href="https://dh.aks.ac.kr/~kimseoyun/wiki/practicemd.html"> 마크다운 실시간 연습장 가기</a>

① 문서 제목과 소개문 제목(#) · 문단
✏️ 입력 (.md 원문) # CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.	👀 결과 (렌더링 화면) CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.

② 강조 문단 굵게(**)
✏️ 입력 (.md 원문) **Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.	👀 결과 (렌더링 화면) Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

③ 1번 원칙 제목(##) · 굵게 · 목록(-)
✏️ 입력 (.md 원문) ## 1. Think Before Coding **Don't assume. Don't hide confusion. Surface tradeoffs.** Before implementing: - State your assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them - don't pick silently. - If a simpler approach exists, say so. Push back when warranted. - If something is unclear, stop. Name what's confusing. Ask.	👀 결과 (렌더링 화면) 1. Think Before Coding Don't assume. Don't hide confusion. Surface tradeoffs. Before implementing: State your assumptions explicitly. If uncertain, ask. If multiple interpretations exist, present them - don't pick silently. If a simpler approach exists, say so. Push back when warranted. If something is unclear, stop. Name what's confusing. Ask.

④ 2번 원칙 제목(##) · 굵게 · 목록(-) · 문단

✏️ 입력 (.md 원문) ## 2. Simplicity First **Minimum code that solves the problem. Nothing speculative.** - No features beyond what was asked. - No abstractions for single-use code. - No "flexibility" or "configurability" that wasn't requested. - No error handling for impossible scenarios. - If you write 200 lines and it could be 50, rewrite it. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

👀 결과 (렌더링 화면) 2. Simplicity First Minimum code that solves the problem. Nothing speculative. No features beyond what was asked. No abstractions for single-use code. No "flexibility" or "configurability" that wasn't requested. No error handling for impossible scenarios. If you write 200 lines and it could be 50, rewrite it. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

⑤ 3번 원칙 제목(##) · 굵게 · 목록 두 묶음

✏️ 입력 (.md 원문) ## 3. Surgical Changes **Touch only what you must. Clean up only your own mess.** When editing existing code: - Don't "improve" adjacent code, comments, or formatting. - Don't refactor things that aren't broken. - Match existing style, even if you'd do it differently. - If you notice unrelated dead code, mention it - don't delete it. When your changes create orphans: - Remove imports/variables/functions that YOUR changes made unused. - Don't remove pre-existing dead code unless asked. The test: Every changed line should trace directly to the user's request.

👀 결과 (렌더링 화면) 3. Surgical Changes Touch only what you must. Clean up only your own mess. When editing existing code: Don't "improve" adjacent code, comments, or formatting. Don't refactor things that aren't broken. Match existing style, even if you'd do it differently. If you notice unrelated dead code, mention it - don't delete it. When your changes create orphans: Remove imports/variables/functions that YOUR changes made unused. Don't remove pre-existing dead code unless asked. The test: Every changed line should trace directly to the user's request.

⑥ 4번 원칙 제목(##) · 굵게 · 목록 · 코드 블록(```)

✏️ 입력 (.md 원문) ## 4. Goal-Driven Execution **Define success criteria. Loop until verified.** Transform tasks into verifiable goals: - "Add validation" → "Write tests for invalid inputs, then make them pass" - "Fix the bug" → "Write a test that reproduces it, then make it pass" - "Refactor X" → "Ensure tests pass before and after" For multi-step tasks, state a brief plan: ``` 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] ``` Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

👀 결과 (렌더링 화면) 4. Goal-Driven Execution Define success criteria. Loop until verified. Transform tasks into verifiable goals: "Add validation" → "Write tests for invalid inputs, then make them pass" "Fix the bug" → "Write a test that reproduces it, then make it pass" "Refactor X" → "Ensure tests pass before and after" For multi-step tasks, state a brief plan: 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

⑦ 맺음말 구분선(---) · 굵게
✏️ 입력 (.md 원문) --- **These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.	👀 결과 (렌더링 화면) These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.