blog-post

name	blog-post
description	bbl 레포에 블로그 글을 쓰고 공개하는 스킬. 슬러그 확정 → 파일 생성 → frontmatter 검증 → 목록·상세 두 경로 렌더 확인 → 공개 판정 → 커밋까지의 워크플로를 다룬다. 사용자가 "블로그 글 쓸래", "포스트 추가해줘", "이 내용 글로 정리해서 올려줘", "초안만 만들어두고 나중에 공개", "글 제목/날짜/슬러그 바꿔줘", "왜 블로그 목록에 안 나와?", "글 순서가 이상해" 등 포스트 마크다운을 만들거나 고치거나 공개 상태를 바꾸는 요청을 하면 반드시 이 스킬을 사용할 것. 블로그 목록·상세 화면의 컴포넌트나 레이아웃을 고치는 작업은 ui-component가 담당하며, 글 자체를 다루는 대화가 아니라 렌더링 코드를 고치는 대화라면 이 스킬을 적용하지 않는다.

Blog Post (포스트 작성·공개 워크플로)

이 레포의 블로그는 실패가 예외로 드러나지 않는다. 파싱 실패도 조회 실패도 빈 목록으로 끝난다 (→ AGENTS.md §6). 핵심 원칙은 "화면을 실제로 열어서 글 수를 세기 전까지는 통과가 아니다".

0. 대원칙

• 파일명이 URL이다. path frontmatter는 URL이 아니다. 라우팅은 파일명 슬러그만 쓰고 path는 어디에서도 소비되지 않는다(→ §6). 슬러그를 바꾸면 기존 링크가 죽고, path만 바꾸면 아무 일도 일어나지 않는다. (나쁜 예: URL을 바꾸려고 path만 수정 / 좋은 예: 파일명을 바꾸고 path를 같은 값으로 맞춘다)
• date는 0을 채운 YYYY-MM-DD 문자열 외에 무엇도 허용하지 않는다. 정렬이 문자열 비교이고 표시용 포맷터는 Invalid Date에서 예외를 던진다(→ §6). 2026-8-2는 순서를 조용히 깨뜨리고 2026.08.02는 페이지를 죽인다.
• published: false는 "비공개"가 아니라 "목록에서 숨김"이다. 상세 경로는 필터 없이 정적 생성되므로 URL을 아는 사람은 전문을 읽는다(→ §6). 진짜 비공개가 필요하면 파일을 만들지 않는다.
• 목록이 비어 보이면 성공이 아니라 실패 신호다. 조회 실패가 예외 없이 blogs: []로 끝난다. "에러가 안 났다"는 검증이 아니다. 항상 글 수를 세서 이전 대비 정확히 예상만큼 변했는지 본다.
• 포스트 디렉터리는 마크다운 전용이다. 로더는 디렉터리의 모든 항목을 포스트로 간주한다 (→ §6). .DS_Store 하나, 초안 .txt 하나, 하위 폴더 하나가 블로그 전체를 빈 목록으로 만든다.

1. 슬러그·제목 확정

래더:

1. 사용자가 슬러그를 지정했으면 그대로 쓴다.
2. 제목이 영문이면 소문자 kebab으로 변환한다.
3. 제목이 한국어면 영문 요약 슬러그를 제안하고 승인을 받는다 — 기존 포스트는 전부 ASCII kebab이고 한글 슬러그 전례가 없다.

게이트: 슬러그 문자열이 확정됐고, 기존 파일명과 충돌하지 않으며, 사용자가 그 문자열 자체를 승인했다.

막히면: 합의가 안 되면 파일을 만들지 않고 멈춘다. 임시 슬러그로 만들고 나중에 rename하는 경로는 금지 — rename이 곧 URL 변경이다.

2. 파일 생성

래더:

1. §8 POST-NEW를 쓴다. 실행 직후 어디에 생겼는지 직접 확인한다.
2. 제너레이터를 쓸 수 없으면 이미 렌더되고 있는 기존 포스트 하나를 형태 기준으로 삼아 직접 만든다.
3. 어느 경로든 생성 후 frontmatter 키 집합을 §6의 스키마와 대조한다.

게이트: 파일이 §6이 지목한 디렉터리에 있고, frontmatter 키가 스키마와 정확히 일치하고 (초과 키 없음), published만 불리언이며 나머지는 인용된 문자열이다.

막히면: 제너레이터가 엉뚱한 위치에 썼다면 파일을 옮기고 원위치에 잔여 디렉터리·파일이 남지 않았는지 확인하는 것까지가 이 단계다. 초과 키가 붙어 나오면 지운다.

3. 본문 작성

게이트: 본문에 ---가 다시 등장하지 않고, 최상위 헤딩이 ##이며, 코드블록에 언어 태그가 있다. 제목은 frontmatter가 담당하고 상세 페이지가 별도로 렌더하므로 본문에 #로 제목을 또 쓰지 않는다.

GFM 래더:

1. 표·취소선·체크박스는 렌더 결과를 실제로 확인한 뒤에만 쓴다 — 이 레포의 remark 조합에 GFM 플러그인이 명시돼 있지 않다.
2. 확인이 불가하면 GFM을 쓰지 않고 리스트·코드블록으로 대체한다.
3. 이미 쓴 상태에서 확인이 불가하면 ⚠️로 표기해 사용자에게 넘긴다.

주의: 본문은 HTML로 변환되어 그대로 주입된다. 외부에서 복사한 HTML·스크립트를 넣지 않는다.

4. 렌더 검증 (이 스킬의 핵심)

래더:

1. §8 DEV로 띄운다. 목록 경로에서 글 수를 세고 새 글 제목이 보이는지, 상세 경로에서 제목·날짜·본문 셋이 모두 보이는지 확인한다.
2. dev가 뜨지 않으면 §8 BUILD 로그에서 해당 상세 경로가 정적 생성 목록에 나타나는지 확인한다.
3. 둘 다 불가하면 통과 중인 기존 포스트와 frontmatter를 문자 단위로 대조하고 날짜 문자열의 정렬 위치를 손으로 검산한다. 이 경우 결과는 반드시 ⚠️ 미검증으로 보고하고 커밋 여부를 묻는다.

게이트: 목록 글 수가 예상대로 변했고(공개면 +1, 초안이면 +0), 상세 페이지에 세 요소가 모두 보이고, 콘솔에 날짜 관련 예외가 없다.

실패 진단 순서:

• 목록이 통째로 비었다 → 디렉터리에 비마크다운 항목이 있거나 frontmatter 파싱이 실패했다
• 새 글만 안 보인다 → published
• 순서만 이상하다 → 날짜 문자열 형식
• 페이지가 죽는다 → 날짜 파싱

5. 공개 판정

게이트: 사용자가 "지금 공개"인지 "초안"인지 명시적으로 답했고, 초안이라면 상세 URL이 그대로 살아 있다는 점을 알렸다.

(나쁜 예: 묻지 않고 공개로 커밋 / 좋은 예: "지금 공개할까요? 초안으로 두면 목록에는 안 뜨지만 URL로는 열립니다")

6. 커밋

게이트: 변경 파일이 마크다운 1개(+ 2단계의 잔여물 정리)뿐이고 libs 아래 파일이 섞여 있지 않다. 커밋 메시지 규약은 §12.

7. 세션 종료 시

확정 슬러그와 최종 URL, 공개 상태, 검증 방식(✅ 실제로 열어봄 / ⚠️ 대조만), 남은 할 일을 요약한다.