Plugins

문제

예전 방식대로 커스텀 슬래시 커맨드를 만들려는데 지금도 그것이 맞는 형태인지 헷갈립니다. 등록된 플러그인 중 무엇이 실제로 쓰이는지도 판단하기 어렵습니다.

이유

~/.claude/commands/에 파일을 두는 방식은 스킬·플러그인 체계가 갖춰지면서 새로 만들 이유가 줄었습니다. 과거에 만든 커스텀 커맨드가 남아 있다면, 새 스킬로 옮기는 편이 allowed-tools로 범위를 좁히거나 skillOverrides로 호출 방식을 통제할 수 있어 더 낫습니다.

사용량 카운터를 볼 때는 어느 카운터인지부터 확인합니다. 플러그인 활성 여부는 ~/.claude/settings.json의 enabledPlugins에, 사용 카운터는 ~/.claude.json의 skillUsage·pluginUsage에 있습니다. usageCount는 설치 이후 누계이고, pluginUsage.lastUsedAt은 설치·활성화 시점에 시드됩니다. 그래서 usageCount == 0인 플러그인의 lastUsedAt은 사용 근거가 못 됩니다. 스킬 쪽 lastUsedAt은 실제 디스패치에만 기록되므로 신뢰할 수 있습니다. override 키 형식도 다릅니다. 플러그인 스킬은 "plugin:skill", 로컬 스킬은 "skill-name"입니다.

disable-model-invocation: true가 걸린 플러그인 커맨드는 모델이 Skill로 부를 수 없습니다. 자동 루프나 에이전트 안에서 같은 동작이 필요하면 Bash로 원 CLI를 직접 호출해야 합니다.

힌트 문자열은 기능의 근거가 못 됩니다. 비활성 기능의 안내 문구가 화면이나 빌드에 그대로 남아 있는데 실제 분기는 하드코딩 게이트로 죽어 있는 경우가 있습니다. 기능 유무는 힌트가 아니라 게이트 변수로 판단합니다.

플러그인에서도 만드는 것과 쓰이는 것은 다른 문제입니다. 새 플러그인이나 스킬을 만들기 전에 기존 것으로 되는지부터 확인하는 편이, 나중에 카운터를 뒤져 무엇이 죽어 있는지 정리하는 것보다 쌉니다.

생태계에서 가져다 쓸 수 있는 것

플러그인은 스킬·훅·서브에이전트·MCP 설정을 하나로 묶어 배포하는 단위입니다. 직접 만들기 전에 같은 일을 하는 것이 이미 있는지 확인하는 편이 쌉니다. /plugin으로 마켓플레이스를 탐색합니다.

잘 만들어진 프로세스 플러그인은 판단의 타이밍을 대신합니다. 코드베이스를 사용자보다 잘 알지는 못합니다. 대신 바쁠 때 건너뛰기 쉬운 단계를 건너뛰지 못하게 만듭니다.

공개된 것 중 성격이 뚜렷한 예를 듭니다. 전체 목록이 아니라 어떤 종류가 있고 각각 어떤 판단을 대신하는지 파악하기 위한 것입니다.

프로세스 체인

superpowers 계열이 이 형태입니다. 탐색·계획·구현·검증·리뷰·마무리를 각각 스킬로 만들고, 앞 단계를 건너뛰지 못하게 게이트를 겁니다.

대신하는 판단은 다음과 같습니다.

지금 계획을 세워야 하는지, 바로 구현해도 되는 크기인지 판단합니다.
계획을 대화에 둘지 파일로 남길지 판단합니다.
이 정도면 완료라고 말해도 되는지 판단합니다.
병합 전에 전체를 다시 봐야 하는지 판단합니다.

실무 Workflow가 같은 순서를 설명합니다. 이 순서는 습관으로 지킬 수도 있고, 게이트를 거는 플러그인을 설치해 강제할 수도 있습니다.

교차 벤더 위임

Codex 계열 플러그인이 다른 벤더의 모델에 리뷰나 진단을 넘깁니다. 같은 모델의 새 컨텍스트가 못 잡는 것을 다른 벤더가 잡는 이유는 Code Review에서 다룹니다. 리뷰어 수를 늘리는 것과 관점을 늘리는 것은 다른 일입니다.

도메인 특화

impeccable은 프런트엔드 디자인을 다룹니다. 화면을 보고 무엇이 어설픈지 말로 옮기지 못할 때, 휴리스틱 점수와 접근성·반응형 실측으로 문제를 이름 붙여 줍니다. 이런 종류의 플러그인은 좁은 영역의 지식과 절차를 함께 묶습니다.

공식

Anthropic 마켓플레이스가 스킬 작성 도우미 같은 기본 도구를 제공합니다. 스킬을 손으로 쓰고 있다면 먼저 확인해 볼 만합니다.

설치 전에

같은 판단이 여기에도 적용됩니다. 설치는 쉽습니다. 쓰이는지는 별개의 문제입니다. 플러그인 하나가 스킬 열몇 개를 한꺼번에 들여오므로, 무엇이 늘었는지 모른 채 목록만 길어지기 쉽습니다. 필요한 것 하나 때문에 묶음 전체를 들이기 전에 그 하나만 직접 만드는 비용과 비교하십시오.

예시

override 키 형식:

"skillOverrides": {
  "<plugin>:<command>": "on",
  "local-skill-name": "user-invocable-only"
}

하지 말 것

lastUsedAt만 보고 “이 플러그인은 쓰인다/안 쓰인다”고 판단하기. 설치 시점에 시드된 값일 수 있습니다. usageCount를 같이 봅니다.

disable-model-invocation이 걸린 커맨드를 자동 루프에서 Skill로 부르려 하기. 조용히 실패합니다. Bash로 원 CLI를 직접 부릅니다.