You type the same instructions into Claude Code every day. "Run the tests." "Check for security issues." "Summarize this PR." Every repeated prompt is wasted context and wasted keystrokes.
Claude Code skills fix this. A skill is a markdown file with YAML frontmatter that turns any workflow into a reusable /slash-command. Type /deploy instead of explaining your deployment steps for the tenth time. Type /fix-issue 42 instead of copy-pasting your bug-fixing checklist.
This article walks through 5 practical skills you can build right now. Each one takes under 10 minutes and works immediately after creating the file.
How Skills Work
A skill lives in a directory with a SKILL.md file as its entrypoint. The SKILL.md has two parts: YAML frontmatter that configures the skill, and markdown content with instructions Claude follows when the skill runs.
~/.claude/skills/my-skill/
├── SKILL.md # Required — instructions + config
├── template.md # Optional — templates Claude fills in
└── scripts/
└── helper.py # Optional — scripts Claude can execute
Skills stored in ~/.claude/skills/ work across all your projects. Skills stored in .claude/skills/ inside a project directory work only for that project.
The name field in the frontmatter becomes the slash command. The description field tells Claude when to load the skill automatically. Here is the minimal structure:
---
name: my-skill
description: "What this skill does and when to use it"
---
Instructions Claude follows when this skill runs.
Two key frontmatter fields control access:
-
disable-model-invocation: true— only you can trigger the skill (prevents Claude from running it automatically) -
user-invocable: false— only Claude can trigger the skill (hides it from the/menu)
Now let's build 5 skills that solve real problems.
Skill 1: Fix a GitHub Issue by Number
This skill takes a GitHub issue number as an argument and handles the entire fix-and-PR workflow. The $ARGUMENTS placeholder gets replaced with whatever you type after the command name.
Create ~/.claude/skills/fix-issue/SKILL.md:
---
name: fix-issue
description: Fix a GitHub issue
argument-hint: "[issue-number]"
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS following our coding standards.
1. Use `gh issue view $ARGUMENTS` to read the issue description
2. Understand the requirements and acceptance criteria
3. Search the codebase for relevant files
4. Implement the fix
5. Write tests that verify the fix
6. Run the test suite and fix any failures
7. Create a descriptive commit message referencing the issue
8. Push and create a PR with `gh pr create`
Run it with /fix-issue 42. Claude reads the issue, finds the relevant code, implements a fix, writes tests, and opens a PR. The disable-model-invocation: true field ensures Claude only runs this when you explicitly ask — you don't want Claude deciding to fix issues on its own.
The argument-hint field shows [issue-number] in autocomplete, so you remember what to pass.
Skill 2: Security Review (Read-Only)
This skill runs a security audit without modifying any files. The allowed-tools field restricts Claude to read-only tools, making it safe to run on any codebase.
Create .claude/skills/security-review/SKILL.md in your project:
---
name: security-review
description: Review code for security vulnerabilities
allowed-tools: Read, Grep, Glob, Bash(grep *), Bash(find *)
context: fork
---
You are a senior security engineer. Review this codebase for:
1. **Injection vulnerabilities** — SQL injection, XSS, command injection
2. **Authentication flaws** — hardcoded credentials, weak session handling
3. **Secrets in code** — API keys, passwords, tokens in source files
4. **Insecure dependencies** — known CVEs in package.json or requirements.txt
5. **Data exposure** — sensitive data in logs, error messages, or responses
For each finding:
- State the file path and line number
- Explain the vulnerability
- Rate severity: CRITICAL / HIGH / MEDIUM / LOW
- Provide a specific fix
If no issues found, state that explicitly. Do not invent problems.
Run it with /security-review. The context: fork field runs the skill in an isolated subagent, so the security review happens in a separate context window without cluttering your main conversation. The allowed-tools restriction means Claude can read and search but cannot write or edit anything during the review.
Skill 3: PR Summary With Live Data
This skill uses dynamic context injection to fetch real PR data before Claude sees the prompt. The !`command` syntax runs shell commands during preprocessing — the command output replaces the placeholder before Claude receives anything.
Create ~/.claude/skills/pr-summary/SKILL.md:
---
name: pr-summary
description: Summarize the current pull request
context: fork
agent: Explore
disable-model-invocation: true
---
## Pull request context
- PR description: !`gh pr view --json title,body --jq '.title + "\n" + .body'`
- Changed files: !`gh pr diff --name-only`
- Diff summary: !`gh pr diff --patch | head -100`
## Your task
Summarize this pull request for a code reviewer. Include:
1. **What changed** — 2-3 sentence summary of the changes
2. **Why** — the motivation (from the PR description)
3. **Files affected** — grouped by concern (e.g., "API changes", "test updates")
4. **Risk areas** — files or patterns that need careful review
5. **Testing** — what tests were added or modified
Run it with /pr-summary. The ! backtick commands execute immediately: gh pr view fetches the PR description, gh pr diff --name-only lists changed files, and gh pr diff --patch | head -100 shows the first 100 lines of the diff in patch format. Claude receives all this data pre-loaded and writes a structured summary.
The agent: Explore field runs this in the Explore agent, which is optimized for reading and analyzing without modifications.
Skill 4: Convention Enforcer (Background Knowledge)
Not every skill is a command you type. This skill teaches Claude your team's conventions and activates automatically when Claude detects relevant work. The user-invocable: false field hides it from the / menu because running /api-conventions as a command doesn't make sense — it's reference material, not a task.
Create .claude/skills/api-conventions/SKILL.md in your project:
---
name: api-conventions
description: REST API design conventions. Use when creating or modifying API endpoints, route handlers, or HTTP response formats.
user-invocable: false
---
## API Design Rules
When writing API endpoints, follow these conventions:
### URL Structure
- Use kebab-case for URL paths: `/user-profiles`, not `/userProfiles`
- Plural nouns for collections: `/users`, not `/user`
- Version in the URL path: `/v1/users`
- Nest resources to show relationships: `/users/123/orders`
### Response Format
Every response follows this structure:
json
{
"data": {},
"meta": {
"request_id": "uuid",
"timestamp": "ISO8601"
},
"errors": []
}
### HTTP Methods
- GET: read (never mutate)
- POST: create (return 201)
- PUT: full replace (return 200)
- PATCH: partial update (return 200)
- DELETE: remove (return 204, empty body)
### Error Handling
- 400: validation errors (include field-level details)
- 401: missing or invalid authentication
- 403: authenticated but not authorized
- 404: resource not found
- 429: rate limited (include Retry-After header)
- 500: internal error (log details, return generic message)
plaintext
This skill loads automatically when you ask Claude to build an API endpoint, modify a route handler, or review HTTP response formats. Claude reads the description, decides the skill is relevant, and incorporates the conventions into its work. You never invoke it — Claude handles that.
Skill 5: Commit With Conventions
This skill enforces your team's commit message format. The $ARGUMENTS placeholder lets you pass an optional description that Claude incorporates into the commit message.
Create ~/.claude/skills/commit/SKILL.md:
---
name: commit
description: Create a conventional commit
argument-hint: "[optional description]"
disable-model-invocation: true
---
Create a git commit following these conventions:
1. Run `git diff --staged` to see what's being committed
2. If nothing is staged, stage all modified files with `git add -A`
3. Write a commit message in Conventional Commits format:
():
[optional body]
[optional footer]
Types: feat, fix, docs, style, refactor, test, chore, perf, ci
Scope: the module or area affected (e.g., auth, api, ui)
Description: imperative mood, lowercase, no period, under 72 chars
4. If the user provided context: $ARGUMENTS — incorporate it into the message
5. Create the commit
6. Show the commit hash and message
Run /commit for an automatic message based on the diff, or /commit fixed the race condition in token refresh to include your context. The disable-model-invocation: true field prevents Claude from committing on its own — commits should always be deliberate.
Organizing Your Skills
After building a few skills, you'll want a system. Here's what works:
Personal skills (~/.claude/skills/) for workflows you use everywhere: commit conventions, issue fixing, PR summaries, code explanations.
Project skills (.claude/skills/) for team conventions: API standards, testing patterns, deployment procedures. Commit these to git so your whole team benefits.
Skills support individual argument access with $ARGUMENTS[0], $ARGUMENTS[1] (or shorthand $0, $1) when you need positional parameters. The ${CLAUDE_SKILL_DIR} variable resolves to the skill's directory, useful for referencing bundled scripts.
Keep each SKILL.md under 500 lines. If a skill needs detailed reference material, move it to supporting files in the same directory and reference them from your SKILL.md:
## Additional resources
- For complete API details, see [reference.md](reference.md)
- For usage examples, see [examples.md](examples.md)
Claude reads these files on demand without loading everything into context.
The Pattern Behind Good Skills
Every skill in this article follows the same structure: a clear trigger (when to use it), scoped permissions (what Claude can do), and step-by-step instructions (what Claude should do). The skills that save the most time are the ones you would otherwise explain manually in every session.
Start with whatever you type most often. If you explain your deployment process to Claude every Monday, that's a skill. If you paste the same testing checklist into every PR review, that's a skill. If you describe your error handling conventions every time you build a new endpoint, that's a skill.
Five skills. Ten minutes each. Hours saved every week.
Follow @klement_gunndu for more Claude Code content. We're building in public.
SOCIAL SHARE CARD GENERATOR