콘텐츠로 이동

베이스 업데이트 받기

라이선시 fork는 한 번 받고 끝이 아닙니다. 베이스(ddakit/blog-studio)가 새 스킬을 추가하거나, 훅을 고치거나, AI_AUTOMATION.md의 도메인 규칙이나 Blogger 발행 스크립트를 갱신할 때마다 그 변경이 fork에 도달해야 라이선스 가치가 유지됩니다. /update-from-basegit rebase 모르고도 안전하게 받게 해주는 자리입니다.

자동 적용 가능, 절대 안 건드림, 사람이 결정. 이 셋의 분기가 핵심입니다.

업데이트가 무엇을 덮어쓰고 무엇을 그대로 두는지는 파일 자리로 결정됩니다.

경로무엇
.claude/skills/{base-skill-name}/베이스 스킬 (start, blog-orchestrator, 블로그 트랙 13 + 마케팅 트랙 6)
.claude/agents/*.md6 에이전트 (strategy, production, quality + marketing-director, content-lead, seo-discovery-lead)
.claude/hooks/*.sh, .claude/settings.json베이스 훅과 등록
AI_AUTOMATION.md도메인 SSOT (Phase 정의, 산출물 계약, AI 게이트 카테고리, 보안 S1~S8)
scripts/deploy_to_blogger.py, scripts/deploy.sh, scripts/requirements.txt, scripts/README.mdBlogger 발행 스크립트
.env.example, .gitignoreplaceholder와 표준

베이스 스킬 본문은 직접 수정하지 않는 것이 원칙입니다. 자기 스킬을 추가하고 싶으면 별도 디렉토리에 만듭니다. base-owned 영역에 새 스킬이 추가돼도 사용자 자기 디렉토리는 영향받지 않습니다.

경로무엇
_workspace/posts/, _workspace/pages/, _workspace/briefs/작성 중 글, 발행 아카이브, 단계별 브리프, 이미지
.envBLOG_ID_KO, BLOG_ID_EN
scripts/credentials.json, scripts/token.jsonGoogle OAuth (git 추적 안 함)
.claude/agent-memory/, .claude/state/, .claude/session-state/메모리, 런타임, 세션 핸드오프
LICENSE, COMMERCIAL-LICENSE.md라이선스

라이선스 파일과 .env는 베이스가 갱신해도 자동으로 덮어쓰지 않습니다. 베이스가 .env.example에 새 변수 자리를 추가했다면 그 변수를 본인 .env에 채우는 자리를 안내만 합니다.

CLAUDE.md, AGENTS.md, README.md 셋. 베이스와 사용자 양쪽 편집이 동시에 들어갈 수 있어 자동 갱신하지 않고 diff만 보여주고 묻습니다. README.md/start가 본인 블로그 이름과 정체성으로 다시 쓰는 자리라, base 변경분을 통째 덮으면 사용자 블로그 정체성이 사라집니다.

.claude/product-marketing-context.md는 한 가지 예외입니다. fork 사용자가 채운 블로그 정체성이라 평소엔 user-owned지만, 베이스가 placeholder 구조 자체를 갱신하면 mixed로 강등해 안내합니다.

베이스를 git remote로 등록합니다. 첫 호출이 이 단계를 자동 안내하므로 미리 칠 필요는 없습니다.

Terminal window
git remote add base https://github.com/ddakit/blog-studio.git
git remote -v

상태 파일은 .claude/state/base-upstream.json에 들어가고, last_synced_commit부터 base/main까지의 변경분만 봅니다.

/update-from-base 또는 “베이스 업데이트 받아줘”라고 부르면 다음을 거칩니다.

  1. git status --porcelain으로 dirty 검사. 저장 안 된 변경이 있으면 git stash 권유
  2. git fetch base main
  3. git diff --name-status <last_synced_commit>..base/main로 변경 파일을 영역별 분류
  4. base-owned 변경 요약. 새 스킬 N개, 갱신된 훅 M개, AI_AUTOMATION.md 갱신 여부, 발행 스크립트 갱신 여부
  5. 사용자 yes 시 base-owned 경로만 git checkout base/main --로 적용
  6. mixed 파일은 한 개씩 옵션 셋(통째 덮기, 3-way merge, 미루기) 중 골라 적용
  7. 적용 후 검증. .shchmod +x, settings.json JSON 파싱, 새 스킬 trigger 키워드 나열
  8. .claude/state/base-upstream.json 갱신
  9. commit 권유. 메시지는 chore(base): sync from ddakit/blog-studio @ {short-hash}

파괴적 명령은 자동 실행하지 않고 사용자 확인을 받습니다. 기본 흐름은 30초에서 2분 사이, mixed 결정에 시간이 더 걸리는 분기가 하나 있습니다.

발행 스크립트가 base-owned인 이유

섹션 제목: “발행 스크립트가 base-owned인 이유”

deploy_to_blogger.py는 AI-smell과 품질 게이트를 코드 레벨에서 강제하는 자리입니다(S8). 사용자가 이 스크립트를 수정하면 게이트가 무력화될 수 있어, 베이스가 SSOT로 들고 있습니다. 발행 동작을 바꾸고 싶으면 스크립트를 고치는 대신 AI_AUTOMATION.md의 게이트 임계값을 따르는 자리에서 조정합니다. 게이트를 우회해야 하는 재발행은 --skip-gate 플래그로만 엽니다.

베이스 스킬을 본인이 수정한 흔적이 있을 때

섹션 제목: “베이스 스킬을 본인이 수정한 흔적이 있을 때”

.claude/skills/{base-skill}/ 안 파일을 사용자가 commit으로 수정한 적이 있으면(git log로 감지) 그 파일은 base-owned가 아니라 mixed로 처리됩니다. 자동 덮어쓰면 사용자 작업이 사라지기 때문입니다. 이걸 피하려면 베이스 스킬을 직접 고치지 말고, 같은 trigger 키워드를 가진 별도 스킬을 자기 디렉토리에 만듭니다.

비개발자 호흡으로 같은 절차를 따라가는 자리는 비개발자용 업데이트에 있습니다.