🌍

Skill visibility와 업데이트

2026년 7월 기준. 제품과 CLI의 경로·옵션은 이후 변경될 수 있다.

에이전트에 스킬을 추가하는 일은 쉽다. 반복해서 설명하던 코드 리뷰 기준, 문서 작성 방식, 배포 절차, 디자인 시스템 사용법을 SKILL.md에 적고 에이전트가 읽는 디렉토리에 두면 된다. 스킬 생성기를 사용하면 디렉토리 구조와 frontmatter까지 자동으로 만들 수 있고, 다른 사람이 공개한 스킬은 명령 한 줄로 설치할 수도 있다. 한 번 만들어 두면 매번 같은 프롬프트를 다시 작성하지 않아도 되므로, 스킬을 만드는 비용에 비해 얻는 편익은 크다.

문제는 설치된 스킬이 많아질수록 에이전트가 관측해야 하는 스킬의 표면도 함께 커진다는 점이다. 물론, Agent Skills는 progressive disclosure 방식으로 동작한다. 에이전트가 세션을 시작할 때 모든 SKILL.md의 본문과 부속 파일을 한꺼번에 읽는 것이 아니라, 우선 각 스킬의 이름과 설명 같은 metadata를 보고 현재 작업과 관련 있는 스킬을 고른다. 선택된 뒤에야 해당 SKILL.md의 본문을 읽고, scripts/, references/, assets/ 같은 부속 리소스는 실제로 필요할 때 추가로 연다(ref2).

하지만 그럼에도 불구하고 초기 목록조차 비용을 가진다. 모델이 적절한 스킬을 고르려면 최소한 어떤 스킬들이 존재하는지, 각각이 언제 쓰이는지를 나타내는 정보가 컨텍스트에 들어가야 한다. 실제로 Codex는 사용 가능한 스킬의 초기 목록이 모델 컨텍스트 윈도우의 2%, 컨텍스트 크기를 알 수 없을 때는 8,000자를 넘지 않도록 제한한다(ref3). 생각보다 그 한도에 금방 다다른다.

스킬을 직접 만드는 비용이 낮다는 사실뿐 아니라, Figma나 Hyperframes 같은 특정 제품·프레임워크를 지원하는 기능 하나를 추가한다고 생각할 수 있지만, 실제 패키지 안에는 서로 다른 역할의 스킬이 함께 들어 있기 때문에 관측 가능한 skill surface가 금방 불어나기 때문이다. 그래서 이 글에서는 스킬의 visibility에 대해 다룬다.

하지만 visibility를 다룰 땐 업데이트 문제도 함께 다루어야 한다. 스킬의 visibility는 스킬이 물리적/논리적으로 어디에 위치해 있는가로 결정되는 경우가 많은데, 위치 이동에 따라 업데이트의 책임이 달라지기 때문이다. 실제로 사용자가 스킬을 바라보는 적절 사용 범위는 시간이 지나면서 달라진다. 처음에는 어느 디렉토리에서 에이전트를 실행하든 보이도록 홈 디렉토리 아래에 두었지만, 실제로 사용해 보니 특정 repository에서만 필요한 스킬일 수 있다. 반대로 한 프로젝트를 위해 만들었던 스킬이 다른 프로젝트에서도 계속 쓰이면서 어디에서나 보이는 위치로 옮길 가치가 생길 수도 있다.

이렇게 스킬 visibility는 최초 설치 때 한 번 결정하고 끝나는 속성이 아니다. 스킬을 만들고, 사용하고, 범위를 좁히거나 넓히고, 필요하면 숨기는 과정이 계속된다. 그런데 스킬의 물리적 위치를 바꾸면 에이전트가 그것을 발견하는 범위는 즉시 달라지는 반면, 그 스킬을 설치하고 업데이트하던 도구가 같은 이동을 자동으로 이해하는 것은 아니다. 파일은 새 위치에서 잘 보이는데 updater의 lockfile은 예전 프로젝트에 남아 있거나, plugin manager는 여전히 기존 bundle version을 설치 상태로 기억할 수 있다.

그래서 이 글에서 다루려는 것은 어디에서(visibility), 어떻게 업데이트하냐(update R&R)다.

Agent Skills 표준

여기서 말하는 스킬은 모델이 가진 능력을 일반적으로 부르는 표현이 아니라, SKILL.md를 중심으로 instructions, scripts, references, assets를 묶는 파일 기반 형식을 뜻한다. 이 형식은 Anthropic이 2025년 10월 16일 Claude의 Skills 기능으로 먼저 공개했다. Anthropic은 같은 해 12월 18일 이를 cross-platform portability를 위한 공개 표준인 Agent Skills로 발표했다(ref1). Claude 안에서 시작한 workflow packaging 형식을 특정 제품에만 묶어두지 않고, 다른 agent host도 같은 디렉토리 구조와 metadata contract를 읽을 수 있게 하려는 흐름이었다. OpenAI의 Codex 문서 역시 현재의 skill 기능이 이 open Agent Skills standard를 기반으로 한다고 설명한다(ref3).

표준화의 대상은 단일 스킬과 artifact의 형식이다. 최소한 SKILL.md를 가진 디렉토리라는 점, SKILL.md 앞부분에 이름과 설명 같은 metadata가 있다는 점, 필요에 따라 실행 코드와 참고 자료를 함께 묶을 수 있다는 점, 그리고 metadata에서 instructions와 resources로 점진적으로 내용을 공개한다는 점이 공통 계약이 된다. 스킬 하나의 전형적인 구조는 다음과 같다.

my-skill/
├── SKILL.md          # 필수: metadata와 instructions
├── scripts/          # 선택: 실행 가능한 코드
├── references/       # 선택: 상세 문서와 참고 자료
├── assets/           # 선택: 템플릿과 정적 리소스
└── ...
Plain Text
복사

SKILL.md는 YAML frontmatter와 Markdown 본문으로 구성된다. name은 스킬의 식별자이고, description은 에이전트가 이 스킬을 언제 후보로 올릴지 판단하는 핵심 metadata다. 본문에는 실제 작업 절차를 적는다. 길고 세부적인 문서는 references/로, 결정적으로 실행돼야 하는 작업은 scripts/로 분리할 수 있다. 이 구조 덕분에 에이전트는 처음에는 작은 metadata만 보고, 선택된 스킬에 대해서만 더 많은 내용을 읽는다(ref2).

반면 어떤 디렉토리를 검색할지, 동일한 이름의 스킬이 겹쳤을 때 무엇을 우선할지, 사용자가 어떤 방식으로 스킬을 끄고 켤지는 각 agent host가 정한다(ref2). Agent Skills가 공개 표준이라고 해서 모든 도구가 동일한 설치 경로와 동일한 scope hierarchy를 사용한다는 뜻은 아니다.

이제 스킬 관리에서 서로 다른 세 가지를 분리해 볼 수 있다. 첫째, SKILL.md와 부속 파일로 구성된 artifact가 있다. 둘째, 에이전트가 어느 작업 범위에서 그 artifact를 발견할지 정하는 visibility scope가 있다. 셋째, artifact가 어디에서 왔고 누가 어떤 버전을 다시 가져올지 정하는 installation and update mechanism이 있다. 같은 artifact도 다른 디렉토리로 옮기면 scope가 달라질 수 있고, 같은 디렉토리에 있는 artifact도 copy, Git clone, installer, plugin 가운데 무엇으로 가져왔는지에 따라 업데이트 책임이 달라진다.

파일이 놓인 곳이 visibility를 결정한다

추상적으로 보면 홈 디렉토리 아래의 agent 전용 skill path에 놓인 스킬은 사용자의 모든 작업 공간에서 보이고, repository 내부의 agent 전용 skill path에 놓인 스킬은 그 repository에서만 보인다. 다만 실제 경로와 공식 명칭은 제품마다 다르다.

Claude Code는 다음 위치를 사용한다.

Personal
~/.claude/skills/<skill-name>/SKILL.md

Project
<repo>/.claude/skills/<skill-name>/SKILL.md
Plain Text
복사

Claude Code에서 personal skill은 해당 사용자의 모든 프로젝트에 적용되고, project skill은 해당 프로젝트에서만 적용된다. Claude Code 문서가 이를 가장 간결하게 표현하는 문장은 “스킬을 어디에 저장하느냐가 누가 사용할 수 있는지를 결정한다”는 것이다(ref4).

Codex는 repository와 사용자 범위에서 .agents/skills를 사용한다.

Repository
<repo>/.agents/skills/<skill-name>/SKILL.md

User
$HOME/.agents/skills/<skill-name>/SKILL.md

Admin
/etc/codex/skills/<skill-name>/SKILL.md
Plain Text
복사

Codex는 현재 working directory에서 repository root까지 올라가며 각 단계의 .agents/skills를 검색한다(ref3). 따라서 repository root에는 전체 코드베이스에 필요한 스킬을 두고, 특정 microservice나 package 가까이에는 그 영역에만 필요한 스킬을 둘 수 있다. User 위치의 스킬은 모든 repository에서 보이고, Admin 위치의 스킬은 같은 머신이나 container의 사용자에게 제공된다. OpenAI가 Codex에 함께 배포한 스킬은 별도의 System 범위로 취급된다.

<agent>/skills라는 표기는 이런 제품별 경로를 한꺼번에 설명할 때 쓰는 추상 표현이다. Claude Code에서는 <agent>가 .claude에, Codex에서는 .agents에 대응한다. .agents/skills는 Codex가 공식적으로 채택했고 여러 범용 installer가 공통 위치로 활용하는 비교적 vendor-neutral한 관례다. 그러나 Agent Skills 표준 자체가 모든 host에 .agents/skills 사용을 강제하는 것은 아니다. 표준은 artifact contract를 정의하고, discovery path는 host가 정한다.

Project skill은 일반적으로 repository에 커밋해 협업자와 공유한다.

모든 스킬을 repo root에 모을 필요도 없다. Claude Code는 작업 중 접근하는 하위 디렉토리의 .claude/skills도 발견할 수 있다(ref4). Codex는 launch한 working directory에서 repository root까지 .agents/skills를 검색한다(ref3). 따라서 root에는 공통 release workflow를 두고, apps/web에는 frontend 배포 스킬을, services/api에는 database migration 스킬을 두는 식으로 skill surface를 작업 영역에 맞춰 좁힐 수 있다.

물론 Visibility 관리가 항상 위치 기반인 것은 아니다. Claude Code는 skillOverrides를 제공한다(ref4). 사용자별 project 설정인 .claude/settings.local.json에 name-only, user-invocable-only, off 같은 상태를 기록할 수 있다. Codex는 관련 설정을 config.toml을 이용하는 방식을 곧 추가할 것으로 보이며, 아직 이 기능은 추가되지 않았다(ref3).

설치 방식이 update R&R을 결정한다

스킬 파일이 어디에 있는지만 보고는 그것을 어떻게 업데이트해야 하는지 알 수 없다. 에이전트는 현재 존재하는 SKILL.md를 읽으면 되지만, updater는 이 파일이 어느 source의 어느 하위 경로에서 왔는지, 어떤 ref를 사용했는지, 마지막 설치 이후 내용이 바뀌었는지를 알아야 한다.

가장 단순한 방식은 디렉토리를 직접 복사하는 것이다. ZIP을 풀어 넣거나 다른 프로젝트의 skill folder를 복사해왔다면, 에이전트는 곧바로 그것을 읽을 수 있다. 그러나 별도의 metadata를 남기지 않았다면 원본 source와 version을 자동으로 복원할 방법은 없다. 새 버전이 나오면 사용자가 다시 내려받아 덮어쓰거나 직접 diff를 적용해야 한다. 이때 updater는 사용자 자신이다.

Git repository를 직접 clone한 경우에는 .git에 Remote URL, branch, tag와 commit history가 남아 있으므로 사용자는 해당 clone에서 git pull할 수 있다. 스킬을 다른 위치로 옮겨도 이를 포함한 디렉토리 전체를 그대로 옮겼다면 Git metadata는 함께 따라간다.

npx skills add는 기본적으로 현재 project에 설치하며 -g를 사용하면 home-wide global 범위에 설치한다. Interactive install에서는 하나의 canonical copy를 여러 agent 경로에 symlink하는 방식과, 각 경로에 독립 사본을 두는 copy 방식을 선택할 수 있다(ref6).

Project 범위로 설치하면 명령을 실행한 working directory에 skills-lock.json이 만들어진다.

<project>/
├── skills-lock.json
├── .claude/
│   └── skills/
└── .agents/
    └── skills/‎
Plain Text
복사

이 lockfile의 각 entry에는 source, source type, ref, 원본 repository 안의 skillPath, 설치된 폴더 내용의 hash 등이 들어간다(ref7). 여기서 skillPath는 현재 프로젝트 내 경로를 뜻하는 것이 아니라, source repository 안에서 해당 SKILL.md가 있었던 경로를 뜻한다. 보통 하나의 저장소에 다수의 스킬들을 묶어 보관하므로, Updater는 이 정보를 이용해 같은 source에서 해당 스킬만 다시 가져오고, hash를 비교해 변경 여부를 판단한다.

npx skills update 명령으로는 스킬들을 일괄 업데이트할 수 있다. 과거에 스킬을 설치한 모든 프로젝트를 컴퓨터 전체에서 찾아다닌다는 뜻은 아니다. 옵션 없이 실행하면 현재 repo의 Project 스킬, Global 스킬, Both 중 하나를 고르는 prompt가 나오고, -p는 현재 디렉토리의 project 스킬만, -g는 global 스킬만 대상으로 한다(ref6). -y는 --yes의 약자로 scope prompt를 생략하며, 현재 디렉토리에 skills-lock.json이 있거나 .agents/skills 아래에서 스킬을 발견하면 project를, 그렇지 않으면 global을 선택한다(ref8).

# 대화형으로 Project / Global / Both 선택
npx skills update

# 현재 working directory의 project 스킬만
npx skills update -p

# 사용자의 global 스킬만
npx skills update -g

# 질문을 생략하고 현재 위치를 기준으로 자동 판별
npx skills update -y
Bash
복사

npx skills로 설치한 스킬을 단일 스킬만 옮기면 project lockfile의 source 정보는 그 부모 디렉토리에 남는다. installer가 그 이동을 기록하지 않았으므로, 다음 update 때 원래의 agent target을 다시 만들거나 중복 사본을 남길 수 있다. 따라서 installer로 관리되는 스킬의 project나 scope를 바꿀 때는 폴더만 이동하기보다 기존 범위에서 remove한 뒤 새 범위에서 다시 add하는 편이 안전하다.

그리고 Plugin

Plugin은 plain skill의 또 다른 scope가 아니라, 하나 이상의 스킬과 관련 구성요소를 한 번에 배포하는 package다. 하나의 plugin에는 여러 skill, hook, subagent, MCP server 설정, app 또는 connector mapping, assets 등이 함께 들어갈 수 있다(ref9, ref11). 따라서 plain skill에서는 skill directory 하나가 관리 단위지만, plugin에서는 manifest가 정의하는 복수 개의 스킬, bundle 전체가 설치와 업데이트의 단위가 된다. OpenAI 문서가 local filesystem skill과 plugin-packaged skill을 서로 다른 lifecycle과 access control을 가진 배포 경로로 구분하는 이유도 여기에 있다.

이렇게 bundle 단위로 갱신하는 이유는 구성요소 사이의 호환성 때문이다. 어떤 skill이 특정 MCP tool 이름과 parameter를 전제로 하고, 같은 plugin의 MCP configuration이 그 tool을 제공하며, hook이 실행 전후 검증을 담당할 수 있다. Skill만 최신 상태이고 나머지가 이전 version이라면 workflow 전체가 깨질 수 있다. Plugin version은 함께 검증된 component set의 경계가 된다.

Claude Code의 marketplace plugin은 user, project, local, managed installation scope를 지원한다(ref9). 여기서 project와 local은 실제 plugin bundle을 repository의 .claude/skills에 풀어놓는 방식이 아니다. 실제 bundle은 repo와 독립적인 plugin cache 디렉토리에서 관리되고 user 또는 project의 settings.json에서 visibility를 설정한다.

OpenAI 쪽에서도 Plugin은 manifest와 함께 cache에 설치되고, 내부 스킬은 계속 bundle component로 남는다. 파일을 옮기는 것만으로 workspace ownership, plugin installation state, app authorization이 함께 이전되지는 않는다(ref12).

부록1. Marketplace

Marketplace는 plugin 자체가 아니라 설치 가능한 plugin의 목록과 source, 표시 정보, 설치 정책을 기술한 catalog다. Marketplace를 추가하는 행위와 plugin을 설치하는 행위는 분리된다. 먼저 catalog source를 등록해 어떤 plugin이 있는지 탐색할 수 있게 하고, 그다음 목록에서 필요한 plugin을 개별적으로 설치한다. Claude Code 문서도 marketplace 추가 시점에는 아직 어떤 plugin도 설치되지 않는다고 명시한다(ref10).

OpenAI 환경의 marketplace는 JSON으로 표현된다. Repository 전용 catalog는 다음 위치에 둘 수 있다.

<repo>/.agents/plugins/marketplace.json
Plain Text
복사

Catalog와 plugin source를 같은 repository에서 함께 관리할 수도 있다.

<repo>/
├── .agents/
│   └── plugins/
│       └── marketplace.json
└── plugins/
    ├── deploy-helper/
    └── code-reviewer/
Plain Text
복사

여기서 <repo>/plugins는 이해하기 쉬운 관례일 뿐 고정된 표준 경로는 아니다. marketplace.json의 각 entry가 marketplace root를 기준으로 source.path를 지정하므로 ./tools/plugins/deploy-helper처럼 다른 위치를 사용할 수 있다. Repository marketplace는 project를 clone한 사람에게 같은 catalog를 보여주기 위한 것이지, catalog에 적힌 모든 plugin을 plain project skill로 복사해 놓는 장치는 아니다(ref11).

Marketplace를 별도의 Git repository로 운영할 수도 있다.

company-plugin-marketplace/
├── .agents/
│   └── plugins/
│       └── marketplace.json
└── plugins/
    ├── jira-helper/
    ├── deploy-helper/
    └── security-review/
Plain Text
복사

다음 명령은 이 repository의 plugin들을 즉시 설치하는 것이 아니라, 해당 Git source를 marketplace로 등록하고 추적하게 한다.

codex plugin marketplace add company/company-plugin-marketplace
Bash
복사

OpenAI marketplace에서 plugin을 설치하면 실제 bundle은 다음과 같은 user cache에 들어간다.

~/.codex/plugins/cache/
└── <marketplace-name>/
    └── <plugin-name>/
        └── <version>/
Plain Text
복사

Local source를 가리키는 plugin도 marketplace entry의 원본 폴더에서 직접 실행되는 것이 아니라 설치된 cache copy에서 로드된다. Plugin 내부의 skill 역시 <repo>/.agents/skills에 hard copy되는 것이 아니라 cache 안의 plugin component로 남는다(ref11). Enable/disable 상태는 별도의 사용자 configuration에 저장된다. 따라서 repo marketplace가 공유하는 것은 “이 project에서 발견할 수 있는 plugin catalog”이고, 실제 설치 사본과 활성화 상태는 별도의 lifecycle을 가진다(ref12).

Marketplace 갱신과 plugin 갱신도 같은 작업이 아니다. Marketplace upgrade는 최신 catalog와 source metadata를 다시 가져오는 일이다. 새 plugin이 목록에 추가됐는지, 기존 entry의 source와 version policy가 달라졌는지를 반영한다. Plugin update는 실제로 설치해 사용 중인 bundle을 새 version으로 교체하는 일이다. Catalog가 최신이라고 해서 설치된 모든 plugin이 자동으로 최신인 것은 아니고, plugin 하나를 업데이트했다고 catalog 전체가 갱신되는 것도 아니다.

부록2. Connector

OpenAI plugin은 skill과 함께 connector mapping을 담을 수 있다. 여기서 connector는 MCP를 대체하는 별도의 tool 형식이 아니다. MCP server가 모델이 호출할 tool과 resource를 제공하는 기술적 endpoint라면, connector 또는 app connection은 그 통합을 제품 안에서 발견하고 연결하며 사용자별 인증 상태와 workspace policy를 관리하는 계층이다.

Raw MCP server를 직접 등록할 때는 endpoint와 transport를 설정하고, 필요한 경우 API key나 OAuth flow를 구성하며, token 갱신과 tool permission을 client별로 관리해야 한다. Connector 계층에서는 사용자가 ChatGPT 안에서 Connect를 누르고 서비스별 로그인과 consent를 완료할 수 있으며, 플랫폼은 그 연결을 사용자의 계정에 귀속해 관리한다.

인증이 필요한 MCP integration에서 ChatGPT는 사용자를 대신하는 OAuth client로 동작한다(ref13). 실제 access token은 각 authorization server가 해당 사용자와 scope에 맞춰 발급한다. Google 연결과 Slack 연결은 서로 다른 grant이며, 한 서비스의 token이 다른 서비스의 권한으로 변환되지 않는다. 여러 서비스별 authorization을 사용자 identity 아래에서 관리하는 hub에 가깝다.

Visibility와 update R&R을 함께 설계하기

스킬이 적을 때는 모든 것을 홈 디렉토리에 넣어도 큰 문제가 드러나지 않는다. 그러나 스킬이 늘어나면 “언제든 쓸 수 있다”는 편리함이 “항상 후보 목록에 들어간다”는 비용으로 바뀐다. 따라서 반복적인 개인 workflow는 사용자 범위에, 특정 repository의 실행법·테스트법·배포법은 project 범위에, monorepo의 특정 package에만 필요한 절차는 해당 package 가까이에 두는 것이 자연스럽다. Repository에서만 필요하지만 팀과 공유하지 않을 스킬은 project path에 두고 Git에서 제외할 수 있다. 이미 공유된 스킬의 visibility만 개인적으로 줄이고 싶다면 파일을 옮기기보다 host의 disable 또는 invocation control을 사용하는 편이 낫다.

설치 방식은 원하는 update R&R에 맞춰 고른다. 일회성으로 가져와 직접 고칠 스킬은 copy로 충분할 수 있다. Source history를 그대로 유지하려면 Git clone이 투명하다. 여러 agent path에 설치하고 source, ref, hash를 추적하고 싶다면 npx skills 같은 installer가 적합하다. 여러 스킬과 MCP, hook, app connection을 호환되는 하나의 제품 단위로 배포하려면 plugin이 적합하다. Plugin을 발견하고 배포할 catalog가 필요할 때 marketplace를 둔다.

스킬을 이동할 때도 같은 질문을 해야 한다. 에이전트가 새 위치에서 파일을 발견하는지만 확인하면 visibility migration만 끝난 것이다. 기존 lockfile, Git remote, plugin installation state가 새 위치와 lifecycle을 가리키는지까지 확인해야 update migration이 끝난다. Installer-managed skill은 remove와 add를 통해 scope를 다시 등록하고, plugin-bundled skill은 내부 폴더를 직접 옮기기보다 plugin version과 installation scope를 통해 관리하는 편이 일관적이다.

결국 skill visibility 관리는 컨텍스트를 절약하는 문제이면서 dependency lifecycle을 설계하는 문제다. Progressive disclosure가 본문의 불필요한 로딩을 줄여 주더라도, 관측 가능한 후보 목록은 계속 관리해야 한다. 파일 위치는 어떤 세션과 사용자가 스킬을 볼 수 있는지를 결정한다. Lockfile, Git metadata, plugin manager는 누가 어떤 source를 기준으로 그 스킬을 갱신할지를 결정한다. 스킬이 많아질수록 중요한 것은 더 많이 설치하는 일이 아니라, 필요한 순간에 필요한 스킬만 보이게 하고, 그 스킬의 update ownership이 어디에 있는지를 잃지 않는 일이다.

언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.

from: 이 메모에 쓰인 생각을 만든 앞의 생각들입니다. 앞의 생각과 연관관계를 설명합니다.

supplementary: 이 메모에 작성된 생각을 뒷받침하는 생각의 새로운 메모입니다.

opposite: 이 메모에 작성된 생각과 대조되는 생각의 새로운 메모입니다.

to: 이 메모에 작성된 생각으로부터 발전된 생각의 새로운 메모입니다.

ref: 생각에 참고한 자료입니다.

We are publishing Agent Skills as an open standard.

•

Anthropic, Introducing Agent Skills: Claude에서 시작한 Skills 형식이 여러 agent product에서 사용할 수 있는 공개 표준으로 확장된 배경을 설명한다.

A skill is a directory containing, at minimum, a SKILL.md file ... Agents load skills progressively.

•

Agent Skills, Specification: Skill directory 구조와 metadata → instructions → resources의 progressive disclosure 모델을 정의한다.

this list uses at most 2% of the model’s context window, or 8,000 characters when the context window is unknown.

•

OpenAI, Build skills: Codex의 initial skill list budget, repository·user·admin·system discovery path, disable 설정과 plugin 배포 기준을 설명한다.

Where you store a skill determines who can use it.

•

Anthropic, Extend Claude with skills: Claude Code의 Enterprise, Personal, Project skill 위치와 nested discovery, visibility override를 설명한다.

Managed settings ... cannot be overridden by user or project settings.

•

Anthropic, Claude Code settings: Managed, user, project, local 설정 계층과 server·MDM·OS policy·system file 기반 배포 위치를 설명한다.

Project (default) ... Committed with your project, shared with team ... -y, --yes Skip scope prompt.

•

Vercel Labs, skills CLI README: npx skills add와 update의 project/global scope, symlink·copy 방식, -p, -g, -y 옵션을 설명한다.

The structure of the local (project-scoped) skill lock file. This file is meant to be checked into version control.

•

Vercel Labs, src/local-lock.ts: Project의 skills-lock.json 위치와 source, ref, skillPath, computedHash 등 lock entry의 구조를 확인할 수 있다.

Check whether the current working directory has project-level skills.

•

Vercel Labs, src/update.ts: npx skills update -y가 현재 working directory의 lockfile과 .agents/skills를 이용해 project/global을 판별하는 구현을 보여준다.

A plugin is a self-contained directory of components that extends Claude Code with custom functionality.

•

Anthropic, Plugins reference: Plugin이 skills, agents, hooks, MCP, LSP, monitors 등을 묶는 bundle이라는 점과 user·project·local·managed installation scope를 설명한다.

10.

A marketplace is a catalog of plugins ... No plugins are installed yet.

•

Anthropic, Discover and install plugins through marketplaces: Marketplace 등록과 개별 plugin 설치가 분리된 두 단계임을 설명한다.

11.

A marketplace is a JSON catalog of plugins ... The app installs plugins into ~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/.

•

OpenAI, Build plugins: Repo·personal·remote marketplace, plugin source, cache 설치 위치, manifest와 bundled component 구조를 설명한다.

12.

Moving a skill doesn’t transfer ... plugin installation state, or app authorization.

•

OpenAI, Skill controls: Workspace Skill, filesystem skill, plugin-packaged skill이 서로 다른 lifecycle과 access control을 가진다는 점을 설명한다.

13.

Client – ChatGPT acting on behalf of the user.

•

OpenAI, Authentication — Apps SDK: 인증된 MCP integration에서 resource server, authorization server, ChatGPT client가 담당하는 역할을 설명한다.

프로젝트메모 템플릿 버전 2026.03.20