Where to Find Claude Skills and What to Check Before Installing

A Claude plugin can include hooks that run shell commands automatically. Read those before you read the sales pitch.

If you run a small SaaS, start with Anthropic’s plugin marketplace, then search independent directories for narrower tasks. But finding a useful listing and deciding to install it are separate jobs.

Before you connect a skill or plugin to your product, you should be able to explain what it can read, change, and execute. A badge, a price, or a polished description won’t answer that for you.

What is a Claude skills marketplace?

A Claude skills marketplace helps you find reusable instructions and extensions for Claude, but the listings can contain different kinds of software. Some directories list individual skills. Others list plugins that bundle several parts together.

Cult of Claude describes a skill as a folder containing a SKILL.md file that teaches Claude Code a procedure. That procedure might cover reviewing a pull request, writing a database migration, or using a testing tool. Claude can load a skill when you request it by name or when its description matches your task.

The same directory distinguishes four related pieces:

• Skills teach Claude how to carry out a task.
• Agents define a separate assistant with its own instructions, tools, and conversation context.
• Hooks run shell commands when certain events happen.
• MCP servers connect Claude to additional tools and services.

A plugin can bundle skills and agents alongside other parts. That matters because the useful procedure advertised on a listing may be only one part of what you install.

For example, “help me review code” describes the outcome you want. It doesn’t tell you whether the package also connects to a remote service or runs a command automatically.

Search for the task first, then identify what the listing actually contains. Are you copying a folder of instructions? Installing a bundle? Connecting a service that needs an account?

You don’t need to memorize the vocabulary. You do need to know which pieces you’re adding. Otherwise, you can’t judge whether the access they need makes sense for the job.

Where should you look for Claude skills?

Start with Anthropic’s plugin marketplace for listed plugins carrying an “Anthropic verified” label. The supplied page includes frontend-design, Superpowers, code-review, context7, playwright, and github.

Those listings give you useful starting points for familiar SaaS work. You can look for help with interface work, debugging, code review, documentation lookup, or browser testing without starting from an unknown repository.

If you can’t find a close match, widen the search:

• Build with Claude indexes community-maintained marketplaces for Claude Code plugins and skills. Use it to discover collections beyond the official marketplace.
• Cult of Claude lists skills and agents found on public GitHub. It says entries show their source, the tools they touch, and an install command.
• SKILLS.pub describes itself as a third-party marketplace with more than 10,600 collected skills. It separates sponsored placements from its other listings.
• Agensi offers free and paid skills and advertises security scanning. Its listings include business tasks as well as coding work.

Use those sites to find candidates, not to make the final install decision. A directory description can help you reject an obvious mismatch. The source files help you judge the candidate that remains.

For a small SaaS, write down the task before browsing. “Check this signup flow in a browser” gives you a clearer search than “best Claude skills.”

Stop when you find a plausible match you can inspect. You’re trying to remove recurring work, not assemble a collection. Another hour of browsing won’t tell you whether the first candidate works on your product.

A verified label doesn’t describe every permission

The supplied Anthropic marketplace labels plugins “Anthropic verified,” but its listing excerpt doesn’t explain the checks behind that label. You can use the label to guide your search without treating it as a complete answer about safety.

The descriptions themselves show why you still need to inspect access. The github plugin advertises repository management through GitHub’s API. The playwright listing describes browser actions, including filling forms and clicking elements. The context7 listing connects to a hosted remote server and asks users to authenticate when prompted.

Those are different jobs with different access needs. Whether a plugin fits your setup depends on what you connect and what you allow it to do.

The same caution applies to other marketplace signals. Agensi advertises “Security scanned” and lists both free and paid downloads. The supplied page doesn’t describe the scan’s coverage. A price tells you what the download costs, not whether its commands fit your project.

Sponsored placement answers another question again. SKILLS.pub says authors pay for sponsored placements, while ranking and indexing aren’t for sale. That’s useful disclosure about discovery. It doesn’t replace reading the files.

Keep these questions separate:

• Who listed or checked the package?
• What does the package contain?
• What access would you give it in your setup?

A badge may help answer the first question. It cannot answer the other two on its own.

Don’t assume a verified plugin needs unrestricted access. Don’t assume a paid skill deserves production credentials. Judge the actual package against the actual task you want it to perform.

Read the files, tool access, and hooks before installing

Hooks can run shell commands on lifecycle events, according to Cult of Claude’s description of Claude extensions. That makes hooks a separate review job from reading a skill’s written instructions.

Open the source repository before copying files or running the install command. Read the full SKILL.md, then follow references to scripts, configuration files, or other instructions. A short main file isn’t enough if it hands the work to something else.

Inspect three things:

1. Instructions and supporting files. What task does the skill tell Claude to perform? What files does it ask Claude to read or change? Does it tell Claude to fetch or run anything else?
2. Tools and connected services. Which tools does the package expose or request? Does it connect to a remote service? What account or credentials would that connection use?
3. Hooks and executable commands. What triggers each command? What does it run? Does the command make sense for the task you chose?

Write the answers in ordinary language. “It reads the selected code and proposes edits” is useful. “It improves developer productivity” tells you nothing about access.

For a documentation lookup tool, check where the documentation comes from and whether authentication is required. For browser testing, check which site and account you intend to use. For repository tools, decide which repository they should reach.

You don’t have to prove every line harmless to notice a mismatch. If a narrow writing task asks for access you can’t explain, stop and investigate.

If you can’t understand a command, don’t run it against your live product to find out what it does. Choose a simpler package, ask for help reviewing it, or do the task without it.

Which Claude skill should you try first for your SaaS?

Choose the task you repeat and can check yourself. Anthropic’s marketplace lists several candidates, but their descriptions point to different uses rather than one universal starter pack.

Match a candidate to a current problem:

• Code review: code-review advertises pull request reviews using multiple specialized agents and confidence-based scoring. Try it on a change you already understand.
• Debugging and tests: Superpowers describes skills for test-driven development, debugging, and collaboration. Start with one reproducible bug.
• Interface work: frontend-design describes a skill for UI and UX implementation. Give it a bounded screen or component.
• Browser checks: playwright advertises page interaction, screenshots, form filling, and automated browser testing. Use a test flow with a clear expected result.
• Documentation lookup: context7 describes version-specific documentation and examples from source repositories. Check its answer against the documentation it retrieves.

These are starting points, not claims that any package will improve your work. Your test has to settle that.

If writing eats more of your week than coding, choose an equally narrow content task. For example, ask a candidate to draft a release note from an approved product change. Don’t start by asking it to run your whole marketing process.

For content, define the inputs and checks yourself: approved sources, links beside claims, and no invented product features. Treat that as your test brief, not something a marketplace badge promises.

Pick one recurring task with an output you can judge. “Draft this release note from these changes” is testable. “Make us more visible” leaves too much room for convincing-looking work that doesn’t help you publish anything.

How do you install and test a Claude skill safely?

Test a Claude skill in a throwaway project without production credentials or customer data. Give it only the access needed for the task, and inspect the result before considering wider use.

Cult of Claude describes two locations for plain skill folders: ~/.claude/skills/ for use across projects, and a repository’s .claude/skills/ directory for that project. It also says agents go in ~/.claude/agents/ as individual files.

Those instructions describe plain files, not every plugin install. Build with Claude separately shows /plugin marketplace add commands for adding marketplace sources. Check which kind of item you found before following its instructions.

For your first test, use this sequence:

1. Inspect the install command. Confirm its source, what it downloads, and where it writes files. Don’t run a command you can’t explain.
2. Prepare a disposable project. Use sample inputs and remove live credentials. Choose project-level placement for a plain skill when that fits the test.
3. Set a narrow task. Give the skill a known bug, a sample screen, or an approved source document.
4. Review the run and output. Check changed files, commands, connections, and any request for more access.

Decide what success looks like before you start. A debugging test might require an explanation you can verify and a test you can run. A writing test might require every factual claim to match the supplied sources.

Keep access narrow even if the first result looks good. A useful draft or a passing test doesn’t explain every part of the package.

The first run should answer two questions: did it help, and did it stay within the boundaries you set?

Keep only the skills that pass a repeatable test

Keep a Claude skill only if you can check its work and explain its access. A marketplace listing tells you what the author promises; a repeatable test tells you whether the package helps with your task.

Cult of Claude says its entries link to public repositories and that installing means copying the author’s files onto your machine. Treat the reviewed files as the thing you approved, rather than approving a name forever. If you later replace those files, review what changed before using the replacement.

Write a short record after the trial:

• What task did you give it?
• Which files and services could it reach?
• What did it change or run?
• What did you have to correct?

You don’t need a complicated scorecard. You need enough detail to decide whether you’d trust the same setup with the same task again.

For code, inspect the diff and run the relevant tests yourself. For content, check the claims, links, and product details against the approved material. Don’t count a polished answer as proof that the underlying work is right.

If the skill helps, keep its job narrow while you test it again. If it creates more review work than it removes, take it out. There’s no prize for keeping a package installed.

Start with one recurring task, one inspected package, and one disposable test. That gives you a useful next step without handing an unfamiliar extension your live product.

Before you connect anything important, finish this sentence: “This package can read these files, change these things, and run these commands.” If you can’t finish it, don’t connect it yet.