task-observer — 스킬을 스스로 고치지 않는 스킬 개선기

task-observer 는 AI 비서(Claude)가 일하는 동안 「내가 고쳐 준 것」과 「자꾸 반복하는 일」을 메모해 두었다가, 일주일에 한 번 「스킬을 이렇게 고치면 어떨까요」라고 내미는 스킬입니다. 스킬은 AI 에게 일하는 법을 적어 둔 글 한 편입니다. 이 스킬은 그 글들을 쓰면서 배운 것으로 다시 고치자는 제안을 만들 뿐, 스스로 고치지는 않습니다. 원본은 github.com/rebelytics/one-skill-to-rule-them-all 입니다.

영상이 말한 것과 레포가 말하는 것은 조금 다릅니다

소개 영상(33초)의 제목은 「클로드 토큰 아끼는 오픈소스 2가지」입니다. 첫째는 Headroom(압축 도구 — 제 쪽 분석은 Headroom 편에 있습니다)이고, 둘째가 이 스킬입니다. 영상은 이렇게 말합니다. 「제가 클로드에서 결과물을 고칠 때마다 얘가 옆에서 다 기록을 해 줘요. 이런 규칙들을 저장해 놓습니다. 몇 달 동안 했던 지적들을 이제 안 해도 된다는 거죠.」 방향은 맞습니다. 다만 레포를 열어 보면 세 군데가 다릅니다.

영상	레포
토큰을 아끼는 도구	토큰을 줄이는 기능은 없다. 오히려 세션마다 코어 파일(45.6KB)을 읽는다. 아낀다면 「같은 지적을 되풀이하는 왕복」이 줄어서 생기는 간접 효과인데, 이 레포는 그걸 재지 않았다
규칙을 저장해 놓는다	저장되는 것은 규칙이 아니라 관찰 메모다. 규칙(스킬 수정)이 되려면 사람이 검토해야 한다
지적을 안 해도 된다	되도록 만드는 장치이지 약속이 아니다. 작성자는 스킬이 몇 개 안 되면 AI 의 기본 기억 기능으로도 비슷하게 된다고 직접 적었다. 설치만으로는 안 돌고 활성화 안내문을 설정 파일에 한 줄 따로 넣어야 한다는 말도 레포가 먼저 한다

이 스킬이 푸는 문제는 「스킬이 얼어붙는다」입니다

스킬을 한 번 만들면 쓰면서 고치지 않는 한 그대로입니다. 쓰다가 「여기가 아쉽다」고 느끼는 순간은 많은데, 그 순간에 스킬 파일을 열어 고치는 사람은 드뭅니다. 그래서 task-observer 는 그 순간을 메모로 붙잡는 일만 맡습니다. 세 가지를 봅니다.

• 내가 AI 의 결과를 고쳐 준 것
• 어떤 스킬로도 안 덮이는데 내가 반복하는 일 (새 스킬 후보)
• 이 스킬 자신이 놓친 것

직접 세어 보니 「기여자 90명 이상」은 맞았습니다

README 는 「90명이 넘는 기여자가 커밋 기록에 이름이 올라 있다」고 적습니다. 깃허브의 기여자 탭에는 5명만 보여서 의심이 들었습니다. 커밋 기록 344건을 전부 받아 세어 보니 이랬습니다.

센 것	수
커밋을 쓴 사람 이름	6
「Co-authored-by」 로 올라 있는 이름	104
둘을 합치고 AI 모델 이름 5개를 뺀 것	103

그러니까 말은 맞습니다. 다만 이름을 센 것이라 한 사람이 이름을 두 개 쓴 경우는 못 걸렀습니다. 그리고 합쳐진 PR 은 18건뿐이고 커밋은 거의 제작자가 썼습니다. 기여자 대부분은 이슈로 의견을 내고 제작자가 공동 저자로 올려 준 사람들로 보입니다(이 마지막 문장은 숫자 구조에서 읽은 추정이고, 이슈 하나하나를 열어 확인하지는 않았습니다).

가장 큰 숫자는 확인할 방법이 없습니다

「관찰 1,900건 이상, 스킬 83개」는 제작자 개인 작업 폴더의 기록입니다. 공개된 것은 도구이고 로그가 아니라서 다시 셀 수 없었습니다. 반대로 「스킬 83개 중 대부분이 이 스킬이 만든 관찰에서 시작했다」도 같은 이유로 믿을 근거도 반박할 근거도 없습니다.

토큰을 아끼는 도구가 아니라 쓰는 도구입니다

영상 제목과 정반대되는 사실이라 따로 적습니다. 코어 파일 SKILL.md 만 45.6KB 입니다. 영어 글자 4개를 토큰 하나로 치면 1만 1천 토큰 안팎(추정입니다. 토큰 계산기로 잰 값이 아닙니다)이고, 이 파일은 세션의 첫 도구 호출 전에 읽히도록 설계되어 있습니다. 거기에 따로 읽는 참고 문서 8개가 468KB, 보조 스크립트 5개가 146KB 입니다. 참고 문서는 필요할 때만 읽는다고 하지만, 코어가 이미 이 정도라는 것이 도입 비용의 바닥입니다.

내 환경에 대봤습니다 — 지금은 들이지 않습니다

• 제 스킬 폴더에는 항목이 113개, 기억 파일이 238개 있습니다. 작성자가 말한 「쓸수록 이득이 커지는 규모」 조건은 넘었습니다.
• 하지만 제가 이미 쓰는 길이 같은 자리에 있습니다. 반복 지적은 기억 메모로 쌓고, 주 1회 weekly-learn 점검에서 사람 승인을 거쳐 반영합니다. task-observer 를 들이면 같은 일을 하는 길이 둘이 됩니다.
• 제게 이 주제는 처음이 아닙니다. 올해 7월 제 PC 에 「모든 행동을 자동으로 관찰해 쌓는」 훅을 걸어 두었다가, 요약하는 단계가 한 번도 돌지 않아 관찰 127파일 20.6MB 만 쌓이고 배운 것은 0 인 채 조용히 죽어 있는 걸 발견했습니다. 살아남은 쪽은 단순하고 사람이 손으로 쓰는 기억 메모였습니다. task-observer 는 같은 종류의 실패, 곧 「적는 일이 조용히 멈추는 것」을 「3번째 할 일 완료마다 디스크에 쓰기」 같은 규칙으로 막으려는 설계로 읽힙니다(제 해석이고 문서가 그렇게 밝힌 것은 아닙니다). 방향은 옳은데, 규칙이 많아질수록 코어(45.6KB)도 함께 커집니다.
• 「같은 규칙을 두 번 어기면 문구를 고치지 말고 장치를 만들라」는 이 스킬의 원칙은 제 기록에 이미 있습니다(문서에만 적어 둔 규칙은 게이트가 아니다). 새로 얻은 것은 없습니다.

아직 모르는 것

• 직접 돌려 보지 않았습니다. 설치하고 2주쯤 써 본 뒤의 관찰 품질, 활성화 한 줄이 실제로 얼마나 잘 먹히는지는 모릅니다.
• 참고 문서 8개를 읽지 않았습니다. 코어 파일도 앞부분 3만 자까지만 읽었습니다. 「주간 검토」 절차의 세부는 이 글이 다루지 않습니다.
• 영상 속 주장은 자동 자막으로 읽었고, 영상 안에 레포 주소는 나오지 않습니다. 주소는 영상의 설명과 가장 맞는 레포를 제가 골랐습니다. 영상 제작자가 다른 도구를 말했을 가능성이 조금 남습니다.

여기부터는 자세한 기록입니다

task-observer 는 「적기」를 자동으로 하고 「고치기」를 사람에게 남긴 스킬이다. 2026-02-15 에 만들어졌고 마지막 푸시는 2026-10-16, 버전은 3.7.0, 별은 3,512(2026-10-23 기준)이다. 라이선스는 CC BY 4.0(출처만 밝히면 쓰고 고칠 수 있다). 릴리스는 9-21 의 3.3.0 부터 10-16 의 3.7.0 까지 25일 사이에 여섯 번 나왔다. 확인한 것은 네 가지다. 기여자 수, 관찰 1,900건, 크기와 도입 비용, 영상의 세 문장. 판정은 보류, 수확 0 이다.

무엇을 하는 물건인가

Claude 의 스킬 시스템 위에 얹는 메타 스킬이다. 다른 스킬을 쓰는 세션을 지켜보다가 관찰을 파일로 적고, 모인 관찰로 기존 스킬의 수정본이나 새 스킬 후보를 만든다.

구성	크기	하는 일
SKILL.md (코어)	45,556B	시작 절차, 무엇을 적을지, 어떻게 적을지. 세션 첫 도구 호출 전에 읽히도록 쓰여 있다
references/ 8개	468,312B	주간 검토·스킬 작성 규칙·로그 형식·환경 설정 등. 필요할 때만 읽는다
scripts/ 5개	145,582B	시작 스캔, 새 관찰 파일 생성, 번들 검증 등
관찰 로그	—	observation-log/ 폴더에 한 건당 파일 하나 (머리말에 상태·대상 스킬·제목)

로그를 파일 한 개로 두지 않고 건마다 쪼갠 이유는, 세션 시작 때 머리말만 훑어서 비용을 낮추려는 것이다. 이 스캔이 1,900건 규모에서도 버티는지는 확인하지 못했다.

대표 기법

기법	어떤 조건에서만 성립하나
3번째 할 일 완료마다 디스크에 쓰기	할 일 목록을 쓰는 세션. 목록 없는 대화에는 방아쇠가 없다(문서가 직접 인정한다)
세션 시작 스캔은 머리말만	로그가 건별 파일일 때. 스캔 결과가 비면 「없다」가 아니라 「명령이 틀렸다」로 읽는다
같은 건이면 새로 쓰지 말고 기존 건에 덧붙이기	관찰이 90개쯤 쌓이면 약 40개가 같은 발견의 재서술이었다는 작성자 실측
두 번 어기면 문구 말고 장치	같은 규칙이 개선 없이 두 번 실패했을 때. 훅·검사기 같은 장치를 제안한다
사람 승인 뒤에야 설치	주간 검토가 만든 수정본은 별도 폴더에 두고, 설치는 세션 밖에서 사람이 한다
활성화 이중화	스킬 설명문의 트리거 + 설정 파일 한 줄 + 선택적으로 세션 시작 훅

깨본 결과 — 숫자 셋과 문장 셋

#	주장	확인한 것	판정
1	기여자 90명 이상	커밋 344건을 API 로 받아 저자 6 + 공동 저자 104 = 108 이름, AI 모델 이름 5개 제외 103. 기여자 탭은 5명	재현됨 (이름 기준)
2	관찰 1,900건 · 스킬 83개	제작자 개인 폴더의 기록. 공개물에 로그가 없다	확인 불가
3	이슈·PR 220건 이상 닫힘	닫힌 이슈 238, 합쳐진 PR 18 (검색 API)	재현됨
4	영상 제목 「토큰 아끼는」	토큰 절감 기능이 없고 코어 45.6KB 를 세션마다 읽는다. 간접 효과는 안 재 봤다	어긋남
5	영상 「규칙을 저장」	저장되는 것은 관찰 메모, 스킬 수정은 사람 승인 뒤	어긋남
6	영상 「지적을 안 해도 된다」	README 가 소규모에서는 기본 기억으로 충분할 수 있다고 인정, 설치 외에 활성화 한 줄도 요구	과장

내 환경에 대봤다 → 수확 → 판정

기법	적용처	판정	이득	도입비용	되돌리기	신뢰도
task-observer 전체 상시 적용	설정 파일 한 줄 + 스킬 폴더	보류	반복 지적이 스킬로 굳는 속도 [추정 불가 — 안 돌려 봄]	코어 약 1만 1천 토큰/세션 [추정] + 기존 주간 점검과 이중	폴더 삭제 + 한 줄	낮음
두 번 어기면 장치	기존 규칙	기각 — 이미 해결	0	—	—	높음
관찰 한 건 한 파일 · 머리말만 스캔	기억 메모 색인	기각 — 이미 해결	0	—	—	높음
활성화 이중화	스킬 호출	기각 — 적용처 없음	0	—	—	중간
다시 여는 조건. 같은 지적이 기억 메모에 세 번 이상 따로 쌓이는 것이 눈에 띄거나(이 레포가 직접 말하는 신호), 스킬이 지금보다 눈에 띄게 늘어 직접 고치기가 감당이 안 될 때 다시 봅니다. 그때는 설치하고 2주 돌려 관찰 몇 건이 쓸 만했는지 세어 보는 것부터 합니다.

못 한 것

• 설치와 실행. 가장 큰 구멍이다. 이 글의 판정은 읽기와 계수만으로 냈다.
• 참고 문서 8개와 코어의 뒷부분. 코어는 도구 한도로 앞 3만 자까지만 읽었고, 주간 검토 절차는 열지 않았다.
• 관찰 1,900건. 개인 폴더라 셀 수 없다.
• 토큰 1만 1천 은 글자 수로 환산한 값이다. 토큰 계산기로 재지 않았다.
• 영상의 도구 식별. 자막과 33초 분량의 장면만 보고 레포를 골랐다. 영상 설명란은 확인하지 못했다.
• 독립 렌즈 적대 검증(반증·이미 해결됨·성립 조건 위반을 결론을 안 보여 주고 각각 돌리는 것)은 안 돌렸다. 기본 깊이다.
• 위 판정은 이 한 PC 한 사람의 환경 기준이다.