How to Find, Share, and Run AI Skills in Codex or Claude Code

If you ask a coding agent to review a pull request, you might tell it which checks to run, what to look for in the diff, and how you want it to report findings. Do that on a few projects and you'll probably find yourself typing the same instructions. An AI skill puts that procedure into a folder you can read, reuse, and share. The main file is called SKILL.md, and the folder can include supporting references or examples.

We built the AppyDev Skills Library so you can search for a workflow, read the actual files, and decide whether the skill is worth adding to a project. You can download the package or open a setup prompt in Codex or Claude Code. If you find a useful one, you can send its public detail page to someone who needs the same workflow.

How to find an AI skill that fits your work

Start with a task that repeats and has a recognizable output. “Review a proposed database migration” is a better candidate than “help with databases.” The first request gives you a way to judge whether the workflow helped. You should be able to point to the migration, check the findings against it, and decide what to do next.

Browse the Skills Library by use case or look for collections for the agent you already use. Open a result and check its summary, author, version, and example request. The example is especially handy because it shows how the maintainer expects you to describe a task. If the example assumes a different language, framework, or artifact from the one you work with, read the instructions before deciding whether to adapt it.

Think about what you want the assistant to do on its first run. For a writing skill, you might ask for an outline from a short brief and check whether it separates facts from open questions. For a code review skill, you could use a small diff and ask the agent to review it without applying changes. A narrow trial makes it easier to spot where the skill adds value and where the agent still needs context from you.

The library also gives teams a way to discuss the same version. Two people can inspect the listed files and compare what the skill asks for before bringing it into their respective repos. If you adapt it, keep a record of which version you started from and follow the license for redistribution.

What to check before downloading SKILL.md

Read the main file first. Its description tells the agent when to consider using the skill. The body should make it possible for you to follow the workflow yourself, at least at a high level. Look for the inputs it expects, which actions it asks the agent to take, the output it produces, and any points where the user needs to make a decision.

Then open the supporting files. A reference can define a format or provide a useful checklist. It can also introduce instructions you would miss if you only skimmed the main file. For example, a review guide might tell the agent to send its report to a remote service. If you want a local review, that changes whether you can use the package as written.

Pay attention to requests involving credentials, unfamiliar URLs, writes outside the project, or destructive shell commands. A published license tells you about reuse terms. An AppyDev review tells you which package version was checked. The agent's permissions and your decision about what it can access are still part of running it. Try unfamiliar skills in a small project with sample data and review any commands before allowing them.

A skill also depends on what the agent has available. Instructions can tell an assistant how to use a tool, but they cannot supply access to an account or install a connector by themselves. If the skill calls for a repository integration or an executable, look for that prerequisite before assuming the example prompt will work as shown.

How to use an AppyDev skill in Codex

On the skill detail page, choose Open in Codex to open a setup prompt. Review the prompt and send it in the intended project. If the app handoff doesn't open on your machine, use the copy fallback on the detail page or download the ZIP and inspect the extracted files.

For a project-scoped manual setup, place the named skill folder under .agents/skills/ in the project, keeping SKILL.md inside that folder. Keep its supporting files alongside it in the same relative structure. Open the project in Codex and check that the skill is available in the agent surface you use. If you're testing a skill for a shared repository, check the folder into version control only after reviewing the package and deciding it belongs in the project. OpenAI documents the discovery and invocation options in its skill setup guide.

For the first task, be explicit about the result. You can start from the example request on AppyDev, replace the example inputs, and name the skill when invoking it. For a review workflow, give it one file or one diff and ask for findings with file references. If it produces a report, verify a couple of findings and see whether the procedure handled the parts of the input you care about.

If the agent skips a step, check whether it had the required file or tool. Then check whether the skill said when to run that step. These two questions are often more informative than rerunning the same prompt with stronger wording.

How to use the same skill in Claude Code

Choose Open in Claude Code to hand off a setup prompt, or use the download and manual instructions if that works better for your environment. For a project-scoped setup, place the named folder under .claude/skills/. Keep the file named SKILL.md and keep the references in the locations the skill expects. Claude Code documents how skill names, project directories, and commands work in its skills guide.

For a first test, start Claude Code in the target project and invoke the skill by its name where supported. Use the same small input you would use in Codex. Comparing the two outputs is useful when you're deciding whether to share a workflow across a team. Check whether both agents understood the intended procedure, produced the requested format, and respected limits you set on edits or tool use.

The file format makes it practical to share the core procedure between agents. Some packages still assume a particular command, plugin, runtime, or feature. If the procedure refers to an integration that only one person on the team has, write down the dependency and decide what the expected behavior should be when it is unavailable. A workflow that describes what to do when a check can't run is easier to reuse.

How sharing and package review work

Use the share controls on the detail page to send someone the public listing. This keeps the version, license, preview, setup instructions, and download together. Add a sentence about what you tried and which environment you used. “I used this with a small TypeScript diff and asked for a read-only review” gives a teammate enough context to decide whether to try it.

Behind the scenes, AppyDev generates downloads from the approved text files recorded for a release. The review fingerprint binds the approval to those files, so changing the package requires another review. The browser preview displays escaped text in a sandboxed frame. Opening the preview is a way to inspect instructions. Running them happens in your agent environment after you choose to proceed.

Community submissions go through format and archive validation, followed by manual review. The checks look for unsafe paths and unexpected file types, enforce size limits, and flag patterns that warrant attention. These are deterministic checks. AppyDev did not train a model to review or run the skill packages. Automated checks can catch common problems, and a reviewer still needs to read the files and check the license.

For AppyDev, a useful shared link is one that leads someone to inspect or use a workflow. The October 20–31 baseline recorded 65 GA skills page views from seven active users. An earlier October reporting window recorded one download click, two Claude-open clicks, and one Codex-open click. Those were small samples. Tagged links now allow the site to measure arrivals and subsequent download or app-open clicks, subject to analytics settings. A click provides evidence of interest and leaves the outcome of setup and execution unknown.

The feature and measurement changes are documented in the Skills Library release, the package viewer update, and the sharing measurement PR.

A first run you can check in a few minutes

Pick a recurring task with a small example you already understand. Open the skill's files on AppyDev, read the main instructions, and try the setup in one project. Ask the agent to explain what it will inspect before it starts. After the run, compare the output with what you would have written yourself and identify a step the procedure helped the agent remember.

If the result saves you some repeat work, share the listing and include your example. If you need to tailor the workflow, keep the change small. Adding your team's required test command or output format will usually give you a clearer result than asking one skill to handle every kind of task.