Hacker News 의견들
•picklenerd: 스킬을 찾아다니기보다 자주 반복하는 작업에 맞춰 직접 작성함 . 로컬과 GitHub에서 버전 관리하고, 각 에이전트의 스킬 폴더에 심볼릭 링크를 걸어 최신 상태를 유지함. 무작정 내려받는 건 클릭하지 않을 북마크나 읽지 않을 전자책을 수천 개 모으는 것과 비슷함.
에이전트로 스킬을 만드는 건 간단하므로, 반복 가능한 작업 흐름이 생길 때 취향에 맞게 만들고 작업 방식이 바뀌면 수정하는 편이 좋음. 현재는 코드·문서의 AI 특유 문체 제거, 원하는 순서로 질문하기와 설계 진행, jj 사용 방식 지정, 서로 다른 6가지 우선순위의 하위 에이전트 실행과 코드 검토, 개인 프로젝트의 로컬 Markdown 이슈 관리에 사용함.
•70rd: 스킬은 모델이 기본적으로 보이지 않는 원하는 행동을 유도하는 수단 이지 수집용 카드가 아님. 실질적인 이득 없이 컨텍스트만 어지럽히기도 함.
•kbos87: 내 작업 흐름에 특화된 일을 반복 수행할 때만 스킬의 가치를 느낌. 널리 공유되는 스킬은 모델이 이미 할 수 있는 것 이상을 별로 더해주지 못함. 직장에서는 같은 환경에 맞춰진 동료의 스킬을 출발점으로 활용하기도 함.
모든 스킬이 하나의 Markdown 표에 설명, 마지막 실행 시점, 발생한 예외, 마지막 수정 시점 을 기록하도록 해둠.
•avaer: 유명인의 능력을 내려받겠다는 식의 스킬 활용은 대부분 과장 광고에 가까움 . 지난해에는 의미가 있었을지 몰라도, 요즘 에이전트는 좋은 저장소와 프롬프트만 있으면 필요한 내용을 스스로 찾을 수 있음. 개발용 매크로로는 유용하지만, 인터넷에서 가져오기보다 팀 저장소에서 공유할 성격임. 관리 도구가 필요할 만큼 스킬이 많다면 설계를 의심해볼 만함.
•sigmoid10: 좋은 저장소와 프롬프트를 만드는 일 에 어려움을 겪는 사람이 HN에서 느껴지는 것보다 훨씬 많음. 일반 사용자는 대충 “X 만들어줘!”라고 입력하고, 모델이 빈칸을 추정하면 불평하곤 함. grill-me 같은 스킬이 도움이 될 수 있지만, 결국 모델이 사용자의 지식수준과 의도를 파악해 스스로 보완하게 될 것으로 봄.
부실한 입력에 되묻는 능력은 이미 좋아지고 있음. 다만 최신 모델도 기업 프로젝트에서 드물게 환각을 고집하며, 언제 반박해야 할지 알려면 해당 분야를 잘 알아야 함.
•itishappy: 회사에서 시험했더니 스킬 사용 시 최상위 모델의 출력 토큰이 약 2~4분의 1로 감소 했고, 최신 모델일수록 절감 폭이 커짐. 하위 에이전트 사용이 늘면서 모델 스스로 프롬프트를 구성하는 일이 많아진 영향으로 추정함.
스킬도 텍스트라 좋은 프롬프트로 대체할 수 있지만, 바로 그 점 덕분에 조직 전체가 공유할 기준선을 만들고 최소 활용 수준과 일관성을 높일 수 있음.
•misja111: 에이전트가 알아낼 수 없는 내용을 알려주는 게 아니라, 알아내는 수고를 줄이는 것 임. 좋은 스킬 파일은 토큰을 절약해 줌.
•theahura: 스킬이 필요 없다는 데는 동의하기 어려움. SPACE—검색, 계획, 검증, 코딩, 평가 를 구현한 스킬 모음은 상당한 이점을 줌. https://open.substack.com/pub/theahura/p/agentics-using-meta... 에 정리해둠.
우리가 쓰는 스킬 모음은 전용 레지스트리 https://noriskillsets.dev/ 에서 공개하며, 팀용 비공개 레지스트리도 만들 수 있음. 로컬에서는 https://github.com/tilework-tech/nori-skillsets CLI로 스킬을 묶고 전환함. 발표 자료에는 사무용, 코딩에는 개발용, 디버깅에는 디버깅용 묶음을 사용함. 조금씩 손보지만 모델이 출시될 때마다 바꿀 필요는 느끼지 못함.
•bensyverson: AGENTS.md 조각의 패키지 관리자 같은 Agents 를 만들고 있음. 저장소에 작업별 상세 지침을 두고 AGENTS.md에 사용 시점을 안내하니 결과가 좋음. 스킬의 단순화된 형태인데, 스킬보다 AGENTS.md 지침을 더 잘 따르는 느낌임. https://github.com/bensyverson/agents/ 에서 볼 수 있음.
•kramer2718: 만든 도구를 superpowers와 비교해줄 수 있음?
•alexhans: 스킬은 직접 만들고, 소프트웨어 저장소에서 관리하며, 사용하는 모든 코딩 에이전트 실행 환경에 심볼릭 링크로 설치함. 나머지는 머리말 메타데이터에 따른 점진적 정보 공개 에 맡김.
AI 평가를 통합 테스트처럼 사용해 행동을 검증 하며, 스킬은 자연어를 작고 빠른 도구 호출로 연결하는 역할에 집중시킴. 새로운 문제가 생길 때 수정하지, 이유 없이 바꾸지는 않음. 팀이나 개인에게 특화된 작업 흐름은 모델 능력이 좋아져도 대체되지 않음. 관련 접근법은 https://alexhans.github.io/posts/series/evals/building-agent... 에 정리함.
•stingraycharles: 평가 이야기는 많이 듣지만, 스킬 작성보다 평가에 100배 더 시간을 쓰지 않는 실용적인 구현이 어려움. 디버깅 스킬을 만들었다면 아주 단순한 항목 말고 무엇을 어떻게 평가해야 함?
•resonious: 스킬을 쇼핑하듯 고르는 건 매력을 모르겠음. 예외는 Axiom의 Apple 개발 스킬이나 공식 Flutter 스킬 정도인데, 사실상 문서임. 공식 문서 URL을 매번 붙여 넣는 대신 설치해두는 셈임.
•imadtaieber: 여러 프로젝트에서 공통으로 필요한 스킬은 어떻게 관리함?
•darren0: 스킬은 절차를 코드화한 것 이며, 그 절차가 특수할수록 유용함. 대상이 넓어지면 일반화되어 모델이 이미 아는 내용과 겹치게 됨. 따라서 소규모 집단에 더 적합하고, 배포와 유지 관리 방식도 그 집단에 맞춰지는 편임.
•WatchDog: 스킬을 쓰지 않는데, 어떤 종류가 가장 유용함? 일반 작업은 모델이 알아서 잘 처리하고, 프로젝트나 환경에 특화된 정보는 readme나 agents.md 에 넣고 있음.
•pletnes: 회사·프로젝트에서 선호하는 작업 방식 을 스킬로 만듦. 테스트 데이터베이스 조회, Git 브랜치 이름, 커밋 메시지 형식, 조회 가능한 클라우드 로그 등이 해당함. git이나 python 문서에 있는 내용은 모델이 이미 알므로 가르칠 이유가 없음.
•ygjb: 내부에서는 완전히 결정적이지는 않아도 그에 가까운 동작을 만든다는 뜻으로 “Determinishtic”이라고 부름. 스킬을 표준 운영 절차, 스크립트, MCP 서버와 함께 적극 활용함.
SessionMiner 는 Claude와 Kiro의 세션 종료 훅으로 실행해 수행한 작업과 스킬화 여부를 분석함. 새 스킬이나 도구가 필요하면 후속 작업 메시지를 보내고, 아니면 접근법을 기록해 장기적인 사용 패턴을 찾음. 덕분에 반복 가능한 도구와 스킬이 쌓이고 개선할 절차도 찾게 됨.
또 소통 분석 스킬 로 온라인 활동 전반에서 약속과 후속 연락을 추적하고, 내가 정한 소통 목표에 맞춰 평가함. 자폐 스펙트럼과 약물 부작용으로 치료약을 쓰지 못하는 ADHD가 있는데, 업무 추적과 마무리, 특히 신뢰할 만한 팀원이 되는 데 필수적인 지루한 일을 챙기는 데 큰 도움이 됨.
•Zambyte: agents.md에는 상위 수준의 정보를 두는 게 좋음. 복잡한 빌드 절차나 테스트 패턴까지 매 요청에 불러오는 건 비효율적일 수 있음. 스킬로 분리하면 실제 사용할 때만 컨텍스트에 포함 할 수 있음.
•gregwebs: 버전 관리부터 적용 하는 게 좋음. 개발용 스킬 저장소 https://github.com/gregwebs/skills-sdlc/ 에 심볼릭 링크 설치 스크립트를 두었고, 각 기기에서는 저장소를 최신 커밋으로 갱신하면 됨. 하나는 Bash 스크립트가 포함되어 있지만 나머지는 사실상 프롬프트임.
프로젝트 전용 스킬은 해당 저장소에 두면 잘 맞음. 각 스킬을 이해하고 PR을 검토하며 최종 결과물을 테스트해 검증함. 결과가 완벽한 경우는 드물어 스킬과 AI 활용 방식을 계속 조정함.
•ryandsilva: 잠깐의 수집기를 지나 반복 작업에 필요한 스킬만 직접 고르거나 만드는 방식 으로 줄였음. 새 스킬을 정해진 폴더에 분류하는 스킬도 만들어둠.
Discovery/ 는 문서·검색·정보 검색, Execution/ 은 절차 실행·CI/CD·출시·배포, Planning/ 은 목표·명세·티켓·위협 모델, Tools/ 는 재사용 가능한 도구 연동, Debugging/ 은 진단·수정, Expertise/ 는 향후 분야별 전문 지식용임.
skillshare 로 에이전트 간 심볼릭 링크와 GitHub 동기화를 관리하고, 외부 저장소에서 가져온 일부 스킬의 업데이트도 추적함. 몇 달마다 사용하지 않는 스킬을 삭제함.
•FailMore: vercel-labs/skills 를 기반으로 삼는 게 괜찮아 보임. 다양한 코딩 에이전트에 전역 설치를 지원하며, 내부 전용 스킬을 만들더라도 같은 기반을 쓸 것 같음. https://github.com/vercel-labs/skills 에서 확인할 수 있음.
•jve: 다른 프로젝트에서 직접 만든 스킬을 재사용할 때 플러그인으로 배포하고 Git 저장소를 마켓플레이스로 등록 하는 방식이 잘 맞았음. 여러 플랫폼에서 같은 코드베이스를 다뤄도 심볼릭 링크 차이를 신경 쓰지 않아도 됨.
Codex에서는 codex plugin marketplace add " https://path-to-my-git-repo" ; 와 codex plugin add agent-tools@mycompany , Claude에서는 claude plugin marketplace add " https://path-to-my-git-repo" ; 와 claude plugin install agent-tools@mycompany 로 설치함. 마켓플레이스용 .json 파일은 AI에게 생성시키면 됨.
업데이트는 아직 시험하지 않았지만 claude plugin marketplace update mycompany 와 claude plugin update agent-tools@mycompany 도 설치처럼 간단할 것으로 기대함.
•yokuze: dotfiles처럼 스킬을 포함한 기본 에이전트 설정을 https://github.com/yokuze/aix-config 에 커밋하고, aix 로 Claude·Codex·OpenCode에 동기화함. 도구는 https://github.com/a1st-dev/aix 에 있음.
스킬·규칙·훅·MCP 서버를 의도적으로 추가·삭제하고 버전 관리하며 공유할 수 있음. 확장 가능한 설정 덕분에 공개 설정 위에 회사 전용 규칙을 얇게 덧붙이면 됨. 한 곳에서 정의한 설정을 한 명령으로 여러 에이전트에 적용 하므로 구독을 바꿔가며 시험하기도 편함.
•veb: Claude 중심으로 작업 흐름을 만들었다가 Codex를 섞으면서 번거로워졌는데, 이 도구를 살펴볼 생각임.
•chandureddyvari: 팀 전체가 활용하도록 스킬을 Git에 커밋함. 저장소마다 구성이 다르고 최소 주 2회 갱신함. 계측 추가, 디버깅, 코딩, 코드 검토, 기술 설계 검토 등에 사용함. skills.sh는 가끔 영감을 얻으러 보지만 대부분 내게는 크게 유용하지 않음.
“X를 하는 방법”으로 표현할 수 있는 작업 이 스킬로 만들기 좋았음. 그렇게 표현하기 어렵다면 추가할 가치가 낮다고 봄. 적을수록 좋다는 원칙도 적용해 현재 9개만 유지 함.
•floriangoebel: 특수한 자체 도구와 오래된 제약이 많은 비공개 코드베이스에서 효과가 좋았음. 맞는 스킬이 있으면 도구 문서를 읽고 기존 저장소와 코딩 스타일을 익히는 학습 단계를 건너뛰고 바로 작업 할 수 있음.
학습 데이터에 흔한 코드라면 효과가 덜할 수 있음. 다만 스킬의 오류가 새 코드 전반에 퍼질 수 있으므로 스킬 저장소는 매우 신중하게 관리해야 함.
•bhkdotdev: 스킬 검증용으로 결정적 통합·행동 테스트 계층 인 https://dynobox.xyz 를 만들고 있음. 전체 평가 체계는 과할 수 있고, 내게는 특정 파일을 수정했는지 또는 건드리지 않았는지, 스킬을 실제로 읽었는지가 핵심임.
나는 Codex를 쓰지만 동료들은 Claude나 Antigravity를 쓰므로, 공유하는 스킬과 프롬프트는 여러 에이전트 실행 환경에서 검증함. 그 밖의 검사 기능도 갖추고 있음.
•maxrev17: 자체 스킬 레지스트리 를 사용함. 어느 에이전트 실행 환경에서든 동적으로 가져올 수 있고 디렉터리별로 권한 범위를 지정함. PDF 출력처럼 널리 유용한 스킬은 전역으로 허용함.
•SillyUsername: 원격 없이 로컬 Git과 지연 로딩 으로 프롬프트 사전 적재를 줄임. 프롬프트에는 Git 검색을 사용하는 스킬 검색기 하나만 넣고, 개별 스킬 요약은 미리 불러오지 않음.
에이전트별 비공개 저장소에는 운영용 main 과 draft- 브랜치를 두며, 그룹 에이전트용 공유 저장소도 같은 구조로 관리함. 적절한 스킬을 못 찾으면 실행 환경의 기본 검색 방식으로 돌아감. 월별 감사 cron이 방치된 초안과 최근 세션에서 쓰지 않은 스킬을 분류하면 삭제 여부를 결정함.
기존 스킬 폴더와 호환되고, Git과 검색기를 제거해도 원본을 훼손하지 않으면서 필요한 스킬만 불러올 수 있음.
•ssivark: 스킬이 단순 능력이 아니라 개인·프로젝트에 맞는 맥락 지침 이라면 모델 발전으로 대체되기 어려움. dotfiles처럼 중앙에서 관리하고 guix home 으로 codex, pi, antigravity, Claude Code, Deepseek 등의 스킬 폴더에 연결함.
기본 읽기 전용 대신 양방향 링크 로 구성해 어느 에이전트에서든 수정하고 추가할 수 있음. 스킬 형식은 공통이라 잘 맞지만 다른 설정은 번거로운 편임. 이런 연결과 편집 규칙 자체를 스킬 관리용 스킬로 만들 수도 있음. LaTeX 수식·cetz 도식의 본문 렌더링, jujutsu, guix, 코드 검토, 글쓰기 피드백도 유용했음.
•ssivark: killix의 댓글이 왜 신고 처리됐는지 모르겠음. 타당한 지적이며 현재 구성에서는 그 절충을 받아들이기로 함. 스킬 관리 지침으로 모든 변경을 에이전트 서명과 함께 즉시 커밋 하도록 충분히 통제할 수 있다면 양쪽 장점을 취할 수 있을지도 궁금함.
•mstr32: 프로젝트와 팀원에 걸쳐 스킬 수정을 통제 하는 데 Git만으로는 부족해서 https://github.com/genged/capshelf 를 만들었음.
새 프로젝트에서는 capshelf add security-review 로 가져오고, 새 스킬은 capshelf promote security-review 로 공용 저장소에 올려 다른 사람이 설치하게 함. 콘텐츠 해시를 고정 해 예상치 못한 수정이 작업 흐름을 깨지 않도록 하며, MCP 설정과 에이전트 설정도 지원함.
•qznc: 내부에서 계속 논의 중이고 Microsoft의 apm 을 좋아하는 이들도 있음. Microsoft 제품이고 기업용 도구다운 인상을 주기 때문일지도 모름. https://microsoft.github.io/apm/ 에서 볼 수 있음.
•jdxcode: CLI 도구별 스킬 배포 표준 을 막 작성했음. 아직 널리 쓰이지는 않지만 mise가 도구와 함께 스킬을 설치하도록 지원할 예정이라 어느 정도 확산될 것으로 기대함.
예전에는 LLM이 --help 만 쓰면 된다고 생각했지만, 여러 명령을 엮는 상위 수준 작업 흐름 을 설명하는 데 스킬이 좋다는 쪽으로 바뀜. https://jdx.dev/posts/2026-09-05-introducing-packslip/ 에 소개함.
•cowanon77: 미리 만들어진 스킬 모음보다 메타 프롬프팅 이 훨씬 유용했음. 작업 공간을 준비한 뒤 AI에게 원하는 작업용 독립 프롬프트를 만들라고 요청함. 최신 AI는 가정, 사용할 도구와 파일을 담은 긴 프롬프트를 작성해 줌. 이를 검토하고 새 컨텍스트에서 실행 함.
•meerita: 사용 중인 방식은 https://www.minid.net/2026/7/14/how-to-automatise-with-ai 에 정리했고, 소스는 https://github.com/meerita/monorepo-nextjs-golang-rust-pytho... 에 공개함.
•jameshiew: chezmoi로 dotfiles와 함께 관리 함. .agents/skills/ 를 만들고 .claude/skills/ 에서 심볼릭 링크를 걸어둠.
전역 AGENTS.md에는 작업 중 겪은 불편과 스킬·도구·AGENTS.md 개선안을 제안하라는 지침을 넣음. AGENTS.md를 작게 유지하려고 적절한 균형을 찾는 중임.
•nhod: SX https://github.com/sleuth-io/sx 를 쓰고 있으며, 자잘한 특성이 있지만 전반적으로 유용함. 그 위에 설정 조각을 합쳐 에이전트별 CLAUDE.md와 AGENTS.md를 생성하는 계층을 직접 추가함.
질문마다 답하기 쉽도록 번호 목록으로 응답하게 하는 조각, Claude 특유 문체를 억제하는 조각, 프로젝트별 조각을 조합함. 생성 파일의 길이도 점검 해 일정 크기를 넘으면 알려주게 함.
•skeledrew: 대부분 프롬프트로 직접 스킬을 만들고, 적합한 것에는 자기 개선 지침 을 넣음. 스킬이 제대로 작동하지 않으면 불필요한 도구 호출이 늘어나는 경우가 많음. 애초에 반복 작업의 여러 호출을 줄일 수 있다는 게 스킬을 만드는 계기임.
AI 관련 글의 댓글을 보면 에이전트 실행 기록을 거의 읽지 않는 듯함. 자기 개선 지침도 항상 실행되지는 않으니, 기록을 확인하지 않으면 스킬이 나아지지 않음.
•theletterf: 스킬을 저장소에 두고 격주로 문서와의 불일치를 검사하는 에이전트 작업 을 실행해 차이가 있으면 PR을 만듦. 저장소 자체가 Claude 플러그인이기도 함.
가장 큰 과제는 사용자마다 최신 스킬을 유지하는 것이어서, 여러 에이전트 실행 환경을 갱신하는 작은 Go 실행 파일을 개발함.
•mstr32: 그 실행 파일은 사용자별 스킬을 어떤 방식으로 업데이트함?
•invaliduser: 같은 프롬프트를 반복 입력하기 지겨울 때 스킬로 만들고 차츰 수정함. 현재 3개 정도로 잘 쓰고 있음. 최근에는 문서를 읽고 이해하기 어렵게 만드는 은유와 과장된 수사를 그만 쓰라고 Claude에 요청하는 수정이 대부분임. 비원어민에게만 특히 거슬리는지는 모르겠음.
•sinuhe69: 새로운 문제에서 에이전트가 고전하면 세션에서 얻은 지식과 시행착오를 스킬 파일로 정리 하게 함. 이후 검토하고 사용하는 도우미 환경에 맞춰 배포함.
에이전트가 스스로 발견한 것뿐 아니라 내 교정과 실수에서도 배우게 하는 효과적인 방식임. 특수한 분야나 문제를 다룰 때 특히 유용할 수 있음.
•mceachen: 에이전트에게 플러그인 마켓플레이스 를 만들게 하면 됨. 내 구성은 https://github.com/photostructure/coding-skills 에서 참고할 수 있음. 수정할 때 비공식 플러그인의 버전도 올려야 함. Codex 자동 업데이트는 꽤 잘 되지만 Claude는 덜 안정적이며, 둘 다 요청하면 자기 설정을 고칠 수 있음.
명시적으로 호출하는 매크로형 스킬이 더 일관되게 유용함. 세션의 90%에서 기술 프로젝트 계획 스킬을 직접 호출 하고, 모든 커밋은 스테이징 후 다른 모델의 추가 검토를 거침.
•threecheese: Codex와 Claude Code는 로컬 개발용 플러그인 심볼릭 링크 를 지원하므로 스킬 저장소를 로컬에 복제해 쓰면 됨. Codex는 기본 지원하지만 Claude는 플러그인을 캐시하려 해서 우회 계층이 필요하며, 로컬 셸 명령으로 플러그인 경로를 얻음.
내 저장소에 사용한 명세는 https://claude.ai/public/artifacts/d37077a6-2cdd-4961-b504-b... 에 있음.
•osr00: 커뮤니티 스킬은 mattpocock, mcollina, trailsofbit처럼 알려진 소수만 유지하고 새 릴리스나 관련 영상을 확인함. 직접 작성한 것은 비공개 GitHub 저장소에 둠. 주로 명령처럼 직접 호출 하므로 작동 여부를 바로 알 수 있음.
커뮤니티 스킬은 패키지 관리자가 도움이 되며 vercel-labs/skills와 withastro/rosie가 괜찮음. 직접 만든 https://github.com/osrim/ski 는 업데이트 명령과 보안 검사를 지원함.
•mrbonner: 스킬·MCP 등 프롬프트 관련 요소를 목적별로 이름을 붙인 프롬프트 로 이해하면 덜 압도됨. 객체지향에서 여러 디자인 패턴에 이름을 붙이고 책까지 쓰지만 결국 다형성을 기반으로 한다는 것과 비슷하게 느껴짐.
•imadtaieber: 조금 더 자세히 설명해줄 수 있음? 기술은 대중문화라는 Alan Kay의 말이 맞는 듯함. 계속 같은 것에 새 이름을 붙이고 있음.
•fallinditch: Claude Code를 만든 Boris가 주기적으로 스킬과 훅을 지운 뒤 없는 상태에서 모델이 어떻게 동작하는지 확인 하라고 권했다는 글을 읽은 적이 있음. 주기적으로 일부를 수정하고 줄이고 삭제하는 게 좋을 듯함.
•synergy20: 변화를 관찰하는 건 느리고 주관적임. 나는 가끔 AI 자체에 스킬을 갱신하도록 요청함.
•tstrimple: 주요 모델이나 실행 환경이 출시될 때마다 Claude Code에 전체 구성과 아키텍처를 감사하고 변경안을 제안하게 함. CLAUDE.md에 넣는 내용은 점점 줄어드는 중 임. 스킬 효과를 판단하는 검토 도구도 사용함.
•tjmaynes1: 친구들과 skulto 를 만들어 여러 프로젝트와 작업용 컴퓨터에서 스킬을 관리하고 설치함. https://github.com/asteroid-belt/skulto 에 공개함.
•woadwarrior01: Tencent가 최근 공개한 teamai-cli 도 살펴볼 만함. https://github.com/Tencent/teamai-cli 에서 확인할 수 있음.
•matheusmoreira: 직접 스킬을 만들고 다듬어서 dotfiles 저장소에 커밋 함.
•bjconlan: AI 동향에 더 밝아 조언을 구하는 예전 동료가 CUE로 스킬·프롬프트를 정형화하고 배포 함. 직접 관리하지 않아도 되는 방식 중 가장 괜찮았음. cuelang.org는 낯설었지만 용도에 잘 맞아 보임.
https://github.com/p3bot/start 는 다른 기능도 있지만, 스킬·프롬프트 관리 부분이 특히 좋았음.
•Kwpolska: 인터넷에서 쉽게 찾을 만큼 일반적이고 모델 발전으로 대체될 스킬은 쓸모없거나 해로울 수도 있음. 모델이 컨텍스트에 얼마나 집착하는지 고려하면 더욱 그럼. 유용한 스킬은 프로젝트에 특화된 작업 흐름 을 담으며, 프로젝트 저장소에서 모두가 사용하고 개선할 수 있음.
•yatsyk: 비공개·공개 Git 저장소 두 곳을 원본 기준 으로 삼음. 요청하면 에이전트가 스킬을 수정하고, 에이전트가 작성한 sync-agent-skill 스크립트로 ~/.claude/skills/ , ~/.codex/skills , ~/.pi/agent/skills , ~/.config/opencode/skills 등에 동기화함. 스크립트는 대상 위치에서 직접 수정한 내용이 없는지도 확인함.
•KerrickStaley: Codex와 Claude Code 모두` ~/.agents/skills` 를 인식 하므로 ~/.codex/skills 와 ~/.claude/skills 를 따로 둘 필요가 없음.
•r0b05: 그렇게 여러 에이전트를 사용하는 이유가 궁금함.
•blackhaj7: 여러 저장소와 앱 사이에서 스킬을 공유하는 좋은 방법이 있음? 한 곳에 저장한 스킬을 저장소, Amp, ChatGPT 데스크톱·iOS, Grok 웹 에서 쉽게 쓰고 싶은데 방법을 못 찾겠음.
•yokuze: 내 구성은 https://news.ycombinator.com/item?id=49601053 에 정리함. 다만 ChatGPT는 앱 내부의 Codex만 지원하고, 일반 ChatGPT와 Grok 웹은 아직 지원하지 않음.
한 곳에서 설정을 버전 관리 하고 프로젝트별 설정도 저장소에 커밋할 수 있어, 여러 에이전트를 지원해야 하는 팀이나 오픈소스 프로젝트에 도움이 됨. 현재 지원하는 편집기·에이전트 8종은 https://aix.a1st.dev/editors/supported-editors/ 에서 확인할 수 있음.
•devolving-dev: 스킬은 모델 능력에 빠르게 흡수된다고 봄. 프로젝트 정보는 agents.md에, 까다로운 코드에는 필요한 주석을 남기고 나머지는 기본 Codex 그대로 사용함.
•c0n5pir4cy: 스킬의 이점은 지식이나 맥락을 매번 프롬프트에 넣지 않고 필요할 때 제공 하는 데도 있음. 모델 능력 확장뿐 아니라 개인 취향, 작업 흐름, 조직 지식, 효율 개선을 담을 수 있음. 에이전트가 스스로 알아낼 수 있어도 문서를 찾아보는 편이 훨씬 효율적임.
데이터베이스 구조와 특이사항, 브랜드 문서 서식, 외부 문서 문체, 시스템 절차, 규정 준수 요구사항 등에 사용함. 매번 불러오기는 싫지만 필요할 때 호출할 수 있어 유용함.
•mark_l_watson: Mac 2대와 VPS 1대, 그리고 빠른 추론 API와 아주 느린 로컬 모델 사이에서 스킬을 관리함. 기기 간에는 검증한 파일을 iCloud에 두고 필요한 곳으로 복사하면 됨.
시간을 많이 쓰는 쪽은 모델 속도에 맞춘 스킬 길이 조정 임. 빠른 API에는 짧은 파일, 느린 로컬 모델에는 극도로 짧은 파일을 쓰며 계속 다듬음. 모델이 좋아질수록 스킬의 비중은 줄겠지만 완전히 무의미해지지는 않을 것임.
•imadtaieber: 나도 스킬 갱신에 시간을 많이 쓰지만 시스템 설계 수준의 작업 이라 낭비라고 보지 않음. 나 자신을 자동화하는 방법임.