목차
Claude Code에는 60개 이상의 내장 슬래시 명령어가 있지만, 대부분의 사용자는 5~6개만 안다. 더 강력한 기능은 .claude/skills/ 폴더에 마크다운 파일을 하나 만드는 것만으로 나만의 명령어를 만들 수 있다는 점이다. 여기서는 실전에서 즉시 사용 가능한 10개 스킬 전문을 소개한다.
커스텀 스킬 동작 원리
스킬 파일은 두 곳에 저장할 수 있다:
.claude/skills/review/SKILL.md → 프로젝트 전용 (git으로 팀 공유)
~/.claude/skills/review/SKILL.md → 개인용 (모든 프로젝트에서 사용 가능)디렉터리 이름이 슬래시 명령어가 된다. review/SKILL.md → /review.
프론트매터로 동작을 제어한다:
name: review
description: Review current diff for bugs, security, and style
allowed-tools: Read, Grep, Glob, Bash(git diff *)description: Claude가 자동으로 스킬을 제안할 때 사용하는 맥락 설명allowed-tools: 해당 명령어에서 허용할 도구 목록
인수 전달도 지원한다:
/review src/auth/ → $ARGUMENTS = "src/auth/"
/fix-issue 423 high → $1 = "423", $2 = "high"commands/ vs skills/ 차이
2026년 4월 Anthropic이 커스텀 명령어를 스킬 시스템으로 통합했다. 둘 다 동작하지만 신규 명령어는 skills/를 쓰는 것이 권장된다.
commands/ (레거시) | skills/ (권장) | |
|---|---|---|
/name으로 호출 | ✓ | ✓ |
| 수동 실행만 가능 | ✓ | – |
| Claude 자동 제안 | – | ✓ |
allowed-tools 제한 | – | ✓ |
스킬의 핵심 장점은 자동 트리거다. description에 “PR 리뷰 중 사용”이라고 적어두면, PR 작업 중에 Claude가 /review를 먼저 제안한다.
10개 스킬 전문
1. /review — 코드 리뷰
name: review
description: Review code for bugs, security issues, and style violations.
Use when reviewing PRs, checking code quality, or when user mentions
"review", "PR", "code quality".
allowed-tools: Read, Grep, Glob, Bash(git diff *)
Review the current diff or specified files for:
1. **Bugs**: logic errors, off-by-one, null handling, race conditions
2. **Security**: OWASP Top 10, hardcoded secrets, SQL injection, XSS
3. **Performance**: N+1 queries, unnecessary re-renders, blocking calls
4. **Style**: naming conventions, dead code, TODOs left behind
Output format:
- Group findings by severity: CRITICAL / WARNING / INFO
- Each finding: file, line, issue, suggested fix
- End with a summary: "X critical, Y warnings, Z info"
If no diff exists, ask which files to review.2. /test — 테스트 작성
name: test
description: Write tests for a file or function. Use when user mentions
"test", "tests", "coverage", or "spec".
allowed-tools: Read, Write, Edit, Bash(npm test *), Bash(npx vitest *)
Before writing tests:
1. Read the target file to understand function signatures and types
2. Find existing test directory, read 1-2 existing tests
3. Identify the testing framework (Jest, Vitest, Pytest, etc.)
4. Match the import style and assertion patterns
Generate tests covering:
- Happy path (expected inputs → expected outputs)
- Edge cases (empty, null, zero, max values, special characters)
- Error cases (invalid inputs, network failures, timeouts)
- Async behavior if applicable
After writing, run the tests. Fix any failures before finishing.3. /commit — 스마트 커밋
name: commit
description: Create structured git commits from current changes. Use when
user says "commit", "save changes", or after finishing a feature.
allowed-tools: Read, Bash(git *)
1. Run `git status` and `git diff` to see all changes
2. Group related changes into logical units (one feature = one commit)
3. For each unit, create a commit:
Format:
type(scope): short description under 50 chars
- What changed
- Why it changed (if not obvious)
Types: feat, fix, refactor, docs, test, chore
Scope: affected module name
4. Stage and commit each unit separately
5. Show summary: "Created N commits: [titles]"
Rules:
- Never combine unrelated changes in one commit
- Description is lowercase, present tense
- No period at end of subject line4. /pr — PR 설명 자동 생성
name: pr
description: Generate a PR description from current branch changes. Use when
user mentions "PR", "pull request", or "merge".
allowed-tools: Read, Bash(git *)
1. Run `git log main..HEAD --oneline` to see all commits
2. Run `git diff main...HEAD --stat` for changed files summary
3. Read the key changed files to understand the full context
Generate a PR description:
## What
[One paragraph: what this PR does]
## Why
[One paragraph: why this change is needed]
## Changes
[Bullet list of key changes, grouped by area]
## Testing
[How this was tested, what to check during review]
## Notes
[Anything reviewers should know: breaking changes, migrations, follow-ups]
Output the description ready to paste into GitHub.5. /debug — 오류 분석
name: debug
description: Debug an error or unexpected behavior. Use when user mentions
"bug", "error", "broken", "not working", "debug", or pastes an error message.
allowed-tools: Read, Grep, Glob, Bash(npm test *), Bash(npx tsc *)
1. Identify the error: read the error message, stack trace, or user description
2. Find the source: search codebase for relevant files using grep/glob
3. Read the relevant code and understand the expected behavior
4. Form a hypothesis for the root cause
5. Verify by reading related code, tests, and recent changes
6. Propose a fix with explanation
Output format:
**Root cause**: [one sentence]
**Location**: [file:line]
**Fix**: [code change with explanation]
**Prevention**: [how to prevent this class of bug in future]
Do NOT make changes unless explicitly asked. Diagnosis first.6. /refactor — 안전한 리팩터링
name: refactor
description: Refactor code while preserving behavior. Use when user mentions
"refactor", "clean up", "simplify", or "restructure".
allowed-tools: Read, Write, Edit, Bash(npm test *), Bash(npx tsc *)
1. Read the target file(s) completely
2. Run existing tests to establish baseline (all must pass)
3. Plan refactoring changes WITHOUT changing external behavior
4. Apply changes incrementally, one logical step at a time
5. Run tests after EACH step
6. Run type check after final step
Refactoring targets (in priority order):
- Extract duplicated code into shared functions
- Simplify complex conditionals
- Reduce function length (under 30 lines ideal)
- Improve naming clarity
- Remove dead code
- Fix type safety issues
Rules:
- NEVER change function signatures without checking all callers
- NEVER change behavior, only structure
- If tests fail after a change, revert and try a different approach7. /docs — 문서 생성
name: docs
description: Generate or update documentation. Use when user mentions
"docs", "documentation", "README", "JSDoc", or "comments".
allowed-tools: Read, Write, Edit, Glob
Determine what needs documenting:
**If README**: Generate project overview, setup, usage, and API reference
**If JSDoc/docstrings**: Add to all exported functions and classes
**If inline comments**: Add to complex logic only (not obvious code)
For each documented item include:
- Description of what it does (one sentence)
- Parameters with types and descriptions
- Return value with type
- Example usage (if non-obvious)
- Throws/errors (if applicable)
Style rules:
- Match existing documentation style in the project
- Be concise, not verbose
- Document WHY, not WHAT (the code shows what)8. /migrate — DB 마이그레이션
name: migrate
description: Create a database migration. Use when user mentions "migration",
"schema change", "add column", "create table", or "alter table".
allowed-tools: Read, Write, Edit, Bash(npm run *), Glob
1. Read existing migrations to understand naming convention and ORM
2. Identify the migration tool (Prisma, Drizzle, Knex, raw SQL, etc.)
3. Create the migration file following project conventions
Rules:
- Always include both UP and DOWN migrations
- Use the project's naming convention for migration files
- Add appropriate indexes for foreign keys and frequently queried columns
- Never drop columns in production without a data migration plan
- Add NOT NULL constraints only with DEFAULT values
After creating, run the migration locally and verify it applies cleanly.9. /deploy-check — 배포 전 검증
name: deploy-check
description: Run pre-deployment checks. Use when user mentions "deploy",
"ship", "release", or "production".
allowed-tools: Read, Bash(npm *), Bash(npx tsc *), Bash(git *), Grep
Run these checks in order. Stop at first failure:
1. `npx tsc --noEmit` — type check passes
2. `npm test` — all tests pass
3. `npm run lint` — no lint errors
4. `npm run build` — build succeeds
5. Check for console.log in src/
6. Check for .env references in committed code
7. Check git status — no uncommitted changes
8. Verify current branch is up to date with main
Output:
✅ or ❌ for each check
Summary: "Ready to deploy" or "N issues must be fixed first"10. /security — 보안 스캔
name: security
description: Scan for security vulnerabilities. Use when user mentions
"security", "audit", "vulnerability", "CVE", or before deployments.
allowed-tools: Read, Grep, Glob, Bash(npm audit *)
Scan the codebase for:
1. **Hardcoded secrets**: API keys, passwords, tokens
2. **Dependency vulnerabilities**: run `npm audit` or equivalent
3. **SQL injection**: check for string concatenation in queries
4. **XSS**: check for unsanitized user input in HTML output
5. **CSRF**: verify token protection on state-changing endpoints
6. **Auth issues**: check for missing auth middleware on protected routes
7. **File access**: check for path traversal vulnerabilities
8. **SSRF**: check for unvalidated URLs in server-side requests
Output format:
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Location: file:line
- Issue: what's wrong
- Fix: how to fix it
- Reference: OWASP category
End with: "Found X issues: N critical, N high, N medium, N low"설치 방법
프로젝트 루트에 아래 폴더 구조를 만들고 git에 커밋하면 팀 전체가 동일한 명령어를 즉시 사용할 수 있다:
.claude/skills/
├── review/SKILL.md
├── test/SKILL.md
├── commit/SKILL.md
├── pr/SKILL.md
├── debug/SKILL.md
├── refactor/SKILL.md
├── docs/SKILL.md
├── migrate/SKILL.md
├── deploy-check/SKILL.md
└── security/SKILL.md개인 전용으로 모든 프로젝트에 적용하려면 ~/.claude/skills/에 저장한다.
전체 워크플로우
10개 스킬을 하나의 피처 개발 사이클로 연결하면 다음과 같다:
/debug→ 이슈 분석- 코드 작성 → 수정 구현
/test→ 새 코드 테스트 생성/refactor→ 필요시 정리/review→ PR 전 셀프 리뷰/security→ 보안 스캔/commit→ 구조적 커밋 생성/pr→ PR 설명 자동 작성/deploy-check→ 배포 전 최종 확인
50단어짜리 프롬프트가 7~15자 명령어로 줄어든다. 한 달 누적하면 절약 시간이 체감될 정도로 쌓인다.
참고 자료
- The Claude Skills Folder That Automates 90% of Workflow (All Commands Included) — X @zodchiii (2026-05-06)