메뉴
42jerrykim.github.io Hugo 블로그의 모든 글쓰기·편집 작업에 적용되는 전역 필수 규칙. frontmatter(draft, tags, description, title), 날짜 확인, 본문 링크 검증, 독자용 본문 원칙, Mermaid 다이어그램 문법, 알고리즘 코드 주석 규칙, 직접 인용 검증을 포함한다. 글 작성·수정, 새 포스트 생성, 컬렉션 글 작업 시 항상 적용한다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
게시물 품질을 루브릭 점수로 채점하고, 임계값을 넘을 때까지(또는 최대 반복까지) 채점→수정→재채점을 반복하는 품질 개선 루프. blog-agent-pipeline의 순환 버전으로, quality-critic 서브에이전트(채점자)와 분리되어 동작하며 점수판(scoreboard)에 상태를 기록한다. draft 해제는 사람만 한다. 신규 초안 게이트·기존 게시글 재점검·야간 자율 실행에 사용한다.
컬렉션 글(content/collection/**/index.md, **/*.md)을 작성할 때 따르는 이론 중심 글쓰기 표준. 전문가 수준의 이론적 설명을 문단으로 먼저 서술하고 코드/표/다이어그램은 보충 자료로만 쓰도록 한다. 컬렉션 글 작성·보강, 기술 시리즈 글 작성 시 사용한다.
AI 보조 시리즈형 교육 글(컬렉션)의 본문 구성·깊이·slug·00 챕터·내용 완결성(석학/SME 기준: 오개념·개념 연결·1차 출처·과목별 필수 요소)·품질 체크리스트를 표준화한다. design-patterns, cleanarchitecture, optimization 시리즈, C++ 성능 트랙, 장문 기술 튜토리얼, 커리큘럼형 블로그 포스트를 작성·보강할 때 사용한다. blog-post-writing 스킬 및 rules-that-must-be-followed와 함께 적용한다.
Hugo 블로그 글을 끝까지 작성하는 멀티스테이지 파이프라인. Research(자료·링크 검증) → Draft(blog-post-writing 준수) → QA(메타·Mermaid·링크) → PublishPrep(draft 해제 전 최종 확인) 순으로 한 세션에서 순차 실행한다. **한 세션에서 전체 사이클을 자동 진행**할 때 사용한다. 단계별 작성 규칙 자체가 필요하면 `blog-post-writing`을 참고한다.
Hugo 블로그 포스트 작성을 위한 종합 가이드. 컬렉션/일반 포스트의 frontmatter 생성, 본문 구조 템플릿, SEO 최적화, 이미지/에셋 관리, 태그 선정(data/tags.yaml), 링크 검증, Mermaid 다이어그램, 한국어/영어 이중 언어 콘텐츠를 포함한다. 블로그 글 작성, 새 컬렉션 생성, 기술 블로그 포스트 작성 시 사용한다. Research→Draft→QA→PublishPrep 전체 파이프라인을 한 번에 진행하려면 `blog-agent-pipeline`을 참고한다.
content/post/ 하위 AI 도구·서비스 활용 글(Claude Code, ChatGPT, Cursor, AI 에이전트·플러그인·워크플로 가이드) 작성 가이드. 아키텍처/기능 설명·적용 시나리오·판단 기준·장단점 구조와 태그·체크리스트를 표준화한다. content/post/ 하위 AI 도구·서비스 소개·활용 가이드 글 작성 시 사용한다.
| name | rules-that-must-be-followed |
| description | 42jerrykim.github.io Hugo 블로그의 모든 글쓰기·편집 작업에 적용되는 전역 필수 규칙. frontmatter(draft, tags, description, title), 날짜 확인, 본문 링크 검증, 독자용 본문 원칙, Mermaid 다이어그램 문법, 알고리즘 코드 주석 규칙, 직접 인용 검증을 포함한다. 글 작성·수정, 새 포스트 생성, 컬렉션 글 작업 시 항상 적용한다. |
content/ 아래 마크다운을 새로 만들거나 수정할 때는 항상 아래 항목을 확인한다.
draft: true로 시작한다. 배포 전 검토 후 필요 시 draft: false로 변경한다.data/tags.yaml은 실제로 병용되는 영/한 쌍을 영어(한글) 형식의 단일 승인 태그로 통합했으므로(Phase 8), 더 이상 같은 개념을 영어·한글 두 줄로 나눠 태그 수를 채우지 않는다. 최소 10개는 data/tags.yaml 승인 태그를 표기 그대로(대소문자·하이픈·괄호 포함) 사용해 다른 글과 실제로 연결되게 한다. 문제 ID·인물명·명령어명처럼 글마다 고유한 태그는 나머지 자리를 채우되, 승인 태그를 임의로 변형(소문자화, 띄어쓰기 변경 등)하지 않는다 — 표기가 갈리면 같은 개념이 서로 다른 태그 페이지로 쪼개진다. 부족하면 목록을 참고해 새 태그를 추가한다.CI 자동검증:
title(≤70자)·tags(≥25개)·태그 표기가data/tags.yaml승인 태그와 대소문자 단위로 일치하는지를.github/workflows/lint-content.yml(script/lint_frontmatter.py)이 PR에서 신규 md 파일에 한해 자동으로 검사한다(위반 시 CI 실패).description길이는 경고만, 기존 파일 수정은 강제하지 않는다 — 과거 콘텐츠 다수가 이 규칙 이전에 작성됐기 때문이다. 태그 파편화 배경과 50→25 기준 재조정 근거는 tag-consolidation-plan.md Phase 8 참고.
새 콘텐츠의 작성일·수정일·lastmod 등 날짜가 필요하면 추측하지 말고, 터미널에서 오늘 날짜를 확인한 뒤 그 값을 사용한다.
Get-Date -Format "yyyy-MM-dd"echo %date%end, subgraph, graph 등)는 노드 ID로 사용하지 않는다.""(double quote)로 전체 라벨을 감싼다. HTML 엔티티·특수문자는 가능한 한 지양하고, 필요 시 따옴표로 감싼다.
F["changes = sum D[l+1..r]"], A["입력 n"], D -->|"type 2: 2 l r"| F[...]\n 대신 </br>을 사용한다 (렌더러에 따라 <br/>도 허용될 수 있음).알고리즘 문제 정답 코드의 상단에는 다음 주석을 추가한다:
42jerrykim.github.io에서 더 많은 정보를 확인할 수 있다
insane-search)로 대조해 정확한 문장·발행일인지 확인한다.post-quality-loop)가 아니라 작성 시점에 이 확인을 해야 한다 — AI가 그럴듯하지만 실재하지 않는 문장을 실존 인물에게 귀속시키는 환각은, 다른 사실 오류와 달리 겉으로는 매우 자연스러워 보여 뒤늦게 발견되면 이미 게시된 뒤일 수 있다.