文档知识库【免费下载链接】awesome Awesome lists about all kinds of interesting topics [NOTE: Pull requests are temporarily disabled until I have a chance to catch up with the existing ones]项目地址https://gitcode.com/GitHub_Trending/aw/awesome点击查看免费下载本文以 awesome 仓库官方文档 create-list.md 为主线系统讲解如何打造并提交一个能被官方收录的 Awesome 列表从阅读 Awesome 宣言 与 列表提交指南 起步到查重、度过 30 天成熟期再到逐条对照列表质量门槛与 Pull Request 提交规范。读完后你将掌握一份可直接照做的创建清单以及仓库源码层面的完整证据链能够避开绝大多数新手踩过的坑一次通过审核的概率大幅提升。一、先建立正确认知Awesome 列表是策展而非收藏在动手之前必须先理解 Awesome 生态的核心哲学。官方文档 awesome.md 开篇即点明If you want your list to be included inawesome, try to only include actual awesome stuff in your list. After all, its a curation, not a collection.这句话定义了整个审校体系的价值基准列表是对真正优秀资源的策展curation而不是对一切资源的收藏collection。对应地宣言第一条准则Only awesome is awesome要求收录前先研究该项目是否真的出色只放入你自己或他人能亲身推荐的条目宁可少收不要滥收You should rather leave stuff out than include too much。这一认知直接决定了 create-list.md 中确保你的列表合规的前提——合规不是指格式而是指内容经得起是否真的 awesome这一灵魂拷问。二、创建前必读两份决定成败的文档create-list.md 给出的第一步是Read the Awesome manifesto and list guidelines and ensure your list complies.即创建列表前必须先通读两份文档并保证自己的列表符合要求Awesome 宣言awesome.md定义了什么才算 awesome的十条质量准则详见本文第七节包括徽章使用、内容描述、许可证选择、贡献指南、排版风格等列表提交指南pull_request_template.md既是提交 PR 时必须填写的模板又是一份非常详尽的检查清单分为PR 的要求与列表的要求两大块其中列表要求部分逐条可达数十项。注意pull_request_template.md 开头有一句提醒Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.这并非客套——该模板中大量要求如 PR 标题格式、unicorn验证词、评审他人 PR 的数量都是新手最容易忽略的细节。因此 create-list.md 特意在最后一步再次强调提交 PR 之前请再读一遍列表指南Make sure you read the list guidelines again before submitting a pull request。三、查重避免重复造轮子create-list.md 的第二个要求Search this list before making a new one, as yours may be a duplicate. If it is, try and contribute to the best one instead of making your own.在创建新列表前务必先在主列表中搜索是否已存在同类列表主列表 readme.md 按主题划分为 Platforms、Programming Languages、Front-End Development、Back-End Development、Computer Science、Big Data、Theory、Books、Editors、Gaming、Development Environment、Entertainment、Databases、Media、Learn、Security、Content Management Systems、Hardware、Business、Work、Networking、Decentralized Systems、Health and Social Science、Events、Testing、Miscellaneous、Related 等二十余个分类覆盖面极广若发现已有列表覆盖你的主题不要另起炉灶而是应尽力为其中最好的那个做出贡献contribute to the best one这样既避免分裂社区也符合列表不重复的收录底线见 pull_request_template.md 的 Not a duplicate. Please search for existing submissions.。四、30 天成熟期为什么必须等待create-list.md 中有一条加粗强调的硬性时间门槛Wait at least 30 days after creating a list before submitting it, to give it a chance to mature.对应地pull_request_template.md 对列表的要求中也明确写了判定口径Has been around for at least 30 days. That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.即30 天从第一次真实提交或开源发布两者中较晚的时间点起算。这一机制的用意是给列表一个真实的生长周期——让内容在社区反馈中沉淀、去芜存菁而不是发布当天就拿来投稿的一次性产物。提交时这一条会自动被审查因此建议在创建仓库并完成首版内容后为它预留至少一个月的持续维护期。五、列表本身的硬性门槛逐条对照自查create-list.md 要求列表合规而合规的完整定义就在 pull_request_template.md 的 Requirements for your Awesome list 一节。以下逐组拆解。5.1 仓库形态与命名不是 AI 生成的Is not AI-generated列表必须是人工策展的产物纯 AI 生成内容直接拒绝默认分支命名为main而不是master仓库名必须是小写 slug 格式awesome-name-of-list正确awesome-swift、awesome-web-typography错误awesome-Swift、AwesomeWebTypography列表标题必须使用 title case格式为# Awesome Name of List正确# Awesome Swift、# Awesome Web Typography错误# awesome-swift、# AwesomeSwift必须是 GitHub 仓库中一份非自动生成的 Markdown 文件仓库必须设置 GitHub topics至少包含awesome-list与awesome两个主题官方鼓励添加更多相关主题不是重复列表见第三节。5.2 内容质量只收录 awesome 条目宣言中的 Only awesome is awesome 在此落地——Awesome lists are curations of the best, not everything不得包含未维护、已归档、已弃用或缺少文档的项目若确实需要收录这类条目必须单独放进另一个独立的 Markdown 文件不能与精选内容混排每个条目都应带描述除非标题本身就足够说明但这种情况极少链接与描述之间用破折号-分隔如- AVA - JavaScript test runner.描述以大写字母开头、以句号结尾命名保持一致与正确例如统一写Node.js而不是NodeJS或node.js。5.3 结构与格式README 顶部必须有一句简洁的主题描述succinct description of the project/theme at the top of the readme让读者一眼看懂列表范围正确Mobile operating system for Apple phones and tablets.正确Prototyping interactive UI designs.错误Resources and tools for iOS development.错误Awesome Framer packages and tools.尽量包含项目 Logo 或插画条件包括居中、通栏或置于 README 右上角图片应链接到项目网站必须是高 DPI 图片设置为原图宽度的一半以内不要既在标题写Awesome X又在 Logo 里出现Awesome X必须包含 Awesome 徽章详见第七节置于 README 标题的右侧若列表采用居中图文头部也可居中放置徽章应链接回本列表必须有目录Table of Contents且命名为Contents而不是Table of Contents必须是列表的第一个章节嵌套列表最多一层最好没有嵌套目录中不得出现Contributing或Footnotes条目非重点但必要的内容额外版权声明、来源链接、扩展内容入口等应统一归入 README 底部的Footnotes章节同样不得出现在目录中不使用硬换行hard-wrapping不添加 CI如 GitHub Actions徽章——可以用 CI 做 lint但徽章对 README 没有价值不在 README 顶部添加Inspired by awesome-foo或Inspired by the Awesome project之类的链接Awesome 徽章已经足够。5.4 许可证与协作机制许可证pull_request_template.md 强烈推荐 CC0 协议任何 Creative Commons 许可证均可MIT、BSD、Apache、GPL 等代码许可证不可接受WTFPL 与 Unlicense 同样不行具体做法是在仓库根目录放置名为license或LICENSE的文件不要把许可证名称、文本或Licence章节写进 README——GitHub 会在仓库顶部自动展示许可证信息贡献指南列表必须有contributing.md文件名大小写不限可选地在 README 中用一个专门的Contributing章节链接它置于正文顶部或底部但该章节不得进入目录验证词unicorn为确认你已经通读全部指南官方要求在提交 PR 时于评论中只写一个词unicorn这是模板中的硬性检查项漏掉会直接暴露你没读文档运行 awesome-lint在提交前对自己的列表运行awesome-lint并修复其报告的所有问题若存在误报或确实无法修复的项应向工具仓库提交 issue 说明而不是置之不理。六、Pull Request 的提交规范列表本身达标只是第一步PR 的提交方式同样被严格审查。pull_request_template.md 的 Requirements for your pull request 一节规定了以下要点纯 AI 生成的 PR 不接受Fully AI-generated pull requests are not accepted不要以 Draft / WIP 状态提交 PRPR 打开时必须 100% 完成并符合全部指南需要孵化期可见性时应利用官方的 incubation issue编号 2242来展示而不是半成品 PR不要浪费维护者的时间认真完成、遵守全部指南、对反馈保持响应必须至少评审 4 个其他开放的 PR优先评审尚未被审过的 PR也可以给已评审的 PR 补充意见并在自己的 PR 中注明评审了哪些。评审必须认真只评论 looks good 或仅标记为 approved 不算评审必须真正指出错误或改进建议指出 lint 违规的评论虽然允许但也不计入评审次数。这一要求意在让 Awesome 项目自给自足self-sustainingPR 标题格式必须为Add Name of List且标题中不得包含Awesome一词正确Add Swift、Add Software Architecture错误Update readme.md、Add Awesome Swift、add Swift、Adding Swift、Added Swift主列表中的条目描述写列表所覆盖的项目/主题的简短客观描述不要描述列表本身首字符大写、以句号结尾、不得含列表名正确- iOS - Mobile operating system for Apple phones and tablets.、- Framer - Prototyping interactive UI designs.错误- iOS - Resources and tools for iOS development.、- Framer、- Framer - prototyping interactive UI designs条目位置添加到对应分类的底部标题与链接条目名称使用 title caseURL 以#readme结尾例如- [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.不接受区块链相关列表No blockchain-related lists。七、Awesome 宣言的十条准则逐条深度解读awesome.md 中的十条准则构成了所有质量要求的思想源头逐条展开如下。7.1 Only awesome is awesome只收录真正 awesome 的内容收录前先研究该项目是否真的出色只放入你能亲自推荐的条目。宁缺毋滥。7.2 Awesome badgeAwesome 徽章徽章用于标识这是一个 Awesome 列表应置于列表标题旁边。官方提供了三种样式常规、扁平、扁平二号用法如下[](https://awesome.re) [](https://awesome.re) [](https://awesome.re)徽章允许用于未收录于此的项目也允许用于私有列表徽章不允许以任何方式修改The badges should not be modified in any way.。本仓库 media 目录中存放了对应的徽章资源文件badge.svg、badge-flat.svg、badge-flat2.svg可供参考其原始形态。7.3 Awesome mentioned badge被收录徽章该徽章供被收录进 Awesome 列表的项目使用并非给列表本身使用。例如某个项目因为出现在 Awesome Node.js 列表中就可以在自身 README 中展示它。它是完全可选的但能直观展示本作品已被 Awesome 列表收录[](https://awesome.re) [](https://awesome.re)使用时需填写占位符——列表名和列表 URL[](https://github.com/INSERT LIST URL)完整示例[](https://github.com/sindresorhus/awesome-nodejs)作为列表维护者可以鼓励列表中的项目添加该徽章。本仓库 media 目录同样提供了这两种徽章的源文件mentioned-badge.svg、mentioned-badge-flat.svg。同样徽章不得修改。7.4 Comment on why something is awesome解释为什么它 awesome除了列出条目还要告诉读者它为什么值得上榜、读者能从中获得什么。主列表 readme.md 中大量条目都带一句描述正是这一准则的体现。7.5 Make it clear what the list is about让列表主题清晰README 顶部要有简洁描述列表必须覆盖明确的范围且不越界如果某个主题已有列表覆盖得很好就链接到那个列表而不是重复收录。7.6 Pay attention to grammar注意语法保证列表语法正确、零拼写错误、无 Markdown 格式错误——这条同样适用于提交的 PR。7.7 Choose an appropriate license选择合适的许可证若仓库没有选择许可证实际上意味着他人不被允许复制、分发或创作衍生作品。Creative Commons 许可证非常适合此类内容列表官方推荐 CC0MIT、BSD、GPL 等代码许可证不推荐。这与第五节 5.4 中的硬性要求相互呼应。7.8 Include contribution guidelines包含贡献指南贡献者需要清楚知道如何为你的列表做贡献。如果不打算从零撰写可以直接取用本仓库的 contributing.md 并按需修改——这也解释了为什么仓库会维护一份通用的贡献指南文件。7.9 Stylize your list properly规范排版创建目录Table of Contents、将内容按分类组织、合适时使用图片保证所有条目风格一致例如所有条目描述都以句号结尾。7.10 Accept other peoples opinion尊重他人意见作为列表所有者要尊重他人的意见当大量用户不同意你的决定时应重新考虑。这是列表长期健康运营的协作准则。八、网页端实操路径如何一步步提交contributing.md 给出了提交 PR 的完整网页操作流程可作为投稿时的操作手册打开目标 Awesome 列表的 GitHub 页面例如本仓库主页点击readme.md文件点击编辑图标在浏览器内置编辑器中修改文本遵循前述全部指南可使用 GitHub Flavored Markdown填写变更原因说明点击 Propose file change提交 Pull Request并按照第六节要求填写标题与条目描述如果维护者要求修改 PR通常是拼写错误或不符合列表指南参考官方提供的修改提交指南更新 PR 即可。需要特别注意的是本仓库同时附带 code-of-conduct.md贡献者行为准则contributing.md 明确声明参与该项目即表示同意遵守其条款——在投稿任何列表之前先阅读它能避免在社区协作层面踩雷。九、完整流程时间线将以上全部内容收敛为一条可执行的时间线读文档通读 awesome.md 宣言与 pull_request_template.md 指南多读几遍查重在 readme.md 中搜索确认无同类列表若有改为贡献给最好的那个创建列表按第五节全部硬性门槛建设仓库命名、标题、描述、目录、徽章、许可证、贡献指南、topics、main 分支持续打磨运行awesome-lint并修复问题用真实维护保证条目质量等待 30 天从第一次真实提交或开源发布取较晚者起算让列表成熟提交 PR 前复查再次阅读列表指南评审至少 4 个其他开放 PR认真指出问题才算数按Add Name of List格式命名标题、在合适分类底部插入条目、描述首字母大写且以句号结尾、URL 以#readme结尾评论中附上验证词unicorn提交并保持响应提交 PR 后对维护者的反馈及时响应、按需更新。结语创建并提交一个 Awesome 列表本质上是一场内容策展 工程规范的双重考验内容上要遵循 awesome.md 的只有 awesome 才叫 awesome工程上要满足 pull_request_template.md 的每一项检查。本文以 create-list.md 为骨架逐层展开了查重、30 天成熟期、列表硬性门槛、PR 提交规范与宣言十准则并把仓库内的 contributing.md、code-of-conduct.md、readme.md 与 media 徽章资源全部串联起来——按这条路径走你的列表才真正有资格被收录。Thanks for being awesome.赞分享文档知识库【免费下载链接】awesome Awesome lists about all kinds of interesting topics [NOTE: Pull requests are temporarily disabled until I have a chance to catch up with the existing ones]项目地址https://gitcode.com/GitHub_Trending/aw/awesome点击查看免费下载相关推荐awesome-shizuku 贡献指南为 Shizuku 应用精选列表提交条目的格式规范、收录门槛与自动化校验awesome shizuku 贡献指南为 Shizuku 应用精选列表提交条目的格式规范、收录门槛与自动化校验 本文以仓库根目录的 CONTRIBUTING文档知识库agentic-awesome-skills 贡献指南从零创建并提交高质量 Agentic Skill 的完整流程agentic awesome skills 贡献指南从零创建并提交高质量 Agentic Skill 的完整流程 本篇指南以仓库 docs/vietnameAI 技能AI 插件ReactPage 贡献指南从 monorepo 环境搭建到提交规范与 PR 流程完整实战ReactPage 贡献指南从 monorepo 环境搭建到提交规范与 PR 流程完整实战 ReactPage 是一个基于 React、使用 TypeScri前端UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
从零创建并提交一个 Awesome 精选列表：完整流程、硬性门槛与规范实战指南
文档知识库【免费下载链接】awesome Awesome lists about all kinds of interesting topics [NOTE: Pull requests are temporarily disabled until I have a chance to catch up with the existing ones]项目地址https://gitcode.com/GitHub_Trending/aw/awesome点击查看免费下载本文以 awesome 仓库官方文档 create-list.md 为主线系统讲解如何打造并提交一个能被官方收录的 Awesome 列表从阅读 Awesome 宣言 与 列表提交指南 起步到查重、度过 30 天成熟期再到逐条对照列表质量门槛与 Pull Request 提交规范。读完后你将掌握一份可直接照做的创建清单以及仓库源码层面的完整证据链能够避开绝大多数新手踩过的坑一次通过审核的概率大幅提升。一、先建立正确认知Awesome 列表是策展而非收藏在动手之前必须先理解 Awesome 生态的核心哲学。官方文档 awesome.md 开篇即点明If you want your list to be included inawesome, try to only include actual awesome stuff in your list. After all, its a curation, not a collection.这句话定义了整个审校体系的价值基准列表是对真正优秀资源的策展curation而不是对一切资源的收藏collection。对应地宣言第一条准则Only awesome is awesome要求收录前先研究该项目是否真的出色只放入你自己或他人能亲身推荐的条目宁可少收不要滥收You should rather leave stuff out than include too much。这一认知直接决定了 create-list.md 中确保你的列表合规的前提——合规不是指格式而是指内容经得起是否真的 awesome这一灵魂拷问。二、创建前必读两份决定成败的文档create-list.md 给出的第一步是Read the Awesome manifesto and list guidelines and ensure your list complies.即创建列表前必须先通读两份文档并保证自己的列表符合要求Awesome 宣言awesome.md定义了什么才算 awesome的十条质量准则详见本文第七节包括徽章使用、内容描述、许可证选择、贡献指南、排版风格等列表提交指南pull_request_template.md既是提交 PR 时必须填写的模板又是一份非常详尽的检查清单分为PR 的要求与列表的要求两大块其中列表要求部分逐条可达数十项。注意pull_request_template.md 开头有一句提醒Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.这并非客套——该模板中大量要求如 PR 标题格式、unicorn验证词、评审他人 PR 的数量都是新手最容易忽略的细节。因此 create-list.md 特意在最后一步再次强调提交 PR 之前请再读一遍列表指南Make sure you read the list guidelines again before submitting a pull request。三、查重避免重复造轮子create-list.md 的第二个要求Search this list before making a new one, as yours may be a duplicate. If it is, try and contribute to the best one instead of making your own.在创建新列表前务必先在主列表中搜索是否已存在同类列表主列表 readme.md 按主题划分为 Platforms、Programming Languages、Front-End Development、Back-End Development、Computer Science、Big Data、Theory、Books、Editors、Gaming、Development Environment、Entertainment、Databases、Media、Learn、Security、Content Management Systems、Hardware、Business、Work、Networking、Decentralized Systems、Health and Social Science、Events、Testing、Miscellaneous、Related 等二十余个分类覆盖面极广若发现已有列表覆盖你的主题不要另起炉灶而是应尽力为其中最好的那个做出贡献contribute to the best one这样既避免分裂社区也符合列表不重复的收录底线见 pull_request_template.md 的 Not a duplicate. Please search for existing submissions.。四、30 天成熟期为什么必须等待create-list.md 中有一条加粗强调的硬性时间门槛Wait at least 30 days after creating a list before submitting it, to give it a chance to mature.对应地pull_request_template.md 对列表的要求中也明确写了判定口径Has been around for at least 30 days. That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.即30 天从第一次真实提交或开源发布两者中较晚的时间点起算。这一机制的用意是给列表一个真实的生长周期——让内容在社区反馈中沉淀、去芜存菁而不是发布当天就拿来投稿的一次性产物。提交时这一条会自动被审查因此建议在创建仓库并完成首版内容后为它预留至少一个月的持续维护期。五、列表本身的硬性门槛逐条对照自查create-list.md 要求列表合规而合规的完整定义就在 pull_request_template.md 的 Requirements for your Awesome list 一节。以下逐组拆解。5.1 仓库形态与命名不是 AI 生成的Is not AI-generated列表必须是人工策展的产物纯 AI 生成内容直接拒绝默认分支命名为main而不是master仓库名必须是小写 slug 格式awesome-name-of-list正确awesome-swift、awesome-web-typography错误awesome-Swift、AwesomeWebTypography列表标题必须使用 title case格式为# Awesome Name of List正确# Awesome Swift、# Awesome Web Typography错误# awesome-swift、# AwesomeSwift必须是 GitHub 仓库中一份非自动生成的 Markdown 文件仓库必须设置 GitHub topics至少包含awesome-list与awesome两个主题官方鼓励添加更多相关主题不是重复列表见第三节。5.2 内容质量只收录 awesome 条目宣言中的 Only awesome is awesome 在此落地——Awesome lists are curations of the best, not everything不得包含未维护、已归档、已弃用或缺少文档的项目若确实需要收录这类条目必须单独放进另一个独立的 Markdown 文件不能与精选内容混排每个条目都应带描述除非标题本身就足够说明但这种情况极少链接与描述之间用破折号-分隔如- AVA - JavaScript test runner.描述以大写字母开头、以句号结尾命名保持一致与正确例如统一写Node.js而不是NodeJS或node.js。5.3 结构与格式README 顶部必须有一句简洁的主题描述succinct description of the project/theme at the top of the readme让读者一眼看懂列表范围正确Mobile operating system for Apple phones and tablets.正确Prototyping interactive UI designs.错误Resources and tools for iOS development.错误Awesome Framer packages and tools.尽量包含项目 Logo 或插画条件包括居中、通栏或置于 README 右上角图片应链接到项目网站必须是高 DPI 图片设置为原图宽度的一半以内不要既在标题写Awesome X又在 Logo 里出现Awesome X必须包含 Awesome 徽章详见第七节置于 README 标题的右侧若列表采用居中图文头部也可居中放置徽章应链接回本列表必须有目录Table of Contents且命名为Contents而不是Table of Contents必须是列表的第一个章节嵌套列表最多一层最好没有嵌套目录中不得出现Contributing或Footnotes条目非重点但必要的内容额外版权声明、来源链接、扩展内容入口等应统一归入 README 底部的Footnotes章节同样不得出现在目录中不使用硬换行hard-wrapping不添加 CI如 GitHub Actions徽章——可以用 CI 做 lint但徽章对 README 没有价值不在 README 顶部添加Inspired by awesome-foo或Inspired by the Awesome project之类的链接Awesome 徽章已经足够。5.4 许可证与协作机制许可证pull_request_template.md 强烈推荐 CC0 协议任何 Creative Commons 许可证均可MIT、BSD、Apache、GPL 等代码许可证不可接受WTFPL 与 Unlicense 同样不行具体做法是在仓库根目录放置名为license或LICENSE的文件不要把许可证名称、文本或Licence章节写进 README——GitHub 会在仓库顶部自动展示许可证信息贡献指南列表必须有contributing.md文件名大小写不限可选地在 README 中用一个专门的Contributing章节链接它置于正文顶部或底部但该章节不得进入目录验证词unicorn为确认你已经通读全部指南官方要求在提交 PR 时于评论中只写一个词unicorn这是模板中的硬性检查项漏掉会直接暴露你没读文档运行 awesome-lint在提交前对自己的列表运行awesome-lint并修复其报告的所有问题若存在误报或确实无法修复的项应向工具仓库提交 issue 说明而不是置之不理。六、Pull Request 的提交规范列表本身达标只是第一步PR 的提交方式同样被严格审查。pull_request_template.md 的 Requirements for your pull request 一节规定了以下要点纯 AI 生成的 PR 不接受Fully AI-generated pull requests are not accepted不要以 Draft / WIP 状态提交 PRPR 打开时必须 100% 完成并符合全部指南需要孵化期可见性时应利用官方的 incubation issue编号 2242来展示而不是半成品 PR不要浪费维护者的时间认真完成、遵守全部指南、对反馈保持响应必须至少评审 4 个其他开放的 PR优先评审尚未被审过的 PR也可以给已评审的 PR 补充意见并在自己的 PR 中注明评审了哪些。评审必须认真只评论 looks good 或仅标记为 approved 不算评审必须真正指出错误或改进建议指出 lint 违规的评论虽然允许但也不计入评审次数。这一要求意在让 Awesome 项目自给自足self-sustainingPR 标题格式必须为Add Name of List且标题中不得包含Awesome一词正确Add Swift、Add Software Architecture错误Update readme.md、Add Awesome Swift、add Swift、Adding Swift、Added Swift主列表中的条目描述写列表所覆盖的项目/主题的简短客观描述不要描述列表本身首字符大写、以句号结尾、不得含列表名正确- iOS - Mobile operating system for Apple phones and tablets.、- Framer - Prototyping interactive UI designs.错误- iOS - Resources and tools for iOS development.、- Framer、- Framer - prototyping interactive UI designs条目位置添加到对应分类的底部标题与链接条目名称使用 title caseURL 以#readme结尾例如- [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.不接受区块链相关列表No blockchain-related lists。七、Awesome 宣言的十条准则逐条深度解读awesome.md 中的十条准则构成了所有质量要求的思想源头逐条展开如下。7.1 Only awesome is awesome只收录真正 awesome 的内容收录前先研究该项目是否真的出色只放入你能亲自推荐的条目。宁缺毋滥。7.2 Awesome badgeAwesome 徽章徽章用于标识这是一个 Awesome 列表应置于列表标题旁边。官方提供了三种样式常规、扁平、扁平二号用法如下[](https://awesome.re) [](https://awesome.re) [](https://awesome.re)徽章允许用于未收录于此的项目也允许用于私有列表徽章不允许以任何方式修改The badges should not be modified in any way.。本仓库 media 目录中存放了对应的徽章资源文件badge.svg、badge-flat.svg、badge-flat2.svg可供参考其原始形态。7.3 Awesome mentioned badge被收录徽章该徽章供被收录进 Awesome 列表的项目使用并非给列表本身使用。例如某个项目因为出现在 Awesome Node.js 列表中就可以在自身 README 中展示它。它是完全可选的但能直观展示本作品已被 Awesome 列表收录[](https://awesome.re) [](https://awesome.re)使用时需填写占位符——列表名和列表 URL[](https://github.com/INSERT LIST URL)完整示例[](https://github.com/sindresorhus/awesome-nodejs)作为列表维护者可以鼓励列表中的项目添加该徽章。本仓库 media 目录同样提供了这两种徽章的源文件mentioned-badge.svg、mentioned-badge-flat.svg。同样徽章不得修改。7.4 Comment on why something is awesome解释为什么它 awesome除了列出条目还要告诉读者它为什么值得上榜、读者能从中获得什么。主列表 readme.md 中大量条目都带一句描述正是这一准则的体现。7.5 Make it clear what the list is about让列表主题清晰README 顶部要有简洁描述列表必须覆盖明确的范围且不越界如果某个主题已有列表覆盖得很好就链接到那个列表而不是重复收录。7.6 Pay attention to grammar注意语法保证列表语法正确、零拼写错误、无 Markdown 格式错误——这条同样适用于提交的 PR。7.7 Choose an appropriate license选择合适的许可证若仓库没有选择许可证实际上意味着他人不被允许复制、分发或创作衍生作品。Creative Commons 许可证非常适合此类内容列表官方推荐 CC0MIT、BSD、GPL 等代码许可证不推荐。这与第五节 5.4 中的硬性要求相互呼应。7.8 Include contribution guidelines包含贡献指南贡献者需要清楚知道如何为你的列表做贡献。如果不打算从零撰写可以直接取用本仓库的 contributing.md 并按需修改——这也解释了为什么仓库会维护一份通用的贡献指南文件。7.9 Stylize your list properly规范排版创建目录Table of Contents、将内容按分类组织、合适时使用图片保证所有条目风格一致例如所有条目描述都以句号结尾。7.10 Accept other peoples opinion尊重他人意见作为列表所有者要尊重他人的意见当大量用户不同意你的决定时应重新考虑。这是列表长期健康运营的协作准则。八、网页端实操路径如何一步步提交contributing.md 给出了提交 PR 的完整网页操作流程可作为投稿时的操作手册打开目标 Awesome 列表的 GitHub 页面例如本仓库主页点击readme.md文件点击编辑图标在浏览器内置编辑器中修改文本遵循前述全部指南可使用 GitHub Flavored Markdown填写变更原因说明点击 Propose file change提交 Pull Request并按照第六节要求填写标题与条目描述如果维护者要求修改 PR通常是拼写错误或不符合列表指南参考官方提供的修改提交指南更新 PR 即可。需要特别注意的是本仓库同时附带 code-of-conduct.md贡献者行为准则contributing.md 明确声明参与该项目即表示同意遵守其条款——在投稿任何列表之前先阅读它能避免在社区协作层面踩雷。九、完整流程时间线将以上全部内容收敛为一条可执行的时间线读文档通读 awesome.md 宣言与 pull_request_template.md 指南多读几遍查重在 readme.md 中搜索确认无同类列表若有改为贡献给最好的那个创建列表按第五节全部硬性门槛建设仓库命名、标题、描述、目录、徽章、许可证、贡献指南、topics、main 分支持续打磨运行awesome-lint并修复问题用真实维护保证条目质量等待 30 天从第一次真实提交或开源发布取较晚者起算让列表成熟提交 PR 前复查再次阅读列表指南评审至少 4 个其他开放 PR认真指出问题才算数按Add Name of List格式命名标题、在合适分类底部插入条目、描述首字母大写且以句号结尾、URL 以#readme结尾评论中附上验证词unicorn提交并保持响应提交 PR 后对维护者的反馈及时响应、按需更新。结语创建并提交一个 Awesome 列表本质上是一场内容策展 工程规范的双重考验内容上要遵循 awesome.md 的只有 awesome 才叫 awesome工程上要满足 pull_request_template.md 的每一项检查。本文以 create-list.md 为骨架逐层展开了查重、30 天成熟期、列表硬性门槛、PR 提交规范与宣言十准则并把仓库内的 contributing.md、code-of-conduct.md、readme.md 与 media 徽章资源全部串联起来——按这条路径走你的列表才真正有资格被收录。Thanks for being awesome.赞分享文档知识库【免费下载链接】awesome Awesome lists about all kinds of interesting topics [NOTE: Pull requests are temporarily disabled until I have a chance to catch up with the existing ones]项目地址https://gitcode.com/GitHub_Trending/aw/awesome点击查看免费下载相关推荐awesome-shizuku 贡献指南为 Shizuku 应用精选列表提交条目的格式规范、收录门槛与自动化校验awesome shizuku 贡献指南为 Shizuku 应用精选列表提交条目的格式规范、收录门槛与自动化校验 本文以仓库根目录的 CONTRIBUTING文档知识库agentic-awesome-skills 贡献指南从零创建并提交高质量 Agentic Skill 的完整流程agentic awesome skills 贡献指南从零创建并提交高质量 Agentic Skill 的完整流程 本篇指南以仓库 docs/vietnameAI 技能AI 插件ReactPage 贡献指南从 monorepo 环境搭建到提交规范与 PR 流程完整实战ReactPage 贡献指南从 monorepo 环境搭建到提交规范与 PR 流程完整实战 ReactPage 是一个基于 React、使用 TypeScri前端UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考