---
name: hermes-delivery
description: "헤르메스(전령) 전달·정기작업·외부연동 절차. 배포/Gitea push/전달 패키지/릴리즈 노트, 정기·예약 작업(cron, /schedule, 헬스체크, 주간 보고), webhook·Gitea API 알림, 전달 이력 조회, 전달 절차 스킬화 요청 시 반드시 이 스킬을 사용하라. 다시 실행·재전달·정기작업 변경/해제 요청 포함."
---

# hermes-delivery — 전령 운영 절차

hermes 에이전트(4대 특징: memory·skill·cron·external APIs)의 실행 절차서. 원칙과 게이트는 에이전트 정의가 권위이고, 이 스킬은 **어떻게**를 담는다.

## 1. 전달 파이프라인 (기본 절차)

1. `_workspace/02_bot_report.md` 읽기 — **PASS 게이트**. 실패 항목 존재 시 전달 중단·리더 보고
2. 메모리 조회 — 이 프로젝트의 채널 레지스트리·학습 패턴 확인 (같은 실패 반복 방지)
3. 전달 패키지 `_workspace/03_delivery.md` 작성:
   ```
   # Delivery Report
   ## 1. 변경 파일 (경로·유형)   ## 2. 변경 요약 (기술)
   ## 3. 릴리즈 노트 (사용자 관점) ## 4. 커밋/push 결과 (해시·브랜치)
   ## 5. 배포 확인 (health)      ## 6. 후속 조치
   ```
4. Git 전달(요청 시만): 변경 파일만 `git add <경로>` → 컨벤션 커밋 → push. 거부 시 원인 진단(behind·훅)만 보고 — force·`--no-verify` 금지
5. 배포 확인: webhook 배포 로그·health 엔드포인트 200 확인 (레지스트리의 URL 사용)
6. 알림: 리더 보고 + `notify_webhook_url` 설정 시 요약 POST(자격증명·IP 제외)
7. 메모리 갱신: 전달 이력 1줄 + 새로 배운 패턴

## 2. Cron / 정기 작업

| 요청 | 도구 | 예 |
|------|------|-----|
| 세션 예약 반복 | `CronCreate` (조회 `CronList`, 해제 `CronDelete`) | 배포 후 10분 헬스체크, 매주 금요일 릴리즈 노트 초안 |
| 세션 밖 클라우드 루틴 | `schedule` 스킬 | 야간 정기 배포 상태 점검·주간 wiki 갱신 |
| 짧은 폴링 루프 | `loop` 스킬 | CI 완료 대기 |

- 등록 전 `CronList`로 중복 확인. 등록·해제 내역은 메모리 채널 레지스트리에 기록
- 정기 작업의 산출(보고서·알림)도 §1의 마스킹 원칙을 따른다

## 3. External APIs

- **Gitea REST** (`https://git.zioinfo.co.kr/api/v1/`): 릴리즈 생성 `POST /repos/{owner}/{repo}/releases`, 이슈 코멘트, webhook 관리. 토큰은 `GITEA_TOKEN` env에서만 — 코드·커밋·로그·메모리 기재 금지
- **알림 webhook**: userConfig `notify_webhook_url` → `{"project","result","commit","summary"}` JSON POST. 미설정이면 조용히 생략
- 새 외부 엔드포인트가 필요하면 임의 호출하지 말고 사용자 승인을 먼저 받는다 (GUARDiA 보안 불변: 외부 API 금지 원칙)

## 4. 스킬 자가 축적 (Hermes 학습 사이클)

Observe→Plan→Act→**Learn**: 전달 완료 후 아래를 점검한다.

1. 이번 절차가 이전과 동일 패턴 2회째인가? → 대상 프로젝트 `.claude/skills/<동사-대상>/SKILL.md` 생성 (frontmatter name/description + 절차 + 검증 기준)
2. 생성한 스킬 포인터를 메모리에 기록, 다음 회부터 해당 스킬 우선 사용
3. 실패→해결 페어가 새로 생겼으면 메모리 학습 패턴에 추가 (프로젝트 CLAUDE.md에 이미 기록된 내용은 중복 저장 금지)

## 에러 핸들링

| 상황 | 대응 |
|------|------|
| push 거부 | fetch로 원인 확인(behind/훅) → 보고. 우회 금지 |
| health 실패 | 배포 로그 수집 → 코드 원인이면 agent에 수정 요청, 1회 재전달 |
| webhook POST 실패 | 1회 재시도 후 생략하고 보고에 명시 (전달 자체는 성공 처리) |
| cron 중복 등록 | 기존 항목 유지, 신규 등록 취소 후 사용자에 알림 |