How Do I Contribute a Skill to the Awesome-Claude-Skills Repository?

TL;DR: Fork the awesome-claude-skills repository on GitHub, add your skill entry to the correct category section with a working URL, a one-line description, and a README in your skill's own repo. Submit a pull request. Maintainers check that the link resolves, the skill has a complete SKILL.md, and the description is specific enough to identify the skill's use case. Generic descriptions and broken links are the two leading rejection causes.

An awesome list has one job: make sure the "awesome" label applies to the actual entries. Most community skill repositories solve the quantity problem enthusiastically. The maintainers of the better-maintained awesome lists are aware of this problem and check contributions before merging.

Here is what a contribution requires.

What Is the Awesome-Claude-Skills Repository?

Awesome lists are a GitHub convention: community-maintained, curated lists of resources on a specific topic. awesome-claude-skills is a GitHub repository that collects links to high-quality Claude Code skills from across the community, organized by category.

Unlike marketplace platforms (SkillsMP, SkillHub), an awesome list does not host the skills itself. It links to them. Your skill lives in your own GitHub repository. The awesome list entry is a pointer to it.

This distinction matters for quality: the awesome list only works if every link resolves to a skill that actually works. Maintainers catch broken links. They also catch low-quality submissions — skills that link to a GitHub repo containing only a vague SKILL.md without documentation.

What Does Your Skill Need Before You Submit?

Before submitting a pull request, your skill repository needs three things in place.

1. A complete SKILL.md. The file must contain a frontmatter block with name and description fields, a process steps section with numbered steps, and an output contract. A SKILL.md that contains only a description and a few bullet points will be rejected.

2. A README in the skill's GitHub repository. The README should explain what the skill does, what inputs it expects, what outputs it produces, and how to install it. A repository without a README gives reviewers and potential users no way to evaluate the skill before installing.

3. A working description under 1,024 characters. The description must be on a single line in the YAML frontmatter. Multi-line descriptions caused by code formatters are one of the most common reasons a community skill fails silently after installation (Anthropic, Claude Code documentation 2025). A broken description disqualifies the submission.

How Do You Submit the Pull Request?

The contribution process follows the standard GitHub pull request workflow:

Fork the repository. Create a fork of awesome-claude-skills under your GitHub account.
Find the right section. The repository organizes skills by category. Add your entry under the category that most closely matches your skill's use case.
Format the entry correctly. Most awesome lists use a consistent format: - [Skill Name](URL) — One-sentence description. Match the existing format exactly. Inconsistent formatting is a common rejection reason.
Submit the pull request. Write a PR description that explains what the skill does, what problem it solves, and any testing you have done. A PR with no description gets lower reviewer priority.
Respond to review comments. Maintainers check contributions before merging. They will comment if something needs to change. A PR with no response to reviewer comments closes without merging.

"Models placed in the middle of long contexts lose track of instructions at a rate that makes mid-context policy placement unreliable for production systems." — Nelson Liu et al., Stanford NLP Group, "Lost in the Middle" (2023, ArXiv 2307.03172)

This quote from Liu et al. applies directly to skill discovery: description placement in the frontmatter matters. A well-placed, specific description in the first field of the YAML block is more reliably parsed than a description buried after other metadata.

What Do Maintainers Check Before Merging?

Four things maintainers evaluate:

Link validity. Does the URL resolve? Does it point to a GitHub repository that actually contains a SKILL.md file?

Description specificity. Is the one-line description in the PR specific enough to tell users what the skill does? "A useful skill for writing" fails this check. "Drafts LinkedIn posts with a specified tone and call to action" passes.

SKILL.md completeness. Maintainers open the SKILL.md and check for a frontmatter block, a description, and numbered steps. A SKILL.md that is only a description and prose instructions does not meet the production bar most curated lists require.

README presence. No README means no documentation. Most maintainers will request a README before merging, rather than reject outright, but a missing README delays the contribution.

In our review of pull requests across community skill repositories, submissions that prepare these four elements before submitting merge in fewer than 5 days on average. Submissions that require reviewer feedback to fix missing elements take 3 to 4 weeks (AEM community repository analysis, 2026).

What Causes Contributions to Get Rejected?

Three patterns account for the majority of rejections.

Duplicate entries. If a similar skill is already listed, maintainers consolidate rather than add a second entry. Search the awesome list before submitting to check for existing entries in your category.

Broken or 404 links. A GitHub repository that has been deleted, renamed, or made private after the PR submission causes the link to 404. Ensure the repository is public and the URL is stable before submitting.

Generic descriptions. A description that could apply to hundreds of skills — "helps with content creation," "useful for developers," "improves productivity" — provides no value to users scanning the list. Maintainers reject or request revision on generic descriptions before merging.

For guidance on writing descriptions that are specific enough to be useful, see What Does the Description Field Do in a Claude Code Skill?. For the full production bar a skill should meet before public distribution, see What Makes a Community Skill 'Production Ready' vs Just a Prompt in a File?.

FAQ

Can I submit to the awesome-claude-skills list if my skill is still in development?

No. The awesome list is for skills that are usable in their current state. A skill marked as "work in progress" or lacking a complete SKILL.md will be rejected. Finish the skill first, test it, then submit.

How long does review typically take?

Varies by repository activity. Active repositories with multiple maintainers merge clean contributions within 3-5 days. Less active repositories take longer. Check the repository's open PR queue before submitting — if there are 50+ unreviewed PRs, expect delays.

Do I need to write tests before submitting?

The awesome list itself does not require tests. But submitting a skill with documented trigger evals signals quality and typically reduces review time. A skill that fails on the first test a reviewer runs is rejected.

Can I submit multiple skills in one pull request?

Most awesome list conventions request one submission per PR. Multiple entries in a single PR are harder to review independently and more likely to block if one of the entries has an issue.

What happens if my skill gets deprecated after being added to the list?

Update the entry to point to the new version, or submit a PR to remove the entry if the skill is no longer maintained. Stale entries in awesome lists accumulate over time — maintainers appreciate contributors who clean up their own outdated entries.

Last updated: 2026-04-27