Community라이팅 & 에디팅github.com

Blog — Jekyll + GitHub Pages

Jekyll + GitHub Pages 블로그에 글을 쓰고 발행하는 스킬로, "블로그로 올려줘", "글 써줘", "블로그에 푸시해줘", "/blog" 같은 명령어에 반응합니다.

Blog — Jekyll + GitHub Pages란 무엇인가요?

이 스킬은 개인 Jekyll + GitHub Pages 블로그에 포스트를 작성하고 발행하는 전체 워크플로를 자동화합니다. 사용자가 블로그 관련 명령을 내리면, 적절한 프론트매터를 포함한 마크다운 포스트를 `_posts/` 디렉토리 아래에 생성하고, Git에 커밋 및 푸시하여 GitHub Pages가 자동 배포하게 합니다. 또한 발행 전에 모든 외부 링크의 HTTP 상태를 확인하고, 배포 후 실제 URL이 200을 반환하는지 검증하여 깨진 링크나 미래 날짜 포스트 문제를 방지합니다. 블로그 인덱스 파일을 최신 상태로 유지하는 것도 포함하며, 게시물 내용에서 고용주 정보를 절대 포함하지 않도록 엄격한 규칙을 적용합니다. Cursor, Claude Code, Codex 등 다양한 AI 에이전트 플랫폼에서 사용할 수 있습니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ankitg12/agent-skills/tree/HEAD/blog-it

Installed? Explore more 라이팅 & 에디팅 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Blog — Jekyll + GitHub Pages은(는) 무엇을 하나요?

저장소: ~/repos/github.com/<your>/<your>.github.io
엔진: Jekyll + GitHub Pages, 테마: minima
브랜치: master → 푸시 시 자동 배포
인덱스: 블로그 인덱스 노트 파일 유지 (예: ~/notes/blog.md) — 매 포스트 후 업데이트

참고 — 로컬 Jekyll 빌드는 필요 없습니다. GitHub에서 서버 측에서 빌드합니다.


⚠️ 강제 규칙: 고용주 정보 금지

어떠한 게시물에도 절대 포함하지 마세요:

  • 고용주의 내부 도구, 시스템, 코드명 또는 인프라
  • 내부 프로젝트 이름, 팀 이름, 조직 구조 또는 로드맵 세부 사항
  • 고객 이름, 파트너 이름 또는 계약 세부 사항
  • 내부 티켓, 위키 페이지 또는 회의 내용
  • 급여, 인원, 예산 또는 비즈니스 지표

기술, 도구, 패턴에 대해 작성하세요 — 어디서 일하는지 또는 고용주가 무엇을 출시하는지가 아니라. 의심스러우면 게시 전에 사용자에게 물어보세요.


워크플로

1. 포스트 작성

_posts/YYYY-MM-DD-slug-here.md

프론트매터:

---
layout: post
title: "Your Title Here"
date: YYYY-MM-DD
categories: ai agents productivity   # space-separated
series: "AI coding agent productivity"   # omit if not in a series
---

2. 스타일

  • 문제로 시작, 해결책이 아니라
  • 하나의 구체적인 시작 문장 — "이 포스트에서는..." 같은 것 없이
  • 실행 가능한 내용은 코드 블록 사용
  • 비교는 표 사용
  • ## Source 섹션으로 마무리하여 저장소/참고자료 연결
  • LLM 장식 금지 — README처럼 작성
  • PDF가 필요할 경우 타이포그래피 인용 오류를 피하기 위해 @word를 \@word로 이스케이프

블로그에 잘 알려진 발행된 포스트 하나를 골라 톤과 밀도의 참고 자료로 사용하세요.

3. 게시 전 모든 링크 검증 (생략 금지)

기억에서 URL을 인용하면 404가 발생합니다. 각 링크의 HTTP 상태를 먼저 확인하세요:

for u in "https://example.com/a" "https://example.com/b"; do
  echo "$(curl -sS -L -o /dev/null -w '%{http_code}' "$u")  $u"
done

커밋 전에 모든 링크가 반드시 200(또는 유효한 대상으로의 301/302)을 반환해야 합니다. 죽은 링크를 배송한 후 사용자가 발견하고 수정하는 것보다 저렴합니다.

4. 커밋 및 푸시

cd ~/repos/github.com/<your>/<your>.github.io
git add _posts/YYYY-MM-DD-slug.md
git commit -m "post: <title>"
git push   # GitHub Pages가 약 60초 후 자동 배포

5. 인덱스 업데이트

블로그 인덱스 노트 파일의 ## Posts 테이블에 행을 추가하세요 (최신순), 그리고 포스트가 시리즈에 속한다면 ## Active series 행에 포스트를 추가하세요:

| YYYY-MM-DD | Title | `category/path/YYYY/MM/DD/slug.html` |

URL은 categories + date + slug에서 파생된 Jekyll의 permalink 패턴을 따릅니다.

6. 실제로 라이브 되었는지 확인 (생략 금지)

Pages 빌드 성공이 포스트가 라이브임을 의미하지는 않습니다 — Jekyll은 미래 날짜의 포스트를 조용히 드랍합니다. 빌드 완료 후 실제 URL을 컬하세요:

base="https://<your>.github.io"; slug="/CATEGORY/PATH/YYYY/MM/DD/slug.html"
curl -sS -L -o /dev/null -w "%{http_code}\n" "$base$slug"   # 반드시 200
curl -sS -L "$base/" | grep -o 'slug[^"]*html' | head -1     # 홈페이지에 나타나야 함

빌드는 성공했는데 404가 나오면, 거의 확실히 아래의 미래 날짜 트랩입니다.


발행된 포스트 업데이트 보호

  • 원래 내러티브를 유지하고 명확히 표시된 업데이트를 추가하세요. 사용자가 명시적으로 재작성을 요청하지 않는 한.
  • 새로 추가되거나 수정된 URL만 HTTP 확인하세요. 링크 감사가 요청되지 않는 한 변경되지 않은 게시된 링크를 반복 확인하지 마세요.
  • 푸시 후 실제 게시된 URL이 HTTP 200을 반환하는지 확인하세요.

팁

  • 블로그 인덱스 노트 파일에 ## TODO 섹션을 유지하여 초안 아이디어를 관리하세요. 처음부터 시작하기 전에 확인하세요.
  • 포스트가 이전 포스트를 이어가거나 반박하는 경우 {% post_url YYYY-MM-DD-slug %}로 연결하세요.
  • 새벽 게시 + 미래 날짜 트랩: Jekyll은 날짜 없는 date: YYYY-MM-DD를 사이트 시간대의 자정으로 해석하고 미래 날짜의 포스트를 조용히 드랍합니다. _config.yml에 명시적인 timezone: 줄이 추가되기 전, 현지 시간 04:00에 작성된 포스트는 UTC 자정(약 1시간 미래)으로 읽혀 UTC가 따라잡힐 때까지 드랍되었습니다. _config.yml에 timezone:을 설정하고 제거하지 마세요. 새벽 포스트가 빌드 성공 후에도 404가 나오면 프론트매터에 명시적 시간을 추가하세요 (date: YYYY-MM-DD 04:00:00 +0530).

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

관련 스킬