agent-ready-template

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目12855的徽章级别为silver 这里是如何嵌入它：
您可以通过将其嵌入在您的Markdown文件中：
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12855/badge)](https://www.bestpractices.dev/projects/12855)
或将其嵌入到HTML中来显示您的徽章状态：
<a href="https://www.bestpractices.dev/projects/12855"><img src="https://www.bestpractices.dev/projects/12855/badge"></a>


这些是白银级别条款。您还可以查看通过或黄金级别条款。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本 17/17 ●

  • 常规

    请注意，其他项目可能使用相同的名称。

    Agent-ready multi-agent repository template specification and starter files

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

  • 先决条件


    足够获得徽章！

    项目必须拥有通过徽章。 [achieve_passing]

  • 基本项目网站内容


    足够获得徽章！

    关于如何贡献的信息必须包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [contribution_requirements]

    Contribution requirements are documented in CONTRIBUTING.md, with coding and repository conventions in CONVENTIONS.md and agent-facing workflow requirements in AGENTS.md: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/CONTRIBUTING.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/CONVENTIONS.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/AGENTS.md


  • 项目监督


    足够获得徽章！

    该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。 (需要网址) [dco]
    DCO是推荐的机制，因为它易于实现，在源代码中进行跟踪，并且git使用“commit -s”直接支持“签名”功能。更有效的是，项目文件解释了该项目的“签名”手段。 CLA是一项法律协议，用于定义知识产权许可给组织或项目的条款。捐助者转让协议（CAA）是将知识产权权利转让给另一方的法律协议；项目不必具备CAA，因为CAA增加了潜在贡献者不愿贡献的风险，特别是如果接收者是一个营利性组织。 Apache Software Foundation CLA（个人贡献者许可证和公司CLA）是CLA的示例，用于确定项目的这些CLA的风险对项目的影响小于其获益。

    CONTRIBUTING.md requires a DCO-style Signed-off-by trailer for contributions: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/CONTRIBUTING.md


    足够获得徽章！

    该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。 (需要网址) [governance]
    需要有一些成熟的书面方式来作出决定和解决争端。在小项目中，这可能就像“项目拥有者和负责人做所有最终决定”一样简单。有各种治理模式，包括仁慈的独裁者和正式的精英统治；有关详细信息，请参阅治理模式。集中式（例如，单一维护者）和分散式（例如，组维护者）方法都已经在项目中成功使用。治理信息不需要记录创建项目分支的可能性，因为对于FLOSS项目来说总是可能的。

    Governance and maintainer responsibilities are documented: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/GOVERNANCE.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/MAINTAINERS.md


    足够获得徽章！

    该项目必须采取行为守则，并将其发布在标准的位置。 (需要网址) [code_of_conduct]
    项目可能能够提高社区的文明程度，并通过采取行为守则来规定对可接受的行为的期望。这可以帮助在发生问题之前避免问题，并使项目成为更加欢迎的地方来鼓励贡献。这应该只关注项目社区/工作场所的行为。行为规范的示例是贡献者约定行为准则和Linux内核代码冲突。

    The project code of conduct is documented: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/CODE_OF_CONDUCT.md


    足够获得徽章！

    该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。 (需要网址) [roles_responsibilities]
    治理和角色和职责的文档可以在一个地方。

    Maintainer, contributor, and reviewer roles are documented: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/GOVERNANCE.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/MAINTAINERS.md


    足够获得徽章！

    如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。 (需要网址) [access_continuity]

    Solo-mode continuity is handled through a private emergency recovery procedure documented publicly without exposing recovery material: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/MAINTAINERS.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/GOVERNANCE.md


    足够获得徽章！

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]
    “公交车系数”（又名“卡车因子”）是指最少数量的项目成员，如果突然离开项目（“被公交车撞了”），项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息，请参阅Cosentino等人的评估Git存储库的卡车因子。

    Current bus factor is one. Private recovery supports continuity but is not claimed as a bus factor of two: https://github.com/Anionix/agent-ready-repoーtemplate/blob/main/MAINTAINERS.md https://github.com/Anionix/agent-ready-template/blob/main/GOVERNANCE.md


  • 文档


    足够获得徽章！

    该项目必须有一个文档化的路线图，描述项目打算做什么，至少在下一年做什么。 (需要网址) [documentation_roadmap]
    项目可能没有实现路线图，没关系。路线图的目的是帮助潜在的用户和贡献者了解项目的预期方向。它不需要特别详细。

    Roadmap documentation is maintained: https://github.com/Anionix/agent-ready-template/blob/main/docs/roadmap.md


    足够获得徽章！

    该项目必须包括项目生成的软件的架构（也称为高级别设计）的文档。如果项目不产生软件，请选择“不适用”（N/A）。 (需要网址) [documentation_architecture]
    软件架构解释了程序的基本结构，即程序的主要组件，它们之间的关系以及这些组件和关系的关键属性。

    Architecture documentation is maintained: https://github.com/Anionix/agent-ready-template/blob/main/docs/architecture.md


    足够获得徽章！

    该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容（其“安全需求”）。 (需要网址) [documentation_security]
    这些是软件意图满足的安全需求。

    Security policy, threat model, and security workflow documentation are maintained: https://github.com/Anionix/agent-ready-template/blob/main/SECURITY.md https://github.com/Anionix/agent-ready-template/blob/main/docs/threat-model.md https://github.com/Anionix/agent-ready-template/blob/main/docs/security-workflows.md


    足够获得徽章！

    该项目必须为新用户提供“快速启动”指南，以帮助他们快速使用该软件。 (需要网址) [documentation_quick_start]
    这个想法是向用户展示如何入门，使软件完全可以做事情。这对于潜在用户是至关重要的。

    README quick start commands show how to use and validate the template: https://github.com/Anionix/agent-ready-template/blob/main/README.md


    足够获得徽章！

    项目必须努力使文档与当前版本的项目结果（包括项目生成的软件）保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的，但是错误地包括一些不再是真实的旧信息，那么将其视为缺陷，然后像往常一样进行跟踪和修复。 [documentation_current]
    该文档可以包括有关软件版本之间的差异或更改的信息，与/或链接到旧版本的文档。这个条款的意图在于努力保持文档的一致性，而不是文档必须完美。

    Documentation is versioned with the repository and updated with release notes and Best Practices evidence: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/docs/openssf-best-practices.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/CHANGELOG.md


    足够获得徽章！

    项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就，包括此最佳实践徽章。 (需要网址) [documentation_achievements]
    一个成就是项目致力于满足的任何外部条款，包括徽章。该信息不需要在项目网站首页上。使用GitHub的项目可以通过将其添加到README文件中，将成果放在存储代码库首页。

    The README links to the template-instance Best Practices status document, which links to the Best Practices project and records achieved levels and blockers: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/README.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/docs/openssf-best-practices.md


  • 无障碍和国际化


    足够获得徽章！

    该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。 [accessibility_best_practices]
    对于Web应用程序，请参阅 Web 内容无障碍指导 (WCAG 2.0，英文) 以及其支持文档 理解 WCAG 2.0（英文）；或者 W3C 无障碍信息（英文）. 图形界面（GUI）应用考虑使用环境特定的无障碍指导（例如 Gnome, KDE, XFCE, Android, iOS, Mac, 以及 Windows). 一些TUI应用 (例如，`ncurses` 程序) 可以做一些特定的工作，增强可访问性（例如，`alpine` 的 `force-arrow-cursor` 设置）。多数命令行应用没有特别的无障碍设置。本条款经常是不涉及（N/A），例如，对于组件库。以下是一些要采取的行动或需要考虑的问题的例子：
    • 提供非文字内容的文字替代，以便于转换为其他需要的格式，如大字体、盲文、语音、符号或者简单文字（ WCAG 2.0 指导 1.1 （英文）)
    • 颜色不被用作传达信息，指示动作，提示响应或区分视觉元素的唯一视觉方式。 ( WCAG 2.0 指导 1.4.1（英文）)
    • 文本和文字图像的视觉呈现对比度至少为4.5：1，除了大文本，次要文本和标识符之外。 ( WCAG 2.0 指导 1.4.3（英文）)
    • 使用键盘可访问所有功能 (WCAG 指导 2.1)
    • 图形界面应用（GUI）或者Web应用在目标平台上，应该至少使用一种屏幕阅读器测试（例如，NVDA；Jaws；Windows上的WindowEyes；Mac & iOS上的VoiceOver；Linux/BSD上的Orca；Android上的TalkBack）。TUI程序可以减少过度渲染以防止屏幕阅读器的冗余读取。

    The project is operated through plain Markdown and command-line documentation, avoiding a non-text-only UI requirement for core use: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/README.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/docs/development.md


    足够获得徽章！

    该项目产生的软件应该被国际化，以便为目标受众的文化，地区或语言进行简单的本地化。如果国际化（i18n）不适用（例如，该软件不会生成针对最终用户的文本，并且不排序可读文本），请选择“不适用”（N/A）。 [internationalization]
    本地化“是指适应产品，应用或文档内容以满足特定目标市场（语言环境）的语言，文化和其他要求。国际化是“设计和开发产品，应用或文档内容，使不同文化，地区或语言的目标受众更容易本地化”。 （请参阅 W3C的“本地化与国际化”）。软件只需通过国际化即可达到此标准。不需要另一种特定语言的本地化，因为一旦软件已被国际化，其他人就可以从事本地化。

    Core operator guidance is English-first and includes Japanese companion text where useful for this template instance: https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/README.md https://github.com/Anionix/agent-ready-repo-template-spec/blob/main/AGENTS.md


  • 其他


    足够获得徽章！

    如果项目站点（网站，存储库和下载URL）存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法将密码存储为具有每用户盐值的迭代散列（例如，PBKDF2，Bcrypt或Scrypt）。如果项目站点不存储密码，请选择“不适用”（N/A）。 [sites_password_security]
    请注意，使用 GitHub 符合此条款。此条款仅适用于用于外部用户认证到项目站点的密码。如果项目站点必须登录到其他站点，则可能需要为此目的存储密码（因为使用像Bcrypt这样的算法会使这些密码无效）。本条款将 crypto_password_storage 条款应用于项目站点，类似于sites_https条款。

    The project does not operate a password-based project website; repository authentication is handled by GitHub.


 变更控制 1/1 ●

 报告 3/3 ●

 质量 19/19 ●

 安全 13/13 ●

 分析 2/2 ●


该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Sho Takayanagi和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Sho Takayanagi.
最后更新于 2026-05-16 16:05:43 UTC, 最后更新于 2026-05-29 15:06:10 UTC。 最后在 2026-05-17 12:13:36 UTC 获得通过徽章。