Related Pages

Related topics: Core Service Framework: BaseService, Routing, Caching & Token Pool, Service Integrations: GitHub, Packages, CI, Social & More

Repository Overview & Architecture

The badges/shields repository is the single source of truth for the Shields.io project. It hosts three independent but related artifacts: the production badge server, the public-facing documentation/catalog website, and the badge-maker NPM library that renders SVG badges. The project is maintained by a small core team and is licensed under CC0-1.0, which places all assets and code in the public domain. Source: README.md:1-50.

What Shields Does

Shields.io produces concise, consistent, and legible SVG badges that are typically embedded in GitHub READMEs and other documentation. The README lists representative use cases: code coverage percentage, stable release version, package manager release, status of third-party dependencies, static code analysis grade, SemVer observance, Liberapay donations per week, Python package downloads, Chrome Web Store extension rating, and Uptime Robot uptime percentage. Source: README.md:60-80.

The product line is intentionally broad: the public shields.io instance exposes dynamic badges (data fetched at request time) and static badges (caller-supplied text and color, e.g., https://img.shields.io/badge/left-right-f39f37). Source: README.md:82-88 and frontend/src/components/homepage-features.js:1-30.

The Three Components

The monorepo is organized into three top-level deliverables, each with its own package metadata and entry point.

Source: package.json:1-40, badge-maker/package.json:1-25, frontend/package.json:1-12, and frontend/src/components/homepage-features.js:38-60.

The root package.json wires these artifacts together through npm scripts. For local development, npm start runs the server (port 8080) and the Docusaurus dev server in parallel via concurrently; for production, npm run build regenerates the OpenAPI spec via node scripts/export-openapi-cli.js and then builds the static frontend into public/, after which npm run start:server:prod (alias now-start) starts node server. Source: package.json:8-25.

High-Level Architecture

At runtime, an incoming HTTP request for a badge URL flows through several layers. The server resolves the route to a service module, which calls an upstream API (such as GitHub, npm, PyPI, etc.), maps the response to a { message, color, label? } object, and hands it to badge-maker, which renders the final SVG. The result is cached and returned with appropriate HTTP headers. The frontend catalog and documentation site are built once and served as static assets from the same Node process.

flowchart LR
  User[Client / README] -->|GET badge URL| Server[Node server<br/>port 8080]
  Server -->|route match| Service[Service module<br/>core/service]
  Service -->|fetch + map| Upstream[(Upstream API<br/>GitHub, npm, ...)]
  Service -->|{message, color}| Maker[badge-maker]
  Maker -->|SVG| Server
  Server -->|SVG + cache headers| User
  Catalog[Static frontend<br/>Docusaurus] -->|served from public/| Server

This separation — service logic in the server, rendering in badge-maker, presentation in the Docusaurus frontend — keeps responsibilities clean and lets third parties reuse the renderer without running the badge server. Source: README.md:36-44 and badge-maker/package.json:3-12.

Server and Service Model

Each badge type is implemented as a service module that conforms to a small interface (route, examples, handlers, and a render function). The server wires every registered service into the HTTP router, so adding a new badge is largely a matter of adding a new service file. Service tests and integration tests run through icedfrisby and cypress (see scripts in package.json). Source: package.json:60-95 and the contributor guidance in README.md:102-116.

GitHub Token Pool

Because the public shields.io instance makes hundreds of thousands of GitHub API calls per hour, well beyond the 5,000/hour authenticated-user limit, the server maintains a token pool of user-shared OAuth tokens. As documented in the official blog post, users may authorize the project's OAuth app, which grants a read-only token that contributes to the shared pool and raises the effective rate limit. Source: frontend/blog/2024-11-14-token-pool.md:1-20.

This design choice has observable consequences for end users: the community has reported intermittent badge degradation when the pool is exhausted (issue #11912) and a failure mode where the server reports "Unable to select next Github token from pool" (issue #11921). These are operations issues at the boundary of the server and the GitHub service modules, not bugs in the route definitions themselves.

Frontend Catalog

The catalog and documentation site is built with Docusaurus 3 and the docusaurus-preset-openapi plugin, which auto-generates browsable service docs from an exported OpenAPI spec. The new-frontend blog post notes that this move reduced the amount of custom frontend code the team has to maintain. Source: frontend/blog/2023-07-03-new-frontend.md:1-12 and package.json:62-70.

The site's homepage advertises the four primary capabilities: dynamic badges, static badges, the badge-maker library, and the option to self-host via Docker. Source: frontend/src/components/homepage-features.js:14-65.

Notable Runtime Concerns

Two cross-cutting concerns surface repeatedly in the codebase and in community discussions.

Response caching. GitHub and other upstream responses are cached aggressively to keep upstream usage and p99 latency within budget. The community has requested the ability to manually clear cached badge responses (issue #11877) — useful when a private repository becomes public and the previously cached "not found" response would otherwise persist for its TTL.

JSONPath injection hardening. A security advisory in late 2024 tightened the JSONPath expression evaluator used by some dynamic badges to prevent remote code execution. The post enumerates the supported syntactic forms and intentionally rejects constructs that would allow prototype or expression evaluation. Source: frontend/blog/2024-09-25-rce.md:1-40.

Both topics illustrate that the architecture is not just "render a string into an SVG" — it is a small, opinionated edge platform with caching, authentication, and an input-handling surface area that must be defended.

Project Governance

The repository lists its active maintainers (calebcartwright, jNullj, LitoMore, paulmelnikow, PyvesB) and alumni, and points contributors at the issues labeled good first issue as a starting point. The community page acknowledges financial, service, and time contributors via Open Collective, and lists Coveralls, Cloudflare, Discord, and GitHub as providers of free plans. Source: README.md:118-148 and frontend/src/pages/community.md:1-30.

See Also

• Badge URL syntax and query parameters (e.g., the filter param described in the tag-filter blog post) — see frontend/blog/2023-07-29-tag-filter.md
• Service test conventions — referenced from README.md:108-110
• Self-hosting via the shieldsio/shields Docker image — referenced from frontend/src/components/homepage-features.js:56-60

Related Pages

Related topics: Repository Overview & Architecture, Service Integrations: GitHub, Packages, CI, Social & More

Core Service Framework: BaseService, Routing, Caching & Token Pool

Overview and Purpose

The Shields.io core service framework is the runtime backbone that turns declarative badge definitions into live HTTP endpoints. It is responsible for four tightly coupled concerns: loading service classes, registering them as URL routes, caching upstream API responses, and managing the GitHub token pool that authenticates a substantial portion of all badge requests. The Server class documented in core/server/server.js is the orchestrator that wires these subsystems together at boot time.

The framework follows a "constellation" pattern for shared dependencies: instead of every service class independently creating its own GitHub or Libraries.io client, the server instantiates a single GithubConstellation and a single LibrariesIoConstellation and injects them into each registered service. This makes rate-limit handling, token rotation, and metrics instrumentation centralized rather than scattered across hundreds of service files.

Server Bootstrap and Service Registration

The Server constructor validates configuration against publicConfigSchema and privateConfigSchema using Joi, then constructs the shared dependencies. As shown in core/server/server.js, the server:

1. Validates public and private configuration blocks.
2. Optionally validates the Influx metrics schema when metrics are enabled.
3. Constructs GithubConstellation, LibrariesIoConstellation, Prometheus metrics, and Influx metrics.
4. Calls registerServices() to walk the /services directory and register each service class.

The registerServices() method delegates discovery to loadServiceClasses() imported from ../base-service/loader.js, then invokes each service class's static register() method, passing in the camp instance, request handler, API providers, and metric instance. This is the single integration point where every badge endpoint becomes a route.

// Source: core/server/server.js
(await loadServiceClasses()).forEach(serviceClass =>
  serviceClass.register(
    {
      camp,
      handleRequest,
      githubApiProvider,
      librariesIoApiProvider,
      metricInstance,
    },
    {
      handleInternalErrors: config.public.handleInternalErrors,
      cacheHeaders: config.public.cacheHeaders,
      rasterUrl: config.public.rasterUrl,
      private: config.private,
      public: config.public,
    },
  ),
)

The framework is built on Scoutcamp (imported as Camp from '@shields_io/camp'), a lightweight Node.js HTTP framework. The server also bootstraps the global-agent proxy when HTTP_PROXY or HTTPS_PROXY environment variables are present, allowing self-hosting behind corporate proxies, and attaches the cloudflare-middleware to honor request origin headers correctly.

Routing, Caching, and Error Handling

Routing is declarative: each service class statically declares its route (an Express-style path with named placeholders such as /github/v/release/:user/:repo) and a handler function. The framework maps these declarations to Scoutcamp routes that accept both /badge/:service and :service URL conventions, and supports both SVG and raster (PNG) output via query parameters.

Caching operates on two levels:

The clearResourceCache symbol is imported into the server module alongside handleRequest, legacy-result-sender, and rasterRedirectUrl, indicating that cache invalidation is a first-class server concern rather than an internal service detail. This is directly relevant to community issue #11877, which requests a manual cache-clearing endpoint.

Error handling uses two strategies: services throw typed errors (e.g., NotFound, InvalidResponse, InvalidParameter) which the legacy result sender translates into a consistent badge image, and the server's handleInternalErrors configuration flag controls whether unexpected exceptions are rendered as badges or surfaced as 500 responses.

The GitHub Token Pool

Because a very large share of shields.io traffic touches the GitHub API, the framework includes a dedicated GithubConstellation that owns a rotating pool of authentication tokens. As documented in frontend/blog/2024-11-14-token-pool.md, GitHub enforces a primary rate limit of 5,000 requests per hour per authenticated token for the v3/REST API, and the v4/GraphQL API uses a separate point-based limit.

The constellation abstracts this away: each GitHub-facing service asks the githubApiProvider for a client, the constellation picks the least-loaded token that still has remaining quota, attaches it to the request, and decrements its remaining-requests counter. When a token is exhausted, the constellation rotates it out of the pool until its hourly window resets.

flowchart LR
    A[Badge Service] -->|requests client| B[GithubConstellation]
    B -->|selects token with| C[Token Pool]
    C -->|least remaining usage| D[Token 1]
    C --> E[Token 2]
    C --> F[Token N]
    D & E & F -->|authenticated request| G[GitHub REST / GraphQL API]
    G -->|429 or remaining = 0| B

Two operational failure modes observed in the wild are tracked in issues #11912 and #11921. When the pool is unexpectedly depleted or exhausted, badges display the literal text "Unable to select next Github token from pool" instead of data, which is the constellation's error path rather than an HTTP failure. The pool size is grown voluntarily by users authorizing the shields.io OAuth application, which contributes a read-only token with minimum permissions.

Service Class Loader and Extension Points

The loadServiceClasses() function imported in core/server/server.js is the framework's only extensibility boundary. Any module under services/ that exports a class conforming to the BaseService contract (with a static route, category, examples, defaultBadgeData, and a handle() method, or a handleLegacy() method for older services) is automatically registered without further wiring. This convention is what enables the broad catalog of badges documented on the shields.io site and is the same contract used by services such as the GitHub tag/release badge with arbitrary filter parameters described in frontend/blog/2023-07-29-tag-filter.md.

Development is supported by npm start, which runs the server and the Docusaurus-based frontend concurrently, and by npm run badge -- /npm/v/nock for debugging a single badge URL from the CLI. The server itself runs in production via npm run start:server:prod, and the nodemonConfig block in package.json excludes the frontend directory and test files from the server's file watcher so frontend edits do not trigger restarts.

See Also

• Frontend and Docusaurus setup
• Badge specification
• Tutorial: Adding a New Badge
• Production Hosting Guide
• Server Secrets Configuration

Related Pages

Related topics: Repository Overview & Architecture, Service Integrations: GitHub, Packages, CI, Social & More

badge-maker Library & Static Badge Generation

Overview and Purpose

The badge-maker package is the standalone SVG badge rendering library that powers Shields.io. It is published on npm as badge-maker and is consumed both internally by the shields.io server and externally by third parties who want to generate badges in their own applications, CLIs, or build pipelines. Source: README.md.

The package exposes a single primary function — makeBadge(format) — that takes a JavaScript object describing the badge and returns a rendered SVG string. The current published version is 5.0.2 as declared in badge-maker/package.json. It is published as an ES module ("type": "module") and supports Node.js 20 and above.

Inside the shields.io repository, the same library is wired into the server bootstrap at core/server/server.js, where import makeBadge from '../../badge-maker/lib/make-badge.js' is used by the legacy request handler to convert internal badge data into SVG output. This shared dependency means that any visual change made to the library is automatically reflected in the live shields.io site. Source: package.json.

Installation and Usage Modes

badge-maker can be consumed in three different ways, all documented in badge-maker/README.md.

As a CLI

After running npm install -g badge-maker, the package ships a badge binary declared in badge-maker/package.json under "bin": { "badge": "lib/badge-cli.js" }. A typical invocation is:

badge build passed :brightgreen > mybadge.svg

As a Library

For programmatic use, the public API is re-exported from badge-maker/lib/index.js:

import { makeBadge, ValidationError } from 'badge-maker'

const format = {
  label: 'build',
  message: 'passed',
  color: 'brightgreen',
}

const svg = makeBadge(format)

Validation failures throw a ValidationError, which is also exported as a named export so consumers can catch and handle it specifically.

As a Dependency of shields.io

The root package.json declares "badge-maker": "file:badge-maker", meaning the server uses the local checkout as the authoritative source. This guarantees that badges served by shields.io are produced by the same code path documented in this page.

Format Specification

The format object accepted by makeBadge is normalized and validated inside badge-maker/lib/index.js. The _validate function enforces type and value constraints, and _clean applies defaults and legacy coercions. The following table summarizes the supported fields:

Source: badge-maker/lib/index.js.

The list of allowed style values is hard-coded in _validate:

const styleValues = [
  'plastic', 'flat', 'flat-square', 'for-the-badge', 'social',
]

If message is missing or any string field has the wrong type, a ValidationError is thrown with a descriptive message, e.g. Field 'message' is required.

Style Rendering and Visual Output

The visual differentiation between badge styles is implemented as a class hierarchy in badge-maker/lib/badge-renderers.js. Each style is a subclass of a base Badge class that overrides properties such as height, verticalMargin, and shadow, and implements its own render() method.

For example, the Plastic style has:

• static get height() { return 18 }
• static get verticalMargin() { return -10 }
• static get shadow() { return true }

The renderer then constructs SVG gradient stops, blur filters, and clip paths to produce the characteristic glossy look. The flat style (the default and most common shields.io style) omits the gradient and shadow, producing a cleaner modern look. The for-the-badge style uses a larger font and uppercase-only text, while the social style capitalizes the first letter of the label, as verified in badge-maker/lib/make-badge.spec.js by the test "should produce capitalized string for badge key".

Text width is computed using the anafanafo package — declared as a dependency in badge-maker/package.json — which provides accurate measurements for the Verdana font at the badge's font size.

Color Handling

Color strings can be supplied in multiple formats. The color.js module (referenced via the library's internal pipeline and tested through snapshot fixtures) supports named CSS colors, hex codes (#rgb, #rrggbb), and short hex forms. When the user supplies a color like brightgreen, it is mapped to a defined palette; when a hex value is supplied, it is passed through unchanged to the SVG fill attribute. The conversion logic lives in badge-maker/lib/color.js, which is consumed through the css-color-converter dependency declared in badge-maker/package.json.

Integration with the Server Pipeline

The badge-maker library is intentionally decoupled from network concerns. It does not fetch data, does not cache responses, and does not perform any HTTP work. The server-side wrapper in core/server/server.js takes care of routing, parameter validation (via Joi), fetching upstream API data, and then invokes makeBadge to produce the final SVG. This separation is what enables the same library to be reused both server-side at scale and client-side in user scripts.

flowchart LR
  A[HTTP Request] --> B[Joi Validation]
  B --> C[Service Handler]
  C --> D[Upstream API Call]
  D --> E{Build format object}
  E --> F[badge-maker.makeBadge]
  F --> G[SVG Output]
  G --> H[HTTP Response]

  classDef lib fill:#e6f7ff,stroke:#1890ff
  class F lib

Common Failure Modes

When integrating the library, several issues are worth anticipating:

1. Missing message field — The most common error. _validate throws a ValidationError with the message Field 'message' is required. Source: badge-maker/lib/index.js.
2. Invalid style name — Supplying a style outside the allowed set throws Field 'style' must be one of (plastic,flat,flat-square,for-the-badge,social).
3. SVG ID collisions — When embedding multiple badges in the same HTML document, identical SVG IDs (used for gradient and clip-path references) can clash. Setting idSuffix to a per-badge unique string resolves this.
4. Logo encoding issues — logoBase64 must be a properly encoded data URL; malformed values are accepted as strings but produce broken renders. Source: badge-maker/README.md.

See Also

• Shields.io Main README
• Adding a New Service Tutorial
• Service Tests Guide
• badge-maker npm Package
• Badge Design Specification

Related Pages

Related topics: Core Service Framework: BaseService, Routing, Caching & Token Pool

Service Integrations: GitHub, Packages, CI, Social & More

Shields.io ships hundreds of badge services that translate live data from external platforms (GitHub, package registries, CI providers, social networks, app stores, code-coverage tools, etc.) into SVG badges. Every service follows a uniform registration model so that a request like https://img.shields.io/github/stars/badges/shields is resolved through the same request lifecycle regardless of which upstream system is queried. Source: README.md.

Architecture of the Service Layer

The server bootstraps two long-lived providers that act as shared API clients for every dependent service:

• GithubConstellation — manages a rotating pool of GitHub OAuth tokens so that badges calling the REST or GraphQL API can stay within GitHub's hourly limit. Source: core/server/server.js
• LibrariesIoConstellation — analogous client for the libraries.io API, used by package-metric badges. Source: core/server/server.js

Once bootstrapped, the server calls loadServiceClasses() to discover every *.service.js module under services/. Each class implements a register({ camp, handleRequest, githubApiProvider, librariesIoApiProvider, metricInstance }, config) method that wires route handlers into the Camp HTTP router. Source: core/server/server.js.

flowchart LR
    A[HTTP Request] --> B[Camp Router]
    B --> C[legacy-request-handler]
    C --> D[Service Class]
    D --> E[github-constellation]
    D --> F[librariesio-constellation]
    D --> G[Upstream API]
    D --> H[legacy-result-sender]
    H --> I[badge-maker / SVG]
    I --> J[Client]

The handleRequest helper validates path parameters against each service's schema and propagates errors into a normalized badge response. Source: core/base-service/legacy-request-handler.js. The final SVG is produced by badge-maker, an in-repo NPM library whose makeBadge function renders label/value/messages into a flat-style SVG. Source: core/server/server.js and badge-maker/package.json.

GitHub-Family Services

GitHub badges form the largest cluster. Common examples include:

These services share the GithubConstellation token pool. As described in the project's blog, users may voluntarily donate a token via the OAuth application to raise the global rate-limit ceiling. Source: frontend/blog/2024-11-14-token-pool.md. When the pool is exhausted or no token can be selected, all GitHub badges display the error message Unable to select next Github token from pool, a regression tracked by the community (see #11921). Source: issue #11921. Sustained high traffic can also drain the pool faster than expected, causing intermittent "rate limit exceeded" badges (see #11912).

URL parameters are common to nearly every GitHub service. The release badge, for example, accepts a filter query that excludes tags via a glob with optional ! negation. Source: frontend/blog/2023-07-29-tag-filter.md. Note that GitHub workflow badges required a route migration that is documented in community thread #8671 — users with .github/workflows/test.yml had to update their URLs accordingly. Source: issue #8671.

Package, CI, Container & Social Services

Beyond GitHub, the loader also registers services for:

• Package registries — npm, PyPI, crates.io, Maven, RubyGems, WinGet, and the GitHub Container Registry (see #5594, #4183).
• CI providers — Travis CI, CircleCI, Azure Pipelines, Bitrise, and others.
• Container hubs — Docker Hub, GHCR, Quay.
• Social platforms — YouTube, Reddit, Stack Exchange, Liberapay.
• App/add-on stores — Chrome Web Store, Mozilla Add-ons (request for Thunderbird ATN tracked in #6994), Figma Community Plugins (tracked in #11925).
• Code quality — Codacy, Codecov, Coveralls, SonarQube.

Each service is independent but reuses common validators exported from services/validators.js (e.g., nonNegativeInteger, optionalUrl, url) to keep input parsing consistent. Source: core/server/server.js.

Caching, Errors, and Common Failure Modes

The resource-cache module deduplicates concurrent upstream requests and applies a TTL so that a flood of badge hits does not translate into a flood of API calls. Source: core/server/server.js. Cache lifetimes are tunable through config.public.cacheHeaders; cached SVG responses therefore frequently appear as 504 timeouts in browser consoles when Cloudflare's edge expires them (tracked in #1568). Source: issue #1568.

When a target repository is private or otherwise inaccessible, the GitHub-family services render a structured error badge rather than failing silently. A frequently requested feature is a manual cache-clearing endpoint so that operators can force a refresh after credentials rotate (see #11877).

Self-hosters can configure the server through config.private and config.public, including the optional rasterUrl for converting SVG to PNG via an external rasterizer. Source: core/server/server.js. A GLOBAL_AGENT_* proxy bootstrap is also provided, enabling self-hosting behind corporate firewalls via standard HTTP_PROXY/HTTPS_PROXY env vars. Source: core/server/server.js.

Unknown paths are answered with a static, on-brand 404 page rather than a generic error. Source: core/server/error-pages/404.html.

See Also

• Badge Generator Library (badge-maker)
• GitHub Token Pool & Rate Limiting
• Adding a New Service — Tutorial
• Configuration Reference

Doramagic Pitfall Log

Found 15 structured pitfall item(s), including 6 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/11285

2. Capability evidence risk: Capability evidence risk requires verification

• Severity: high
• Finding: Project evidence flags a capability evidence risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/6047

3. Runtime risk: Runtime risk requires verification

• Severity: high
• Finding: Project evidence flags a runtime risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/11877

4. Maintenance risk: Maintenance risk requires verification

• Severity: high
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/11925

5. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/6994

6. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/11912

7. Identity risk: Identity risk requires verification

• Severity: medium
• Finding: Project evidence flags a identity risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: identity.distribution | github_repo:7910045 | https://github.com/badges/shields

8. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/badges/shields/issues/11917

9. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | github_repo:7910045 | https://github.com/badges/shields

10. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | github_repo:7910045 | https://github.com/badges/shields

11. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | github_repo:7910045 | https://github.com/badges/shields

12. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | github_repo:7910045 | https://github.com/badges/shields

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using shields with real data or production workflows.

• Figma Community Plugins badges - github / github_issue
• Add a way to manually clear cached badge responses - github / github_issue
• Unexpectedly Rapid GitHub Token Rate Limit Depletion - github / github_issue
• GitHub badges showing "Unable to select next Github token from pool" - github / github_issue
• Badge request: GitHub Discussions - github / github_issue
• Provide high resolution favicon - github / github_issue
• Mozilla Thunderbird add-ons (ATN) - github / github_issue
• GitHub org not verified - github / github_issue
• WinGet Service: add ReleaseDate - github / github_issue
• Identity risk requires verification - GitHub / issue