How to create skills for Claude: a developer guide

Developers do not need Claude to be “smarter” in some vague way. They need Claude to follow the repo rules, remember the release process, run the right checks, review code the way the team reviews code, and stop asking for the same context every session.

That is where Claude Skills become useful.

A Claude Skill is a small package of instructions, examples, scripts, and supporting files that teaches Claude how to perform a specific workflow. For developers, that workflow might be code review, issue triage, test generation, migration planning, API design, release notes, local app verification, or security review.

This guide is written for developers who want to learn how to create skills for claude in a practical way. We will cover how SKILL.md works, where Claude Code loads Skills from, how to use the claude code skill-creator, how to add skills to Claude, how to test triggering, and when to use GitHub or a claude skills marketplace for examples.

By the end, you should be able to build a Skill that belongs in a real repo, not just a demo folder.

If you already know how Skills work and just want a shortlist of what is worth installing, the companion piece Best Claude Skills for developers ranks the Skills and GitHub repos worth studying first.

What are Claude Skills for developers?

A Claude Skill is a directory with a SKILL.md file inside it.

That sounds almost too simple, but the folder can become powerful. A Skill can include:

• instructions Claude should follow
• examples of good output
• repo conventions
• shell commands
• validation scripts
• templates
• architecture notes
• test fixtures
• release checklists
• security rules
• coding standards

For a developer, the most useful way to think about Skills is this:

A Skill is a reusable procedure Claude can load when the task matches the description.

Instead of pasting your code review checklist every time, you can make a code-review Skill. Instead of explaining your deployment process every sprint, you can make a deploy-staging Skill. Instead of telling Claude how to inspect a monorepo, you can create a monorepo-navigator Skill.

Skills are especially good for workflows that are:

• repeated often
• specific to your project or team
• easy to describe as steps
• improved by examples
• safer when Claude follows a known process
• too long to keep pasting into chat

A Skill should not be a random pile of tips. It should be a focused operating procedure.

Claude Skills vs CLAUDE.md

Many developers already use CLAUDE.md. So why use a Skill?

Use CLAUDE.md for broad project context. Use a Skill for a repeatable task.

Use CLAUDE.md for project facts

Good things to put in CLAUDE.md:

• project overview
• package manager
• common commands
• architecture summary
• testing approach
• important directories
• team preferences
• naming conventions

This is context Claude should know often.

Use Skills for workflows

Good things to put in Skills:

• “Review this PR like our senior engineer”
• “Generate a migration plan for this service”
• “Run our release checklist”
• “Analyze this Git diff”
• “Create an API endpoint following our conventions”
• “Debug a flaky Playwright test”
• “Prepare iOS release notes from commits”

This is action-oriented. Claude should load it only when the task needs it.

A simple rule: if the instruction starts to feel like a mini manual, make it a Skill.

The developer anatomy of a Claude Skill

A basic Skill looks like this:

my-skill/
  SKILL.md

A more useful developer Skill might look like this:

repo-reviewer/
  SKILL.md
  examples/
    good-review.md
    weak-review.md
  scripts/
    changed-files.sh
    check-tests.sh
  references/
    code-style.md
    security-checklist.md

Only SKILL.md is required. Everything else is optional.

The SKILL.md file usually has two parts:

1. YAML frontmatter
2. Markdown instructions

Here is the smallest possible version:

---
name: repo-reviewer
description: Review code changes for correctness, maintainability, security, and missing tests. Use when the user asks for a code review, PR review, diff review, or risk check.
---

# Repo reviewer

Review the current code changes and return:
- risky changes first
- missing tests
- possible bugs
- security concerns
- suggested fixes

Keep comments specific. Reference files and functions when possible.

That is a real Skill. Small, but real.

Why the description field matters

The description is not just documentation. It is the trigger.

Claude uses the Skill description to decide whether the Skill applies to the user’s request. If the description is too vague, Claude may not use the Skill. If it is too broad, Claude may use it when it should not.

Bad:

description: Helps with code.

Better:

description: Review code changes for correctness, maintainability, security, and missing tests. Use when the user asks for a code review, PR review, diff review, or risk check.

The better version includes:

• the task
• the expected review areas
• trigger phrases
• related user intents

When people search how to create skills for claude reddit, many of the useful discussions come down to this same issue: Skills fail when the trigger is fuzzy. Developers often write decent instructions but weak descriptions.

Write the description like you are teaching Claude when to reach for the tool.

How to create Skills for Claude Code

Claude Code is the developer-friendly place to start because Skills are filesystem based.

You can create personal Skills that work across projects or project Skills that live inside one repository.

Personal Skill

Use a personal Skill when you want it available everywhere:

mkdir -p ~/.claude/skills/repo-reviewer
touch ~/.claude/skills/repo-reviewer/SKILL.md

Personal Skills are useful for your own habits:

• commit message writer
• code review style
• debugging checklist
• refactor planner
• test case generator

Project Skill

Use a project Skill when the workflow belongs to a repo:

mkdir -p .claude/skills/api-endpoint-builder
touch .claude/skills/api-endpoint-builder/SKILL.md

Project Skills are useful for team conventions:

• API patterns
• release process
• monorepo package rules
• test commands
• deployment checklist
• database migration policy

If the Skill is part of how your team works, commit it to the repo. If it is just your personal preference, keep it under ~/.claude/skills/.

Create your first developer Skill

Here is a practical first Skill: a Git diff reviewer.

Create the folder:

mkdir -p ~/.claude/skills/summarize-changes

Create the file:

touch ~/.claude/skills/summarize-changes/SKILL.md

Add this content:

---
name: summarize-changes
description: Summarize uncommitted Git changes and flag risky edits. Use when the user asks what changed, wants a commit summary, wants a PR summary, or asks whether the current diff looks safe.
---

# Summarize changes

## Context

Review the current Git diff and explain what changed.

## Instructions

1. Start with a short summary of the change.
2. Group related edits together.
3. Call out risky changes first.
4. Mention missing or weak tests.
5. Suggest the smallest next step.
6. Do not invent files or behavior that is not visible in the diff.

## Output format

Return:

- Summary
- Files changed
- Risks
- Missing tests
- Suggested next step

Now open Claude Code in a Git repository and ask:

What changed in this repo?

You can also invoke the Skill directly:

/summarize-changes

That is the basic loop: create the directory, write SKILL.md, test it, then improve the trigger and instructions.

Add dynamic context for developer workflows

Developer Skills become more useful when they can pull fresh context.

For example, a Git review Skill can include a command that injects the current diff before Claude reviews it.

---
name: summarize-changes
description: Summarize uncommitted Git changes and flag risky edits. Use when the user asks what changed, wants a commit summary, wants a PR summary, or asks whether the current diff looks safe.
---

# Current diff

!`git diff HEAD`

# Instructions

Summarize the diff in plain English.

Call out:
- behavior changes
- risky files
- missing tests
- hardcoded values
- error handling gaps
- security concerns

If the diff is empty, say there are no uncommitted changes.

This is the kind of pattern developers should care about. The Skill does not rely on Claude guessing from open files. It pulls the live diff and makes the output more grounded.

Use dynamic context carefully. Commands should be predictable, safe, and easy to inspect.

Good commands:

git diff HEAD
git status --short
npm test
npm run lint
find . -maxdepth 2 -type f

Be careful with commands that mutate files, delete data, publish packages, or touch production systems. If your Skill needs to operate inside a repo that talks to multiple Git remotes, the conventions in Configuring multiple Git accounts are the kind of context the Skill should encode so Claude never picks the wrong identity.

Use allowed tools carefully

Claude Code Skills can include tool permissions. That can save time, but it can also create risk.

For example, a commit Skill might allow Git commands:

---
name: commit-local-changes
description: Stage and commit local changes after reviewing the diff. Use only when the user explicitly asks to create a commit.
disable-model-invocation: true
allowed-tools: Bash(git status *) Bash(git diff *) Bash(git add *) Bash(git commit *)
---

# Commit local changes

1. Run `git status --short`.
2. Review the diff.
3. Ask for confirmation if the commit scope is unclear.
4. Stage only relevant files.
5. Write a concise commit message.
6. Commit the changes.

Notice disable-model-invocation: true.

For risky actions, do not let Claude auto-trigger the Skill. Make the developer invoke it directly.

This is a better pattern for commands like:

• commit
• deploy
• publish
• migrate database
• rotate secrets
• modify infrastructure
• run expensive jobs

A Skill should reduce repeated work, not remove judgment. For deploy and release Skills specifically, anchor the safety rules to the validation work you already do — for example, the boot-time checks in Type-safe environment configuration for Next.js and EnvValidator for Laravel & PHP make natural pre-deploy steps to encode in a release Skill.

How to add Skills to Claude

The answer depends on where you want to use the Skill.

Add Skills to Claude Code

For Claude Code, add the Skill folder to one of these locations:

~/.claude/skills/<skill-name>/SKILL.md

or:

.claude/skills/<skill-name>/SKILL.md

Use personal Skills for your own setup. Use project Skills for repo-specific workflows.

After adding or editing a Skill, test it in Claude Code:

/skill-name

or ask a natural request that should trigger it.

Add Skills to Claude.ai

If you want to know how to add skills to claude in the Claude web app, the flow is different. You usually package the Skill folder as a ZIP file and upload it through Claude settings or the Skills area.

Use this structure before zipping:

repo-reviewer/
  SKILL.md
  examples/
    good-review.md

Then zip the repo-reviewer folder.

Do not zip only the contents. Claude should receive the folder with SKILL.md inside it.

Add Skills through the API

For product teams and platform developers, the Claude API is the more scalable route. You can create and manage custom Skills through API endpoints, then reference Skills from your application.

Use the API route when:

• Skills need to be shared across an app
• users should not upload ZIP files manually
• your team needs versioning
• you are building an internal developer platform
• your product has repeatable AI workflows

Claude Code is best for local development. The API is better when Skills become part of your product infrastructure. If you also run a self-hosted assistant outside Claude Code, What is OpenClaw (formerly Clawd AI, Moltbot)? shows a different shape of agent worth comparing against — useful when deciding what belongs in a Claude Skill versus a separate process.

Using claude code skill-creator

The claude code skill-creator is useful when you do not want to handwrite everything from scratch.

Use it to draft the first version of a Skill, but do not treat the generated result as final. A good Skill still needs a developer to review the trigger, tool permissions, commands, and examples.

Ask Claude Code something like:

Use the claude code skill-creator to create a project Skill called api-endpoint-builder. It should help generate Express API endpoints that follow this repo's validation, error handling, test, and folder conventions.

Then ask it to inspect the result:

Review this Skill for weak triggering, too-broad instructions, unsafe tool permissions, and missing tests.

The claude code skill-creator is strongest when you already know the workflow. If you only say “make me a coding Skill,” the result will be generic. If you describe the exact workflow, it can create a useful first draft.

Give it:

• the task name
• when the Skill should trigger
• when it should not trigger
• required commands
• output format
• examples of good output
• files Claude should read
• actions Claude must avoid

Developer Skill examples worth building

The best Claude skills for developers are boring in the best way. They capture repeated work.

Code review Skill

Use for:

• PR review
• risk review
• reviewing a diff before commit
• finding missing tests
• checking security issues

Suggested structure:

code-review/
  SKILL.md
  references/
    security-checklist.md
    testing-policy.md

Good trigger:

description: Review code changes for bugs, missing tests, security concerns, and maintainability. Use when the user asks for a PR review, code review, diff review, or pre-commit risk check.

API endpoint builder Skill

Use for:

• adding REST endpoints
• generating validation
• matching error format
• writing tests
• updating route docs

Suggested structure:

api-endpoint-builder/
  SKILL.md
  examples/
    user-route.good.ts
    user-route.bad.ts
  references/
    api-style.md

Good trigger:

description: Create or update API endpoints following this repo's routing, validation, error handling, response, and test conventions.

Test writer Skill

Use for:

• unit tests
• integration tests
• regression tests
• adding coverage for bug fixes

Suggested structure:

test-writer/
  SKILL.md
  references/
    test-patterns.md
  examples/
    service-test.example.ts

Good trigger:

description: Write or update tests for changed code. Use when the user asks to add tests, cover a bug, improve coverage, or create regression tests.

Monorepo navigator Skill

Use for:

• understanding package boundaries
• finding ownership
• identifying affected services
• planning safe changes

Suggested structure:

monorepo-navigator/
  SKILL.md
  scripts/
    list-workspaces.sh
    affected-packages.sh

Good trigger:

description: Help navigate this monorepo, identify affected packages, explain ownership boundaries, and plan changes across workspaces.

iOS development Skill

Searches for how to create skills for claude ios often mean one of two things: creating Skills from the iOS app, or building Skills for iOS development.

For developers, the better angle is iOS development. Create a Skill for:

• SwiftUI debugging
• Xcode build failures
• TestFlight release notes
• App Store review checklist
• accessibility audits
• migration from UIKit to SwiftUI
• Core Data or SwiftData changes

Example trigger:

description: Help debug iOS app issues in Swift, SwiftUI, Xcode, and TestFlight workflows. Use when the user asks about iOS build errors, simulator issues, release notes, or SwiftUI bugs.

For serious iOS Skills, include your minimum iOS version, package manager, architecture pattern, testing tools, and release workflow.

How to use Claude Skills GitHub download results safely

Searching claude skills github download is a good way to find examples, but do not install random Skills without reading them.

A Skill can include scripts. A Skill can also request tool permissions. That does not make it bad, but it means you need to inspect it like any other developer tool.

Before using a GitHub Skill, check:

• Does SKILL.md exist?
• Is the description specific?
• Are there scripts?
• Do the scripts mutate files?
• Do the scripts access secrets?
• Does the Skill request broad tool access?
• Is disable-model-invocation used for risky tasks?
• Does the repository have a license?
• Is the Skill maintained?
• Are examples included?

A safe workflow:

git clone <repo>
cd <repo>
find . -name "SKILL.md" -maxdepth 4

Then read the Skill before copying it into your local Claude folder.

For team use, create a review process. Treat shared Skills like code.

Should developers use a Claude skills marketplace?

A claude skills marketplace is useful for discovery. It can help you see how other developers structure Skills, name them, write descriptions, and organize examples.

But marketplace Skills should be treated as starting points.

Use marketplace Skills to learn:

• common folder patterns
• useful developer categories
• how Skills describe triggers
• how examples are bundled
• how official Skills organize support files
• what the community considers best Claude skills

Do not assume a marketplace Skill matches your repo. Your codebase has its own commands, folder layout, error patterns, test setup, deployment process, and security rules.

The best approach is:

1. Browse marketplace Skills for ideas.
2. Download or inspect one that matches your use case.
3. Copy only what you understand.
4. Rewrite the trigger and process for your repo.
5. Test it on real work.
6. Commit project Skills only after review.

Testing your Skill like a developer

Most weak Skills are not obviously broken. They produce something plausible. That is the problem.

Test Skills with real cases.

Trigger tests

Ask prompts that should trigger the Skill:

Review this diff before I commit.

Can you check this PR for missing tests?

What changed in this branch?

Then ask prompts that should not trigger it:

Explain what a Git diff is.

Write a blog post about code review.

Summarize this article about software teams.

If the Skill triggers too often, narrow the description. If it does not trigger enough, add better trigger phrases.

Output tests

Compare the result against your expected format.

Check:

• Did Claude follow the steps?
• Did it read the right context?
• Did it reference actual files?
• Did it avoid guessing?
• Did it flag real risks?
• Did it suggest practical next steps?
• Did it run commands safely?
• Did it avoid changing files without permission?

Regression tests

Keep a few test prompts in the Skill folder:

repo-reviewer/
  SKILL.md
  tests/
    should-trigger.md
    should-not-trigger.md
    expected-output.md

This is simple, but it helps when you revise the Skill later.

Common mistakes developers make with Claude Skills

Making one giant Skill

A giant “senior developer assistant” Skill sounds useful, but it usually becomes vague.

Make smaller Skills:

• code-review
• test-writer
• api-endpoint-builder
• release-checklist
• security-scan-helper

Small Skills trigger better and are easier to debug.

Writing vague descriptions

The description is the matching layer. Spend more time on it.

Weak:

description: Helps with tests.

Better:

description: Write or update unit and integration tests for changed TypeScript code. Use when the user asks to add tests, cover a bug, improve coverage, or create regression tests.

Putting everything in SKILL.md

If the Skill grows too large, split supporting material into files.

Use:

references/
examples/
scripts/
templates/

Then tell Claude when to read each file.

Allowing risky tools too early

Do not give broad tool permissions just because it saves a few prompts.

For risky actions:

• require direct invocation
• keep permissions narrow
• ask for confirmation
• prefer read-only commands first
• review project Skills before trusting a repo

Forgetting the human workflow

A Skill should match how developers actually work. If your team always runs pnpm test before pnpm build, put that order in the Skill. If PR reviews always check migrations, add that. If your API errors follow a custom format, include the example.

Generic Skills are fine for demos. Repo-specific Skills are where developers get value.

A production-ready Skill template for developers

Use this as a starting point.

---
name: developer-workflow-name
description: Describe the exact developer workflow and trigger phrases. Use when the user asks for [specific task], [related task], or [common phrase]. Do not use for [out-of-scope task].
---

# Developer workflow name

## When to use

Use this Skill when:
- the user asks for [specific workflow]
- the task involves [specific files or commands]
- the expected output is [specific format]

Do not use this Skill when:
- the user only wants a general explanation
- the task is unrelated to this repo
- the action would require unsafe changes without approval

## Inputs to inspect

Check these first:
- relevant source files
- tests
- config files
- package scripts
- recent Git diff
- linked issue or ticket, if provided

## Process

1. Restate the task in one sentence.
2. Inspect the relevant files or diff.
3. Follow the repo conventions.
4. Identify risks before making changes.
5. Make the smallest useful change.
6. Run or suggest the right validation command.
7. Summarize what changed and what still needs attention.

## Output format

Return:
- Summary
- Files touched
- Risks
- Validation
- Next step

## Safety rules

- Do not publish, deploy, or delete files unless explicitly asked.
- Do not invent commands.
- Do not assume secrets or environment variables.
- Ask before running destructive commands.
- Prefer read-only inspection before mutation.

How to make your article or Skill rank for this topic

If you are publishing content around how to create skills for claude, developer intent matters.

A general guide will compete with many surface-level tutorials. A developer-focused guide can rank by covering the details most posts skip:

• SKILL.md examples
• Claude Code folder paths
• personal vs project Skills
• direct /skill-name invocation
• dynamic context injection
• allowed-tools
• disable-model-invocation
• GitHub download safety
• marketplace evaluation
• testing trigger behavior
• API vs Claude Code differences
• iOS development Skills
• real developer templates

Use the primary keyword naturally:

• in the title
• in the meta title
• in the introduction
• in one H2
• in the FAQ
• in the slug

Use secondary keywords where they make sense:

• claude code skill-creator
• how to add skills to claude
• claude skills marketplace
• claude skills github download
• best claude skills
• how to create skills for claude ios
• how to create skills for claude reddit

Do not stuff them. Developers can smell SEO padding from a mile away.

Final developer checklist

Before you call a Skill done, check this:

• The Skill has one clear job.
• SKILL.md is in the correct folder.
• The description includes trigger phrases.
• The instructions are specific.
• Risky actions require direct invocation.
• Tool permissions are narrow.
• Examples are included when output quality matters.
• Scripts are readable and safe.
• The Skill works with real prompts.
• It does not trigger on unrelated prompts.
• Project Skills are reviewed before being committed.

A good Claude Skill feels boring after you finish it. That is the point. It turns a repeated developer workflow into a reliable command.

FAQ

What is the best way to create Skills for Claude as a developer?

The best way is to start with one repeated workflow, create a folder with SKILL.md, write a precise description, add step-by-step instructions, then test it in Claude Code with real prompts. Use supporting files only when they improve the workflow.

What is the claude code skill-creator?

The claude code skill-creator helps generate and refine Claude Skills. It is useful for drafting SKILL.md, improving descriptions, creating test cases, and checking whether a Skill is too broad or poorly triggered.

How do I add Skills to Claude Code?

Add the Skill folder under ~/.claude/skills/<skill-name>/SKILL.md for personal use, or .claude/skills/<skill-name>/SKILL.md inside a repository for project-specific use. Then invoke it with /skill-name or ask a matching natural language request.

How do I add Skills to Claude.ai?

Package the Skill folder as a ZIP file and upload it through Claude’s Skills or settings area. Make sure the ZIP contains the Skill folder with SKILL.md inside it.

Can I download Claude Skills from GitHub?

Yes. Search for claude skills github download or inspect Anthropic’s public Skills repository. Read every SKILL.md, script, and permission before installing anything from GitHub.

Should I use a Claude skills marketplace?

Use a claude skills marketplace for ideas and examples, not as a blind install source. Marketplace Skills are helpful for discovery, but your best production Skills should match your own repo, commands, tests, and team workflow.

What are the best Claude Skills for developers?

The best Claude skills for developers usually solve repeated repo tasks: code review, test writing, API endpoint creation, migration planning, release checklists, security review, monorepo navigation, iOS debugging, and Git diff summaries.

Can I create Skills for Claude iOS development?

Yes. For iOS developers, create Skills for SwiftUI debugging, Xcode build errors, TestFlight release notes, App Store review checklists, accessibility audits, and release workflows.

Related posts

• Best Claude Skills for developers — a ranked shortlist of Claude Code Skills worth installing or studying once you know how to build your own.
• What is OpenClaw (formerly Clawd AI, Moltbot)? — a different agent shape (local-first, messaging-app driven), useful when deciding what belongs in a Skill versus a standalone agent.
• Configuring multiple Git accounts — repo conventions worth encoding in a commit or PR-review Skill so Claude never picks the wrong identity.
• Type-safe environment configuration for Next.js — boot-time validation that pairs well with a release-checklist Skill.
• EnvValidator for Laravel & PHP — the same pattern for PHP repos, again a natural anchor for a deploy Skill.
• 20 JavaScript tricks every developer must know — useful baseline knowledge to reference inside language-specific code-review and refactor Skills.