공식 스킬과 연결

설치되는 공식 스킬

기본으로 neon은 28개, supabase는 25개를 설치해요. 기준 목록은 각 템플릿의 files/skills.manifest.json이에요. 용어 정리에 쓰는 domain-modeling처럼 널리 쓰이는 외부 스킬도 같은 방식으로 설치해요.

일부 프로젝트만 쓰는 스킬은 선택 스킬 묶음에 따로 모아 두었어요.

프로세스 스킬과 전역 도구

위 표의 공식 도메인 스킬은 무엇으로 만드는지(Next.js, DB, 인증)를 다뤄요. 아래 도구는 어떤 순서로 일하는지(설계, 계획, 구현, 리뷰, 확인)를 다뤄요. 단계마다 무엇을 먼저 쓰고, 없으면 무엇으로 대신하는지는 설치된 프로젝트의 .agents/skills/prokit-dev-cycle/references/process-routing.md가 정본이에요. Vercel CLI, Neon CLI, Supabase CLI, GitHub CLI처럼 DB와 배포에 쓰는 명령줄 도구는 쓰는 기술과 도구에 모았어요.

지키는 경계도 정해 두었어요.

• 리뷰 행의 증거는 prokit-reviewer만 채워요. ponytail-review, gstack review, OMX code-review, Claude Code의 /code-review는 추가 관점이에요.

• OMC·OMX의 모드(team, ralph 등)는 실행 수단이에요. 모드가 낸 완료 보고는 증거가 아니고, 라운드가 끝났는지는 pnpm dev-cycle audit만 판정해요. 모드가 커밋, push, 배포를 하게 두지 않아요.

• 코드를 고치거나 배포하는 gstack 스킬(qa, ship, land-and-deploy)은 사용자가 요청할 때만 써요. 배포는 prokit-deploy로 해요.

• 빠진 것은 pnpm skills:check로 확인해요. omx가 없는 기기는 OMX를 빠진 것으로 세지 않아요.

읽을 스킬을 정해 두는 방법

• prokit-web, prokit-api, prokit-db, prokit-deploy, prokit-dev-cycle에는 어떤 상황에서 어떤 공식 스킬을 읽을지 적은 "공식 스킬 연결" 표가 있어요. prokit-ui와 prokit-verify는 본문의 단계와 규칙에 스킬 이름을 적어 둬요.

• dev-cycle 대조표의 행에도 그 단계에서 읽을 스킬 이름이 괄호로 들어가 있어요. 에이전트는 그 행을 진행할 때 스킬을 실제로 읽고 증거 칸에 이름을 남겨요(사용: supabase-postgres-best-practices(schema-data-types)).

• 외부 스킬은 .agents/skills/<이름>/SKILL.md를 직접 읽게 해요. 같은 이름의 개인 스킬(~/.claude/skills)이 있으면 Claude Code의 Skill 도구가 그쪽을 먼저 불러오기 때문이에요.

자세히

호출률과 활용도

새 세션에서 사용자가 할 법한 요청 7개(스펙·계획, 화면, API, DB, 인증 설정, 성능 분석, 배포 준비)를 두 판으로 두 번씩 실행하고 각 단계에서 읽어야 할 스킬을 실제로 읽었는지 로그로 셌어요. 두 판은 v0.6.1(before)과 공식 스킬 연결을 보강한 판(after)이에요(neon 템플릿, claude -p, Opus 5.5, 2026-09-30). 무엇을 읽어야 하는지는 보강하기 전에 미리 정했어요.

%%{init: {"themeVariables": {"xyChart": {"plotColorPalette": "#2a78d6, #8c929b"}}}}%%
xychart-beta
  title "기대 스킬 호출률 (%) — 회색 before, 파랑 after"
  x-axis ["전체 110항목", "공식 스킬 36", "프로세스 스킬 20", "prokit 스킬 44"]
  y-axis "호출률 (%)" 0 --> 100
  bar [95, 97, 90, 95]
  bar [69, 36, 70, 89]

before에서도 대조표 행에 이름이 있던 스킬은 거의 매번 불렸어요. 분야별 스킬의 연결 표에만 있던 공식 스킬은 대부분 건너뛰었어요. after는 그 단계의 행에 스킬 이름을 넣었어요. 공식 스킬별 결과는 다음과 같아요(두 번 실행한 평균).

활용도는 두 가지로 봤어요. 설치한 공식 스킬이 하네스의 어디에 연결되어 있는지, 그리고 측정에서 실제로 읽혔는지예요.

%%{init: {"themeVariables": {"pie1": "#6aa5ea", "pie2": "#b9d4f3", "pie3": "#dde1e6", "pieSectionTextColor": "#111418", "pieStrokeColor": "#ffffff"}}}%%
pie showData title 측정 때 neon 공식 도메인 스킬 26개가 연결된 곳 (after)
  "dev-cycle 대조표 행" : 11
  "prokit 스킬 연결 표·에이전트" : 14
  "다른 스킬이 안에서 부름" : 1

• after에서도 읽히지 않은 11개는 측정 요청에 그 상황이 없었기 때문이에요. 해당하는 스킬은 원격 Neon 브랜치(neon 4종), 실제 배포(Vercel 배포 3종), 컴포넌트 조합 설계(vercel-composition-patterns), 설계 질문(grill-with-docs, grilling. 요청이 질문을 모아 두라고 했어요)이에요. agent-browser는 macOS에서 ego lite를 먼저 써서 읽히지 않았어요.

• 같은 이름의 개인 스킬(~/.claude/skills)이 있으면 Claude Code의 Skill 도구가 그 스킬을 먼저 불러와요. 그래서 before에서는 프로젝트에 설치한 판 대신 전역 판을 읽는 일이 많았어요. after는 .agents/skills/<이름>/SKILL.md를 Read로 읽게 했어요.

• 측정할 때 공식 도메인 스킬은 neon 26개, supabase 23개였어요. 그 뒤 use-design-md와 gpt-image가 더해져 지금은 neon 28개, supabase 25개예요.

• 한계: 설정마다 두 번만 실행했고, neon 템플릿과 전역 스킬이 많은 기기 하나에서만 쟀어요. 스킬을 읽었는지만 셌고, 읽은 내용을 제대로 적용했는지는 채점하지 않았어요.

• 2026-09-30에는 Codex CLI에서도 따로 검수했어요. 스킬을 읽는지와 적용하는지를 나눠 확인했고, 그 결과 Vitest 행이 빠지거나 다른 자리로 옮겨지는 문제를 고쳤어요. Neon·Supabase DB 사례와 전역 스킬을 제외한 사례도 다시 확인했어요. 운영 인증 보안과 성능 재현의 한계는 Codex 검수 보고서(새 탭)에 적었어요. 위 호출률 차트는 이전에 Claude로 잰 값이에요.

• 측정 방법, 찾은 결함 3건, 시나리오별 세부 결과, 비용은 스킬 연결 점검 보고서(새 탭)에 있어요. 내려받아 브라우저로 열거나 claude.ai 게시본(새 탭)을 보세요. 수치와 판정은 neon 검증 기록(새 탭)에도 있어요.

관련 문서

• prokit 스킬 8개

• 선택 스킬 묶음

• 설치와 업데이트 구조

• 템플릿 고르기