이전에 Metadata API Context Skill을 조사했을 때, forcedotcom/sf-skills라는 리포지토리를 스킬 하나만 살펴보고 끝낸 적이 있습니다.

나중에 "애초에 이 리포지토리에는 다른 어떤 스킬들이 들어있을까"라는 궁금증이 생겨서, 이번에는 리포지토리 전체를 가볍게 훑어보고 정리해 보려 합니다.

개별 스킬의 사용법을 깊게 파고드는 것이 아니라, "어떤 입도로", "어떤 영역에" 스킬이 준비되어 있는지에 대한 지도를 만드는 것이 목적입니다.

※ 본 기사는 개인적인 정리 메모입니다. 수치 및 구성은 모두 2026-08-04 시점의 forcedotcom/sf-skills 리포지토리(커밋 fe3e2ed, 릴리스 1.33.0, 2026-07-31)를 실제로 가져와서 계산한 것입니다. README 자체에서 "빈번하게 변경된다"라고 명시하고 있는 리포지토리이므로, 읽을 때는 반드시 실물을 확인하시기 바랍니다.

• forcedotcom/sf-skills 리포지토리의 전체 구성 - 112개의 스킬이 어떤 도메인으로 나뉘어 있는지

• 스킬 이름의 명명 규칙 (도메인 × 대상 × 동사)

• SKILL.md의 frontmatter에 무엇이 적혀 있는지 - 도입 방법과 설치 대상 디렉토리

• 사용 전에 알아두어야 할 주의사항

• 개별 스킬을 실제로 운영 조직(Production Org)에 적용한 검증 결과

• Agentforce Vibes의 계약 조건 및 라이선스 비용 상세

• "이 스킬을 넣으면 개발이 빨라진다"라는 효과 측정

• 스킬의 내용(프롬프트 설계)의 좋고 나쁨에 대한 평가

계산 방법은 간단합니다. 리포지토리를 얕게 클론(clone)하여 skills/ 하위의 디렉토리와 SKILL.md를 집계했을 뿐입니다. 특별한 도구는 사용하지 않았습니다.

먼저 결론을 쓰자면, sf-skills는 다음과 같이 파악하면 정리하기 쉽다고 느꼈습니다.

개인적으로 가장 큰 발견은, 카테고리용 디렉토리가 존재하지 않는다는 점이었습니다. skills/ 바로 아래에 112개가 플랫(flat)하게 나열되어 있으며, 분류는 모두 "이름의 앞부분"으로 표현되어 있습니다.

README에 적혀 있는 구성은 다음과 같습니다.

sf-skills/
├── skills/ # 디렉토리 단위의 실행 가능한 워크플로우
│ ├── platform-apex-generate/
...

실제로 가져와서 세어보니, skills/ 하위의 내역은 다음과 같았습니다.

README에서는 각 스킬의 디렉토리 구성이 다음과 같이 설명되어 있습니다.

• SKILL.md (필수): 지시 내용과 YAML frontmatter
• scripts/ (선택 사항): 실행 가능한 스크립트 (Python, Bash, JavaScript 등)
• references/ (선택 사항): 추가 참조 문서
• assets/ (선택 사항): 템플릿, 스키마, 룩업 데이터

참고로 examples/는 README 목록에는 나오지 않지만, 27개의 스킬이 실제로 가지고 있습니다. "선택 디렉토리는 이 세 가지만 가능하다"라는 제약은 아닌 것 같습니다.

samples/

는 스킬이 아니라, npm 패키지(@salesforce/ui-bundle-template-app-react-sample-b2e 등)로부터 매일 밤 GitHub Actions를 통해 동기화되는 React 샘플 앱 저장소입니다. 버전이 변경될 때만 PR(Pull Request)이 생성되는 구조로 되어 있습니다.

112개 스킬의 이름을 나열하면, 거의 예외 없이 다음과 같은 형식을 따르고 있습니다.

<도메인> - <대상> - <동사>
platform - apex - generate
platform - metadata-api-context - get
...

끝에 오는 동사를 세어보면 상위 항목은 다음과 같습니다.

'생성'과 '설정'이 58개 스킬로 전체의 절반 이상을 차지합니다. 역설적으로 말하면, **sf-skills는 '생성과 설정을 자동화하기 위한 도구 상자'**라는 성격이 강합니다.

명명 규칙(Naming Rule)은 리포지토리 내의 검증 스크립트 scripts/validate-skills.ts를 통해 기계적으로 체크됩니다. 스크립트를 읽어보면 다음과 같은 제약 사항을 알 수 있습니다.

• 이름은 kebab-case(소문자, 숫자, 하이픈만 사용)여야 함
• 이름은 64자 이내여야 함
• skills/ 바로 아래의 1계층 디렉토리만 허용 (카테고리용 서브 디렉토리를 만들 수 없음)
• 디렉토리 이름과 frontmatter의 name이 일치해야 함

이 스크립트는 npm run validate:skills로 실행할 수 있으며, GitHub Actions의 pull_request 트리거를 통해 자동으로 실행됩니다. 변경된 스킬만 검증하는 --changed --base=origin/main 모드도 있습니다.

여담이지만, 이 검증기(Validator)에는 "이름의 첫 단어는 -ing로 끝나는 동명사 형태여야 한다 (예: generating-apex-tests)"라는 체크 항목도 포함되어 있습니다. 다만 중요도가 warning 수준으로 처리되어 있으며, 코드 내에도 "경고는 표시되지만 종료 코드(Exit Code)는 0으로 유지된다"라고 적혀 있습니다. sf-skills의 112개 스킬은 모두 도메인 이름으로 시작하기 때문에, 이 경고는 모든 항목에서 발생한다는 전제하에 운영되고 있는 것으로 보입니다. 이는 Agent Skills 일반의 권장 사항과 Salesforce 측의 사정(도메인별로 정렬하고 싶어 함)이 충돌한 흔적으로 읽힙니다.

이름의 앞부분을 기준으로 분류하면 14개의 도메인이 됩니다.

훑어보면서 흥미로웠던 점 몇 가지.

Apex (생성 · 테스트 생성 · 테스트 실행 · 로그 디버깅의 4분할), 커스텀 오브젝트 (Custom Object) / 항목 (Field) / 탭 (Tab) / 애플리케이션 (Application), 권한 세트 (Permission Set), 공유 설정 (OWD와 공유 규칙으로 별도 스킬 구분), 입력 규칙 (Validation Rule), 리포트 (Report), SOQL…… 등, Salesforce 개발에서 일상적으로 다루는 대상이 거의 하나씩 스킬로 되어 있습니다.

1스킬 1태스크의 입도가 상당히 세밀하다는 것이 특징으로, 예를 들어 Apex는 「작성하기」, 「테스트 작성하기」, 「테스트 실행하기」, 「로그 보기」로 4개의 스킬로 나뉘어 있습니다.

17개 스킬 중 12개가 experience-ui-bundle-* 입니다. 프로젝트 생성, 프론트엔드 생성, 메타데이터 생성, 배포 (Deploy), MFA 설정, 파일 업로드, Salesforce 데이터 액세스…… 등, UI bundle의 공정별로 나뉘어 있습니다.

Multi-Framework GA (Salesforce에서 React 앱을 구동) 맥락과 이어지는 영역이며, 공정별로 스킬을 나눌 정도로 공을 들이고 있다는 것을 알 수 있습니다.

automation-flow-generate (Flow 생성)는 1개 스킬뿐이지만, description에는 「This is the only skill for Salesforce Flow generation.」라고 명시되어 있습니다. 수가 적다고 해서 반드시 미흡하다는 뜻은 아닌 듯합니다.

스킬의 실체는 SKILL.md 한 장입니다. 상단에 YAML frontmatter가 있고, 그 아래가 AI를 위한 지시 본문이 됩니다.

실제 예시 (platform-apex-generate)를 짧게 줄이면 다음과 같은 형태입니다.

---
name: platform-apex-generate
description: "Primary Apex authoring skill for class generation, refactoring, and review.
...

112개 스킬분의 frontmatter를 집계하면 사용된 키는 다음과 같았습니다.

description 작성 방식에는 검증기 (Validator)를 통해 상당히 세밀한 제약이 걸려 있습니다.

• 큰따옴표로 감쌀 것
• 20단어 이상 (정보량 확보를 위해)
• 1,024자 이내
• 소문자로 변환했을 때 use를 포함할 것 (= 발동 조건을 작성하게 하기 위함)

실제 분포를 측정해 보면, 112개 스킬의 description은 중앙값 710자, 최대 1,023자 (상한선에 육박)였습니다. 일본어 감각으로 보면 '설명문'이라기보다, **AI에게 언제 발동해야 하는지를 가르치는 작은 프롬프트 (Prompt)**에 가깝습니다.

본문의 길이는 중앙값 207행, 최대 623행입니다. 검증기는 500행을 초과하면 경고를 내보내지만 (이 역시 경고 수준에 그침), 이를 초과한 것은 3개 스킬뿐이었습니다.

metadata.minApiVersion 값은 67.0이 13개 스킬로 가장 많았으며, 오래된 것은 47.0도 있었습니다. 이는 해당 스킬이 전제로 하는 최소 API 버전을 나타냅니다. 프로젝트의 sourceApiVersion이나 이용하는 API/메타데이터 버전과의 정합성을 확인하는 것이 좋아 보입니다.

훑어보면서 가장 "잘 만들었다"고 느낀 점은, 발동 조건뿐만 아니라 발동하지 않는 조건이 description에 적혀 있다는 점입니다.

112개 스킬 중,

• TRIGGER when:을 포함하는 것: 70개 스킬
• DO NOT TRIGGER를 포함하는 것: 72개 스킬
• 다른 스킬의 이름을 description 안에서 직접 언급하는 것: 81개 스킬

예를 들어 experience-lwc-generate는 다음과 같이 작성되어 있습니다.

TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html, 
.css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. 
DO NOT TRIGGER when: Apex classes (use platform-apex-generate), Aura components, 
...

data360-query 역시 마찬가지로 "표준 CRM SOQL이라면 platform-soql-query를 사용해라", "세그먼트 설계라면 data360-segment를 사용해라"라며 옆에 있는 스킬로 명시적으로 넘겨주고 있습니다.

112개 스킬을 전부 넣으면 AI 입장에서는 "비슷한 이름의 도구가 112개 나열되어 있는" 상태가 됩니다. 그래서 오작동(False Positive)을 방지하기 위해, 각 스킬이 자신의 경계선을 스스로 신고하고 있는 것입니다.

나아가 metadata.relatedSkills를 선언한 스킬이 35개 있었으며, 평균 4.7개, 최대 37개의 관련 스킬을 열거하고 있었습니다. 스킬들끼리 느슨하게 그래프 (Graph)를 형성하고 있다고 이해하면 쉽습니다.

직접 스킬을 작성할 때도, 이 "DO NOT TRIGGER를 작성하기", "옆에 있는 스킬 이름을 직접 언급하기"는 본받고 싶은 작성 방식이었습니다.

스킬 수만 보면 112개로 나란히 있는 것처럼 보이지만, 내용물의 크기는 전혀 균일하지 않습니다. 파일 수가 많은 순서대로 나열하면 다음과 같습니다.

상위 2개가 전체 4,100개 파일의 약 3분의 2를 차지하고 있습니다. 이 두 가지는 "AI에게 전달할 참조 데이터 그 자체"를 담고 있는 스킬로, platform-metadata-api-context-get은 604개의 Metadata API 타입 JSON을 보유하고 있습니다 (이 스킬에 대해서는 지난 기사에서 정리했습니다).

반면, 중앙값은 6개 파일입니다. 많은 스킬이 SKILL.md에 몇 개의 references/가 붙는 정도입니다.

즉, sf-skills에는 성격이 다른 두 종류가 섞여 있습니다.

자료고형은 "전부를 읽히지 않는다"는 것을 전제로 설계되어 있으므로, 다룰 때 주의가 필요합니다.

README에 적혀 있는 도입 방법은 두 가지입니다.

이 skills 커맨드는 Salesforce 제품이 아니라, Agent Skills 에코시스템의 공통 CLI (npm 패키지 skills / vercel-labs/skills)입니다. 설치 위치는 에이전트마다 정해져 있으며, README의 대응표에서 발췌하면 다음과 같습니다.

갑자기 112개를 전부 넣을 필요는 없으며, 다음과 같이 압축할 수 있습니다.

# 무엇이 들어있는지만 확인 (설치하지 않음)
npx skills add forcedotcom/sf-skills --list
# 필요한 스킬만 설치
...

압축 사용을 권장하는 데에는 이유가 있는데, 스킬의 description(설명)은 항상 컨텍스트(Context)에 포함되기 때문입니다. 112개 스킬 분량의 description을 합치면 약 78,000자였습니다. 영어이므로 단순 계산으로도 2만 토큰 전후의 상설 비용이 발생합니다 (실제 소비량은 도구의 읽기 방식이나 토크나이저(Tokenizer)에 따라 다르므로, 참고용으로만 생각하세요).

Apex만 다루는 프로젝트에 OmniStudio와 Commerce, Mobile 스킬을 상주시키는 것은 의미가 적으므로, 우선 --list로 살펴본 뒤 필요한 영역만 넣는 것이 다루기 편하다고 느꼈습니다.

README의 서두에 경고가 있습니다.

잦은 변경이 예상됩니다. Salesforce 스킬 라이브러리는 패턴을 정교화하고 피드백을 반영함에 따라 빠르게 진화하고 있습니다. 스킬은 릴리스 사이에 이름이 변경되거나, 구조가 재편되거나, 삭제될 수 있습니다. 즉, GA (General Availability) 플랫폼 API와 동일한 안정성 보장을 따르지 않습니다.

스킬 이름을 매뉴얼이나 사내 문서에 직접 적어두면, 이름 변경 시 동작이 깨지게 됩니다. 본 기사의 '112'라는 숫자도 읽고 계신 시점에는 바뀌어 있을 가능성이 높습니다.

compatibility

필드를 가진 14개의 스킬은 추가적인 전제 조건이 필요합니다. 예를 들면 다음과 같습니다.

• data360-query: "외부 커뮤니티 제작 sf data360 CLI 플러그인과 Data Cloud가 활성화된 조직이 필요"
• commerce-b2b-store-create: "Commerce 라이선스, Experience Cloud, Salesforce CLI가 필요"

또한 metadata.cliTools를 선언하고 있는 41개의 스킬은 sf (>=2.139.6 등), jq, python3, curl과 같은 도구의 버전 요구 사항을 가지고 있습니다. 단순히 설치만 해서는 작동하지 않는 스킬이 있다는 전제로 보는 것이 좋아 보입니다.

automation-flow-generate의 description은 "Generate Salesforce Flows using the MCP tool execute_metadata_action"로 시작합니다. metadata.mcpTools를 선언하고 있는 스킬도 4개가 있습니다.

스킬만 넣는다고 해서 MCP 서버 측이 설정되어 있지 않으면 기대한 대로 작동하지 않으므로, 스킬과 MCP는 세트로 보아야 합니다.

이 부분은 실무에서 판단이 필요할 것 같아 적어둡니다.

CC-BY-NC-4.0은 비영리 라이선스이므로, Apache-2.0과는 조건이 상당히 다릅니다. 동일한 리포지토리 안에 두 가지가 모두 존재하는 상태입니다.

어느 표기가 어떤 배포물이나 이용 형태에 적용되는지는 이 두 파일만으로는 단정할 수 없습니다. 스킬을 포크(Fork)하여 재배포하거나, 내용을 제품 또는 사내 자산에 포함시키는 경우에는 리포지토리 관리자에게 확인하거나 법무 검토를 거치는 것이 안전합니다 (본 기사는 법적 조언이 아닙니다).

platform-apex-generate와 같이 정적 분석 (Code Analyzer) 및 테스트 실행까지 절차에 포함하고 있는 스킬도 있지만, 그럼에도 조직 고유의 설정, 라이선스, 의존 기능까지 스킬 측에서 파악할 수는 없습니다.

배포 전의 sf project deploy validate와 차이점 리뷰 (diff review)는 기존처럼 남겨두어야 할 작업이라고 생각하는 것이 무난합니다.

sf-skills를 대략적으로 살펴보고 알게 된 점을 3가지로 요약하면 다음과 같습니다.

• 평면적인 112개의 스킬, 분류는 이름의 접두사로 표현됨. 카테고리 디렉토리는 없으며, platform-, experience-, dx- 등의 프리픽스(Prefix)가 실질적인 도메인 역할을 합니다. platform-*만으로 38개의 스킬을 보유한 최대 세력입니다.
• 입도가 세밀하며, 스킬끼리 서로 양보하는 설계. Apex만으로 4개의 스킬로 나뉘어 있고, 72개의 스킬이 DO NOT TRIGGER를 명시하며, 81개의 스킬이 옆의 스킬을 직접 지칭하고 있습니다. 112개가 나열되어도 오작동(False trigger)하지 않기 위한 고안으로 읽힙니다.
• 전부 넣는 것을 전제로 한 도구 상자가 아님. description의 총합은 약 78,000자이며, 항상 컨텍스트(Context)에 올라가게 됩니다. --list와 --skill을 사용하여 필요한 영역만 넣는 것이 다루기 쉽습니다.

「Salesforce 개발의 어떤 부분이 AI에게 맡길 수 있는 범위로 정리되어 있는가」를 알 수 있는 자료로서, 이 목록은 꽤 흥미로운 읽을거리였습니다. 다음에는 platform-apex-generate 정도를 실제로 구동하여, 절차서(Procedure)형 스킬의 내용을 따라가 보려고 합니다.

• Salesforce Skills Library | GitHub

https://github.com/forcedotcom/sf-skills - Salesforce Skills Library README

https://github.com/forcedotcom/sf-skills/blob/main/README.md - 스킬 검증 스크립트 (Skill validation script)
scripts/validate-skills.ts

| GitHub

https://github.com/forcedotcom/sf-skills/blob/main/scripts/validate-skills.ts - Metadata API Context Get Skill | GitHub

https://github.com/forcedotcom/sf-skills/tree/main/skills/platform-metadata-api-context-get - skills CLI (Agent Skills 에코시스템의 공통 CLI) | GitHub

https://github.com/vercel-labs/skills - Agent Skills specification

https://agentskills.io/ - Build Smarter with Metadata API Context Skills | Salesforce Developers Blog