# Minimum Requirements for an Awesome List: How to Get Accepted into sindresorhus/awesome > Discover the minimum requirements to get your Awesome list accepted into the sindresorhus/awesome repository. Learn about age, linting, branch, formatting and licensing rules. - Repository: [Sindre Sorhus/awesome](https://github.com/sindresorhus/awesome) - Tags: getting-started - Published: 2026-07-07 --- **To have your Awesome list accepted into the main sindresorhus/awesome repository, you must satisfy a strict checklist defined in the [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md), including a 30-day age requirement, passing `awesome-lint`, using a `main` branch, and adhering to specific formatting and licensing rules.** The sindresorhus/awesome project maintains one of the most curated collections of open-source lists on GitHub. Meeting the minimum requirements for an awesome list involves satisfying both technical constraints and qualitative standards enforced by maintainers through the pull request template. Every missing checkbox will result in immediate rejection or closure of your submission. ## Mandatory Checklist: The Minimum Requirements The [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md) file serves as the authoritative gatekeeper. These requirements are non-negotiable and must all be satisfied before maintainers will consider your list. ### Repository Configuration Your list must meet specific structural criteria before submission: - **Age**: The repository must have existed for at least **30 days** from the first real commit or open-source date - **Branch name**: The default branch must be named `main` (not `master`) - **Repository name**: Use a lower-case slug format like `awesome-my-list` - **Visibility**: Must be a public GitHub repository - **AI policy**: The list cannot be generated automatically by AI tools ### Content Standards Quality and uniqueness are enforced through these rules: - **Uniqueness**: Your list must not duplicate an existing Awesome list already in the collection - **Quality bar**: Every entry must be genuinely "awesome"; avoid exhaustive or low-quality collections - **Item descriptions**: Each item requires a description (unless the title is self-explanatory). No archived or unmaintained repositories unless segregated into a separate Markdown file - **No duplicates**: Check existing lists to ensure your topic isn't already covered ### Formatting and Structure Strict formatting rules ensure consistency across the ecosystem: - **README heading**: Must be title-cased: `# Awesome My List` - **Description**: Include a succinct, objective description at the very top of the README (no marketing fluff) - **Table of contents**: Add a `Contents` section as the first major heading; avoid generic "Table of Contents" labels - **Badge placement**: Include the official Awesome badge on the right side of the heading using `` tags - **Footnotes**: Place copyright notices, source links, and meta-information in a `Footnotes` section at the bottom, excluded from the TOC ### Technical Specifications Linting and file handling requirements: - **Lint compliance**: Run `awesome-lint` on your list and fix all reported issues before submitting - **Markdown file**: The list must be a non-generated Markdown file - **Hard-wrap**: Do not hard-wrap lines; let Markdown handle line breaks naturally - **No CI badges**: Remove all CI badges (GitHub Actions, Travis, etc.) from the README - **No inspiration text**: Remove any "Inspired by awesome-foo" notices; the Awesome badge alone is sufficient attribution ### Licensing and Contribution Legal and collaborative requirements: - **License**: Use a Creative Commons license (CC0 is preferred). Code-style licenses like MIT or GPL are explicitly rejected - **Contribution guidelines**: Provide a [`contributing.md`](https://github.com/sindresorhus/awesome/blob/main/contributing.md) file (or similar) and optionally link it from the README - **GitHub topics**: Add the topics `awesome-list` and `awesome` to your repository (plus any relevant extras) ## Implementation Guide: Code Examples Follow these patterns to satisfy the formatting requirements in [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md). ### Repository Setup Name your repository using the lower-case slug convention: ```markdown # Awesome Rust ``` Repository name: `awesome-rust` ### Badge Integration Place the official Awesome badge to the right of your title: ```markdown # Awesome Rust Awesome ``` ### Description Format Add an objective description immediately below the heading: ```markdown A curated list of high-quality Rust libraries and resources. ``` ### Table of Contents Structure Name the section `Contents` and place it before any other sections: ```markdown ## Contents - [Web Development](#web-development) - [CLI Tools](#cli-tools) - [Data Processing](#data-processing) ``` ### Item Entry Formatting Use dashes between links and descriptions, with proper capitalization and punctuation: ```markdown - [Rocket](https://github.com/SergioBenitez/Rocket) - A web framework for Rust. - [Serde](https://github.com/serde-rs/serde) - A powerful serialization framework. ``` ### License Implementation Create a `LICENSE` file containing CC0 text. Do not place license notices in the README body. According to the [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md), Creative Commons licenses are mandatory while code licenses like MIT are prohibited. ### Contribution Guidelines Create a [`contributing.md`](https://github.com/sindresorhus/awesome/blob/main/contributing.md) file: ```markdown # Contributing Please read the main repository's [pull request template](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md) before submitting changes. ``` ## Summary Meeting the minimum requirements for an awesome list requires strict adherence to the [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md) checklist: - **Repository age**: Minimum 30 days of existence before submission - **Branch naming**: Must use `main` as the default branch - **Linting**: All `awesome-lint` errors must be resolved - **Formatting**: Title-cased headings, `Contents` sections, and dash-separated item descriptions with proper punctuation - **Legal**: Creative Commons licensing only (CC0 preferred), no MIT/GPL - **Quality**: No AI-generated content, no duplicate topics, no archived repositories mixed with active ones ## Frequently Asked Questions ### How long must my Awesome list exist before I can submit it? Your list must have existed for at least **30 days** from its first real commit or the date it was open-sourced. This requirement, defined in the [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md), ensures the list has matured beyond initial creation and demonstrates ongoing maintenance. ### Can I use an AI tool to generate my Awesome list? No. The [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md) explicitly prohibits AI-generated lists. Your curation must be manual and reflect genuine human judgment about what constitutes "awesome" content in your domain. ### What license must I use for my Awesome list? You must use a **Creative Commons** license, with **CC0** being the preferred option. Code-style licenses such as MIT, GPL, or Apache are not accepted according to the template requirements. Create a `LICENSE` file in your repository root containing the CC0 text. ### Why does my pull request keep getting rejected? Missing any single checkbox from the [`pull_request_template.md`](https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md) results in automatic rejection. Common failures include using a `master` branch instead of `main`, hard-wrapping Markdown lines, including CI badges, using the wrong license type, or failing to run `awesome-lint` before submission. Review the template line-by-line to ensure every requirement is satisfied.