Codex skill 추천 10선: 코덱스 스킬 설치·사용법

Codex skill 추천 10개: 지금 맡길 일로 고른다

Codex skill 추천을 찾는다면 먼저 지금 가장 자주 되풀이하는 일을 골라야 한다. 화면이 제대로 동작하는지 확인하는 일인가, 빨간 CI 로그를 읽는 일인가, 리뷰 의견을 반영하는 일인가. 같은 코덱스라도 필요한 작업 절차는 다르다. 웹 앱을 만드는 사람에게는 브라우저 확인이, 보고서를 만드는 사람에게는 PDF 렌더링이 먼저다.

스킬은 작업 지침과 참고자료, 필요한 실행 파일을 묶는 SKILL.md 형식이다. 설치 목록에 이름이 있다는 것과 외부 도구가 연결됐다는 것은 다르다. 아래 표에서 맡길 일과 준비할 도구가 맞는 후보를 먼저 고르면 된다.

여러 개를 한 번에 설치할 필요는 없다. 오늘 확인할 화면이 있다면 playwright부터, 지금 PR의 검사 실패가 막고 있다면 gh-fix-ci부터 시작한다. 같은 프로젝트에서 반복되는 일이 확인될 때 다음 스킬을 추가한다.

브라우저·CI·PR 작업은 결과를 직접 보게 하는 스킬이 먼저다

1. playwright: 코드가 아니라 실제 화면을 확인한다

playwright는 터미널에서 실제 브라우저를 열고 입력·클릭·화면 캡처를 수행하는 스킬이다. 최신 화면 상태를 읽은 뒤 요소를 조작하고, 페이지가 바뀌면 다시 상태를 읽는 순서를 사용한다. Node/npm의 npx가 필요하다. 기본 흐름은 브라우저 조작이며, Playwright 테스트 파일을 작성하는 일은 별도로 요청해야 한다.

“$playwright로 로컬 앱의 가입 화면을 열어 필수 입력 누락과 정상 제출을 각각 확인해줘. 오류가 있으면 재현 순서와 화면 캡처를 남기고 아직 코드는 바꾸지 마.”

첫 요청은 화면 하나와 동작 두세 개로 좁힌다. 전체 사이트가 정상인지 묻기보다 정상 제출과 오류 상태처럼 확인할 장면을 지정해야 결과를 판단하기 쉽다.

2. gh-fix-ci: 실패 로그를 읽고 수정 계획부터 만든다

gh-fix-ci는 현재 PR의 GitHub Actions 검사와 로그를 찾고 실패 맥락을 요약한다. gh 인증이 필요하며 원본 절차는 수정 계획을 제시한 뒤 명시적 승인을 받고 구현한다. Buildkite 같은 다른 CI까지 같은 스킬이 고치는 것은 아니다.

“$gh-fix-ci로 이 PR의 실패한 GitHub Actions를 확인해줘. 실패한 작업, 원인 로그, 최소 수정 계획을 먼저 보여줘. 계획 승인 전에는 변경하지 마.”

버그 수정 스킬과의 차이는 시작점에 있다. 코드의 어느 부분이 문제라고 짐작하기 전에 실제로 실패한 검사와 로그를 가져오는 일부터 맡긴다.

3. gh-address-comments: 리뷰 의견을 한꺼번에 적용하지 않는다

gh-address-comments는 현재 브랜치의 PR 코멘트와 리뷰 스레드를 가져온다. 번호별로 필요한 변경을 요약하고 사용자가 선택한 의견을 반영하는 흐름이다. gh 인증과 해당 저장소 접근이 필요하다.

“$gh-address-comments로 현재 PR의 리뷰 의견을 번호별로 보여줘. 각 의견에 필요한 변경을 설명한 뒤 내가 선택한 항목만 수정해줘.”

리뷰에서 제안한 설계 변경과 지금 필요한 버그 수정은 범위가 다를 수 있다. 어떤 의견을 이번 PR에서 처리할지 고르는 단계가 있어야 수정 범위도 유지된다.

React 성능과 Figma 구현은 다른 스킬을 골라야 한다

4. vercel-react-best-practices: 요청 순서와 번들부터 점검한다

vercel-react-best-practices는 Vercel의 React·Next.js 성능 규칙을 사용한다. 데이터 요청이 차례로 대기하는 워터폴과 번들 크기를 우선순위가 높은 문제로 다루고, 서버 처리와 다시 렌더링되는 구조도 살핀다. 스킬 이름과 저장소 폴더 이름이 다르다. 설치할 폴더는 skills/react-best-practices다.

“$vercel-react-best-practices로 상품 목록 페이지의 요청 워터폴과 불필요한 번들을 점검해줘. 변경 후보를 먼저 보여주고 기존 화면과 동작은 유지해줘.”

작업을 마친 뒤에는 실제 페이지를 다시 열고 원래 동작이 유지되는지 본다. 이 확인에 playwright를 함께 쓰는 조합이 적합하다. 성능 규칙 적용과 화면 확인은 같은 작업이 아니다.

5. figma-implement-design: 디자인에서 코드로 옮기는 작업에 맞다

figma-implement-design은 Figma 디자인을 사용자의 프로젝트 코드로 구현하는 스킬이다. Figma MCP 연결과 노드가 지정된 디자인 URL이 필요하다. Figma 데스크톱 MCP를 쓰는 경우에는 선택한 노드를 사용할 수 있다. 기존 컴포넌트와 디자인 토큰을 재사용하고 기준 이미지와 구현 화면을 대조하는 흐름을 갖는다.

“$figma-implement-design으로 이 Figma 노드를 구현해줘. 프로젝트의 기존 버튼과 폰트·색상 토큰을 먼저 찾아 재사용하고, 구현 화면을 기준 디자인과 비교해줘.”

Figma 캔버스 자체를 수정하는 스킬은 아니다. 스킬을 설치했어도 디자인에 접근할 연결과 권한이 없으면 입력 자료를 가져올 수 없다.

기획이 모호하면 질문부터, 구현은 테스트부터 시작한다

6. grill-me / grilling: 만들기 전에 결정을 맞춘다

Matt Pocock의 grilling은 계획과 아이디어를 질문으로 구체화한다. 어떤 결정을 먼저 해야 다음 결정을 내릴 수 있는지 나누고, 현재 답할 수 있는 질문을 몇 차례로 나눠 제시한다. 사용자와 요구사항에 대한 이해가 일치하는지 확인한 뒤 실행으로 넘어간다.

현재 grill-me는 grilling을 호출하는 짧은 래퍼다. 래퍼 하나만 복사하지 말고 핵심 스킬을 함께 설치해야 한다. 원본의 Skill 도구 호출이 현재 Codex 환경에서 지원되는지 확인하고, 이 인터뷰가 목적이라면 $grilling으로 핵심 스킬을 직접 지정한다.

“$grilling으로 견적 자동화 계획에서 아직 결정하지 않은 부분을 질문해줘. 포함·제외 기준, 결과 양식, 승인할 사람부터 맞추고 내가 확인하기 전에는 구현하지 마.”

7. tdd: 실패하는 테스트 하나와 최소 구현을 반복한다

tdd는 사용자에게 보이는 동작을 공개 인터페이스에서 테스트한다. 테스트할 범위를 먼저 합의하고 실패하는 테스트 하나를 만든 뒤, 그 테스트를 통과할 최소 구현을 하는 흐름이다. 내부 함수의 구조보다 실제 동작을 확인하는 데 초점을 둔다.

“$tdd로 주문 취소 기능을 구현하자. 사용자가 호출할 인터페이스와 테스트할 동작부터 합의하고, 테스트 하나가 실패하는 것을 확인한 뒤 최소 구현으로 통과시켜줘.”

현재 스킬은 red→green 구현을 반복하고 리팩터링은 code-review 단계로 구분한다. 인터페이스 설계 논의에는 codebase-design 참조를 사용한다. 한 폴더를 설치했다고 이런 후속 지침까지 모두 확보된 것으로 생각하면 안 된다.

8. security-best-practices: 언어와 보안 검토 범위를 지정한다

security-best-practices의 지원 언어는 Python, JavaScript·TypeScript, Go다. 명시적인 보안 검토나 안전한 기본값을 요청할 때 사용하며, 해당 언어·프레임워크의 지침을 읽고 개선점을 제안한다. 보고서 뒤의 수정은 별도 요청으로 이어진다.

“$security-best-practices로 이 서비스의 로그인과 사용자 데이터 접근 부분을 검토해줘. 언어와 프레임워크를 확인하고 파일 위치·영향·수정 우선순위를 보고해줘. 아직 수정하지 마.”

일반 코드 리뷰와 보안 검토를 같은 요청으로 묶기보다 어떤 데이터와 기능을 확인할지 먼저 정한다. 지원 언어 밖의 프로젝트를 같은 범위로 취급하지 않는다.

PDF와 배포 스킬은 전달할 결과물이 분명할 때 고른다

9. pdf: 문서가 생성됐다는 사실과 잘 보인다는 사실은 다르다

pdf는 PDF 읽기·생성·검토를 맡는다. Python의 reportlab, pdfplumber, pypdf 등을 사용하고, Poppler로 페이지를 이미지로 렌더링해 배치와 가독성을 확인한다. 텍스트가 추출돼도 표가 잘리거나 글자가 겹친 문제는 별도로 볼 필요가 있다.

“$pdf로 이 자료를 고객용 제안서로 만들어줘. 표와 페이지 번호가 잘리지 않게 하고, 최종 PDF를 페이지 이미지로 렌더링해 확인한 뒤 전달해줘.”

첫 작업은 짧은 문서로 고른다. 숫자와 문구가 맞는지, 페이지가 바뀔 때 표가 유지되는지를 함께 확인하면 다음 문서에서도 요구할 결과가 분명해진다.

10. vercel-deploy: 운영 전에 검토할 미리보기 주소를 만든다

vercel-deploy는 Vercel 배포를 위한 스킬이다. 기본은 preview이며 production은 명시적으로 요청할 때만 수행한다. Vercel CLI를 쓸 수 없거나 인증 정보가 없는 경우에는 별도 배포 스크립트를 이용하는 경로가 있고, 미리보기 주소와 배포를 자신의 Vercel 계정에 연결할 수 있는 claim 주소를 반환한다.

“$vercel-deploy로 이 프로젝트의 preview만 만들어줘. 운영 배포는 하지 말고 검토할 주소를 알려줘.”

Vercel 배포용이므로 자체 서버의 nginx·systemd 배포를 대신하지 않는다. 다른 배포 환경은 그 환경에 맞는 절차를 별도로 정해야 한다.

Codex 스킬 설치 방법: 공식 이름과 외부 폴더 URL을 나눈다

공식 curated 스킬은 Codex 대화창에서 skill-installer에 이름을 지정해 설치를 요청한다. 아래 문장은 터미널 명령이 아니라 Codex에 입력하는 요청이다.

$skill-installer playwright
$skill-installer gh-fix-ci
$skill-installer pdf

외부 스킬에는 정확한 폴더 URL을 넣는다. Vercel의 React 스킬은 폴더 이름과 호출 이름이 다르고, Matt Pocock의 현재 스킬은 productivity와 engineering 아래에 있다. 저장소의 옛 링크보다 원본 폴더를 먼저 확인해야 한다.

$skill-installer 아래 폴더의 스킬을 설치해줘.
https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices

grill-me와 핵심 인터뷰 지침을 같이 확보하려면 두 경로를 지정한다. 설치할 내용을 먼저 읽고 각 폴더의 참조 파일과 실제 실행 도구도 함께 확인한다.

$skill-installer 아래 두 스킬 폴더를 설치해줘.
https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me
https://github.com/mattpocock/skills/tree/main/skills/productivity/grilling

직접 만든 프로젝트 스킬은 .agents/skills/스킬이름/SKILL.md에 둘 수 있고, 개인용 공통 스킬은 ~/.agents/skills에서 관리할 수 있다. 설치 도구가 사용하는 위치와 프로젝트에서 직접 관리하는 위치를 구별한다. 스킬 내용은 지침과 실행 스크립트이므로 설치 전에 외부 전송·파일 변경·인증 사용 범위를 읽어야 한다.

새 스킬이 목록에 나타나면 바로 작은 작업을 지정한다. 나타나지 않으면 Codex를 재시작하고 경로와 파일 이름을 다시 본다. 직접 만드는 단계가 필요하면 Codex Skills 작성법으로 이어가면 된다.

스킬을 설치했는데 작동하지 않으면 이 순서로 본다

설치돼도 결과가 없는 이유를 모두 모델 성능으로 돌리면 해결할 곳을 놓친다. 스킬 발견, 호출, 도구 실행, 외부 권한은 각각 다른 단계다. Reddit의 한 이용자도 브라우저 제어 도구와 디자인 작업 지침을 구별하고 실제 화면을 확인하는 흐름이 필요하다고 지적했다. 브라우저에 접근할 수 없는 환경에서 이름만 설치해도 클릭이 가능해지는 것은 아니다.

CLI·IDE에서는 /skills로 목록을 보고 $스킬이름으로 명시적인 요청을 만들 수 있다. 처음에는 “알아서 필요한 스킬을 써줘”보다 사용할 스킬과 입력·결과를 함께 적는 편이 어디에서 막혔는지 찾기 쉽다. 서비스 연결 자체가 필요하면 Codex MCP 연결법을 별도로 확인한다.

처음에는 이 조합으로 시작한다

한 번의 요청에 열 개를 전부 붙이지 않는다. 지금 맡길 일의 입력과 결과를 정하고 필요한 스킬만 지정한다. 화면이 중요하면 브라우저에서 보고, 변경이 중요하면 테스트 결과를 받고, 문서라면 실제 페이지를 본다. 그 결과를 반복해서 만들어주는 스킬부터 남기는 것이 코덱스 스킬을 고르는 기준이다.

자주 묻는 질문