Claude Code Skills: The Complete Practical Guide to Creating, Using, and Managing Them

At a glance

• What they are: Reusable folders containing instructions, references, and optional scripts that help Claude Code perform specific tasks consistently.
• Main file: SKILL.md
• Personal skills: ~/.claude/skills/
• Project skills: .claude/skills/
• How to run one: Use /skill-name, or let Claude load it automatically when your request matches its description.
• Key controls: description, disable-model-invocation, allowed-tools, disallowed-tools, and context: fork.
• Best use cases: Code review, testing, debugging, documentation, commit messages, deployment checklists, and team conventions.

Most developers eventually notice the same pattern: they keep pasting the same instructions into Claude Code. “Review this diff for security issues.” “Check whether the tests cover the new behavior.” “Follow our release checklist.” “Write a commit message using our team’s conventions.”

Those repeated instructions work, but they are inefficient. They consume time, produce inconsistent results, and remain trapped in individual conversations. Claude Code skills solve that problem by turning recurring guidance into a named, reusable, versionable unit that Claude can load when it is needed.

This guide explains what skills are, how to create them, where to store them, how to control when they run, how to avoid context and security problems, and how to build a small set of skills that genuinely improves day-to-day development.

If you’re still deciding which Anthropic product best suits your work, read our comparison of Claude AI, Claude Code, and Claude Cowork.

What Claude Code skills are

A Claude Code skill is a directory containing a required SKILL.md file. That file combines metadata and instructions in a simple, readable format.

The metadata appears in YAML frontmatter at the top of the file. It tells Claude what the skill is called, what it does, and when it should be used. The Markdown body contains the actual instructions Claude follows once the skill is active.

A minimal skill looks like this:

---
name: code-review
description: Examines code changes to identify bugs, security vulnerabilities, and gaps in test coverage. Use when reviewing a diff or pull request.
---

# Code Review

1. Inspect the relevant code and recent changes.
2. Identify likely bugs and security risks.
3. Check error handling, edge cases, and test coverage.
4. Prioritize findings by severity.
5. Reference affected files and explain each finding.
6. Suggest fixes without changing files unless explicitly requested.

That is enough to create a usable skill. Claude can discover it through its description, or you can invoke it directly with:

/code-review

Skills become more powerful when you add supporting material. A code-review skill might include a detailed security checklist, examples of good and bad review comments, and a script that runs linters against changed files.

code-review/
├── SKILL.md
├── security-checklist.md
├── review-examples.md
└── scripts/
    └── lint_changed_files.sh

The main SKILL.md file should contain the workflow. Supporting files should contain detail that is useful only in specific situations. This structure keeps the primary instructions focused while still allowing the skill to be comprehensive.

Why skills matter

Without skills, every recurring workflow depends on someone remembering to provide the right instructions. That creates several problems.

First, it wastes time. A developer may type or paste the same review checklist dozens of times per week.

Second, it creates inconsistency. One person may ask for security findings, another may ask for test coverage, and another may ask only for general feedback. The output changes depending on who asks and how carefully they phrase the request.

Third, it makes team knowledge fragile. If the release process lives in one senior engineer’s head, or in a Slack message from six months ago, new team members cannot reliably benefit from it.

Skills address all three problems. They preserve the process, make it repeatable, and allow a team to review and improve it like any other piece of project infrastructure.

A skill is not magic, however. It does not guarantee that Claude will perform every step perfectly. Claude still needs access to the relevant files, clear instructions, and enough context to understand the task. Important changes should still be reviewed, and results should be validated with tests, builds, or other evidence.

Skills vs. prompts

A prompt handles an immediate request. A skill preserves a repeatable process.

Feature	Prompt	Claude Code skill
Reuse	Copy or rewrite it	Save, name, and reuse it
Structure	Usually standalone text	Instructions, references, and optional scripts
Activation	Enter the request	Slash command or automatic matching
Consistency	Depends on wording	Uses a defined procedure
Team value	Limited	Can be committed, reviewed, and shared
Maintenance	Easy to lose	Versioned alongside code
Best for	One-off tasks	Repeatable workflows

Consider a simple example. You might repeatedly ask:

Review my changes. Look for security issues, missing tests, poor error handling, and anything that could break production.

That works, but it must be repeated every time. With a skill, you define the process once:

---
name: production-review
description: Reviews uncommitted changes for production risks, including security issues, missing tests, poor error handling, and unsafe configuration changes. Use when reviewing a diff before merge or deployment.
---

# Production Risk Review

1. Inspect the current diff and affected files.
2. Identify security risks such as injection, unsafe deserialization, secrets in code, or improper authorization.
3. Check error handling and failure paths.
4. Identify missing or inadequate tests.
5. Flag configuration, migration, or dependency changes that could affect production.
6. Report findings by severity: critical, high, medium, and low.
7. Include file references and a short explanation for each finding.
8. Do not modify files unless explicitly asked.

Now the workflow has a name, a consistent structure, and a clear activation condition.

How Claude Code skills load

Claude Code skills use progressive disclosure. Claude does not read the full contents of every skill at the beginning of every session. Instead, information is loaded in layers.

Layer	When it loads	What it contains
Metadata	Listed for relevant skills	Skill name and description
Instructions	When the skill triggers	The body of SKILL.md
Resources and scripts	Only if needed	Reference files, templates, and executable helpers

This design matters because context is finite. Every skill’s metadata can occupy space in the model’s context, while the full body is loaded only when the skill is actually used.

That has an important practical consequence: descriptions are not decoration. They are the primary mechanism Claude uses to decide whether a skill is relevant.

A weak description:

description: Helps with code.

A strong description:

description: Reviews uncommitted changes for bugs, security issues, and missing tests. Use when the user asks to review a diff, pull request, or recent code changes.

The second description includes the task, the likely user request, and the relevant artifacts. That makes automatic discovery much more reliable.

Context cost and skill collections

Skills are inexpensive while idle compared with placing every procedure in CLAUDE.md, but they are not free. For skills Claude can invoke automatically, names and descriptions may be present in context on every turn.

A large collection of broad, overlapping skills can therefore reduce the space available for your actual request, code, and conversation history. It can also make discovery worse: when many skills have similar descriptions, Claude has more difficulty choosing the right one.

Follow these rules:

• Create a skill only for a workflow you repeat often.
• Keep descriptions short, specific, and keyword-rich.
• Avoid creating multiple skills that overlap heavily.
• Move detailed reference material into supporting files.
• Disable or remove skills you no longer use.
• Use manual invocation for actions that should not happen automatically.

A focused set of five to fifteen high-quality skills is usually more valuable than a directory containing dozens of vague ones.

Create your first skill

Start with one task you perform repeatedly. If you’re comparing AI-assisted development environments before committing to a workflow, see our Claude Code vs Cursor comparison. Avoid building a giant “do everything” skill. A good first skill might handle code review, test generation, commit messages, debugging, or documentation.

Step 1: Choose the scope

Ask yourself:

• Do I perform this task repeatedly?
• Does it have steps that should be consistent?
• Would a named procedure help me or my team?
• Does it need information that Claude does not already have?
• Should it be available across projects or only in one repository?

If the answer to most of these questions is yes, a skill is appropriate.

Step 2: Create the directory

For a personal skill available across your projects:

mkdir -p ~/.claude/skills/code-review

For a project-specific skill that can be committed to the repository:

mkdir -p .claude/skills/code-review

The directory name usually becomes the default command name. In the examples above, both create a skill invoked as:

/code-review

You can also explore our guide to Claude Code commands to understand how commands and reusable workflows fit into everyday development.

Step 3: Add SKILL.md

Create a file named exactly SKILL.md inside the directory.

---
name: code-review
description: Reviews code changes for bugs, security issues, and missing tests. Use when reviewing a diff or pull request.
---

# Code Review

## Scope

Review the relevant code changes without modifying files unless the user explicitly asks for edits.

## Steps

1. Identify the files and changes under review.
2. Understand the intended behavior of the change.
3. Inspect the diff for correctness, security, performance, and maintainability.
4. Check error handling and edge cases.
5. Evaluate whether important behavior is covered by tests.
6. Identify unclear naming, duplicated logic, or unnecessary complexity.
7. Prioritize findings by severity.
8. Reference affected files and line-level areas where useful.
9. Suggest concrete fixes, but do not apply them unless requested.

## Output format

Return findings in this order:

1. Summary
2. Critical issues
3. High-priority issues
4. Medium-priority issues
5. Low-priority suggestions
6. Missing test coverage
7. Recommended next steps

The YAML frontmatter provides the skill’s name and description. The Markdown body gives Claude a repeatable procedure.

Step 4: Invoke and test it

Start Claude Code in the appropriate project and run:

/code-review

You can also ask naturally:

Review my recent changes for security and testing gaps.

To streamline the broader developer workflow, explore our guide to Claude Code shortcuts and faster AI-assisted development.

If the skill does not activate, invoke it directly first. That helps distinguish a discovery problem from an instruction problem.

If Claude finds the skill but does not follow it well, improve the body. Add explicit steps, examples, output requirements, and boundaries.

Step 5: Refine with real usage

The first version of a skill is a hypothesis. Treat it like software: use it, observe where it fails, and revise it.

Common refinements include:

• Adding examples of desired output.
• Clarifying ambiguous terms such as “risky” or “important.”
• Specifying what Claude should do when information is missing.
• Defining whether it may run tests or commands.
• Moving long reference material into separate files.
• Removing instructions Claude already knows or does not need.

Where to store skills

The location determines who can use the skill and in which contexts it is available.

Location	Purpose
~/.claude/skills/	Personal skills available across your projects
.claude/skills/	Project skills shared through the repository
Plugin skill directories	Skills distributed through a Claude Code plugin
Enterprise managed settings	Skills deployed across an organization
claude.ai account	Skills available in eligible Claude surfaces and sessions

Personal skills

Personal skills live in:

~/.claude/skills/

Use them for preferences and workflows that are useful across many repositories. Examples include:

• Your preferred code-review style.
• A personal commit-message format.
• A debugging routine.
• A documentation checklist.
• A generic test-generation process.

Personal skills are convenient, but they are not automatically available to teammates.

Project skills

Project skills live in:

.claude/skills/

Use them for repository-specific standards and workflows. Examples include:

• How to run the project’s tests.
• How to add a new API endpoint.
• How to write database migrations.
• How to deploy to staging.
• How to follow the team’s code-review process.

Project skills should usually be committed to version control. That makes them visible, reviewable, and maintainable by the whole team.

Plugins and enterprise distribution

For broader distribution, skills can be packaged in plugins or delivered through managed settings. This is useful when an organization wants to provide standard skills to many developers while retaining central control.

When a workflow also needs access to external tools or services, our guide to Claude Code MCP servers explains how Model Context Protocol integrations extend its capabilities.

Plugin skills are typically namespaced, which helps avoid naming conflicts with local or project-level skills.

Useful frontmatter fields

Most skills only need name and description, but Claude Code supports controls for invocation, permissions, execution behavior, and more.

Field	Purpose
name	Command name in the / menu; defaults to the directory name
description	Explains what the skill does and when to use it
disable-model-invocation	Makes the skill manual-only
user-invocable	Hides the skill from the / menu while still allowing Claude to use it
allowed-tools	Pre-approves listed tools for the turn that invokes the skill
disallowed-tools	Removes tools while the skill is active
context: fork	Runs the skill in a separate subagent
paths	Limits automatic activation to matching files or directories
argument-hint	Provides an autocomplete hint for arguments
arguments	Defines named positional arguments
model	Overrides the model for the invoking turn
hooks	Registers hooks while the skill is active

You do not need to use every field. In fact, the best skills often use only a few.

Control who can invoke a skill

By default, both you and Claude can trigger a skill. Two frontmatter fields change that behavior.

Frontmatter	You can invoke	Claude can invoke	Context behavior
Default	Yes	Yes	Description may be listed; body loads on use
disable-model-invocation: true	Yes	Not on its own	Description is not listed; body loads when invoked
user-invocable: false	No	Yes	Claude can load it, but it is hidden from the / menu

Manual-only skills

Add disable-model-invocation: true to prevent the model from automatically invoking actions that require deliberate execution.

Good candidates include:

• Deploying to staging or production.
• Creating a release.
• Running destructive database operations.
• Committing code.
• Sending notifications.
• Performing a costly full-project audit.

Example:

---
name: deploy-staging
description: Deploys the current project to the staging environment.
disable-model-invocation: true
---

# Deploy to Staging

1. Confirm the target branch and current commit.
2. Run the project’s test suite.
3. Build the application.
4. Deploy to staging using the approved deployment command.
5. Report the deployment status and any errors.
6. Do not deploy to production.

This prevents Claude from deciding on its own that the code looks ready to deploy.

Background knowledge skills

Use user-invocable: false for reference material that Claude should be able to use but that does not make sense as a slash command.

Examples include:

• A legacy-system explanation.
• Internal API conventions.
• A glossary of domain terms.
• A guide to an unusual architecture.

Understand allowed-tools

allowed-tools is one of the most misunderstood skill features.

It does not turn a skill into a strict tool whitelist. The listed tools receive pre-approved access for the turn when the skill runs, eliminating repeated authorization prompts. Other tools remain available, and your normal permission settings still apply.

For example:

---
name: commit
description: Stages and commits the current changes.
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

This tells Claude Code that the skill may use those Git commands without prompting during that invocation. It does not say that Claude may use only those tools.

If you want to prevent Claude from using certain tools while a skill is active, use disallowed-tools. For broader restrictions, use permission deny rules.

Skills vs. CLAUDE.md, hooks, and subagents

Claude Code provides several ways to shape behavior. Choosing the right one prevents wasted context and unreliable automation.

Mechanism	Loads when	Best for	Enforcement
CLAUDE.md	Every session	Architecture, conventions, test commands	Advisory
Skills	When relevant or invoked	Task-specific procedures and reference material	Advisory
Hooks	When their event fires	Rules that must always run	Deterministic
Subagents	When work is delegated	Isolated tasks with separate context	Configuration-dependent
Plugins	When enabled	Packaging skills, agents, hooks, and tools	Bundles multiple capabilities

Use CLAUDE.md for persistent context

CLAUDE.md is best for information Claude should know in nearly every session:

• Project architecture.
• Common commands.
• Coding conventions.
• Test commands.
• Important constraints.
• Directory structure.

Example:

# Project conventions

- Use TypeScript strict mode.
- Run `pnpm test` before suggesting a change is complete.
- Place API route handlers in `src/app/api`.
- Use Zod for request validation.
- Do not introduce new state-management libraries without discussion.

Use skills for procedures

Use a skill when the information is procedural and task-specific:

• “How to review a pull request.”
• “How to add a new endpoint.”
• “How to investigate a failed deployment.”
• “How to write a migration.”
• “How to prepare a release.”

Use hooks for mandatory behavior

Skills are advisory. Claude may follow them imperfectly, especially in long sessions. If something must happen every time, use a hook.

For a deeper look at event-driven automation, configuration, and guardrails, see our complete guide to Claude Code hooks.

For example, if every commit must run formatting and tests, a hook is more reliable than a skill instruction saying “please run tests before committing.”

Use subagents for isolation

Use context: fork when a skill should run in a separate subagent. This can be useful for research, large analyses, or tasks where you do not want the main conversation context to become overloaded.

A forked subagent does not automatically see the full conversation history. Therefore, the skill must contain enough information to stand alone.

Dynamic context injection

Developers can use shell-command injection to supply context that changes dynamically when a Claude Code skill runs. This lets a skill insert live information, such as the current Git diff, before Claude reads the instructions.

Example:

---
description: Summarizes uncommitted changes and flags risky changes. Apply this whenever the user asks about code modifications, requests a commit message, or wants their diff examined.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes in two or three bullet points.

Then list risks such as:

- Missing error handling
- Hardcoded values
- Security concerns
- Missing tests
- Potentially breaking API changes

If no differences are found, report that the working tree has no uncommitted changes.

The !git diff HEAD line runs before the skill is presented to Claude. Claude receives the actual diff output rather than an instruction to go find it.

This is powerful, but use it carefully:

• Inject only the context Claude needs.
• Avoid commands that produce enormous output.
• Remember that a failing command can abort the invocation.
• Review commands before adopting a third-party skill.
• Pre-approve required commands with allowed-tools when appropriate.

Best skills to create first

Start with a small set of skills that remove repeated work. These are practical starting points, not claims that every skill is included by default.

1. Code review

A code-review skill should produce consistent, prioritized feedback.

---
name: code-review
Description: Examines code changes for bugs, security vulnerabilities, maintainability concerns, and gaps in test coverage. Use when reviewing a diff or pull request.
---

# Code Review

1. Inspect the relevant diff and affected files.
2. Understand the intended behavior.
3. Identify correctness, security, performance, and maintainability issues.
4. Check error handling and edge cases.
5. Evaluate test coverage.
6. Prioritize findings by severity.
7. Reference affected files.
8. Suggest fixes without changing files unless requested.

Ask for prioritized findings rather than a vague quality score.

2. Test generation

A test-generation skill should focus on behavior, not merely line coverage.

---
name: generate-tests
description: Creates focused tests for uncovered behavior in the specified code. Use when the user asks for tests, coverage improvements, or regression protection.
---

# Test Generation

1. Identify the behavior that needs testing.
2. Inspect existing tests and testing conventions.
3. Write focused tests for important paths and edge cases.
4. Run the relevant test command.
5. Distinguish tests that were executed from tests that were only recommended.
6. Report failures and likely causes.

3. Debugging

A debugging skill should discourage guessing.

---
name: debug
description: Investigates a reported bug by reproducing it where possible, inspecting relevant code and logs, forming a hypothesis, and verifying the fix.
---

# Debugging

1. Restate the reported problem.
2. Gather relevant error messages, logs, and reproduction steps.
3. Inspect the likely affected code paths.
4. Form one or more specific hypotheses.
5. Verify each hypothesis with evidence.
6. Propose the smallest reasonable fix.
7. Identify tests that would prevent regression.

4. Documentation

A documentation skill should use the actual codebase rather than assumptions.

---
name: update-docs
description: Updates project documentation based on the current codebase. Use when the user asks to update a README, setup guide, API documentation, or contributor instructions.
---

# Documentation Update

1. Identify the documentation files that need changes.
2. Inspect the relevant source code, configuration, and scripts.
3. Update only documentation supported by the codebase.
4. Preserve accurate existing content.
5. Flag assumptions that require human confirmation.
6. Provide a concise summary of changes.

5. Commit messages

A commit-message skill is useful for consistency.

---
name: commit-message
description: Generates a clear commit message from staged or uncommitted changes. Apply this when the user needs a commit message or an overview of the modifications made.

---

# Commit Message

1. Inspect the diff.
2. Identify the primary purpose of the change.
3. Write a concise subject line.
4. Add supporting details only when useful.
5. Follow the repository’s existing commit-message conventions.
6. Do not commit unless explicitly asked.

6. Release checklist

A release skill should focus on evidence, not optimism.

---
name: release-check
description: Checks whether the project is ready for release by reviewing tests, build status, migration notes, documentation, and unresolved risks.
---

# Release Checklist

1. Identify the changes included in the release.
2. Check test status and coverage concerns.
3. Verify build and deployment requirements.
4. Review migration or configuration changes.
5. Check documentation and changelog needs.
6. List unresolved risks.
7. Recommend whether the release is ready, with evidence.

Write skills that hold up

A good skill is focused, discoverable, concise, and testable.

1. Solve one problem

Do not create a skill called engineering that handles code review, testing, deployment, documentation, and debugging. Split those into separate skills.

A skill should have a clear purpose:

• code-review
• generate-tests
• debug
• update-docs
• release-check

2. Write a useful description

The description should answer two questions:

1. What does this skill do?
2. When should Claude use it?

Use language that matches how a developer would naturally ask for the task.

Description: Inspects uncommitted changes for bugs, security vulnerabilities, and gaps in test coverage. Use when reviewing a diff, pull request, or recent code changes.

3. Make steps actionable

Avoid vague instructions such as:

Check the code carefully.

Use specific instructions:

Check authentication, authorization, input validation, error handling, secrets handling, and unsafe data serialization.

4. Define boundaries

State what the skill may and may not do.

Do not modify files unless explicitly requested.
Do not run destructive commands.
Ask before installing dependencies.
Report uncertainty instead of guessing.

5. Keep the main file lean

Keep the core workflow in SKILL.md. Move long checklists, examples, and reference documentation into separate files.

api-review/
├── SKILL.md
├── security-checklist.md
├── api-conventions.md
└── examples.md

6. Prefer scripts for deterministic work

If a task requires the same command every time, consider a script. Scripts can make behavior more repeatable and reduce the amount of code Claude needs to generate or hold in context.

Make it clear whether Claude should execute the script or read it as reference material.

7. Avoid stale instructions

Do not hard-code information that will quickly become wrong:

• Dates.
• Temporary tool versions.
• URLs that may change.
• Assumptions about a specific model version.
• Instructions tied to a short-lived experiment.

8. Verify outcomes

Require evidence for important claims.

Do not claim tests pass unless you ran them or can point to their output.
Do not claim a bug is fixed unless the fix has been verified.

Security and third-party skills

Treat third-party skills like dependencies, not harmless documentation. A skill can influence how Claude uses tools, execute scripts, or request access to files and commands.

Before adopting a skill from a public repository, plugin, or teammate:

• Read its SKILL.md and every supporting script.
• Check whether it runs shell commands, accesses files, or makes network requests.
• Verify that its instructions match its stated purpose.
• Review allowed-tools carefully, especially in repository-provided skills.
• Look for destructive commands, credential access, or broad permissions.
• Test it in a safe environment before using it on important code.

Project skills can pre-approve tools through allowed-tools, so review them before running Claude Code in an unfamiliar repository.

For practical guidance on configuring external integrations, see our tutorial on Claude Code MCP server setup and configuration.

A useful rule is simple: if you would not blindly run a shell script from the same source, do not blindly install a skill from it either.

Evaluating a skill

Seeing a skill trigger does not prove it is useful. Claude may load the right skill but still produce weak output.

Evaluate skills on two dimensions:

1. Discovery: Does Claude choose the skill for the right requests?
2. Quality: Once loaded, does it produce the desired result?

A practical evaluation method:

1. Collect five to ten realistic prompts.
2. Run each prompt in a fresh session with the skill enabled.
3. Run the same prompts with the skill disabled.
4. Compare accuracy, completeness, consistency, and usefulness.
5. Revise the skill based on the differences.

This baseline comparison helps you determine whether the skill actually improves results or merely adds context overhead.

Troubleshooting

Problem	Likely cause	Fix
Skill never triggers	Weak description or malformed frontmatter	Make the description more specific; check YAML; invoke it directly
/skill-name is not recognized	Incorrect folder structure or invalid name	Confirm the directory and SKILL.md filename
Claude ignores part of the workflow	Vague or buried instructions	Use ordered steps, explicit constraints, and a defined output format
Skill is too expensive	Overly long body or too many skills	Move detail to reference files; prune unused skills
Inconsistent output	No completion criteria or examples	Add examples, output format, and verification steps
Unexpected file changes	Missing boundaries	State whether the skill may edit files or run commands
Skill triggers too often	Description is too broad	Narrow the description or make the skill manual-only
Skill triggers too rarely	Description lacks natural keywords	Include the task, artifacts, and likely user requests

Frequently asked questions

Q: What is a Claude Code skill?

A: A reusable folder containing a SKILL.md file and optional supporting resources. It helps Claude Code perform a specific workflow consistently.

Q: How do I create one?

A: Create a directory under ~/.claude/skills/ or .claude/skills/, add a SKILL.md file with YAML frontmatter and Markdown instructions, then test it with /skill-name or a matching request.

Q: Can skills run automatically?

A: Yes. Claude can select a skill when its description matches the task. You can also invoke it manually with /skill-name.

Q: Should I use a skill or CLAUDE.md?

A: Use CLAUDE.md for persistent project context and conventions. Use skills for procedures needed only for particular tasks.

Q: Does allowed-tools restrict Claude?

A: No. It pre-approves the listed tools for the invoking turn; it does not make them the only tools available. Use disallowed-tools or permission rules to restrict tool access.

Q: How long should SKILL.md be?

A: Keep it focused. A concise core workflow is better than a long document. Move detailed reference material into separate files when needed.

Q: Are third-party skills safe?

A: Not automatically. Review their instructions, scripts, permissions, and shell commands before use.

Q: Do I need a skill for every task?

A: No. Create one when a workflow is repeated often enough that consistent instructions save time or reduce errors.

Conclusion

Claude Code skills are most valuable when they encode real, repeatable work: a review rubric, a debugging method, a release checklist, or a documentation standard. They turn tribal knowledge into something that can be named, reused, reviewed, and improved.

Begin with one practical use case. Write a clear SKILL.md, use a specific description, define boundaries, and refine the skill using real results. Keep the collection small, prefer hooks for mandatory behavior, and treat third-party skills with the same caution as any other executable dependency.

The goal is not to accumulate the most skills. It is to maintain a small, trustworthy set that makes everyday development more consistent, shareable, and easier to verify.