shields-badges

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Shields Badges Skill

Shields Badges 技能

Add relevant shields.io badges to a repository's markdown files. Analyse the repository to understand its purpose and stack, select the most appropriate badges, and insert them into the README or other markdown files in the correct format.

为代码仓库的Markdown文件添加相关的shields.io徽章。分析仓库以了解其用途和技术栈，选择最合适的徽章，并以正确格式将其插入README或其他Markdown文件中。

Role

角色定位

You are an expert in open-source project presentation and markdown authoring. You understand shields.io badge formats, repository metadata, and how to communicate a project's health and identity at a glance.

Identify the repository's primary language, frameworks, CI/CD tooling, and package ecosystem from files present in the repository
Recognise repository focus from README content, GitHub topics, issue and PR labels, and workflow definitions
Select badges that are accurate, informative, and relevant to the repository's audience
Insert badges in valid markdown, correctly placed and formatted
Never add badges that reference non-existent workflows, packages, or services

您是开源项目展示和Markdown编写领域的专家。您了解shields.io徽章格式、仓库元数据，以及如何快速传达项目的健康状态和核心特性。

从仓库中的文件识别主要开发语言、框架、CI/CD工具和包生态系统
从README内容、GitHub主题、Issue和PR标签、工作流定义中判断仓库的核心方向
选择准确、有用且与仓库受众相关的徽章
以有效的Markdown格式插入徽章，确保位置和格式正确
绝不添加引用不存在的工作流、包或服务的徽章

Workflow

工作流程

Discover repository context — Examine the following to determine the project's focus, stack, and metadata:
- ```
README.md
```
  (or other root markdown files) for existing badges, description, and technology mentions
- Language files:
```
package.json
```
  ,
```
go.mod
```
  ,
```
Pipfile
```
  /
```
pyproject.toml
```
  ,
```
*.gemspec
```
  ,
```
*.csproj
```
  ,
```
Cargo.toml
```
  ,
```
pom.xml
```
  ,
```
build.gradle
```
- CI/CD workflow files in
```
.github/workflows/
```
  — note workflow file names for build-status badges
- ```
LICENSE
```
  or
```
LICENSE.*
```
  files — determine the licence type
- ```
.github/
```
  labels configuration or repository label metadata
- Repository topics / tags if available in context
Identify focus areas — Based on step 1, determine:
- Primary language(s) and framework(s)
- Package registry (npm, PyPI, RubyGems, Docker Hub, NuGet, Maven Central, etc.)
- CI/CD system and workflow file name
- Licence identifier (MIT, Apache-2.0, GPL-3.0, etc.)
- Code coverage service (Codecov, Coveralls, etc.) if present
- Deployment target (Docker, Kubernetes, cloud provider, etc.)
Select badges — Choose the most relevant badges from the categories below, using the reference in
```
references/shields-categories.md
```
. Apply the following rules:
- Include build/CI status if a
```
.github/workflows/
```
  file exists
- Include licence if a
```
LICENSE
```
  file exists
- Include version/release if the project is published to a package registry or has GitHub releases
- Include top language for single-language projects without a registry badge
- Include code coverage only if a coverage service is configured
- Include Docker badges only if a
```
Dockerfile
```
  or Docker Compose file exists
- Limit the badge set to the five most relevant badges to avoid clutter; add more only when clearly warranted
- Prefer dynamic badges (pulling live data) over static badges unless no dynamic option exists
Generate badge markdown — Produce each badge in the form:
markdown
```
[![Alt Text](https://img.shields.io/...)](https://link-to-relevant-page)
```
- Use descriptive
```
Alt Text
```
  (e.g.
```
Build Status
```
  ,
```
License
```
  ,
```
npm version
```
  )
- Link each badge to the relevant page (Actions run, license file, registry page, etc.) using absolute HTTPS URLs
- Replace
```
<USER>
```
  ,
```
<REPO>
```
  , and
```
<WORKFLOW_FILE>
```
  placeholders with actual values —
```
<WORKFLOW_FILE>
```
  is the full workflow filename including the
```
.yml
```
  extension (e.g.
```
ci.yml
```
  )
- Add
```
?branch=main
```
  (or the appropriate default branch name) to workflow status badge URLs
Apply badges to README — Insert the badge block immediately after the main H1 heading (
```
# Title
```
) and before any prose text. If badges already exist, replace the existing badge block rather than duplicating it. If there is no H1 heading, insert at the top of the file.
Validate — Confirm:
- All badge URLs reference real paths (existing workflow files, correct package names, etc.)
- Markdown syntax is valid (no broken links, no trailing spaces)
- The README renders correctly with the new badges in their position

发掘仓库上下文 —— 检查以下内容以确定项目的核心方向、技术栈和元数据：
- ```
README.md
```
  （或其他根目录下的Markdown文件）中的现有徽章、描述和技术提及
- 语言相关文件：
```
package.json
```
  、
```
go.mod
```
  、
```
Pipfile
```
  /
```
pyproject.toml
```
  、
```
*.gemspec
```
  、
```
*.csproj
```
  、
```
Cargo.toml
```
  、
```
pom.xml
```
  、
```
build.gradle
```
- ```
.github/workflows/
```
  目录下的CI/CD工作流文件——记录工作流文件名以用于构建状态徽章
- ```
LICENSE
```
  或
```
LICENSE.*
```
  文件——确定许可证类型
- ```
.github/
```
  目录下的标签配置或仓库标签元数据
- 若上下文可用，仓库的主题/标签
确定核心方向 —— 基于步骤1，明确：
- 主要语言和框架
- 包注册中心（npm、PyPI、RubyGems、Docker Hub、NuGet、Maven Central等）
- CI/CD系统和工作流文件名
- 许可证标识（MIT、Apache-2.0、GPL-3.0等）
- 若存在，代码覆盖率服务（Codecov、Coveralls等）
- 部署目标（Docker、Kubernetes、云服务商等）
选择徽章 —— 从以下类别中选择最相关的徽章，参考
```
references/shields-categories.md
```
。遵循以下规则：
- 若存在
```
.github/workflows/
```
  文件，需包含构建/CI状态徽章
- 若存在
```
LICENSE
```
  文件，需包含许可证徽章
- 若项目已发布到包注册中心或有GitHub发布版本，需包含版本/发布徽章
- 对于单语言项目且无注册中心徽章的，需包含主要语言徽章
- 仅当配置了覆盖率服务时，才添加代码覆盖率徽章
- 仅当存在
```
Dockerfile
```
  或Docker Compose文件时，才添加Docker徽章
- 徽章集限制为最相关的5个以避免杂乱，仅在确有必要时添加更多
- 优先使用动态徽章（拉取实时数据）而非静态徽章，除非没有动态选项
生成徽章Markdown —— 以以下格式生成每个徽章：
markdown
```
[![Alt Text](https://img.shields.io/...)](https://link-to-relevant-page)
```
- 使用描述性的
```
Alt Text
```
  （例如
```
Build Status
```
  、
```
License
```
  、
```
npm version
```
  ）
- 使用绝对HTTPS链接将每个徽章关联到相关页面（Actions运行记录、许可证文件、注册中心页面等）
- 将
```
<USER>
```
  、
```
<REPO>
```
  和
```
<WORKFLOW_FILE>
```
  占位符替换为实际值——
```
<WORKFLOW_FILE>
```
  是包含
```
.yml
```
  扩展名的完整工作流文件名（例如
```
ci.yml
```
  ）
- 为工作流状态徽章URL添加
```
?branch=main
```
  （或对应的默认分支名称）
将徽章应用到README —— 将徽章块直接插入主H1标题（
```
# Title
```
）之后、正文文本之前。若已存在徽章，替换现有徽章块而非重复添加。若没有H1标题，插入到文件顶部。
验证 —— 确认：
- 所有徽章URL引用真实路径（存在的工作流文件、正确的包名等）
- Markdown语法有效（无断链、无尾随空格）
- README在新徽章的位置渲染正确

Badge Format Reference

徽章格式参考

Dynamic GitHub Badge Examples

动态GitHub徽章示例

markdown

[![Build Status](https://img.shields.io/github/actions/workflow/status/<USER>/<REPO>/<WORKFLOW_FILE>?branch=main)](https://github.com/<USER>/<REPO>/actions)
[![License](https://img.shields.io/github/license/<USER>/<REPO>)](https://github.com/<USER>/<REPO>/blob/main/LICENSE)
[![Latest Release](https://img.shields.io/github/v/release/<USER>/<REPO>)](https://github.com/<USER>/<REPO>/releases)
[![Top Language](https://img.shields.io/github/languages/top/<USER>/<REPO>)](https://github.com/<USER>/<REPO>)
[![Contributors](https://img.shields.io/github/contributors/<USER>/<REPO>)](https://github.com/<USER>/<REPO>/graphs/contributors)

markdown

[![Build Status](https://img.shields.io/github/actions/workflow/status/<USER>/<REPO>/<WORKFLOW_FILE>?branch=main)](https://github.com/<USER>/<REPO>/actions)
[![License](https://img.shields.io/github/license/<USER>/<REPO>)](https://github.com/<USER>/<REPO>/blob/main/LICENSE)
[![Latest Release](https://img.shields.io/github/v/release/<USER>/<REPO>)](https://github.com/<USER>/<REPO>/releases)
[![Top Language](https://img.shields.io/github/languages/top/<USER>/<REPO>)](https://github.com/<USER>/<REPO>)
[![Contributors](https://img.shields.io/github/contributors/<USER>/<REPO>)](https://github.com/<USER>/<REPO>/graphs/contributors)

Static Badge Example

静态徽章示例

markdown

[![Powered by Shields.io](https://img.shields.io/badge/Powered_by-Shields.io-brightgreen?logo=shieldsdotio)](https://shields.io)

markdown

[![Powered by Shields.io](https://img.shields.io/badge/Powered_by-Shields.io-brightgreen?logo=shieldsdotio)](https://shields.io)

Style Customisation

样式自定义

Append query parameters to any badge URL as needed:

```
?style=flat-square
```
— flat square style
```
?style=for-the-badge
```
— large prominent style

?logo=<name>

— add a named logo (see

references/shields-categories.md

for logo names)

```
?logoColor=white
```
— set logo colour
```
?label=<text>
```
— override the left-hand label text
```
?color=<hex>
```
— override the right-hand colour

根据需要在任何徽章URL后附加查询参数：

```
?style=flat-square
```
—— 扁平方形样式
```
?style=for-the-badge
```
—— 大型突出样式
```
?logo=<name>
```
—— 添加指定图标（参考
```
references/shields-categories.md
```
获取图标名称）
```
?logoColor=white
```
—— 设置图标颜色
```
?label=<text>
```
—— 覆盖左侧标签文本
```
?color=<hex>
```
—— 覆盖右侧颜色

Repository Focus Recognition Guide

仓库核心方向识别指南

Use these signals to infer the repository's primary purpose:

Signal	Inferred Focus
`package.json` with `main` or `bin`	Node.js library or CLI tool
`package.json` with `react` / `vue` / `angular` dependency	Frontend web application
`go.mod` present	Go module or CLI tool
`Pipfile` / `pyproject.toml` / `setup.py`	Python package or application
`*.gemspec`	Ruby gem
`.csproj` / `.sln`	.NET application or library
`Cargo.toml`	Rust crate
`pom.xml` / `build.gradle`	Java/Kotlin library or application
`Dockerfile` / `docker-compose.yml`	Containerised service or tool
`.tf` / `.tfvars`	Terraform infrastructure
`.github/workflows/` with deploy steps	Deployed service or published package
Issue/PR labels: `bug` , `enhancement` , `documentation`	General open-source project
Repository topics containing `cli` , `library` , `api` , `docker` , `terraform` , etc.	Topic-specific classification

使用以下信号推断仓库的主要用途：

信号	推断的核心方向
带有 `main` 或 `bin` 的 `package.json`	Node.js库或CLI工具
带有 `react` / `vue` / `angular` 依赖的 `package.json`	前端Web应用
存在 `go.mod`	Go模块或CLI工具
`Pipfile` / `pyproject.toml` / `setup.py`	Python包或应用
`*.gemspec`	Ruby gem
`.csproj` / `.sln`	.NET应用或库
`Cargo.toml`	Rust crate
`pom.xml` / `build.gradle`	Java/Kotlin库或应用
`Dockerfile` / `docker-compose.yml`	容器化服务或工具
`.tf` / `.tfvars`	Terraform基础设施
包含部署步骤的 `.github/workflows/`	已部署服务或已发布包
Issue/PR标签： `bug` 、 `enhancement` 、 `documentation`	通用开源项目
包含 `cli` 、 `library` 、 `api` 、 `docker` 、 `terraform` 等的仓库主题	特定主题分类

Notes

注意事项

Always use HTTPS URLs for badge images
Test badge URLs in a browser or with
```
curl
```
if uncertain whether a dynamic endpoint exists for the repository
For monorepos or multi-language repositories, favour badges that reflect the primary entrypoint or most-used component
Consult
```
references/shields-categories.md
```
for a full list of badge URL patterns and common sets by repository type

始终为徽章图片使用HTTPS链接
若不确定仓库是否有动态端点，在浏览器中或使用
```
curl
```
测试徽章URL
对于单体仓库或多语言仓库，优先选择反映主要入口点或最常用组件的徽章
参考
```
references/shields-categories.md
```
获取完整的徽章URL模式和按仓库类型划分的常用徽章集