한 줄 요약
AI 코딩 도구용 GPTERS 사례글 작성 스킬을 Hermes Agent용 write-hermes-post 스킬로 바꿔봤습니다.
AI 활용 사례글을 쓰려고 하면 "그래서 내가 뭘 했더라?" 하고 막히기 마련입니다.
GPTERS 스터디 수강생들의 사례글 작성용으로 만들어진 write-post 스킬을 봤습니다.
원본 스킬은 나쁘지 않았습니다. AI 코딩 도구로 작업한 세션을 읽고, 먼저 DEVLOG를 만든 뒤, 그 로그를 바탕으로 사례글을 쓰는 구조였습니다.
다만 이 구조를 그대로 Hermes에 적용하기에는 적합하지 않아 보였습니다..
Hermes는 Claude Code나 Codex CLI와 유사한 부분도 있지만 결정적으로 다른 부분들이 있습니다. 하나의 글 주제가 특정 프로젝트에 국한되는것이 아니라 여러 프로젝트, 여러 세션에 걸쳐서 남아있기 때문에 좀 더 광범위하게 기록을 찾아야 한다고 봤습니다. 대신 기록들이 .hermes 라는 폴더 내에 쌓이기 때문에 범위가 좁혀지는 측면도 있습니다.
이런 이유로 원본 스킬을 그대로 설치하는 게 아니라, Hermes가 실제로 일하는 방식에 맞춰 다시 설계하도록 해봤습니다.
이렇게 변환한 결과물은 여기 올려두었습니다.
https://github.com/fliklab/gpters-hermes-post-skill
이글도 스킬 활용해서 작성 후 제가 다시 수정한 것인데, 사실 마음에 들지는 않아서 거의 다시 써야 할 것 같네요.
제가 쓰기 좋은 스킬은 따로 만들어야 할 것 같습니다.
이런 분들께 도움될 것 같습니다
- Hermes Agent에서 직접 skill을 만들어보고 싶은 분
- 기존 AI 코딩 도구용 워크플로우를 Hermes에 맞게 바꿔보고 싶은 분
- GPTERS 사례글을 감으로 쓰지 않고, 작업 로그 기반으로 쓰고 싶은 분
- memory, skills, session_search, cron이 실제 글쓰기 흐름에서 어떻게 쓰이는지 보고 싶은 분
원본 스킬에서 좋았던 점
원본 write-post 스킬은 이런 흐름이 좋았습니다.
```
작업 기록 수집
→ DEVLOG 생성
→ 사용자 확인/수정
→ 사례글 작성
```
이 구조에서 중요한 것은 DEVLOG에서 글감과 구조를 먼저 정리한 뒤에 사례글을 쓰게 됩니다.
이런 구조를 포함하여 전체적인 원칙은 Hermes 버전에서도 그대로 가져가야 한다고 봤습니다.
Hermes에 맞지 않는 부분
원본 스킬은 AI 코딩 도구의 세션 파일과 프로젝트 폴더를 중심으로 움직입니다.
예를 들면 Claude Code, OpenCode, Codex CLI, Gemini CLI, Antigravity 같은 도구의 작업 기록을 읽고, 프로젝트 단위로 DEVLOG를 만드는 방식입니다.
그래서 그런지 특정 프로젝트를 지정을 하지 않으면 넘어가지 않는 경우가 있었습니다.
그런데 Hermes에서는 작업의 단위가 꼭 프로젝트 폴더가 아닙니다.
예를 들어 이런 것도 Hermes 스터디에서는 하나의 사례가 됩니다.
Telegram에서 AI 개인 비서처럼 쓰기
과거 대화를
session_search로 찾아 이어서 작업하기반복 절차를 skill로 저장하기
사용자 선호나 운영 규칙을 memory에 남기기
일정 시간이 지난 뒤 먼저 물어보게 하기(cron)
파일, 브라우저, 터미널, Git을 필요할 때 섞어 쓰기
즉 사례의 근거는 한 폴더 안에만 있지 않습니다.
코드 저장소에 있을 수도 있고, 대화 기록에 있을 수도 있고, skill 파일에 있을 수도 있고, cron 출력에 있을 수도 있습니다.
그래서 Hermes 버전에서는 "프로젝트 폴더를 스캔한다"보다 "이 사례를 증명할 수 있는 근거를 여러 소스에 걸쳐 찾는것"이 더 적합했습니다.
그래서 이렇게 바꿨습니다
새로 만든 스킬 이름은 write-hermes-post입니다.
원본의 큰 흐름은 유지했습니다.
주제 확인→ Hermes 활동 로그 수집→ DEVLOG 작성→ 사용자 확인→ GPTERS 사례글 작성→ 이미지/업로드 전 점검
대신 Hermes에 맞게 근거 수집 범위를 넓혔습니다.
session_search: 과거 Hermes 대화에서 실제 작업 흐름 찾기skills: 반복 절차로 저장된 작업 방식 확인memory: 사용자 선호와 운영 규칙 확인cron: 정기 팔로업이나 자동화 결과 확인Telegram gateway: 사용자가 어떤 식으로 지시했는지 확인
파일 도구: 실제 만들어진 문서나 스킬 파일 확인
terminal/Git: 커밋, README, 저장소 상태 확인
이렇게 바꾸니 Hermes에서 수행해본 실습도 자연스럽게 사례글로 바꿀 수 있었습니다.
제일 중요했던 변경: 주제 선정하기
Hermes는 할 수 있는 일이 많습니다.
이게 장점이기도 하지만, 글을 쓸 때는 오히려 문제가 됩니다. 범위가 너무 쉽게 넓어집니다.
그래서 write-hermes-post에는 본문 작성 전에 주제 후보를 먼저 정리하는 단계를 넣었습니다.
사용자가 정확한 주제를 말하면 그걸 기준으로 갑니다.
아니면 Hermes가 최근 세션을 훑고, 사례글 후보를 3~5개 추천합니다.
예를 들면 이런 식입니다.
1. Telegram에서 AI 매니저처럼 쓰기2. cron으로 먼저 팔로업 받기3. memory/skill로 개인 운영 규칙 만들기4. GitHub 작업을 Hermes로 정리하기
그리고 사용자가 하나를 고른 뒤에 DEVLOG를 만듭니다.
이 단계가 없으면 글이 쉽게 산만해집니다. 반대로 주제를 먼저 잡으면, 어떤 기록을 찾아야 하는지도 명확해집니다.
프로젝트 폴더를 찾는 현상
원본 스킬에서는 프로젝트 폴더를 지정하지 않은 경우, 진행이 계속되지 않고 특정 프로젝트 폴더에서 다시 진행하라는 현상이 있었습니다.
그런데 Hermes 사례에서는 항상 프로젝트 폴더가 필요한 건 아닙니다.
예를 들어 Telegram 코칭이나 cron 팔로업은 대화 기록과 cron 출력이 더 중요한 근거입니다.
그래서 꼭 필요한 경우 외에는 프로젝트 폴더가 없어도 되도록 했습니다. Hermes다운 사례를 더 안전하게 쓸 수 있었습니다.
스킬 배포 및 README 작성
스킬은 github에 새 저장소를 만들어 배포했고, 설치와 사용법은 최대한 간략하게 만들었습니다
Hermes 사용자가 따라 하려면 README가 길면 안 된다고 봤습니다.
그래서 설치 방법은 거의 이것만 남겼습니다.
hermes skills install https://raw.githubusercontent.com/fliklab/gpters-hermes-post-skill/main/SKILL.md
또는 Hermes에게 이렇게 요청하면 됩니다.
아래 주소의 skill을 설치해줘.https://raw.githubusercontent.com/fliklab/gpters-hermes-post-skill/main/SKILL.md설치 후에는 이렇게 부릅니다.
write-hermes-post 스킬로 GPTERS 사례글 작성하자.더 짧게는 이렇게 말해도 됩니다.
gpters 사례글 작성하자.결과적으로 달라진 점
이번 변환에서 가장 크게 달라진 점은 네 가지입니다.
첫째, 세션 파일 중심에서 Hermes 활동 로그 중심으로 바뀌었습니다.
원본은 AI 코딩 도구의 세션 파일을 읽습니다. Hermes 버전은 여기에 대화 검색, skill, memory, cron, Telegram 흐름, Git 기록까지 포함합니다.
둘째, 프로젝트 폴더가 없어도 사례글을 쓸 수 있게 했습니다.
Hermes의 작업은 꼭 레포지토리 안에서만 일어나지 않습니다. 개인 루틴, 코칭, 리마인더, 대화 기반 리서치는 폴더보다 세션과 상태가 더 중요합니다.
셋째, DEVLOG 확인 단계를 더 강조했습니다.
공개 글을 만들기 전에 빠진 내용, 잘못된 요약, 개인정보, 내부 경로, 확인되지 않은 수치를 먼저 점검하게 했습니다.
넷째, GPTERS 사례글 작성 자체가 Hermes 안의 재사용 가능한 skill이 됐습니다.
앞으로 비슷한 글을 쓸 때는 처음부터 설명할 필요 없이 gpters 사례글 작성하자. 라고만 하면 됩니다.
배운 점
좋은 스킬이라도 내가 사용하는 환경에 맞아야 합니다. 시중에 있는 스킬들은 claude code나 codex를 로컬에서 실행하는 환경에 적합한 경우가 많고 hermes에서 사용시 다른 부분이 있습니다.
앞으로도 이렇게 환경에 맞게 조금씩 변형해서 사용하면 유용할 것 같습니다.
주의할 점
Hermes는 개인화된 에이전트라서 공개 글을 쓸 때 조심해야 할 것도 많습니다.
특히 다음은 꼭 확인해야 합니다.(스킬에 포함되어있습니다.)
- Telegram 캡처에 개인 대화나 알림이 보이지 않는지
- chat ID, 계정 정보, 내부 경로가 노출되지 않는지
- memory 내용 중 민감한 정보가 섞여 있지 않은지
- 확인되지 않은 효과를 숫자로 과장하지 않았는지
저도 이번 스킬에 공개 전 점검 단계를 넣었습니다.
사례글을 잘 쓰는 것도 중요하지만, 공개하면 안 되는 것을 빼는 게 먼저라고 봤습니다.
마무리
이번 작업은 "좋은 스킬을 Hermes에 설치했다"기보다는 "좋은 스킬의 의도를 Hermes의 실행 방식에 맞게 다시 설계했다"에 가까웠습니다.
원본의 장점은 DEVLOG 기반으로 사례글을 쓰게 만드는 구조였습니다.
Hermes 버전에서는 그 근거가 더 넓어졌습니다. 코딩 세션뿐 아니라 대화, memory, skills, cron, Git 기록까지 포함합니다.
그래서 write-hermes-post는 단순한 글쓰기 프롬프트가 아니라, Hermes에서 실제 작업을 회고하고 공개 가능한 사례글로 바꾸는 절차가 됐습니다.
다음에 비슷한 글을 쓸 때는 이렇게 시작하면 됩니다.
gpters 사례글 작성하자.그러면 Hermes가 먼저 주 제를 잡고, 근거를 모으고, DEVLOG를 만든 뒤, 공개 가능한 글로 바꾸는 흐름을 따라갈 수 있습니다.
