From 0ba0af6b05711b0df4510934504349eea9ead6ac Mon Sep 17 00:00:00 2001
From: DongHyunnn <hyun00083@gmail.com>
Date: Mon, 23 Feb 2026 16:09:58 +0900
Subject: [PATCH 1/7] Add well-writing skill for technical blog post review

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .claude/skills/well-writing/SKILL.md          | 230 +++++++
 .../well-writing/references/checklist.md      |  84 +++
 .../well-writing/references/styleguide.md     | 553 ++++++++++++++++
 .gemini/config.yaml                           |  34 +
 .gemini/styleguide.md                         | 621 ++++++++++++++++++
 plans-for-pr/well-writing-skill-plan.md       | 337 ++++++++++
 6 files changed, 1859 insertions(+)
 create mode 100644 .claude/skills/well-writing/SKILL.md
 create mode 100644 .claude/skills/well-writing/references/checklist.md
 create mode 100644 .claude/skills/well-writing/references/styleguide.md
 create mode 100644 .gemini/config.yaml
 create mode 100644 .gemini/styleguide.md
 create mode 100644 plans-for-pr/well-writing-skill-plan.md

diff --git a/.claude/skills/well-writing/SKILL.md b/.claude/skills/well-writing/SKILL.md
new file mode 100644
index 0000000..647fa38
--- /dev/null
+++ b/.claude/skills/well-writing/SKILL.md
@@ -0,0 +1,230 @@
+---
+name: Well-Writing
+description: This skill should be used when reviewing and editing markdown blog posts for the HyperAccel technical blog. It provides style guide compliance checking and readability improvements.
+---
+
+# Well-Writing
+
+This skill helps review and edit markdown blog posts for the HyperAccel technical blog by ensuring style guide compliance and improving readability.
+
+## When to Use This Skill
+
+Use this skill when:
+- Reviewing or editing markdown blog posts (`.md` files)
+- Checking style guide compliance
+- Improving readability and technical writing quality
+- Validating frontmatter and metadata
+
+## Workflow
+
+### 1. Load Style Guide Reference
+
+To review a blog post, first load the style guide:
+- Load `references/styleguide.md` for detailed rules and examples
+- Load `references/checklist.md` for quick reference during review
+
+The style guide contains:
+- Critical Issues (Must Fix): Bold rendering, acronym usage, capitalization
+- Content Quality (High Priority): Readability, technical writing
+- Markdown Formatting (Medium Priority): Headings, code blocks, images, lists
+- Frontmatter and Metadata: Required fields and format
+
+### 2. Review Critical Issues
+
+Check for these critical issues first (must fix before merging):
+
+**Bold Rendering**:
+- Search for pattern: `\*\*[^*]+\*\*[가-힣]` (bold text immediately followed by Korean)
+- Ensure space between closing `**` and Korean text
+- Example: `**GPU** 는` (correct) vs `**GPU**는` (incorrect)
+
+**Acronym Usage**:
+- Verify all acronyms are introduced with full terms first: `**FullTerm(Acronym)**`
+- Check that acronyms in title/summary are introduced in first paragraph
+- Common acronyms: GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton
+
+**Capitalization**:
+- Ensure consistent capitalization throughout
+- Acronyms uppercase: GPU, TPU, SM
+- Common nouns lowercase: loop, thread, warp, core
+- Brand names correct: NVIDIA, Google, TensorFlow, PyTorch
+
+### 3. Review Content Quality
+
+Check readability and technical writing:
+
+**Readability**:
+- Sentences should be within 50 characters (flexible for technical terms)
+- Paragraphs should be within 10 sentences or 200 characters
+- Break complex explanations into multiple sentences
+- Use blank lines to separate distinct ideas
+
+**Technical Writing**:
+- Technical terms explained when first introduced
+- Code examples have comments or explanations
+- Images have meaningful alt text
+- Content has logical structure with clear sections
+
+### 4. Review Markdown Formatting
+
+Check formatting consistency:
+
+- Headings: Proper hierarchy (H2 → H3, maximum H3 level, no H4 or deeper)
+- Code blocks: All have language tags (` ```python`, ` ```bash`, etc.)
+- Images: Descriptive alt text, meaningful file names
+- Links: Descriptive link text
+- Lists: Consistent formatting (`-` for unordered)
+- Frontmatter: All required fields present and correct
+
+### 5. Images from Confluence
+
+When a blog post references images from Confluence:
+
+- **Images must be downloaded manually** from the Confluence page
+- The agent should inform the user that images need to be manually downloaded
+- Provide guidance on where to find the images:
+  1. Identify the corresponding Confluence page (if the page ID or URL is known)
+  2. Open the Confluence page in a browser
+  3. Right-click on each image and select "Save image as..." or "Download"
+  4. Save images to the appropriate `images/` directory relative to the markdown file
+  5. **Rename images with sequential numbers**: Images should be named with a two-digit prefix (e.g., `01-`, `02-`, `03-`) followed by a descriptive name
+     - Format: `{number}-{descriptive-name}.{ext}`
+     - Example: `01-tpuv1-arch.png`, `02-pallas-lowering.png`, `03-tpuv7-arch.png`
+     - Numbers should reflect the order in which images appear in the blog post
+  6. Ensure the saved file names match the image references in the markdown file
+
+**Note**: Automatic image download from Confluence is not supported. All images must be manually downloaded and placed in the correct directory.
+
+### 6. Verify and Insert Images in Blog Posts
+
+When reviewing a blog post, the agent should verify that images are properly referenced and placed:
+
+1. **Check the images directory**:
+   - Locate the `images/` directory relative to the markdown file (typically `content/posts/{post-name}/images/`)
+   - List all image files in the directory
+   - Note the file names and formats (`.png`, `.jpg`, `.webp`, etc.)
+   - **Verify naming convention**: All image files should follow the format `{number}-{descriptive-name}.{ext}` where:
+     - `{number}` is a two-digit sequential number (01, 02, 03, etc.)
+     - `{descriptive-name}` is a lowercase, hyphen-separated descriptive name
+     - Example: `01-tpuv1-arch.png`, `02-pallas-lowering.png`, `03-tpuv7-arch.png`
+
+2. **Read and analyze the markdown file**:
+   - Search for all image references using the pattern: `!\[.*?\]\(images/.*?\)`
+   - Extract:
+     - Image file paths (e.g., `images/tpu-v1-architecture.png`)
+     - Alt text (the text between `![` and `]`)
+     - Caption text (if present in alt text or nearby context)
+
+3. **Match images with references**:
+   - For each image file in the directory, check if it's referenced in the markdown
+   - For each image reference in the markdown, verify the file exists
+   - Identify:
+     - **Orphaned images**: Files in directory but not referenced in markdown
+     - **Missing images**: References in markdown but files don't exist
+     - **Mismatched names**: References that don't match actual file names
+
+4. **Verify image placement**:
+   - Check that images are placed in logical positions:
+     - **Images should be placed BEFORE the content they illustrate** (recommended)
+     - This allows readers to see the visual context before reading the explanation
+     - Images should appear near the text that describes them
+     - Images should not interrupt the flow of reading
+   - Verify image context:
+     - The surrounding text should mention or describe what the image shows
+     - Images should support the narrative, not just be decorative
+
+5. **Check image metadata**:
+   - **Alt text**: Should be descriptive and meaningful (not just the filename)
+     - Good: `![TPU v1 아키텍처 다이어그램](images/01-tpuv1-arch.png)`
+     - Bad: `![image](images/01-tpuv1-arch.png)` or `![01-tpuv1-arch.png](images/01-tpuv1-arch.png)`
+   - **File names**: Must follow the sequential numbering format `{number}-{descriptive-name}.{ext}`
+     - Numbers should be two digits (01, 02, 03, ..., 10, 11, etc.)
+     - Numbers should reflect the order images appear in the blog post
+     - Descriptive name should be lowercase with hyphens (e.g., `tpuv1-arch`, `pallas-lowering`)
+   - **Image format**: Prefer `.webp` for smaller file sizes, but `.png` is acceptable for diagrams
+
+6. **Suggest improvements**:
+   - If images are missing, suggest adding them with appropriate alt text and sequential numbering
+   - If images are in wrong locations, suggest moving them to better positions
+   - If alt text is missing or poor, suggest improvements
+   - If file names don't follow the numbering convention, suggest renaming:
+     - Determine the correct order based on where images appear in the markdown
+     - Rename files to follow `{number}-{descriptive-name}.{ext}` format
+     - Update all references in the markdown file to match the new names
+   - If file names don't match references, suggest renaming files or updating references
+   - If orphaned images exist, ask if they should be removed or referenced
+   - If sequential numbers are missing or incorrect, suggest renumbering all images in order
+
+7. **When inserting images**:
+   - **Place images BEFORE the content they illustrate** (recommended)
+   - This allows readers to see the visual context before reading the explanation
+   - Use descriptive alt text that explains what the image shows
+   - Consider the reading flow - images should enhance understanding, not interrupt it
+   - **File naming**: Before inserting, ensure the image file follows the sequential numbering format:
+     - Determine the correct sequence number based on where this image appears in the post
+     - If it's the first image, use `01-`, second image use `02-`, etc.
+     - Format: `{number}-{descriptive-name}.{ext}` (e.g., `01-tpuv1-arch.png`)
+   - Format: `![Descriptive alt text](images/{number}-{descriptive-name}.{ext})`
+   - If the image needs a caption, include it in the alt text or add a caption below
+   - **Renaming existing images**: If inserting an image requires renumbering existing ones:
+     - Rename all affected image files
+     - Update all references in the markdown file to match the new names
+     - Maintain sequential order throughout the post
+
+**Example workflow**:
+```
+1. Read markdown file: content/posts/pallas-programming-model/index.md
+2. Check images directory: content/posts/pallas-programming-model/images/
+3. Find all image references in markdown (in order of appearance)
+4. Verify all image files follow naming convention: {number}-{descriptive-name}.{ext}
+5. Match files with references
+6. Verify each image is in the right place contextually
+7. Check alt text quality
+8. Verify sequential numbering matches the order images appear in the post
+9. Report any issues and suggest fixes (renaming, renumbering, etc.)
+```
+
+**Image naming examples**:
+- First image in post: `01-tpuv1-arch.png`
+- Second image in post: `02-pallas-lowering.png`
+- Third image in post: `03-tpuv7-arch.png`
+- Tenth image in post: `10-common-hw-model.png`
+
+## Providing Feedback
+
+When reviewing a post:
+
+1. **Prioritize by severity**:
+   - Critical: Must fix (rendering issues, major readability problems)
+   - High: Significantly impacts readability or understanding
+   - Medium: Formatting or consistency issues
+
+2. **Be specific**:
+   - Point to exact locations (line numbers if possible)
+   - Provide before/after examples
+   - Reference specific rules from `references/styleguide.md`
+
+3. **Suggest fixes**:
+   - Show correct format
+   - Explain why the fix is needed
+   - Reference relevant sections of the style guide
+
+4. **Use the checklist**:
+   - Refer to `references/checklist.md` for quick verification
+   - Check off items as you review
+   - Focus on critical and high-priority items first
+
+## Common Patterns
+
+Based on existing blog posts:
+
+- **Series posts**: Use `series: ["시리즈 이름"]` in frontmatter
+- **Code languages**: Python, CUDA, Bash, C, Go, F# are commonly used
+- **Image formats**: `.webp`, `.png`, `.jpg` are used
+- **Technical terms**: GPU, TPU, SM, CUDA, HBM, Systolic Array, Tensor Core, etc.
+
+## Notes
+
+- **Context matters**: Some rules may be flexible for technical content (e.g., longer sentences for complex explanations)
+- **Consistency first**: If a pattern is used consistently throughout a post, it may be acceptable even if not ideal
+- **Be constructive**: When pointing out issues, suggest specific fixes and explain the reasoning
diff --git a/.claude/skills/well-writing/references/checklist.md b/.claude/skills/well-writing/references/checklist.md
new file mode 100644
index 0000000..8bb0047
--- /dev/null
+++ b/.claude/skills/well-writing/references/checklist.md
@@ -0,0 +1,84 @@
+# Quick Reference Checklist
+
+This is a quick reference checklist for reviewing blog posts. For detailed explanations, see `styleguide.md`.
+
+---
+
+## Critical Issues (Must Fix)
+
+### Bold Rendering
+- [ ] No `**text**한글` patterns without spaces
+- [ ] Search pattern: `\*\*[^*]+\*\*[가-힣]`
+- [ ] All bold markers followed by Korean text have a space
+
+### Acronym Usage
+- [ ] All acronyms introduced with full terms first: `**FullTerm(Acronym)**`
+- [ ] Acronyms in title/summary are introduced in first paragraph
+- [ ] Only full term is bolded, not the acronym
+- [ ] Common acronyms: GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton
+
+### Capitalization
+- [ ] Consistent capitalization throughout document
+- [ ] Acronyms are uppercase: GPU, TPU, SM, CUDA
+- [ ] Common nouns are lowercase: loop, thread, warp, core
+- [ ] Brand names correct: NVIDIA, Google, TensorFlow, PyTorch
+
+---
+
+## High Priority
+
+### Readability
+- [ ] Sentences within 50 characters (flexible for technical terms)
+- [ ] Paragraphs within 10 sentences
+- [ ] Paragraphs within 200 characters
+- [ ] Complex explanations broken into multiple sentences
+- [ ] Blank lines separate distinct ideas
+
+### Technical Writing
+- [ ] Technical terms explained when first introduced
+- [ ] Code examples have comments or explanations
+- [ ] Images have meaningful alt text
+- [ ] Content has logical structure with clear sections
+- [ ] Transitions connect sections smoothly
+
+---
+
+## Medium Priority
+
+### Markdown Formatting
+- [ ] H1 only for page title
+- [ ] Heading hierarchy not skipped (H2 → H3 → H4)
+- [ ] All code blocks have language tags
+- [ ] Inline code uses single backticks
+- [ ] List markers are consistent (`-` for unordered)
+- [ ] Images have descriptive alt text
+- [ ] Link text is descriptive
+
+### Frontmatter
+- [ ] All required fields present
+- [ ] Date format: `'2026-01-03T17:20:16+09:00'`
+- [ ] Authors match entries in `content/authors/`
+- [ ] Tags are relevant and consistent
+- [ ] Summary is concise and descriptive
+
+---
+
+## Quick Search Patterns
+
+Use these patterns to find common issues:
+
+- **Bold + Korean**: `\*\*[^*]+\*\*[가-힣]`
+- **Acronyms**: Search for common acronyms (GPU, TPU, SM, etc.) and verify first use
+- **Capitalization**: Search for variations (Loop/loop, GPU/gpu)
+- **Long sentences**: Look for sentences with multiple commas or conjunctions
+- **Code blocks**: Search for ` ``` ` without language tags
+
+---
+
+## Common Acronyms Reference
+
+**Must follow FullTerm(Acronym) rule**:
+- GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton, VLIW, DMA, ALU, SIMD, SPMD
+
+**May skip full form**:
+- CPU, AI, ML, API, URL, HTTP, HTTPS
diff --git a/.claude/skills/well-writing/references/styleguide.md b/.claude/skills/well-writing/references/styleguide.md
new file mode 100644
index 0000000..4ff268a
--- /dev/null
+++ b/.claude/skills/well-writing/references/styleguide.md
@@ -0,0 +1,553 @@
+# HyperAccel Blog Style Guide
+
+This document defines style rules for writing markdown posts in the HyperAccel technical blog. Follow these rules to ensure consistency, readability, and proper rendering across all blog posts.
+
+---
+
+## Table of Contents
+
+1. [Critical Issues (Must Fix)](#1-critical-issues-must-fix)
+   - [Markdown Bold Rendering](#11-markdown-bold-rendering)
+   - [Acronym Usage](#12-acronym-usage)
+   - [Term Capitalization Consistency](#13-term-capitalization-consistency)
+2. [Content Quality (High Priority)](#2-content-quality-high-priority)
+   - [Readability](#21-readability)
+   - [Technical Writing](#22-technical-writing)
+3. [Markdown Formatting (Medium Priority)](#3-markdown-formatting-medium-priority)
+   - [Headings](#31-headings)
+   - [Code Blocks](#32-code-blocks)
+   - [Images and Links](#33-images-and-links)
+   - [Lists and Quotes](#34-lists-and-quotes)
+4. [Frontmatter and Metadata](#4-frontmatter-and-metadata)
+5. [Complete Examples](#5-complete-examples)
+6. [Review Checklist](#6-review-checklist)
+
+---
+
+## 1. Critical Issues (Must Fix)
+
+These issues cause rendering problems or significantly impact readability. They must be fixed before merging.
+
+### 1.1 Markdown Bold Rendering
+
+**Problem**: When Korean text immediately follows bold text, markdown rendering may break, causing asterisks to appear as literal characters in the rendered output.
+
+**Rules**:
+- Always add a space when Korean particles (은, 는, 이, 가, 을, 를, 으로, 로, 의, 에, 에서, 와, 과, 등) immediately follow bold markers `**`
+- Pay special attention when Korean text follows bold text ending with parentheses
+- This applies to all bold text, not just acronyms
+- The space should be between the closing `**` and the Korean text
+
+**Incorrect Examples**:
+```markdown
+**SM(Streaming Multiprocessor)**으로 구성되어 있습니다.
+**TPU(Tensor Processing Unit)**는 이와 대조적입니다.
+**대기 시간을 다른 작업으로 메워 효율을 극대화(Latency Hiding)**하는 방식입니다.
+**GPU**는 병렬 연산에 최적화되어 있습니다.
+```
+
+**Correct Examples**:
+```markdown
+**Streaming Multiprocessor(SM)** 으로 구성되어 있습니다.
+**Tensor Processing Unit(TPU)** 는 이와 대조적입니다.
+**대기 시간을 다른 작업으로 메워 효율을 극대화(Latency Hiding)** 하는 방식입니다.
+**GPU** 는 병렬 연산에 최적화되어 있습니다.
+```
+
+**How to Check**:
+- Search for pattern: `\*\*[^*]+\*\*[가-힣]` (bold text immediately followed by Korean)
+- Visual inspection: Render the markdown and check if asterisks appear as literal characters
+
+**Checkpoints**:
+- [ ] No pattern like `**text(acronym)**한글` exists
+- [ ] No pattern like `**text**한글` exists
+- [ ] All bold markers followed by Korean text have a space
+- [ ] Rendered output shows no literal asterisks
+
+---
+
+### 1.2 Acronym Usage
+
+**Problem**: Using acronyms before introducing the full term confuses readers. Incorrect formatting makes terms hard to understand and breaks the reading flow.
+
+**Rules**:
+- **First use**: Always write `FullTerm(Acronym)` format
+- **Subsequent use**: Only the acronym can be used
+- **Bold formatting**: Bold only the full term, not the acronym: `**FullTerm(Acronym)**`
+- If an acronym appears in the title or summary, introduce it in the first paragraph
+- For well-known acronyms (e.g., CPU, GPU, AI), you may skip the full form if it's extremely common
+
+**Incorrect Examples**:
+```markdown
+SM은 GPU의 핵심 구성 요소입니다. (Acronym used before full term)
+**SM(Streaming Multiprocessor)**으로 구성되어 있습니다. (Acronym is bolded)
+이 글에서는 TPU에 대해 설명합니다. (TPU not introduced)
+```
+
+**Correct Examples**:
+```markdown
+**Streaming Multiprocessor(SM)**은 GPU의 핵심 구성 요소입니다.
+이후 문장에서는 SM으로 지칭할 수 있습니다.
+
+이 글에서는 **Tensor Processing Unit(TPU)**에 대해 설명합니다.
+TPU는 구글이 개발한 AI 가속기입니다.
+```
+
+**Common Acronyms in This Blog** (must follow the rule):
+- GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton, VLIW, DMA, ALU, SIMD, SPMD
+
+**Well-Known Acronyms** (may skip full form):
+- CPU, AI, ML, API, URL, HTTP, HTTPS
+
+**How to Check**:
+- Search for acronyms in the document
+- Verify that each acronym appears with its full term before standalone use
+- Check that acronyms in title/summary are introduced in the first paragraph
+
+**Checkpoints**:
+- [ ] Acronym is presented with full term when it first appears
+- [ ] Acronym does not appear before the full term
+- [ ] Only the full term is bolded, not the acronym
+- [ ] Acronyms in title/summary are introduced in first paragraph
+
+---
+
+### 1.3 Term Capitalization Consistency
+
+**Problem**: Inconsistent capitalization of the same term throughout a document confuses readers and looks unprofessional.
+
+**Rules**:
+- Decide capitalization when a technical term first appears, then maintain it consistently throughout the document
+- Acronyms should be all uppercase (e.g., GPU, TPU, SM, CUDA, HBM, SMEM)
+- Common nouns should be lowercase (e.g., loop, thread, warp, core, unit, array)
+- Proper nouns and brand names follow their official capitalization (e.g., NVIDIA, Google, TensorFlow, PyTorch)
+- When in doubt, check official documentation or websites
+
+**Incorrect Examples**:
+```markdown
+이 문서에서는 Loop와 loop를 혼용하고 있습니다.
+GPU와 gpu가 섞여 있습니다.
+Tensorflow와 TensorFlow가 혼용됩니다.
+```
+
+**Correct Examples**:
+```markdown
+이 문서에서는 loop를 사용합니다.
+GPU는 Graphics Processing Unit의 약자입니다.
+TensorFlow는 구글이 개발한 프레임워크입니다.
+```
+
+**Common Terms and Their Correct Capitalization**:
+- **Lowercase**: loop, thread, warp, core, unit, array, buffer, memory, register
+- **Uppercase (Acronyms)**: GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX
+- **Brand Names**: NVIDIA, Google, TensorFlow, PyTorch, JAX, Pallas, Triton
+
+**How to Check**:
+- Search for variations of the same term (e.g., "Loop", "loop", "LOOP")
+- Verify consistency throughout the document
+- Check brand names against official sources
+
+**Checkpoints**:
+- [ ] Same term uses consistent capitalization within the document
+- [ ] All acronyms are unified in uppercase
+- [ ] Brand names use correct capitalization
+- [ ] Common nouns are lowercase
+
+---
+
+## 2. Content Quality (High Priority)
+
+These rules ensure blog posts are readable, well-structured, and technically accurate.
+
+### 2.1 Readability
+
+**Problem**: Long sentences and paragraphs make technical content hard to follow. Readers lose focus and miss important information.
+
+**Rules**:
+
+**Sentence Length**:
+- A sentence should be **within 50 characters** (recommended, flexible for technical terms)
+- Break complex explanations into multiple sentences
+- Split long sentences connected with commas (`,`) or conjunctions (`그리고`, `또한`, `또한`)
+- Use periods (`.`) more liberally to create shorter, clearer sentences
+- One idea per sentence when possible
+
+**Paragraph Length**:
+- A paragraph should be approximately **5-7 sentences**
+- Consider splitting if a paragraph has **10 or more sentences**
+- Consider splitting if a paragraph exceeds **200 characters**
+- Use blank lines to separate distinct ideas
+- Each paragraph should focus on one main idea
+
+**Incorrect Example**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어로, 구글이 2016년부터 개발해온 것으로, 행렬 곱셈 연산에 최적화되어 있으며, Systolic Array라는 특별한 연산 유닛을 사용하며, 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+**Correct Example**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어입니다. 구글이 2016년부터 개발해온 TPU는 행렬 곱셈 연산에 최적화되어 있습니다.
+
+TPU는 Systolic Array라는 특별한 연산 유닛을 사용합니다. 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+**How to Check**:
+- Count characters in each sentence (approximate)
+- Count sentences in each paragraph
+- Look for sentences with multiple commas or conjunctions
+- Check for paragraphs that span multiple screen heights
+
+**Checkpoints**:
+- [ ] No sentence exceeds 50 characters (flexible for technical terms)
+- [ ] No paragraph has 10 or more sentences
+- [ ] No paragraph exceeds 200 characters
+- [ ] Complex explanations are broken into multiple sentences
+- [ ] Blank lines separate distinct ideas
+
+---
+
+### 2.2 Technical Writing
+
+**Problem**: Technical content without proper explanations, context, or structure is hard to understand.
+
+**Rules**:
+
+**Term Definitions**:
+- Briefly explain technical terms when they first appear
+- Provide context: why is this term important? How does it relate to the topic?
+- Follow the "Acronym Usage Rules" above for acronyms
+- Use examples or analogies when helpful
+
+**Code Examples**:
+- Use code examples that actually work (test them if possible)
+- Add explanations through comments in the code
+- Explain complex code step by step before or after the code block
+- Use appropriate language tags for syntax highlighting
+- If code is pseudocode or conceptual, mention it in the text
+
+**Diagrams and Images**:
+- Use diagrams to explain complex concepts (architecture, flow, relationships)
+- Add meaningful alt text that describes the content, not just "image" or "diagram"
+- Use captions when helpful for context
+- Name image files meaningfully (e.g., `tpu-architecture.png`, not `image1.png`)
+
+**Structure**:
+- Start with an introduction that sets context
+- Use headings to organize content logically
+- End with a summary or conclusion
+- Use transitions between sections
+- Guide readers from general to specific concepts
+
+**Incorrect Examples**:
+```markdown
+SM은 GPU의 구성 요소입니다. (No explanation of what SM does or why it matters)
+
+```python
+def compute(x, y):
+    return x * y
+``` (No explanation of what this code does or why it's relevant)
+```
+
+**Correct Examples**:
+```markdown
+**Streaming Multiprocessor(SM)**은 GPU의 핵심 연산 단위입니다. 각 SM은 수백 개의 CUDA 코어를 포함하며, 독립적으로 스레드 블록을 실행합니다. 이는 GPU의 병렬 처리 능력의 기반이 됩니다.
+
+다음 코드는 행렬 곱셈을 수행합니다:
+
+```python
+def matrix_multiply(A, B):
+    """두 행렬 A와 B를 곱합니다."""
+    return A @ B  # NumPy의 행렬 곱셈 연산자 사용
+```
+
+이 함수는 NumPy의 최적화된 행렬 곱셈을 사용하여 효율적으로 연산을 수행합니다.
+```
+
+**Checkpoints**:
+- [ ] Technical terms are explained when first introduced
+- [ ] Code examples have comments or explanations
+- [ ] Images have meaningful alt text
+- [ ] Content has logical structure with clear sections
+- [ ] Transitions connect sections smoothly
+
+---
+
+## 3. Markdown Formatting (Medium Priority)
+
+These rules ensure proper markdown rendering and consistent formatting.
+
+### 3.1 Headings
+
+**Rules**:
+- Use H1(`#`) only for the page title (usually in frontmatter, not in body)
+- Start body sections with H2(`##`)
+- Use H3(`###`) for subsections
+- Use H4(`####`) for sub-subsections if needed
+- Do not skip heading hierarchy (e.g., do not use H4 after H2)
+- Use descriptive headings that summarize the section content
+- Headings should form a logical outline of the content
+
+**Incorrect Examples**:
+```markdown
+# Main Title
+## Section 1
+#### Subsection (Skipped H3)
+```
+
+**Correct Examples**:
+```markdown
+## TPU Architecture
+### Systolic Array
+#### Data Flow
+```
+
+**Checkpoints**:
+- [ ] H1 is only used for page title
+- [ ] Heading hierarchy is not skipped
+- [ ] Headings are descriptive
+- [ ] Headings form a logical outline
+
+---
+
+### 3.2 Code Blocks
+
+**Rules**:
+- Code blocks must specify language tags: ` ```python`, ` ```bash`, ` ```cuda`, etc.
+- Use single backticks for inline code: `` `variable_name` ``
+- For file paths or commands, use inline code: `` `hugo server` ``
+- Add comments in code to explain complex logic
+- If code is pseudocode or conceptual, mention it in the text
+- Format code properly (indentation, spacing)
+
+**Incorrect Examples**:
+```markdown
+```
+def hello():
+    print("world")
+```
+(No language tag)
+```
+
+**Correct Examples**:
+```python
+def hello():
+    """Print hello world."""
+    print("world")
+```
+
+**Common Languages in This Blog**:
+- `python`, `cuda`, `bash`, `c`, `go`, `fsharp`, `javascript`, `yaml`, `toml`
+
+**Checkpoints**:
+- [ ] All code blocks have language tags
+- [ ] Inline code uses single backticks
+- [ ] Complex code has comments or explanations
+- [ ] Code is properly formatted
+
+---
+
+### 3.3 Images and Links
+
+**Rules**:
+
+**Images**:
+- Always include alt text: `![descriptive alt text](path/to/image.png)`
+- Alt text should describe the content, not just say "image" or "diagram"
+- Use relative paths for images in the same post directory
+- Use meaningful file names (e.g., `tpu-architecture.png`, not `img1.png`)
+- Prefer `.webp` format for better compression
+
+**Links**:
+- Use descriptive link text: `[descriptive text](URL)`
+- Avoid generic text like "click here" or "link"
+- For external links, consider adding `{:target="_blank"}` if needed (Hugo-specific)
+- Link to authoritative sources when possible
+
+**Incorrect Examples**:
+```markdown
+![image](tpu.png)  (No descriptive alt text)
+[여기](https://example.com)를 클릭하세요.  (Generic link text)
+```
+
+**Correct Examples**:
+```markdown
+![TPU architecture diagram showing Systolic Array](tpu-architecture.png)
+[TPU 논문](https://arxiv.org/pdf/1704.04760)을 참고하세요.
+```
+
+**Checkpoints**:
+- [ ] All images have descriptive alt text
+- [ ] Link text is descriptive
+- [ ] Image file names are meaningful
+- [ ] Images use appropriate formats
+
+---
+
+### 3.4 Lists and Quotes
+
+**Rules**:
+
+**Lists**:
+- Use `-` for unordered lists (consistent throughout)
+- Use `1.` for ordered lists when order matters
+- Maintain consistency between list items (same structure, same level of detail)
+- Nested lists are recommended up to 2 levels
+- Add blank lines before and after lists for readability
+- Use parallel structure in list items
+
+**Block Quotes**:
+- Use `>` for block quotes
+- Use quotes for important statements, definitions, or callouts
+- Keep quotes concise
+- Use quotes to highlight key concepts or definitions
+
+**Incorrect Examples**:
+```markdown
+- Item 1
+* Item 2  (Inconsistent list markers)
+```
+
+**Correct Examples**:
+```markdown
+- Item 1
+- Item 2
+  - Sub-item 2.1
+  - Sub-item 2.2
+```
+
+**Checkpoints**:
+- [ ] List markers are consistent
+- [ ] List items have consistent structure
+- [ ] Quotes are used appropriately
+- [ ] Lists have proper spacing
+
+---
+
+## 4. Frontmatter and Metadata
+
+**Rules**:
+- All posts must have frontmatter with required fields
+- `date` should be in ISO 8601 format: `'2026-01-03T17:20:16+09:00'`
+- `draft: false` for published posts
+- `title` should be descriptive and match the H1 heading
+- `tags` should be relevant and consistent (use existing tags when possible)
+- `authors` must match entries in `content/authors/`
+- `summary` should be a concise one-line description
+- `description` can be longer (used for SEO)
+- For series posts, include `series: ["시리즈 이름"]`
+- `cover` image is optional but recommended
+
+**Required Fields**:
+```yaml
+---
+date: '2026-01-03T17:20:16+09:00'
+draft: false
+title: 'Post Title'
+authors: ["Author Name"]
+tags: ["Tag1", "Tag2"]
+categories: ["Category"]
+summary: "One-line summary"
+description: "Longer description for SEO"
+---
+```
+
+**Optional Fields**:
+```yaml
+series: ["Series Name"]
+cover:
+  image: "path/to/image.png"
+  alt: "Image description"
+  caption: "Image caption"
+  relative: true
+comments: true
+```
+
+**Checkpoints**:
+- [ ] All required frontmatter fields are present
+- [ ] Date format is correct
+- [ ] Authors match existing author entries
+- [ ] Tags are relevant and consistent
+- [ ] Summary is concise and descriptive
+
+---
+
+## 5. Complete Examples
+
+### 5.1 Before and After: Acronym and Bold Rendering
+
+**Before (Incorrect)**:
+```markdown
+SM은 GPU의 핵심 구성 요소입니다. **SM(Streaming Multiprocessor)**으로 구성되어 있으며, 각 SM은 수백 개의 CUDA 코어를 포함합니다.
+```
+
+**After (Correct)**:
+```markdown
+**Streaming Multiprocessor(SM)**은 GPU의 핵심 구성 요소입니다. GPU는 수백 개의 SM 으로 구성되어 있으며, 각 SM은 수백 개의 CUDA 코어를 포함합니다.
+```
+
+### 5.2 Before and After: Readability
+
+**Before (Incorrect)**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어로, 구글이 2016년부터 개발해온 것으로, 행렬 곱셈 연산에 최적화되어 있으며, Systolic Array라는 특별한 연산 유닛을 사용하며, 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+**After (Correct)**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어입니다. 구글이 2016년부터 개발해온 TPU는 행렬 곱셈 연산에 최적화되어 있습니다.
+
+TPU는 Systolic Array라는 특별한 연산 유닛을 사용합니다. 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+---
+
+## 6. Review Checklist
+
+When reviewing a blog post, check the following items in order of priority:
+
+### Critical (Must Fix)
+- [ ] **Bold rendering**: No `**text**한글` patterns without spaces
+- [ ] **Acronyms**: All acronyms introduced with full terms first
+- [ ] **Capitalization**: Consistent capitalization throughout
+
+### High Priority
+- [ ] **Readability**: Sentences within 50 characters, paragraphs within 10 sentences
+- [ ] **Technical terms**: All technical terms explained when first introduced
+- [ ] **Code examples**: All code blocks have language tags and explanations
+- [ ] **Images**: All images have descriptive alt text
+
+### Medium Priority
+- [ ] **Headings**: Proper hierarchy (H2 → H3 → H4, no skipping)
+- [ ] **Links**: Descriptive link text
+- [ ] **Lists**: Consistent formatting
+- [ ] **Frontmatter**: All required fields present and correct
+
+### Additional Checks
+- [ ] Content flows logically with clear transitions
+- [ ] No typos or grammatical errors
+- [ ] Examples are accurate and tested (if applicable)
+- [ ] Images are properly placed and referenced
+
+---
+
+## Notes for Reviewers
+
+- **Severity Levels**: 
+  - **Critical**: Causes rendering issues or major readability problems
+  - **High**: Significantly impacts readability or understanding
+  - **Medium**: Formatting or consistency issues
+
+- **Be Constructive**: When pointing out issues, suggest specific fixes
+- **Context Matters**: Some rules may be flexible for technical content (e.g., longer sentences for complex explanations)
+- **Consistency First**: If a pattern is used consistently throughout a post, it may be acceptable even if not ideal
+
+---
+
+## Common Patterns in This Blog
+
+Based on existing posts, here are common patterns to follow:
+
+- **Series Posts**: Use series tag for series like `series: ["지피지기면 백전불태"]`
+- **Code Languages**: Python, CUDA, Bash, C, Go, F# are commonly used
+- **Image Formats**: `.webp`, `.png`, `.jpg` are used
+- **Technical Terms**: GPU, TPU, SM, CUDA, HBM, Systolic Array, Tensor Core, etc.
diff --git a/.gemini/config.yaml b/.gemini/config.yaml
new file mode 100644
index 0000000..95f8a9d
--- /dev/null
+++ b/.gemini/config.yaml
@@ -0,0 +1,34 @@
+# Gemini Code Assist Configuration
+# 블로그 포스트 리뷰를 위한 설정
+
+have_fun: true  # 블로그 글은 비공식적(유머 등)이어도 좋습니다.
+
+memory_config:
+  disabled: false
+
+# 리뷰에서 제외할 파일/디렉토리 패턴
+ignore_patterns:
+  - "themes/**"  # 테마 파일은 제외
+  - "*.lock"  # 빌드 락 파일
+  - ".git/**"  # Git 메타데이터
+  - "public/**"  # 빌드 결과물
+  - "static/**"  # 정적 파일 (이미지, favicon 등)
+  - "layouts/**"  # HTML 템플릿 파일
+  - "archetypes/**"  # Hugo 템플릿 파일
+  - "assets/**"  # CSS 등 에셋 파일 (선택적)
+
+# 코드 리뷰 설정
+code_review:
+  disable: false
+  comment_severity_threshold: MEDIUM  # MEDIUM 이상의 이슈만 코멘트
+  max_review_comments: -1  # 최대 코멘트 수 제한
+  pull_request_opened:
+    help: false
+    summary: true
+    code_review: true
+    include_drafts: true  # 초안 PR에서 제미나이로 수정 많이 해주세요
+
+# 마크다운 파일에 집중
+file_patterns:
+  - "content/posts/**/*.md"
+  - "content/**/*.md"
diff --git a/.gemini/styleguide.md b/.gemini/styleguide.md
new file mode 100644
index 0000000..fae4978
--- /dev/null
+++ b/.gemini/styleguide.md
@@ -0,0 +1,621 @@
+# HyperAccel Blog Style Guide
+
+This document defines style rules for writing markdown posts in the HyperAccel technical blog. Follow these rules to ensure consistency, readability, and proper rendering across all blog posts.
+
+---
+
+## Table of Contents
+
+1. [Critical Issues (Must Fix)](#1-critical-issues-must-fix)
+   - [Markdown Bold Rendering](#11-markdown-bold-rendering)
+   - [Acronym Usage](#12-acronym-usage)
+   - [Term Capitalization Consistency](#13-term-capitalization-consistency)
+2. [Content Quality (High Priority)](#2-content-quality-high-priority)
+   - [Readability](#21-readability)
+   - [Technical Writing](#22-technical-writing)
+3. [Markdown Formatting (Medium Priority)](#3-markdown-formatting-medium-priority)
+   - [Headings](#31-headings)
+   - [Code Blocks](#32-code-blocks)
+   - [Images and Links](#33-images-and-links)
+   - [Lists and Quotes](#34-lists-and-quotes)
+4. [Frontmatter and Metadata](#4-frontmatter-and-metadata)
+5. [Complete Examples](#5-complete-examples)
+6. [Review Checklist](#6-review-checklist)
+
+---
+
+## 1. Critical Issues (Must Fix)
+
+These issues cause rendering problems or significantly impact readability. They must be fixed before merging.
+
+### 1.1 Markdown Bold Rendering
+
+**Problem**: When Korean text immediately follows bold text, markdown rendering may break, causing asterisks to appear as literal characters in the rendered output.
+
+**Rules**:
+- Always add a space when Korean particles (은, 는, 이, 가, 을, 를, 으로, 로, 의, 에, 에서, 와, 과, 등) immediately follow bold markers `**`
+- Pay special attention when Korean text follows bold text ending with parentheses
+- This applies to all bold text, not just acronyms
+- The space should be between the closing `**` and the Korean text
+
+**Incorrect Examples**:
+```markdown
+**SM(Streaming Multiprocessor)**으로 구성되어 있습니다.
+**TPU(Tensor Processing Unit)**는 이와 대조적입니다.
+**대기 시간을 다른 작업으로 메워 효율을 극대화(Latency Hiding)**하는 방식입니다.
+**GPU**는 병렬 연산에 최적화되어 있습니다.
+```
+
+**Correct Examples**:
+```markdown
+**Streaming Multiprocessor(SM)** 으로 구성되어 있습니다.
+**Tensor Processing Unit(TPU)** 는 이와 대조적입니다.
+**대기 시간을 다른 작업으로 메워 효율을 극대화(Latency Hiding)** 하는 방식입니다.
+**GPU** 는 병렬 연산에 최적화되어 있습니다.
+```
+
+**How to Check**:
+- Search for pattern: `\*\*[^*]+\*\*[가-힣]` (bold text immediately followed by Korean)
+- Visual inspection: Render the markdown and check if asterisks appear as literal characters
+
+**Checkpoints**:
+- [ ] No pattern like `**text(acronym)**한글` exists
+- [ ] No pattern like `**text**한글` exists
+- [ ] All bold markers followed by Korean text have a space
+- [ ] Rendered output shows no literal asterisks
+
+---
+
+### 1.2 Acronym Usage
+
+**Problem**: Using acronyms before introducing the full term confuses readers. Incorrect formatting makes terms hard to understand and breaks the reading flow.
+
+**Rules**:
+- **First use**: Always write `FullTerm(Acronym)` format
+- **Subsequent use**: Only the acronym can be used
+- **Bold formatting**: Bold only the full term, not the acronym: `**FullTerm(Acronym)**`
+- If an acronym appears in the title or summary, introduce it in the first paragraph
+- For well-known acronyms (e.g., CPU, GPU, AI), you may skip the full form if it's extremely common
+
+**Incorrect Examples**:
+```markdown
+SM은 GPU의 핵심 구성 요소입니다. (Acronym used before full term)
+**SM(Streaming Multiprocessor)**으로 구성되어 있습니다. (Acronym is bolded)
+이 글에서는 TPU에 대해 설명합니다. (TPU not introduced)
+```
+
+**Correct Examples**:
+```markdown
+**Streaming Multiprocessor(SM)**은 GPU의 핵심 구성 요소입니다.
+이후 문장에서는 SM으로 지칭할 수 있습니다.
+
+이 글에서는 **Tensor Processing Unit(TPU)**에 대해 설명합니다.
+TPU는 구글이 개발한 AI 가속기입니다.
+```
+
+**Common Acronyms in This Blog** (must follow the rule):
+- GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton, VLIW, DMA, ALU, SIMD, SPMD
+
+**Well-Known Acronyms** (may skip full form):
+- CPU, AI, ML, API, URL, HTTP, HTTPS
+
+**How to Check**:
+- Search for acronyms in the document
+- Verify that each acronym appears with its full term before standalone use
+- Check that acronyms in title/summary are introduced in the first paragraph
+
+**Checkpoints**:
+- [ ] Acronym is presented with full term when it first appears
+- [ ] Acronym does not appear before the full term
+- [ ] Only the full term is bolded, not the acronym
+- [ ] Acronyms in title/summary are introduced in first paragraph
+
+---
+
+### 1.3 Term Capitalization Consistency
+
+**Problem**: Inconsistent capitalization of the same term throughout a document confuses readers and looks unprofessional.
+
+**Rules**:
+- Decide capitalization when a technical term first appears, then maintain it consistently throughout the document
+- Acronyms should be all uppercase (e.g., GPU, TPU, SM, CUDA, HBM, SMEM)
+- Common nouns should be lowercase (e.g., loop, thread, warp, core, unit, array)
+- Proper nouns and brand names follow their official capitalization (e.g., NVIDIA, Google, TensorFlow, PyTorch)
+- When in doubt, check official documentation or websites
+
+**Incorrect Examples**:
+```markdown
+이 문서에서는 Loop와 loop를 혼용하고 있습니다.
+GPU와 gpu가 섞여 있습니다.
+Tensorflow와 TensorFlow가 혼용됩니다.
+```
+
+**Correct Examples**:
+```markdown
+이 문서에서는 loop를 사용합니다.
+GPU는 Graphics Processing Unit의 약자입니다.
+TensorFlow는 구글이 개발한 프레임워크입니다.
+```
+
+**Common Terms and Their Correct Capitalization**:
+- **Lowercase**: loop, thread, warp, core, unit, array, buffer, memory, register
+- **Uppercase (Acronyms)**: GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX
+- **Brand Names**: NVIDIA, Google, TensorFlow, PyTorch, JAX, Pallas, Triton
+
+**How to Check**:
+- Search for variations of the same term (e.g., "Loop", "loop", "LOOP")
+- Verify consistency throughout the document
+- Check brand names against official sources
+
+**Checkpoints**:
+- [ ] Same term uses consistent capitalization within the document
+- [ ] All acronyms are unified in uppercase
+- [ ] Brand names use correct capitalization
+- [ ] Common nouns are lowercase
+
+---
+
+## 2. Content Quality (High Priority)
+
+These rules ensure blog posts are readable, well-structured, and technically accurate.
+
+### 2.1 Readability
+
+**Problem**: Long sentences and paragraphs make technical content hard to follow. Readers lose focus and miss important information.
+
+**Rules**:
+
+**Sentence Length**:
+- A sentence should be **within 50 characters** (recommended, flexible for technical terms)
+- Break complex explanations into multiple sentences
+- Split long sentences connected with commas (`,`) or conjunctions (`그리고`, `또한`, `또한`)
+- Use periods (`.`) more liberally to create shorter, clearer sentences
+- One idea per sentence when possible
+
+**Paragraph Length**:
+- A paragraph should be approximately **5-7 sentences**
+- Consider splitting if a paragraph has **10 or more sentences**
+- Consider splitting if a paragraph exceeds **200 characters**
+- Use blank lines to separate distinct ideas
+- Each paragraph should focus on one main idea
+
+**Incorrect Example**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어로, 구글이 2016년부터 개발해온 것으로, 행렬 곱셈 연산에 최적화되어 있으며, Systolic Array라는 특별한 연산 유닛을 사용하며, 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+**Correct Example**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어입니다. 구글이 2016년부터 개발해온 TPU는 행렬 곱셈 연산에 최적화되어 있습니다.
+
+TPU는 Systolic Array라는 특별한 연산 유닛을 사용합니다. 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+**How to Check**:
+- Count characters in each sentence (approximate)
+- Count sentences in each paragraph
+- Look for sentences with multiple commas or conjunctions
+- Check for paragraphs that span multiple screen heights
+
+**Checkpoints**:
+- [ ] No sentence exceeds 50 characters (flexible for technical terms)
+- [ ] No paragraph has 10 or more sentences
+- [ ] No paragraph exceeds 200 characters
+- [ ] Complex explanations are broken into multiple sentences
+- [ ] Blank lines separate distinct ideas
+
+---
+
+### 2.2 Technical Writing
+
+**Problem**: Technical content without proper explanations, context, or structure is hard to understand.
+
+**Rules**:
+
+**Term Definitions**:
+- Briefly explain technical terms when they first appear
+- Provide context: why is this term important? How does it relate to the topic?
+- Follow the "Acronym Usage Rules" above for acronyms
+- Use examples or analogies when helpful
+
+**Code Examples**:
+- Use code examples that actually work (test them if possible)
+- Add explanations through comments in the code
+- Explain complex code step by step before or after the code block
+- Use appropriate language tags for syntax highlighting
+- If code is pseudocode or conceptual, mention it in the text
+
+**Diagrams and Images**:
+- Use diagrams to explain complex concepts (architecture, flow, relationships)
+- Add meaningful alt text that describes the content, not just "image" or "diagram"
+- Use captions when helpful for context
+- Name image files meaningfully (e.g., `tpu-architecture.png`, not `image1.png`)
+
+**Structure**:
+- Start with an introduction that sets context
+- Use headings to organize content logically
+- End with a summary or conclusion
+- Use transitions between sections
+- Guide readers from general to specific concepts
+
+**Incorrect Examples**:
+```markdown
+SM은 GPU의 구성 요소입니다. (No explanation of what SM does or why it matters)
+
+```python
+def compute(x, y):
+    return x * y
+``` (No explanation of what this code does or why it's relevant)
+```
+
+**Correct Examples**:
+```markdown
+**Streaming Multiprocessor(SM)**은 GPU의 핵심 연산 단위입니다. 각 SM은 수백 개의 CUDA 코어를 포함하며, 독립적으로 스레드 블록을 실행합니다. 이는 GPU의 병렬 처리 능력의 기반이 됩니다.
+
+다음 코드는 행렬 곱셈을 수행합니다:
+
+```python
+def matrix_multiply(A, B):
+    """두 행렬 A와 B를 곱합니다."""
+    return A @ B  # NumPy의 행렬 곱셈 연산자 사용
+```
+
+이 함수는 NumPy의 최적화된 행렬 곱셈을 사용하여 효율적으로 연산을 수행합니다.
+```
+
+**Checkpoints**:
+- [ ] Technical terms are explained when first introduced
+- [ ] Code examples have comments or explanations
+- [ ] Images have meaningful alt text
+- [ ] Content has logical structure with clear sections
+- [ ] Transitions connect sections smoothly
+
+---
+
+## 3. Markdown Formatting (Medium Priority)
+
+These rules ensure proper markdown rendering and consistent formatting.
+
+### 3.1 Headings
+
+**Rules**:
+- Use H1(`#`) only for the page title (usually in frontmatter, not in body)
+- Start body sections with H2(`##`)
+- Use H3(`###`) for subsections
+- **Maximum heading level is H3** - Do not use H4(`####`) or deeper levels
+- Do not skip heading hierarchy (e.g., do not use H3 after H1)
+- Use descriptive headings that summarize the section content
+- Headings should form a logical outline of the content
+- If you need more levels of organization, use lists or paragraphs instead of deeper headings
+
+**Incorrect Examples**:
+```markdown
+# Main Title
+## Section 1
+#### Subsection (Skipped H3, and H4 not allowed)
+
+## TPU Architecture
+### Systolic Array
+#### Data Flow  (H4 not allowed - maximum is H3)
+```
+
+**Correct Examples**:
+```markdown
+## TPU Architecture
+### Systolic Array
+
+데이터 흐름은 다음과 같습니다: (Use paragraph instead of H4)
+
+## TPU Architecture
+### Systolic Array
+### Data Flow  (Use H3 instead of H4)
+```
+
+**Checkpoints**:
+- [ ] H1 is only used for page title
+- [ ] Maximum heading level is H3 (no H4 or deeper)
+- [ ] Heading hierarchy is not skipped
+- [ ] Headings are descriptive
+- [ ] Headings form a logical outline
+
+---
+
+### 3.2 Code Blocks
+
+**Rules**:
+- Code blocks must specify language tags: ` ```python`, ` ```bash`, ` ```cuda`, etc.
+- Use single backticks for inline code: `` `variable_name` ``
+- For file paths or commands, use inline code: `` `hugo server` ``
+- Add comments in code to explain complex logic
+- If code is pseudocode or conceptual, mention it in the text
+- Format code properly (indentation, spacing)
+
+**Incorrect Examples**:
+```markdown
+```
+def hello():
+    print("world")
+```
+(No language tag)
+```
+
+**Correct Examples**:
+```python
+def hello():
+    """Print hello world."""
+    print("world")
+```
+
+**Common Languages in This Blog**:
+- `python`, `cuda`, `bash`, `c`, `go`, `fsharp`, `javascript`, `yaml`, `toml`
+
+**Checkpoints**:
+- [ ] All code blocks have language tags
+- [ ] Inline code uses single backticks
+- [ ] Complex code has comments or explanations
+- [ ] Code is properly formatted
+
+---
+
+### 3.3 Images and Links
+
+**Rules**:
+
+**Images**:
+- Always include alt text: `![descriptive alt text](path/to/image.png)`
+- Alt text should describe the content, not just say "image" or "diagram"
+- Use relative paths for images in the same post directory
+- Use meaningful file names (e.g., `tpu-architecture.png`, not `img1.png`)
+- Prefer `.webp` format for better compression
+- **Image placement**: Place images **BEFORE** the content they illustrate (recommended)
+  - This allows readers to see the visual context before reading the explanation
+  - Example: Place a diagram before the paragraph that explains it, not after
+
+**Links**:
+- Use descriptive link text: `[descriptive text](URL)`
+- Avoid generic text like "click here" or "link"
+- For external links, consider adding `{:target="_blank"}` if needed (Hugo-specific)
+- Link to authoritative sources when possible
+
+**Incorrect Examples**:
+```markdown
+![image](tpu.png)  (No descriptive alt text)
+[여기](https://example.com)를 클릭하세요.  (Generic link text)
+
+TPU는 Systolic Array 구조를 사용합니다.
+![TPU architecture](tpu-architecture.png)  (Image placed after content)
+```
+
+**Correct Examples**:
+```markdown
+![TPU architecture diagram showing Systolic Array](tpu-architecture.png)
+
+TPU는 Systolic Array 구조를 사용합니다. 이 구조는...
+
+[TPU 논문](https://arxiv.org/pdf/1704.04760)을 참고하세요.
+```
+
+**Checkpoints**:
+- [ ] All images have descriptive alt text
+- [ ] Images are placed BEFORE the content they illustrate (recommended)
+- [ ] Link text is descriptive
+- [ ] Image file names are meaningful
+- [ ] Images use appropriate formats
+
+---
+
+### 3.4 Lists and Quotes
+
+**Rules**:
+
+**Lists**:
+- Use `-` for unordered lists (consistent throughout)
+- Use `1.` for ordered lists when order matters
+- Maintain consistency between list items (same structure, same level of detail)
+- Nested lists are recommended up to 2 levels
+- Add blank lines before and after lists for readability
+- Use parallel structure in list items
+
+**Block Quotes**:
+- Use `>` for block quotes
+- Use quotes for important statements, definitions, or callouts
+- Keep quotes concise
+- Use quotes to highlight key concepts or definitions
+
+**Incorrect Examples**:
+```markdown
+- Item 1
+* Item 2  (Inconsistent list markers)
+```
+
+**Correct Examples**:
+```markdown
+- Item 1
+- Item 2
+  - Sub-item 2.1
+  - Sub-item 2.2
+```
+
+**Checkpoints**:
+- [ ] List markers are consistent
+- [ ] List items have consistent structure
+- [ ] Quotes are used appropriately
+- [ ] Lists have proper spacing
+
+---
+
+## 4. Frontmatter and Metadata
+
+**Rules**:
+- All posts must have frontmatter with required fields
+- `date` should be in ISO 8601 format: `'2026-01-03T17:20:16+09:00'`
+- `draft: false` for published posts
+- `title` should be descriptive and match the H1 heading
+- `tags` should be relevant and consistent (use existing tags when possible)
+- `authors` must match entries in `content/authors/`
+- `summary` should be a concise one-line description
+- `description` can be longer (used for SEO)
+- For series posts, include `series: ["시리즈 이름"]`
+- `cover` image is optional but recommended
+
+**Required Fields**:
+```yaml
+---
+date: '2026-01-03T17:20:16+09:00'
+draft: false
+title: 'Post Title'
+authors: ["Author Name"]
+tags: ["Tag1", "Tag2"]
+categories: ["Category"]
+summary: "One-line summary"
+description: "Longer description for SEO"
+---
+```
+
+**Optional Fields**:
+```yaml
+series: ["Series Name"]
+cover:
+  image: "path/to/image.png"
+  alt: "Image description"
+  caption: "Image caption"
+  relative: true
+comments: true
+```
+
+**Checkpoints**:
+- [ ] All required frontmatter fields are present
+- [ ] Date format is correct
+- [ ] Authors match existing author entries
+- [ ] Tags are relevant and consistent
+- [ ] Summary is concise and descriptive
+
+---
+
+## 5. Complete Examples
+
+### 5.1 Before and After: Acronym and Bold Rendering
+
+**Before (Incorrect)**:
+```markdown
+SM은 GPU의 핵심 구성 요소입니다. **SM(Streaming Multiprocessor)**으로 구성되어 있으며, 각 SM은 수백 개의 CUDA 코어를 포함합니다.
+```
+
+**After (Correct)**:
+```markdown
+**Streaming Multiprocessor(SM)**은 GPU의 핵심 구성 요소입니다. GPU는 수백 개의 SM 으로 구성되어 있으며, 각 SM은 수백 개의 CUDA 코어를 포함합니다.
+```
+
+### 5.2 Before and After: Readability
+
+**Before (Incorrect)**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어로, 구글이 2016년부터 개발해온 것으로, 행렬 곱셈 연산에 최적화되어 있으며, Systolic Array라는 특별한 연산 유닛을 사용하며, 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+**After (Correct)**:
+```markdown
+TPU는 AI 연산에 특화된 하드웨어입니다. 구글이 2016년부터 개발해온 TPU는 행렬 곱셈 연산에 최적화되어 있습니다.
+
+TPU는 Systolic Array라는 특별한 연산 유닛을 사용합니다. 이는 일반적인 CPU나 GPU와는 다른 접근 방식을 취하고 있습니다.
+```
+
+### 5.3 Complete Post Example
+
+**Good Example Structure**:
+```markdown
+---
+date: '2026-01-03T17:20:16+09:00'
+draft: false
+title: '지피지기면 백전불태 2편: TPU의 등장과 부상'
+authors: ["Jaewon Lim"]
+tags: ["TPU", "Google", "Ironwood"]
+categories: ["AI Hardware"]
+series: ["지피지기면 백전불태"]
+summary: "TPU의 등장 배경과 하드웨어/소프트웨어 구조를 분석합니다."
+---
+
+# 지피지기면 백전불태 2편: TPU의 등장과 부상
+
+> **지피지기면 백전불태(知彼知己 百戰不殆)**  
+> 상대를 알고 나를 알면 백 번 싸워도 위태롭지 않다는 뜻입니다.
+
+## TPU?
+
+최근 AI 가속기 시장에서 가장 핫하게 떠오른 키워드 중 하나는 바로 **Tensor Processing Unit(TPU)**일 것입니다. 
+
+## TPU의 등장
+
+**Tensor Processing Unit(TPU)** 구조를 이해하기 위해서는 먼저 TPU가 개발된 배경에 대해 알아야 할 필요가 있습니다.
+
+![TPU 실제 사진](tpu2.webp)
+
+## TPU 하드웨어 아키텍처
+
+### Systolic Array
+
+TPU는 AI 연산에 특화되어 제작되었습니다. AI 연산 중 가장 큰 특징은 대규모의 행렬 곱셈을 수행한다는 점입니다.
+
+다음 코드는 행렬 곱셈의 개념을 보여줍니다:
+
+```python
+def matrix_multiply(A, B):
+    """두 행렬을 곱합니다."""
+    return A @ B  # NumPy의 행렬 곱셈
+```
+
+이러한 Systolic Array는 TPU에서 사용한 대표적인 특징입니다.
+```
+
+---
+
+## 6. Review Checklist
+
+When reviewing a blog post, check the following items in order of priority:
+
+### Critical (Must Fix)
+- [ ] **Bold rendering**: No `**text**한글` patterns without spaces
+- [ ] **Acronyms**: All acronyms introduced with full terms first
+- [ ] **Capitalization**: Consistent capitalization throughout
+
+### High Priority
+- [ ] **Readability**: Sentences within 50 characters, paragraphs within 10 sentences
+- [ ] **Technical terms**: All technical terms explained when first introduced
+- [ ] **Code examples**: All code blocks have language tags and explanations
+- [ ] **Images**: All images have descriptive alt text and are placed before the content they illustrate
+
+### Medium Priority
+- [ ] **Headings**: Proper hierarchy (H2 → H3, maximum H3, no skipping)
+- [ ] **Links**: Descriptive link text
+- [ ] **Lists**: Consistent formatting
+- [ ] **Frontmatter**: All required fields present and correct
+
+### Additional Checks
+- [ ] Content flows logically with clear transitions
+- [ ] No typos or grammatical errors
+- [ ] Examples are accurate and tested (if applicable)
+- [ ] Images are properly placed (before content) and referenced
+
+---
+
+## Notes for Reviewers
+
+- **Severity Levels**: 
+  - **Critical**: Causes rendering issues or major readability problems
+  - **High**: Significantly impacts readability or understanding
+  - **Medium**: Formatting or consistency issues
+
+- **Be Constructive**: When pointing out issues, suggest specific fixes
+- **Context Matters**: Some rules may be flexible for technical content (e.g., longer sentences for complex explanations)
+- **Consistency First**: If a pattern is used consistently throughout a post, it may be acceptable even if not ideal
+
+---
+
+## Common Patterns in This Blog
+
+Based on existing posts, here are common patterns to follow:
+
+- **Series Posts**: Use series tag for series like `series: ["지피지기면 백전불태"]`
+- **Code Languages**: Python, CUDA, Bash, C, Go, F# are commonly used
+- **Image Formats**: `.webp`, `.png`, `.jpg` are used
+- **Technical Terms**: GPU, TPU, SM, CUDA, HBM, Systolic Array, Tensor Core, etc.
diff --git a/plans-for-pr/well-writing-skill-plan.md b/plans-for-pr/well-writing-skill-plan.md
new file mode 100644
index 0000000..7b66c9e
--- /dev/null
+++ b/plans-for-pr/well-writing-skill-plan.md
@@ -0,0 +1,337 @@
+# Well-Writing 스킬 계획서
+
+## 📋 개요
+
+**스킬 이름**: `well-writing`  
+**목적**: HyperAccel 블로그의 마크다운 포스트 글쓰기 교정 및 품질 향상  
+**주요 기능**:
+1. 마크다운 포스트의 스타일 가이드 준수 확인 및 교정
+2. Confluence 문서에서 이미지 다운로드 지원
+3. 글쓰기 품질 검증 (가독성, 일관성, 기술적 정확성)
+
+---
+
+## 📁 디렉토리 구조 (Progressive Disclosure 원칙 적용)
+
+```
+well-writing/
+├── SKILL.md                    # 메인 스킬 파일 (필수, lean하게 유지)
+│   ├── YAML frontmatter (name, description)
+│   └── 핵심 워크플로우 가이드라인만 포함
+├── scripts/
+│   └── download_confluence_images.py  # Confluence 이미지 다운로드 스크립트
+├── references/                 # 상세 참조 문서 (필요시 로드)
+│   ├── styleguide.md           # 전체 스타일 가이드 (.gemini/styleguide.md 기반)
+│   └── checklist.md            # 빠른 체크리스트
+└── assets/                     # 출력에 사용되는 파일 (선택적)
+    └── (필요시 템플릿 파일)
+```
+
+**Progressive Disclosure 구조**:
+1. **Metadata** (항상 컨텍스트): name + description (~100 words)
+2. **SKILL.md body** (스킬 트리거 시): 핵심 워크플로우만 (<5k words)
+3. **Bundled resources** (필요시 로드):
+   - `references/`: 상세 스타일 가이드, 체크리스트
+   - `scripts/`: 실행 가능한 코드
+
+---
+
+## 📝 파일별 상세 계획
+
+### 1. SKILL.md (필수, Lean하게 작성)
+
+**YAML Frontmatter** (3인칭 사용):
+```yaml
+name: Well-Writing
+description: This skill should be used when reviewing and editing markdown blog posts for the HyperAccel technical blog. It provides style guide compliance checking, readability improvements, and Confluence image download support.
+```
+
+**주요 내용** (Imperative/Infinitive form 사용):
+- **목적**: HyperAccel 블로그 마크다운 포스트의 글쓰기 교정 및 품질 향상
+- **사용 시점**: 마크다운 포스트 작성/수정/검토 요청 시
+- **핵심 워크플로우**:
+  1. `references/styleguide.md`를 로드하여 스타일 가이드 확인
+  2. Critical Issues 검사 (Bold Rendering, Acronym Usage, Capitalization)
+  3. Content Quality 검사 (Readability, Technical Writing)
+  4. Markdown Formatting 검사
+  5. 구체적인 수정 제안 제공
+  6. 필요시 `scripts/download_confluence_images.py`의 `download_confluence_images()` 함수 사용
+     - 환경변수 확인 (`CONFLUENCE_EMAIL`, `CONFLUENCE_API_TOKEN`)
+     - 없으면 사용자에게 인증 정보 요청
+     - 함수 호출하여 이미지 다운로드
+
+**작성 원칙**:
+- **Lean하게 유지**: 핵심 워크플로우와 절차만 포함
+- **상세 정보는 references/로**: 스타일 가이드 상세 내용은 `references/styleguide.md`에
+- **Imperative form**: "To accomplish X, do Y" 형식 사용
+- **중복 방지**: SKILL.md와 references/에 동일 정보 중복 금지
+
+### 2. references/styleguide.md
+
+**목적**: 상세 스타일 가이드 문서 (필요시 로드)
+
+**내용**:
+- `.gemini/styleguide.md`의 전체 내용을 기반으로 작성
+- Critical Issues (Must Fix)
+- Content Quality (High Priority)
+- Markdown Formatting (Medium Priority)
+- Frontmatter and Metadata
+- Complete Examples
+
+**사용 방법**:
+- SKILL.md에서 grep 패턴 제공 (큰 파일인 경우)
+- Claude가 필요시 로드하여 참조
+- SKILL.md와 중복되지 않도록 주의
+
+### 3. references/checklist.md
+
+**목적**: 빠른 참조용 체크리스트 (필요시 로드)
+
+**내용**:
+- Critical Issues 체크리스트
+- Content Quality 체크리스트
+- Markdown Formatting 체크리스트
+- Frontmatter 검증 체크리스트
+
+### 4. scripts/download_confluence_images.py
+
+**기능**:
+- Confluence 페이지의 ADF 형식에서 이미지 정보 추출
+- Attachment API를 통한 이미지 다운로드
+- 로컬 파일명 매핑 및 저장
+
+**개선 사항** (인증 정보 처리):
+1. **환경변수 우선 확인**: `CONFLUENCE_EMAIL`, `CONFLUENCE_API_TOKEN`
+2. **에이전트 요청 방식**: 환경변수가 없으면 함수가 `None`을 반환하고, Claude가 사용자에게 요청
+3. **함수화**: 스킬 컨텍스트에서 쉽게 사용할 수 있도록 함수로 제공
+   - `get_credentials()`: 인증 정보 가져오기 (환경변수 또는 파라미터)
+   - `download_confluence_images(page_id, output_dir, email=None, api_token=None)`: 메인 함수
+4. **에러 핸들링 강화**: 명확한 에러 메시지 및 대안 제시
+5. **진행 상황 표시 개선**: 다운로드 진행률 표시
+
+**인증 정보 처리 우선순위**:
+1. 함수 파라미터로 전달된 값 (최우선)
+2. 환경변수 (`CONFLUENCE_EMAIL`, `CONFLUENCE_API_TOKEN`)
+3. 환경변수도 없으면 `None` 반환 → Claude가 사용자에게 요청
+
+**함수 시그니처**:
+```python
+def get_credentials(email=None, api_token=None):
+    """
+    인증 정보를 가져옵니다.
+    
+    우선순위:
+    1. 파라미터로 전달된 값
+    2. 환경변수 (CONFLUENCE_EMAIL, CONFLUENCE_API_TOKEN)
+    3. 없으면 (None, None) 반환 → 사용자에게 요청 필요
+    
+    Returns:
+        tuple: (email, api_token) 또는 (None, None)
+    """
+    pass
+
+def download_confluence_images(
+    page_id, 
+    output_dir, 
+    email=None, 
+    api_token=None,
+    image_mapping=None
+):
+    """
+    Confluence 페이지에서 이미지를 다운로드합니다.
+    
+    Args:
+        page_id: Confluence 페이지 ID
+        output_dir: 출력 디렉토리 (Path 객체 또는 문자열)
+        email: Confluence 이메일 (선택적, 없으면 환경변수 또는 사용자 요청)
+        api_token: Confluence API 토큰 (선택적, 없으면 환경변수 또는 사용자 요청)
+        image_mapping: 이미지 매핑 딕셔너리 (선택적)
+    
+    Returns:
+        dict: {'downloaded': int, 'failed': int, 'total': int}
+    """
+    pass
+```
+
+**사용 방법**:
+- SKILL.md에서 명시: "To download images from Confluence, use `download_confluence_images()` function. If credentials are not in environment variables, request them from the user."
+- Claude가 필요시:
+  1. 환경변수 확인
+  2. 없으면 사용자에게 이메일/API 토큰 요청
+  3. 함수 호출하여 이미지 다운로드
+
+---
+
+## 🎯 스킬 사용 시나리오 (구체적인 예시)
+
+### 시나리오 1: 새 포스트 작성 후 교정
+```
+사용자: "이 포스트를 well-writing 스킬로 검토해줘"
+→ Metadata 확인 (name + description)
+→ SKILL.md 로드
+→ references/styleguide.md 로드 (필요시)
+→ Critical Issues 검사
+→ Content Quality 검사
+→ Markdown Formatting 검사
+→ 구체적인 수정 제안 제공
+```
+
+### 시나리오 2: Confluence에서 이미지 다운로드
+```
+사용자: "Confluence 페이지 332202045의 이미지를 다운로드해줘"
+→ Metadata 확인
+→ SKILL.md 로드
+→ scripts/download_confluence_images.py 읽기
+→ get_credentials() 호출하여 환경변수 확인
+→ 환경변수 없으면 사용자에게 이메일/API 토큰 요청
+→ download_confluence_images(page_id, output_dir, email, api_token) 호출
+→ 이미지 다운로드 및 적절한 위치에 삽입
+```
+
+### 시나리오 3: 스타일 가이드 위반 수정
+```
+사용자: "이 문서의 약어 사용 규칙을 확인해줘"
+→ Metadata 확인
+→ SKILL.md 로드
+→ references/styleguide.md의 약어 섹션 로드
+→ 약어 사용 패턴 검사
+→ 수정 제안 제공
+```
+
+### 시나리오 4: 빠른 체크리스트 확인
+```
+사용자: "이 포스트의 Critical Issues를 빠르게 확인해줘"
+→ Metadata 확인
+→ SKILL.md 로드
+→ references/checklist.md 로드
+→ Critical Issues 체크리스트로 빠른 검사
+```
+
+---
+
+## 🔧 기술적 요구사항
+
+### 의존성
+- Python 3.7+
+- `requests` 라이브러리 (이미지 다운로드용)
+- Claude Desktop (Skills 기능 지원)
+
+### 환경 변수 (선택적)
+- `CONFLUENCE_EMAIL`: Confluence API 인증용 (없으면 사용자에게 요청)
+- `CONFLUENCE_API_TOKEN`: Confluence API 인증용 (없으면 사용자에게 요청)
+
+**인증 정보 처리**:
+- 환경변수가 설정되어 있으면 자동 사용
+- 환경변수가 없으면 Claude가 사용자에게 이메일과 API 토큰을 요청
+- API 토큰 생성 방법 안내: Atlassian 계정 → Security → API tokens → Create API token
+
+---
+
+## 📊 구현 우선순위 (스킬 생성 프로세스 기반)
+
+### Step 1: 구체적인 예시 이해 ✅
+- [x] 사용 시나리오 정의
+- [x] 기능 요구사항 명확화
+
+### Step 2: 재사용 가능한 리소스 계획 ✅
+- [x] scripts/ 필요성 확인 (이미지 다운로드)
+- [x] references/ 필요성 확인 (스타일 가이드)
+- [x] assets/ 필요성 확인 (현재는 불필요)
+
+### Step 3: 스킬 초기화
+- [ ] `init_skill.py` 스크립트 실행 (또는 수동으로 디렉토리 생성)
+- [ ] 기본 디렉토리 구조 생성
+
+### Step 4: 스킬 편집
+- [ ] **references/ 구현** (우선):
+  - [ ] `references/styleguide.md` 작성 (.gemini/styleguide.md 기반)
+  - [ ] `references/checklist.md` 작성
+- [ ] **scripts/ 구현**:
+  - [ ] `scripts/download_confluence_images.py` 개선 및 이동
+  - [ ] 인증 정보 처리 개선:
+    - [ ] `get_credentials()` 함수 추가 (환경변수 또는 파라미터)
+    - [ ] `download_confluence_images()` 메인 함수화
+    - [ ] 환경변수 없을 때 사용자 요청 방식 구현
+  - [ ] 스킬 컨텍스트에서 사용 가능하도록 함수화
+- [ ] **SKILL.md 작성** (마지막, lean하게):
+  - [ ] YAML frontmatter 작성 (3인칭)
+  - [ ] 핵심 워크플로우만 포함 (imperative form)
+  - [ ] references/ 및 scripts/ 참조 방법 명시
+  - [ ] 인증 정보 요청 방법 명시
+
+### Step 5: 패키징
+- [ ] `package_skill.py` 실행
+- [ ] 검증 통과 확인
+- [ ] ZIP 파일 생성
+
+### Step 6: 반복 개선
+- [ ] 실제 포스트로 테스트
+- [ ] 사용자 피드백 수집
+- [ ] SKILL.md 또는 bundled resources 업데이트
+
+---
+
+## 🎨 스킬 활성화 조건 (description에 반영)
+
+**description 작성 원칙**:
+- 3인칭 사용: "This skill should be used when..."
+- 구체적이고 명확하게
+- 사용 시점을 명확히 표현
+
+**예상 트리거 시나리오**:
+1. 마크다운 파일(`.md`) 편집/작성/검토 요청
+2. "교정", "검토", "스타일", "가이드", "well-writing" 등의 키워드
+3. Confluence 이미지 다운로드 요청
+4. 블로그 포스트 품질 개선 요청
+5. 스타일 가이드 준수 확인 요청
+
+---
+
+## 📌 참고 자료
+
+- `.gemini/styleguide.md`: 전체 스타일 가이드
+- `.gemini/config.yaml`: Gemini 설정 (참고용)
+- `content/posts/`: 실제 블로그 포스트 예시
+- Claude Skills 공식 문서
+
+---
+
+## ✅ 다음 단계 (구현 순서)
+
+### 즉시 실행 가능한 단계
+
+1. **스킬 초기화**:
+   - `init_skill.py` 실행 또는 수동으로 디렉토리 생성
+   - `well-writing/` 폴더 및 하위 구조 생성
+
+2. **references/ 구현** (우선순위 높음):
+   - `references/styleguide.md`: `.gemini/styleguide.md` 기반으로 작성
+   - `references/checklist.md`: 빠른 참조용 체크리스트 작성
+
+3. **scripts/ 구현**:
+   - `scripts/download_confluence_images.py`: 기존 스크립트 개선 및 이동
+   - **인증 정보 처리 개선**:
+     - `get_credentials()` 함수 추가
+     - `download_confluence_images()` 메인 함수화
+     - 환경변수 없을 때 사용자 요청 방식 구현
+   - 스킬 컨텍스트에서 사용 가능하도록 함수화
+
+4. **SKILL.md 작성** (마지막):
+   - YAML frontmatter (3인칭, 명확한 description)
+   - 핵심 워크플로우만 포함 (imperative form)
+   - references/ 및 scripts/ 참조 방법 명시
+   - 인증 정보 요청 방법 명시
+   - **중요**: references/와 중복되지 않도록 주의
+
+5. **패키징 및 테스트**:
+   - `package_skill.py` 실행하여 검증
+   - 실제 포스트로 테스트
+   - 피드백 반영하여 반복 개선
+
+### 작성 스타일 가이드
+
+- **SKILL.md**: Imperative/Infinitive form ("To accomplish X, do Y")
+- **description**: 3인칭 ("This skill should be used when...")
+- **Lean principle**: SKILL.md는 핵심만, 상세는 references/
+- **No duplication**: 정보는 한 곳에만 (SKILL.md 또는 references/)
+- **인증 정보**: 환경변수 우선, 없으면 사용자 요청

From 09b1eb707a8ec58784aa9d4e645f26e40c39a2a1 Mon Sep 17 00:00:00 2001
From: DongHyunnn <hyun00083@gmail.com>
Date: Wed, 25 Feb 2026 18:02:50 +0900
Subject: [PATCH 2/7] it works good now

---
 .claude/skills/tech-blog-coauthoring/SKILL.md | 187 +++++++++++++++
 .claude/skills/well-writing/SKILL.md          | 222 +++++-------------
 content/posts/cerebras-wse/index.ko.md        | 125 ++++++++++
 3 files changed, 377 insertions(+), 157 deletions(-)
 create mode 100644 .claude/skills/tech-blog-coauthoring/SKILL.md
 create mode 100644 content/posts/cerebras-wse/index.ko.md

diff --git a/.claude/skills/tech-blog-coauthoring/SKILL.md b/.claude/skills/tech-blog-coauthoring/SKILL.md
new file mode 100644
index 0000000..21bb766
--- /dev/null
+++ b/.claude/skills/tech-blog-coauthoring/SKILL.md
@@ -0,0 +1,187 @@
+---
+name: tech-blog-coauthoring
+description: Guides users through collaborative writing of HyperAccel technical blog posts. Use when writing new blog posts, drafting tech content, or creating posts. Follows a 3-stage workflow (Context → Refinement → Reader Testing), then English translation. Author writes in Korean first.
+---
+
+# Tech Blog Co-Authoring
+
+This skill guides collaborative writing of HyperAccel technical blog posts: **Korean first**, then English translation after completion. Use the `well-writing` skill for review to sustain the feedback loop (write → review → revise).
+
+## When to Offer This Workflow
+
+**Triggers**: "write a blog post", "draft a post", "create a tech blog post"
+
+**When offering**: Explain the 3-stage workflow and ask if the user wants to try it.
+1. **Context Gathering**: Audience, purpose, series info, reference materials
+2. **Refinement & Structure**: Section-wise brainstorming → curation → drafting
+3. **Reader Testing**: Validate the doc with reader-perspective questions
+
+If declined, proceed freeform. If accepted, start with Stage 1.
+
+---
+
+## Stage 1: Context Gathering
+
+**Goal**: Clarify audience, purpose, and structure.
+
+### Initial Questions
+
+1. Post topic / core message?
+2. Target audience? (e.g., ML engineers, compiler practitioners)
+3. What should readers gain after reading?
+4. Is this part of a series? Series name?
+5. Reference materials (papers, Confluence, docs)?
+
+Short answers are fine. Ask for templates or existing posts to reference if applicable.
+
+**Format reference**: Before drafting, identify posts by the **same author** (`authors` in frontmatter) and use them as the primary reference for document format—frontmatter structure, section flow, tone, and styling. If none exist, refer to other posts in `content/posts/`.
+
+### Info Dumping
+
+Encourage dumping background, architecture, related discussions, why alternatives weren't used, and constraints. No need to organize.
+
+### Clarifying Questions
+
+After the dump, ask 5–10 clarifying questions on unclear areas. Accept shorthand replies (e.g., "1: yes, 2: see #channel, 3: no because…").
+
+**Exit**: Proceed to Stage 2 when basics are clear and you can ask about trade-offs and edge cases.
+
+---
+
+## Stage 2: Refinement & Structure
+
+**Goal**: For each section: brainstorm → curate → draft → refine. Apply `.gemini/styleguide.md` while drafting.
+
+### Section Order
+
+If structure is clear, ask which section to start with. Otherwise propose 3–5 sections and confirm with the user.
+
+### Document Scaffold
+
+Create `content/posts/{post-slug}/index.ko.md` with headers and placeholders (`[To be written]`). Match frontmatter and structure to **same-author** existing posts when available.
+
+**Plan review**: Before drafting section content, present the scaffold (section structure and headers) to the author for review. Proceed to per-section drafting only after confirmation.
+
+### Per-Section Process
+
+#### 1. Clarifying Questions
+
+Ask 5–10 questions about what belongs in this section.
+
+#### 2. Brainstorming
+
+Generate 5–20 numbered options for section content.
+
+#### 3. Curation
+
+Ask which to keep / remove / combine. Example: "Keep 1,4,7,9", "Remove 3 (duplicates 1)".
+
+#### 4. Gap Check
+
+Ask if anything important is missing given the selections.
+
+#### 5. Drafting
+
+Replace placeholders with drafted content. **Always** apply `.gemini/styleguide.md`:
+- Space after bold when followed by Korean: `**GPU** 는`
+- First use of acronym: `**FullTerm(Acronym)**`
+- Sentence/paragraph length, heading hierarchy (max H3), code block language tags
+
+#### 6. Iterative Refinement
+
+Edit with `str_replace` based on feedback. Reflect direct edits in future sections.
+
+**Section done**: After 3 iterations with no substantial changes, ask if anything can be removed, then confirm completion.
+
+### Near Completion
+
+At ~80% done, read the full document and check:
+- Flow and consistency
+- Redundancy or contradictions
+- Unnecessary content
+- Whether each sentence carries weight
+
+---
+
+## Stage 3: Reader Testing
+
+**Goal**: Verify the doc works for readers.
+
+### With Sub-agent
+
+1. Predict 5–10 realistic reader questions
+2. Test with a fresh Claude instance using only the doc and questions
+3. Check for ambiguity, false assumptions, contradictions
+4. Loop back to refine sections if issues exist
+
+### Without Sub-agent
+
+Guide the user:
+1. Open a fresh Claude conversation (https://claude.ai)
+2. Paste the document
+3. Ask the predicted questions
+4. Also ask: "What's ambiguous in this doc?", "What knowledge does it assume?"
+5. Apply fixes based on the results
+
+**Exit**: When questions are answered correctly and no new gaps or ambiguities remain.
+
+---
+
+## Stage 4: English Translation
+
+**When**: After the Korean post (`index.ko.md`) passes Reader Testing.
+
+### Translation Workflow
+
+1. Create `content/posts/{post-slug}/index.en.md`
+2. Translate frontmatter and body from `index.ko.md`
+3. Apply style guide rules for English (bold spacing, acronym format, sentence/paragraph length, code blocks, images, links)
+4. Recommend Reader Testing on the English version too
+
+### Multilingual Structure
+
+- Korean: `content/posts/{post-slug}/index.ko.md`
+- English: `content/posts/{post-slug}/index.en.md`
+- Same slug/folder for both
+
+---
+
+## Feedback Loop: Review and Revise
+
+After writing/translation, use the **well-writing** skill for review.
+
+1. Suggest: "Run the `well-writing` skill to review?"
+2. For issues (Critical / High / Medium), apply fixes using this workflow
+3. Re-run well-writing as needed
+
+Sustain the loop: write (tech-blog-coauthoring) ↔ review (well-writing).
+
+---
+
+## Style Guide Reference
+
+Refer to `.gemini/styleguide.md` when drafting. Summary:
+
+| Priority | Item | Summary |
+|----------|------|---------|
+| Critical | Bold + Korean | `**GPU** 는` (space required) |
+| Critical | Acronyms | First use: `**FullTerm(Acronym)**` |
+| Critical | Capitalization | Acronyms uppercase, common nouns lowercase |
+| High | Readability | ~50 chars/sentence, 5–7 sentences/paragraph |
+| High | Technical terms | Explain on first use |
+| Medium | Headings | H2→H3, no H4+ |
+| Medium | Code | Language tag required |
+
+Image rules: see well-writing skill "Stage 4: Images".
+
+---
+
+## Tips
+
+**Tone**: Direct and procedural. Explain rationale only when it affects behavior.
+
+**Deviations**: If the user wants to skip a stage, ask and allow freeform flow.
+
+**Editing**: Use `str_replace`. Avoid reprinting the whole doc.
+
+**Quality**: Prefer meaningful edits over speed.
diff --git a/.claude/skills/well-writing/SKILL.md b/.claude/skills/well-writing/SKILL.md
index 647fa38..0ab310c 100644
--- a/.claude/skills/well-writing/SKILL.md
+++ b/.claude/skills/well-writing/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: Well-Writing
+name: well-writing
 description: This skill should be used when reviewing and editing markdown blog posts for the HyperAccel technical blog. It provides style guide compliance checking and readability improvements.
 ---
 
@@ -7,67 +7,69 @@ description: This skill should be used when reviewing and editing markdown blog
 
 This skill helps review and edit markdown blog posts for the HyperAccel technical blog by ensuring style guide compliance and improving readability.
 
-## When to Use This Skill
+**Feedback Loop**: Use with `tech-blog-coauthoring`: write → review (well-writing) → revise (tech-blog-coauthoring) → re-review (well-writing).
 
-Use this skill when:
-- Reviewing or editing markdown blog posts (`.md` files)
-- Checking style guide compliance
-- Improving readability and technical writing quality
-- Validating frontmatter and metadata
+## When to Offer This Review
 
-## Workflow
+**Triggers**: "review this post", "check style", "edit blog post", "validate frontmatter", "improve readability"
 
-### 1. Load Style Guide Reference
+**When offering**: Explain that you'll check Critical Issues → Content Quality → Markdown Formatting → Images. Ask which file(s) to review.
 
-To review a blog post, first load the style guide:
-- Load `references/styleguide.md` for detailed rules and examples
-- Load `references/checklist.md` for quick reference during review
+---
 
-The style guide contains:
-- Critical Issues (Must Fix): Bold rendering, acronym usage, capitalization
-- Content Quality (High Priority): Readability, technical writing
-- Markdown Formatting (Medium Priority): Headings, code blocks, images, lists
-- Frontmatter and Metadata: Required fields and format
+## Stage 1: Critical Issues
 
-### 2. Review Critical Issues
+**Goal**: Fix must-fix items before merging.
 
-Check for these critical issues first (must fix before merging):
+### Load Style Guide
+
+- Load `.gemini/styleguide.md` (or `references/styleguide.md`) for detailed rules
+- Load `references/checklist.md` for quick reference during review
+
+### Bold Rendering
 
-**Bold Rendering**:
 - Search for pattern: `\*\*[^*]+\*\*[가-힣]` (bold text immediately followed by Korean)
 - Ensure space between closing `**` and Korean text
 - Example: `**GPU** 는` (correct) vs `**GPU**는` (incorrect)
 
-**Acronym Usage**:
+### Acronym Usage
+
 - Verify all acronyms are introduced with full terms first: `**FullTerm(Acronym)**`
 - Check that acronyms in title/summary are introduced in first paragraph
 - Common acronyms: GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton
 
-**Capitalization**:
+### Capitalization
+
 - Ensure consistent capitalization throughout
 - Acronyms uppercase: GPU, TPU, SM
 - Common nouns lowercase: loop, thread, warp, core
 - Brand names correct: NVIDIA, Google, TensorFlow, PyTorch
 
-### 3. Review Content Quality
+---
+
+## Stage 2: Content Quality
+
+**Goal**: Check readability and technical writing.
 
-Check readability and technical writing:
+### Readability
 
-**Readability**:
 - Sentences should be within 50 characters (flexible for technical terms)
 - Paragraphs should be within 10 sentences or 200 characters
 - Break complex explanations into multiple sentences
 - Use blank lines to separate distinct ideas
 
-**Technical Writing**:
+### Technical Writing
+
 - Technical terms explained when first introduced
 - Code examples have comments or explanations
 - Images have meaningful alt text
 - Content has logical structure with clear sections
 
-### 4. Review Markdown Formatting
+---
+
+## Stage 3: Markdown Formatting
 
-Check formatting consistency:
+**Goal**: Ensure formatting consistency.
 
 - Headings: Proper hierarchy (H2 → H3, maximum H3 level, no H4 or deeper)
 - Code blocks: All have language tags (` ```python`, ` ```bash`, etc.)
@@ -76,119 +78,17 @@ Check formatting consistency:
 - Lists: Consistent formatting (`-` for unordered)
 - Frontmatter: All required fields present and correct
 
-### 5. Images from Confluence
-
-When a blog post references images from Confluence:
-
-- **Images must be downloaded manually** from the Confluence page
-- The agent should inform the user that images need to be manually downloaded
-- Provide guidance on where to find the images:
-  1. Identify the corresponding Confluence page (if the page ID or URL is known)
-  2. Open the Confluence page in a browser
-  3. Right-click on each image and select "Save image as..." or "Download"
-  4. Save images to the appropriate `images/` directory relative to the markdown file
-  5. **Rename images with sequential numbers**: Images should be named with a two-digit prefix (e.g., `01-`, `02-`, `03-`) followed by a descriptive name
-     - Format: `{number}-{descriptive-name}.{ext}`
-     - Example: `01-tpuv1-arch.png`, `02-pallas-lowering.png`, `03-tpuv7-arch.png`
-     - Numbers should reflect the order in which images appear in the blog post
-  6. Ensure the saved file names match the image references in the markdown file
-
-**Note**: Automatic image download from Confluence is not supported. All images must be manually downloaded and placed in the correct directory.
-
-### 6. Verify and Insert Images in Blog Posts
-
-When reviewing a blog post, the agent should verify that images are properly referenced and placed:
-
-1. **Check the images directory**:
-   - Locate the `images/` directory relative to the markdown file (typically `content/posts/{post-name}/images/`)
-   - List all image files in the directory
-   - Note the file names and formats (`.png`, `.jpg`, `.webp`, etc.)
-   - **Verify naming convention**: All image files should follow the format `{number}-{descriptive-name}.{ext}` where:
-     - `{number}` is a two-digit sequential number (01, 02, 03, etc.)
-     - `{descriptive-name}` is a lowercase, hyphen-separated descriptive name
-     - Example: `01-tpuv1-arch.png`, `02-pallas-lowering.png`, `03-tpuv7-arch.png`
-
-2. **Read and analyze the markdown file**:
-   - Search for all image references using the pattern: `!\[.*?\]\(images/.*?\)`
-   - Extract:
-     - Image file paths (e.g., `images/tpu-v1-architecture.png`)
-     - Alt text (the text between `![` and `]`)
-     - Caption text (if present in alt text or nearby context)
-
-3. **Match images with references**:
-   - For each image file in the directory, check if it's referenced in the markdown
-   - For each image reference in the markdown, verify the file exists
-   - Identify:
-     - **Orphaned images**: Files in directory but not referenced in markdown
-     - **Missing images**: References in markdown but files don't exist
-     - **Mismatched names**: References that don't match actual file names
-
-4. **Verify image placement**:
-   - Check that images are placed in logical positions:
-     - **Images should be placed BEFORE the content they illustrate** (recommended)
-     - This allows readers to see the visual context before reading the explanation
-     - Images should appear near the text that describes them
-     - Images should not interrupt the flow of reading
-   - Verify image context:
-     - The surrounding text should mention or describe what the image shows
-     - Images should support the narrative, not just be decorative
-
-5. **Check image metadata**:
-   - **Alt text**: Should be descriptive and meaningful (not just the filename)
-     - Good: `![TPU v1 아키텍처 다이어그램](images/01-tpuv1-arch.png)`
-     - Bad: `![image](images/01-tpuv1-arch.png)` or `![01-tpuv1-arch.png](images/01-tpuv1-arch.png)`
-   - **File names**: Must follow the sequential numbering format `{number}-{descriptive-name}.{ext}`
-     - Numbers should be two digits (01, 02, 03, ..., 10, 11, etc.)
-     - Numbers should reflect the order images appear in the blog post
-     - Descriptive name should be lowercase with hyphens (e.g., `tpuv1-arch`, `pallas-lowering`)
-   - **Image format**: Prefer `.webp` for smaller file sizes, but `.png` is acceptable for diagrams
-
-6. **Suggest improvements**:
-   - If images are missing, suggest adding them with appropriate alt text and sequential numbering
-   - If images are in wrong locations, suggest moving them to better positions
-   - If alt text is missing or poor, suggest improvements
-   - If file names don't follow the numbering convention, suggest renaming:
-     - Determine the correct order based on where images appear in the markdown
-     - Rename files to follow `{number}-{descriptive-name}.{ext}` format
-     - Update all references in the markdown file to match the new names
-   - If file names don't match references, suggest renaming files or updating references
-   - If orphaned images exist, ask if they should be removed or referenced
-   - If sequential numbers are missing or incorrect, suggest renumbering all images in order
-
-7. **When inserting images**:
-   - **Place images BEFORE the content they illustrate** (recommended)
-   - This allows readers to see the visual context before reading the explanation
-   - Use descriptive alt text that explains what the image shows
-   - Consider the reading flow - images should enhance understanding, not interrupt it
-   - **File naming**: Before inserting, ensure the image file follows the sequential numbering format:
-     - Determine the correct sequence number based on where this image appears in the post
-     - If it's the first image, use `01-`, second image use `02-`, etc.
-     - Format: `{number}-{descriptive-name}.{ext}` (e.g., `01-tpuv1-arch.png`)
-   - Format: `![Descriptive alt text](images/{number}-{descriptive-name}.{ext})`
-   - If the image needs a caption, include it in the alt text or add a caption below
-   - **Renaming existing images**: If inserting an image requires renumbering existing ones:
-     - Rename all affected image files
-     - Update all references in the markdown file to match the new names
-     - Maintain sequential order throughout the post
-
-**Example workflow**:
-```
-1. Read markdown file: content/posts/pallas-programming-model/index.md
-2. Check images directory: content/posts/pallas-programming-model/images/
-3. Find all image references in markdown (in order of appearance)
-4. Verify all image files follow naming convention: {number}-{descriptive-name}.{ext}
-5. Match files with references
-6. Verify each image is in the right place contextually
-7. Check alt text quality
-8. Verify sequential numbering matches the order images appear in the post
-9. Report any issues and suggest fixes (renaming, renumbering, etc.)
-```
-
-**Image naming examples**:
-- First image in post: `01-tpuv1-arch.png`
-- Second image in post: `02-pallas-lowering.png`
-- Third image in post: `03-tpuv7-arch.png`
-- Tenth image in post: `10-common-hw-model.png`
+---
+
+## Stage 4: Images
+
+**Goal**: Ensure images are referenced correctly. **Recommend manual verification** by the author.
+
+- Confluence images: Download manually; save to `images/` with format `{number}-{descriptive-name}.{ext}` (e.g., `01-tpuv1-arch.png`)
+- The agent may briefly remind: check references match files, alt text is descriptive, placement is logical
+- Full verification (orphaned files, missing refs, naming, placement) → **ask the author to verify manually**
+
+---
 
 ## Providing Feedback
 
@@ -202,29 +102,37 @@ When reviewing a post:
 2. **Be specific**:
    - Point to exact locations (line numbers if possible)
    - Provide before/after examples
-   - Reference specific rules from `references/styleguide.md`
+   - Reference specific rules from style guide
 
 3. **Suggest fixes**:
    - Show correct format
    - Explain why the fix is needed
-   - Reference relevant sections of the style guide
 
-4. **Use the checklist**:
-   - Refer to `references/checklist.md` for quick verification
-   - Check off items as you review
-   - Focus on critical and high-priority items first
+---
+
+## Style Guide Reference
+
+Refer to `.gemini/styleguide.md` when reviewing. Summary:
+
+| Priority | Item | Summary |
+|----------|------|---------|
+| Critical | Bold + Korean | `**GPU** 는` (space required) |
+| Critical | Acronyms | First use: `**FullTerm(Acronym)**` |
+| Critical | Capitalization | Acronyms uppercase, common nouns lowercase |
+| High | Readability | ~50 chars/sentence, 5–7 sentences/paragraph |
+| High | Technical terms | Explain on first use |
+| Medium | Headings | H2→H3, no H4+ |
+| Medium | Code | Language tag required |
+| Medium | Images | `{number}-{descriptive-name}.{ext}`, descriptive alt text |
+
+---
 
-## Common Patterns
+## Tips
 
-Based on existing blog posts:
+**Context matters**: Some rules may be flexible for technical content (e.g., longer sentences for complex explanations).
 
-- **Series posts**: Use `series: ["시리즈 이름"]` in frontmatter
-- **Code languages**: Python, CUDA, Bash, C, Go, F# are commonly used
-- **Image formats**: `.webp`, `.png`, `.jpg` are used
-- **Technical terms**: GPU, TPU, SM, CUDA, HBM, Systolic Array, Tensor Core, etc.
+**Consistency first**: If a pattern is used consistently throughout a post, it may be acceptable even if not ideal.
 
-## Notes
+**Be constructive**: When pointing out issues, suggest specific fixes and explain the reasoning.
 
-- **Context matters**: Some rules may be flexible for technical content (e.g., longer sentences for complex explanations)
-- **Consistency first**: If a pattern is used consistently throughout a post, it may be acceptable even if not ideal
-- **Be constructive**: When pointing out issues, suggest specific fixes and explain the reasoning
+**After review**: If changes are needed, return to `tech-blog-coauthoring` to revise those sections, then run this skill again.
diff --git a/content/posts/cerebras-wse/index.ko.md b/content/posts/cerebras-wse/index.ko.md
new file mode 100644
index 0000000..b7ed2f6
--- /dev/null
+++ b/content/posts/cerebras-wse/index.ko.md
@@ -0,0 +1,125 @@
+---
+date: '2026-02-25T10:00:00+09:00'
+draft: true
+title: '지피지기면 백전불태 5편: Cerebras와 웨이퍼 스케일 엔진'
+cover:
+  image: "images/01-cerebras-wse.png"
+  alt: "Cerebras WSE-3 또는 CS-3 시스템"
+  caption: "Cerebras 웨이퍼 스케일 엔진"
+  relative: true
+authors: ["Donghyeon Choi"]
+tags: ["Cerebras", "WSE", "Wafer Scale Engine", "AI Hardware", "Inference", "OpenAI"]
+categories: ["AI Hardware", "Architecture", "Accelerator"]
+series: ["지피지기면 백전불태"]
+series_idx: 5
+summary: "OpenAI가 100억 달러 규모로 선택한 Cerebras의 웨이퍼 스케일 엔진(WSE) 아키텍처와 장단점을 비전공자 눈높이에서 살펴봅니다."
+description: "Cerebras의 최근 근황과 WSE-3 아키텍처, 웨이퍼 스케일 칩의 장단점, OpenAI 파트너십 배경을 비전공자도 이해할 수 있게 정리합니다."
+comments: true
+keywords: [
+  "Cerebras", "WSE", "Wafer Scale Engine", "OpenAI",
+  "AI Inference", "CS-3", "AI Hardware", "웨이퍼 스케일"
+]
+---
+
+# 지피지기면 백전불태 5편: Cerebras와 웨이퍼 스케일 엔진
+
+> **지피지기면 백전불태(知彼知己 百戰不殆)**  
+상대를 알고 나를 알면 백 번 싸워도 위태롭지 않다는 뜻입니다.  
+이 시리즈는 AI 가속기 설계를 위해 경쟁사들의 하드웨어를 깊이 이해하는 것을 목표로 합니다.  
+다섯 번째 글에서는 **OpenAI** 가 100억 달러 규모로 선택한 **Cerebras** 의 **웨이퍼 스케일 엔진(WSE)** 을 다룹니다.
+
+2026년 1월, **Cerebras** 는 AI 업계에 큰 소식을 전했습니다. **OpenAI** 와 100억 달러 규모의 계약을 맺었다는 것입니다. 최대 750MW 규모의 연산 능력을 2028년까지 3년간 공급한다는 내용이었죠. AI 가속기 시장에서 **NVIDIA** 이외의 플레이어가 이렇게 큰 계약을 따낸 건 이례적입니다.
+
+이 글에서는 **Cerebras** 의 핵심 기술인 **웨이퍼 스케일 엔진(WSE)** 아키텍처가 무엇인지, 어떤 강점과 한계가 있는지 비전공자도 이해할 수 있게 정리합니다.
+
+![Cerebras 로고 또는 CS-3 시스템](images/01-cerebras-wse.png)
+
+---
+
+## Cerebras, 2026년에 왜 주목받는가
+
+2026년 1월, **Cerebras** 는 **OpenAI** 와 100억 달러 규모 계약을 공식 발표했습니다. 최대 750MW 연산 능력을 2028년까지 3년간 공급한다는 내용이죠. 2025년 8월에는 **OpenAI** 오픈 모델 **gpt-oss-120B** 를 초당 3,000토큰이라는 속도로 구동하는 데 성공했습니다. 당시 세계 기록이었습니다.
+
+주간 9억 명이 넘는 사용자를 돌리려면 **OpenAI** 에겐 데이터센터 용량이 크게 부족합니다. **NVIDIA** GPU에만 의존하면 비용과 공급 모두 한계가 있죠. **OpenAI** 는 더 저렴하고 효율적인 대안으로 **Cerebras** 에 눈을 돌린 것입니다. 특히 코딩 보조, 에이전트형 AI 같은 **추론(inference)** 작업에 적극 활용할 계획이라고 합니다.
+
+---
+
+## Cerebras란 어떤 회사인가
+
+**Cerebras** 는 2015년 미국 캘리포니아에서 설립된 AI 반도체 스타트업입니다. 창업자 **Andrew Feldman** 과 **Gary Lauterbach** 는 2007년 **SeaMicro** 를 공동 설립했고, 2012년 **AMD** 에 3억 5,700만 달러에 매각한 경력이 있습니다. **Cerebras** 는 이 팀이 AI 시대를 맞아 "범용 GPU 외의 길"을 탐색하며 만든 회사입니다.
+
+일반 GPU는 칩을 여러 개 이어 붙여 성능을 올립니다. 칩 간 통신과 메모리 대역폭이 병목이 되기 쉽죠. **Cerebras** 는 이 구조 자체를 바꾸겠다고 결심했습니다. 웨이퍼를 쪼개지 않고 **통째로 하나의 칩**처럼 쓰는 **웨이퍼 스케일 엔진(WSE)** 을 만들어 AI 학습과 추론에 쓰고 있습니다. 2016년 시리즈 A에서 2,700만 달러를 유치한 뒤, 2026년 기준 누적 18억 달러 이상을 모았습니다.
+
+---
+
+## 웨이퍼 스케일 엔진이란
+
+![웨이퍼에서 칩을 잘라내는 과정](images/02-wafer-vs-die.png)
+
+일반적으로 반도체 칩은 **웨이퍼(wafer)** 라는 원형 실리콘 판에서 여러 개를 잘라냅니다. 하나의 웨이퍼에서 수십 개에서 수백 개의 작은 칩이 나오죠. 각 칩은 따로 포장되어 GPU, CPU 같은 제품이 됩니다.
+
+**Cerebras** 는 이 방식을 뒤집었습니다. 웨이퍼를 쪼개지 않고 **통째로 하나의 칩**처럼 사용합니다. **Wafer Scale Engine 3(WSE-3)** 의 경우 가로세로 약 215mm로, **NVIDIA** H100 칩(약 814mm²)보다 면적이 50배 이상 큽니다. 이런 방식을 웨이퍼 스케일(wafer-scale)이라고 부릅니다.
+
+그런데 왜 지금까지 웨이퍼 스케일 칩을 만드는 회사가 거의 없었을까요? 반도체 제조 과정에서 **결함(defect)** 이 생기는 것은 피할 수 없습니다. 칩이 클수록 결함이 하나라도 들어가면 전체가 못 쓰게 됩니다. 작은 칩은 결함 있는 부분만 버리고 나머지를 쓰면 되지만, 웨이퍼 통째로 쓰면 수율이 극히 낮아진다는 문제가 있었죠. 그래서 웨이퍼 스케일은 오랫동안 **경제적으로 불가능**하다고 여겨져 왔습니다.
+
+**Cerebras** 는 이 문제를 **아키텍처 설계** 로 풀었습니다. 다음 섹션에서 그 비결을 살펴보겠습니다.
+
+---
+
+## WSE-3 아키텍처 핵심
+
+![WSE-3 아키텍처 개요](images/03-wse3-architecture.png)
+
+**WSE-3** 는 2024년 3월에 공개된 3세대 웨이퍼 스케일 칩입니다. **TSMC** 5nm 공정으로 만들어진 단일 웨이퍼 위에 **4조 개의 트랜지스터** 가 들어갑니다. AI 연산에 최적화된 코어가 약 **90만 개** 들어가며, 최대 **125 페타플롭스(petaFLOPS)** 의 AI 연산 성능을 냅니다.
+
+일반 GPU는 칩 밖에 있는 **High Bandwidth Memory(HBM)** 에서 데이터를 가져옵니다. **HBM** 은 대역폭이 크지만 칩과의 연결 구간에서 병목이 생기기 쉽죠. **WSE-3** 는 **44GB의 Static Random-Access Memory(SRAM)** 을 칩 안에 직접 넣었습니다. **SRAM** 은 **HBM** 보다 훨씬 빠르게 데이터를 읽고 쓸 수 있습니다. **WSE-3** 의 온칩 메모리 대역폭은 초당 **21 페타바이트(PB/s)** 에 달합니다. **NVIDIA** H100의 **HBM** 대역폭(약 3TB/s)과 비교하면 약 7,000배에 가깝죠.
+
+웨이퍼 스케일의 수율 문제를 **Cerebras** 는 **코어를 매우 작게** 만드는 방식으로 해결했습니다. **WSE-3** 의 AI 코어 하나는 약 0.05mm²로, **H100** 의 **Streaming Multiprocessor(SM)** 하나(약 6mm²)의 1% 수준입니다. 결함이 생겨도 영향을 받는 면적이 작고, 칩 내부 회로로 우회할 수 있어 **결함 허용도** 가 기존 대비 수백 배 높아집니다.
+
+**WSE-3** 를 쓰는 **CS-3** 슈퍼컴퓨터는 최대 2,048대까지 묶어 **256 엑사플롭스(exaFLOPS)** 규모까지 확장할 수 있습니다. 모델 파라미터 **24조 개** 까지 한 번에 올려 훈련할 수 있는 통합 메모리 구조를 갖추고 있습니다.
+
+---
+
+## Cerebras의 강점과 한계
+
+**Cerebras** 의 가장 큰 강점은 **메모리 대역폭** 입니다. 온칩 **SRAM** 으로 **HBM** 대비 수천 배 수준의 대역폭을 얻습니다. 그 덕분에 **Large Language Model(LLM)** 추론처럼 메모리 접근이 많은 작업에서 **NVIDIA** DGX B200보다 2배 이상 빠른 토큰 생성 속도를 보이기도 합니다. Llama 4 Maverick 기준으로 사용자당 초당 2,500토큰을 처리했다는 벤치마크가 있습니다.
+
+![Cerebras 대 GPU 추론 성능 비교](images/04-cerebras-comparison.png)
+
+칩·메모리·연결이 모두 한 웨이퍼 안에 들어가 있어 여러 칩을 이어 붙일 때 생기는 **통신 오버헤드** 가 거의 없습니다. **NVLink** 같은 칩 간 연결이 필요하지 않죠. 이로 인해 대규모 AI 훈련에서 코드량을 GPU 대비 97% 줄일 수 있다고 **Cerebras** 는 주장합니다. **PyTorch** 2.0도 네이티브로 지원합니다.
+
+반면 웨이퍼 스케일 방식의 한계도 있습니다. **TSMC** 와 함께 기존 **레티클 한계(reticle limit)** 를 넘어가는 노출 방식을 개발해야 했고, 제조 난이도와 초기 비용이 높습니다. 4편에서 다룬 **Inference Context Memory Storage(ICMS)** 나 3편의 **Language Processing Unit(LPU)** 와 비교하면, **Cerebras** 는 학습과 추론을 모두 목표로 하는 **범용 AI 가속기** 에 가깝습니다. **LPU** 는 추론 전용, **ICMS** 는 메모리 계층 확장에 집중한다는 점에서 역할이 다릅니다.
+
+---
+
+## 왜 OpenAI가 Cerebras를 선택했는가
+
+**OpenAI** 는 2025년 말 기준 주간 9억 명이 넘는 사용자를 돌리며 **데이터센터 용량 부족** 이 심각해졌습니다. **NVIDIA** GPU에만 의존하면 공급과 비용 모두 한계가 있죠. **Sachin Katti** 인프라 담당자는 특히 코딩 보조, 문서 질의응답, 에이전트형 연구 같은 **추론** 워크로드에서 **Cerebras** 를 활용할 계획이라고 밝혔습니다.
+
+**Cerebras** 의 추론 속도와 전력 효율은 **NVIDIA** 대비 유리할 수 있습니다. 같은 모델을 같은 조건에서 돌렸을 때 **Cerebras** 가 2배 이상 빠른 토큰 속도를 보인 사례가 있고, 단일 장치 구조 덕분에 여러 GPU를 묶는 복잡함과 오버헤드가 적습니다. **OpenAI** 입장에서는 비용 대비 성능과 확장성 모두에서 **Cerebras** 가 매력적인 선택이었을 것입니다.
+
+---
+
+## 정리하자면…
+
+이 글에서는
+
+① 2026년 **Cerebras** 의 근황과 **OpenAI** 100억 달러 계약,  
+② **Cerebras** 의 창업 배경과 웨이퍼 스케일 도입 이유,  
+③ **웨이퍼 스케일 엔진(WSE)** 개념과 **WSE-3** 아키텍처 핵심,  
+④ **Cerebras** 의 강점(대역폭, 추론 속도)과 한계(제조 복잡도),  
+⑤ **OpenAI** 가 **Cerebras** 를 선택한 배경을 살펴봤습니다.
+
+**Cerebras** 의 **웨이퍼 스케일 엔진** 은 웨이퍼를 통째로 칩으로 쓰는 과감한 설계로, 메모리 대역폭과 결함 허용을 통해 기존 GPU와 다른 길을 걸어가고 있습니다. AI 가속기 시장은 이제 **NVIDIA** 일변도가 아닙니다. 웨이퍼 스케일, 추론 전용, 메모리 계층 확장 등 다양한 접근이 공존하는 시대가 됐습니다.
+
+그럼 **지피지기면 백전불태 5편: Cerebras와 웨이퍼 스케일 엔진** 에서 다시 뵙겠습니다.
+
+---
+
+## 추신: HyperAccel은 채용 중입니다!
+
+지피지기면 백전불태라지만 백전백승을 위해서는 훌륭한 인재가 많이 필요합니다!
+
+저희가 다루는 기술들을 보시고, 관심이 있으시다면 [HyperAccel Career](https://hyperaccel.career.greetinghr.com/ko/guide)로 지원해 주세요!
+
+HyperAccel에는 정말 훌륭하고 똑똑한 엔지니어분들이 많습니다. 여러분의 지원을 기다립니다.

From fbba38377d25703da1440cc7938932119220ffa6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Donghyeon=20Choi=20=7C=20=EC=B5=9C=EB=8F=99=ED=98=84?=
 <93566126+DongHyunnn@users.noreply.github.com>
Date: Wed, 25 Feb 2026 18:20:23 +0900
Subject: [PATCH 3/7] Update
 .claude/skills/well-writing/references/styleguide.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 .claude/skills/well-writing/references/styleguide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.claude/skills/well-writing/references/styleguide.md b/.claude/skills/well-writing/references/styleguide.md
index 4ff268a..384fc50 100644
--- a/.claude/skills/well-writing/references/styleguide.md
+++ b/.claude/skills/well-writing/references/styleguide.md
@@ -73,7 +73,7 @@ These issues cause rendering problems or significantly impact readability. They
 **Rules**:
 - **First use**: Always write `FullTerm(Acronym)` format
 - **Subsequent use**: Only the acronym can be used
-- **Bold formatting**: Bold only the full term, not the acronym: `**FullTerm(Acronym)**`
+- **Bold formatting**: Bold the full term and the acronym together: `**FullTerm(Acronym)**`
 - If an acronym appears in the title or summary, introduce it in the first paragraph
 - For well-known acronyms (e.g., CPU, GPU, AI), you may skip the full form if it's extremely common
 

From ae03f59e64dbc6466f9b926a25ca6b81c3835ae7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Donghyeon=20Choi=20=7C=20=EC=B5=9C=EB=8F=99=ED=98=84?=
 <93566126+DongHyunnn@users.noreply.github.com>
Date: Wed, 25 Feb 2026 18:21:03 +0900
Subject: [PATCH 4/7] Update .claude/skills/well-writing/SKILL.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 .claude/skills/well-writing/SKILL.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.claude/skills/well-writing/SKILL.md b/.claude/skills/well-writing/SKILL.md
index 0ab310c..a45c5fa 100644
--- a/.claude/skills/well-writing/SKILL.md
+++ b/.claude/skills/well-writing/SKILL.md
@@ -54,7 +54,7 @@ This skill helps review and edit markdown blog posts for the HyperAccel technica
 ### Readability
 
 - Sentences should be within 50 characters (flexible for technical terms)
-- Paragraphs should be within 10 sentences or 200 characters
+- Paragraphs should be within 10 sentences or about 300 characters
 - Break complex explanations into multiple sentences
 - Use blank lines to separate distinct ideas
 

From 1fbd916b53b934f7aa60a6a3d6e1763f0246de48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Donghyeon=20Choi=20=7C=20=EC=B5=9C=EB=8F=99=ED=98=84?=
 <93566126+DongHyunnn@users.noreply.github.com>
Date: Wed, 25 Feb 2026 18:21:15 +0900
Subject: [PATCH 5/7] Update content/posts/cerebras-wse/index.ko.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 content/posts/cerebras-wse/index.ko.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/posts/cerebras-wse/index.ko.md b/content/posts/cerebras-wse/index.ko.md
index b7ed2f6..d25cd52 100644
--- a/content/posts/cerebras-wse/index.ko.md
+++ b/content/posts/cerebras-wse/index.ko.md
@@ -112,7 +112,7 @@ keywords: [
 
 **Cerebras** 의 **웨이퍼 스케일 엔진** 은 웨이퍼를 통째로 칩으로 쓰는 과감한 설계로, 메모리 대역폭과 결함 허용을 통해 기존 GPU와 다른 길을 걸어가고 있습니다. AI 가속기 시장은 이제 **NVIDIA** 일변도가 아닙니다. 웨이퍼 스케일, 추론 전용, 메모리 계층 확장 등 다양한 접근이 공존하는 시대가 됐습니다.
 
-그럼 **지피지기면 백전불태 5편: Cerebras와 웨이퍼 스케일 엔진** 에서 다시 뵙겠습니다.
+그럼 **지피지기면 백전불태** 다음 편에서 다시 뵙겠습니다.
 
 ---
 

From 0623881d139da4cfdf5f65ce389157c013b70d6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Donghyeon=20Choi=20=7C=20=EC=B5=9C=EB=8F=99=ED=98=84?=
 <93566126+DongHyunnn@users.noreply.github.com>
Date: Wed, 25 Feb 2026 18:21:39 +0900
Subject: [PATCH 6/7] Update
 .claude/skills/well-writing/references/styleguide.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 .claude/skills/well-writing/references/styleguide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.claude/skills/well-writing/references/styleguide.md b/.claude/skills/well-writing/references/styleguide.md
index 384fc50..3572770 100644
--- a/.claude/skills/well-writing/references/styleguide.md
+++ b/.claude/skills/well-writing/references/styleguide.md
@@ -175,7 +175,7 @@ These rules ensure blog posts are readable, well-structured, and technically acc
 **Paragraph Length**:
 - A paragraph should be approximately **5-7 sentences**
 - Consider splitting if a paragraph has **10 or more sentences**
-- Consider splitting if a paragraph exceeds **200 characters**
+- Consider splitting if a paragraph exceeds **300 characters**
 - Use blank lines to separate distinct ideas
 - Each paragraph should focus on one main idea
 

From e71a20c8f7ce942777ee60ad359264398af845fe Mon Sep 17 00:00:00 2001
From: DongHyunnn <hyun00083@gmail.com>
Date: Wed, 25 Feb 2026 18:25:11 +0900
Subject: [PATCH 7/7] apply gem reviews

---
 .claude/skills/tech-blog-coauthoring/SKILL.md |  4 +--
 .claude/skills/well-writing/SKILL.md          |  4 +--
 .../well-writing/references/checklist.md      |  1 -
 .../well-writing/references/styleguide.md     |  2 --
 .gemini/styleguide.md                         | 25 +++++--------------
 5 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/.claude/skills/tech-blog-coauthoring/SKILL.md b/.claude/skills/tech-blog-coauthoring/SKILL.md
index 21bb766..0b0a5f0 100644
--- a/.claude/skills/tech-blog-coauthoring/SKILL.md
+++ b/.claude/skills/tech-blog-coauthoring/SKILL.md
@@ -85,7 +85,7 @@ Ask if anything important is missing given the selections.
 Replace placeholders with drafted content. **Always** apply `.gemini/styleguide.md`:
 - Space after bold when followed by Korean: `**GPU** 는`
 - First use of acronym: `**FullTerm(Acronym)**`
-- Sentence/paragraph length, heading hierarchy (max H3), code block language tags
+- Sentence/paragraph length, heading hierarchy (H2→H3→H4, no skipping), code block language tags
 
 #### 6. Iterative Refinement
 
@@ -169,7 +169,7 @@ Refer to `.gemini/styleguide.md` when drafting. Summary:
 | Critical | Capitalization | Acronyms uppercase, common nouns lowercase |
 | High | Readability | ~50 chars/sentence, 5–7 sentences/paragraph |
 | High | Technical terms | Explain on first use |
-| Medium | Headings | H2→H3, no H4+ |
+| Medium | Headings | H2→H3→H4, no skipping |
 | Medium | Code | Language tag required |
 
 Image rules: see well-writing skill "Stage 4: Images".
diff --git a/.claude/skills/well-writing/SKILL.md b/.claude/skills/well-writing/SKILL.md
index a45c5fa..d7b1fe1 100644
--- a/.claude/skills/well-writing/SKILL.md
+++ b/.claude/skills/well-writing/SKILL.md
@@ -71,7 +71,7 @@ This skill helps review and edit markdown blog posts for the HyperAccel technica
 
 **Goal**: Ensure formatting consistency.
 
-- Headings: Proper hierarchy (H2 → H3, maximum H3 level, no H4 or deeper)
+- Headings: Proper hierarchy (H2 → H3 → H4, no skipping)
 - Code blocks: All have language tags (` ```python`, ` ```bash`, etc.)
 - Images: Descriptive alt text, meaningful file names
 - Links: Descriptive link text
@@ -121,7 +121,7 @@ Refer to `.gemini/styleguide.md` when reviewing. Summary:
 | Critical | Capitalization | Acronyms uppercase, common nouns lowercase |
 | High | Readability | ~50 chars/sentence, 5–7 sentences/paragraph |
 | High | Technical terms | Explain on first use |
-| Medium | Headings | H2→H3, no H4+ |
+| Medium | Headings | H2→H3→H4, no skipping |
 | Medium | Code | Language tag required |
 | Medium | Images | `{number}-{descriptive-name}.{ext}`, descriptive alt text |
 
diff --git a/.claude/skills/well-writing/references/checklist.md b/.claude/skills/well-writing/references/checklist.md
index 8bb0047..1e0c061 100644
--- a/.claude/skills/well-writing/references/checklist.md
+++ b/.claude/skills/well-writing/references/checklist.md
@@ -14,7 +14,6 @@ This is a quick reference checklist for reviewing blog posts. For detailed expla
 ### Acronym Usage
 - [ ] All acronyms introduced with full terms first: `**FullTerm(Acronym)**`
 - [ ] Acronyms in title/summary are introduced in first paragraph
-- [ ] Only full term is bolded, not the acronym
 - [ ] Common acronyms: GPU, TPU, SM, CUDA, HBM, SMEM, VMEM, MXU, VPU, TCS, XLA, JAX, Pallas, Triton
 
 ### Capitalization
diff --git a/.claude/skills/well-writing/references/styleguide.md b/.claude/skills/well-writing/references/styleguide.md
index 3572770..be05e9f 100644
--- a/.claude/skills/well-writing/references/styleguide.md
+++ b/.claude/skills/well-writing/references/styleguide.md
@@ -73,7 +73,6 @@ These issues cause rendering problems or significantly impact readability. They
 **Rules**:
 - **First use**: Always write `FullTerm(Acronym)` format
 - **Subsequent use**: Only the acronym can be used
-- **Bold formatting**: Bold the full term and the acronym together: `**FullTerm(Acronym)**`
 - If an acronym appears in the title or summary, introduce it in the first paragraph
 - For well-known acronyms (e.g., CPU, GPU, AI), you may skip the full form if it's extremely common
 
@@ -107,7 +106,6 @@ TPU는 구글이 개발한 AI 가속기입니다.
 **Checkpoints**:
 - [ ] Acronym is presented with full term when it first appears
 - [ ] Acronym does not appear before the full term
-- [ ] Only the full term is bolded, not the acronym
 - [ ] Acronyms in title/summary are introduced in first paragraph
 
 ---
diff --git a/.gemini/styleguide.md b/.gemini/styleguide.md
index fae4978..110c6d1 100644
--- a/.gemini/styleguide.md
+++ b/.gemini/styleguide.md
@@ -73,7 +73,6 @@ These issues cause rendering problems or significantly impact readability. They
 **Rules**:
 - **First use**: Always write `FullTerm(Acronym)` format
 - **Subsequent use**: Only the acronym can be used
-- **Bold formatting**: Bold only the full term, not the acronym: `**FullTerm(Acronym)**`
 - If an acronym appears in the title or summary, introduce it in the first paragraph
 - For well-known acronyms (e.g., CPU, GPU, AI), you may skip the full form if it's extremely common
 
@@ -107,7 +106,6 @@ TPU는 구글이 개발한 AI 가속기입니다.
 **Checkpoints**:
 - [ ] Acronym is presented with full term when it first appears
 - [ ] Acronym does not appear before the full term
-- [ ] Only the full term is bolded, not the acronym
 - [ ] Acronyms in title/summary are introduced in first paragraph
 
 ---
@@ -282,39 +280,28 @@ These rules ensure proper markdown rendering and consistent formatting.
 - Use H1(`#`) only for the page title (usually in frontmatter, not in body)
 - Start body sections with H2(`##`)
 - Use H3(`###`) for subsections
-- **Maximum heading level is H3** - Do not use H4(`####`) or deeper levels
-- Do not skip heading hierarchy (e.g., do not use H3 after H1)
+- Use H4(`####`) for sub-subsections if needed
+- Do not skip heading hierarchy (e.g., do not use H4 after H2, do not use H3 after H1)
 - Use descriptive headings that summarize the section content
 - Headings should form a logical outline of the content
-- If you need more levels of organization, use lists or paragraphs instead of deeper headings
 
 **Incorrect Examples**:
 ```markdown
 # Main Title
 ## Section 1
-#### Subsection (Skipped H3, and H4 not allowed)
-
-## TPU Architecture
-### Systolic Array
-#### Data Flow  (H4 not allowed - maximum is H3)
+#### Subsection (Skipped H3)
 ```
 
 **Correct Examples**:
 ```markdown
 ## TPU Architecture
 ### Systolic Array
-
-데이터 흐름은 다음과 같습니다: (Use paragraph instead of H4)
-
-## TPU Architecture
-### Systolic Array
-### Data Flow  (Use H3 instead of H4)
+#### Data Flow
 ```
 
 **Checkpoints**:
 - [ ] H1 is only used for page title
-- [ ] Maximum heading level is H3 (no H4 or deeper)
-- [ ] Heading hierarchy is not skipped
+- [ ] Heading hierarchy is not skipped (H2 → H3 → H4)
 - [ ] Headings are descriptive
 - [ ] Headings form a logical outline
 
@@ -585,7 +572,7 @@ When reviewing a blog post, check the following items in order of priority:
 - [ ] **Images**: All images have descriptive alt text and are placed before the content they illustrate
 
 ### Medium Priority
-- [ ] **Headings**: Proper hierarchy (H2 → H3, maximum H3, no skipping)
+- [ ] **Headings**: Proper hierarchy (H2 → H3 → H4, no skipping)
 - [ ] **Links**: Descriptive link text
 - [ ] **Lists**: Consistent formatting
 - [ ] **Frontmatter**: All required fields present and correct