GO — Healthy across the board

• Last commit 1d ago
• 71+ active contributors
• Distributed ownership (top contributor 26% of recent commits)
• CC0-1.0 licensed
• CI configured
• ⚠ No test directory detected
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

sindresorhus/awesome is a curated, community-maintained meta-list of 'awesome lists' — GitHub repositories that collect high-quality resources on specific topics. It solves the discoverability problem for developers by aggregating vetted, topic-specific resource lists into a single navigable index. The project enforces strict quality standards via a pull request template (pull_request_template.md), a linting workflow (.github/workflows/main.yml + repo_linter.sh), and detailed contribution guidelines (contributing.md, create-list.md). Flat repo structure: readme.md is the single source of truth containing all categorized list links, supported by governance docs (contributing.md, create-list.md, awesome.md, code-of-conduct.md) and a media/ directory for badge SVGs and logo assets. Automation lives entirely in .github/workflows/ with a GitHub Actions workflow and a bash linter script.

Developers, researchers, and hobbyists who want to discover best-in-class resources for a specific technology or topic, and community curators who want to submit or maintain their own 'awesome list' that meets the project's quality bar. Contributors are typically open source enthusiasts who have already created a well-maintained list in a specific domain.

This is one of the most starred repositories on GitHub (100k+ stars) and has been actively maintained since 2014, making it extremely mature. CI is configured via .github/workflows/main.yml with a shell-based repo linter (repo_linter.sh) that validates incoming lists. It is unambiguously production-ready and represents a reference standard for the 'awesome list' format.

Risk is minimal for consumers — it is a static markdown document with no runtime dependencies. The primary risk for contributors is rejection of PRs due to strict quality enforcement via repo_linter.sh and pull_request_template.md requirements. Single-maintainer risk exists (sindresorhus), but the repo has broad community trust and a long track record.

Active work is primarily incoming PRs from the community adding or updating list entries in readme.md. The GitHub Actions workflow in .github/workflows/main.yml and repo_linter.sh are the active automation layer; any changes to acceptance criteria would appear there. No major structural refactors are visible from the file tree.

git clone https://github.com/sindresorhus/awesome.git && cd awesome && open readme.md # No build step or package manager needed — this is a pure markdown project. To test the linter locally: bash .github/workflows/repo_linter.sh

Daily commands: No dev server needed. To preview markdown: open readme.md in any markdown renderer (GitHub, VS Code with Markdown Preview). To run the linter: bash .github/workflows/repo_linter.sh <repo-url>

• readme.md — The main curated list of awesome lists — the primary content artifact every contributor modifies when adding or updating links.
• contributing.md — Defines the strict contribution guidelines and quality standards that all PRs must satisfy before merging.
• create-list.md — Step-by-step instructions for creating a new awesome list that meets the project's curation standards.
• awesome.md — The manifesto defining what qualifies as 'awesome' — the philosophical and quality bar for all included lists.
• .github/workflows/main.yml — CI workflow that automatically lints PRs and validates that contributions meet formatting and quality requirements.
• .github/workflows/repo_linter.sh — Shell script that enforces repository-level linting rules during CI, catching common formatting and structural violations.
• pull_request_template.md — PR checklist template that guides contributors through all required steps before a submission can be reviewed.

• readme.md (Markdown) — Single source of truth for all curated list links organized by category.
  • Failure mode: Broken links, duplicate entries, or mis-sorted entries degrade user trust.
• contributing.md (Markdown) — Defines the acceptance criteria and formatting rules that gate all contributions.
  • Failure mode: Outdated or ambiguous guidelines cause contributor confusion and increased review overhead.
• repo_linter.sh (Bash, GitHub Actions) — Automated enforcement of structural rules on the repository during CI.
  • Failure mode: Gaps in linting rules allow non-compliant entries to be merged undetected.
• main.yml (GitHub Actions YAML) — Orchestrates CI checks triggered by PRs and pushes to the main branch.
  • Failure mode: Misconfigured triggers or permissions could cause CI to silently skip validation.
• pull_request_template.md (Markdown) — Presents contributors with a mandatory checklist embedded in every PR description.
  • Failure mode: Contributors ignoring the checklist bypass the quality gate, increasing maintainer review burden.
• media/badge.svg (SVG) — Provides the canonical awesome badge for downstream list maintainers to embed in their repos.
  • Failure mode: Badge URL changes or corruption break the visual signal on hundreds of downstream repos.

• Contributor → readme.md — Contributor edits the markdown file to add, update, or remove a list entry.
• GitHub PR → main.yml — PR event triggers the GitHub Actions CI workflow.
• main.yml → repo_linter.sh — CI workflow executes the shell linter against the changed files.
• repo_linter.sh → GitHub PR — Linter results are reported back as a pass/fail status check on the PR.
• Maintainer → readme.md — Approved PRs are merged, permanently updating the curated list.

Add a new awesome list link to the main list

1. Read the quality checklist to confirm the list meets all awesome criteria before submitting (awesome.md)
2. Review formatting conventions (alphabetical order, description style, category placement) (contributing.md)
3. Add the new list entry under the appropriate category in the correct alphabetical position (readme.md)
4. Open a PR and verify every item in the contributor checklist is ticked (pull_request_template.md)

Create a brand-new awesome list and get it included

1. Follow the full guide to scaffold a compliant awesome list repo with required files and structure (create-list.md)
2. Embed the awesome badge in your new list's readme using the provided SVG asset (media/badge.svg)
3. Once the list is mature, add it to the main readme under the correct category (readme.md)

Update or extend the CI linting rules

1. Edit the shell linter to add new structural or formatting checks for incoming PRs (.github/workflows/repo_linter.sh)
2. Update the GitHub Actions workflow to adjust triggers, steps, or environment if needed (.github/workflows/main.yml)
3. Update contributing guidelines to document any new rules contributors must follow (contributing.md)

Add or update a badge variant for awesome lists

1. Create or modify the SVG badge file following the existing flat/standard style conventions (media/badge.svg)
2. Update badge usage instructions so list maintainers know how to embed the new variant (media/readme.md)

• Markdown — Human-readable, universally renderable format ideal for a community-curated link list with no build step required.
• GitHub Actions — Native CI integration with the hosting platform, enabling automated linting of PRs without external services.
• Shell scripting (Bash) — Lightweight, dependency-free way to implement repo structure validation directly in the CI environment.
• SVG badges — Scalable, theme-aware graphics that render well in GitHub dark/light mode for downstream list maintainers.

• Plain markdown files with no static site generator

  • Why: Minimizes toolchain complexity and contribution friction — anyone with a text editor can contribute.
  • Consequence: No search, filtering, or dynamic features; navigation relies entirely on GitHub's markdown renderer.

• Manual curation over automated aggregation

  • Why: Ensures quality and relevance by requiring human judgment for every inclusion.
  • Consequence: Does not scale as rapidly as automated approaches; maintainer review is a bottleneck.

• Shell-based linter instead of a Node/Python linting tool

  • Why: Zero dependency installation time in CI, keeping feedback loops fast.
  • Consequence: More limited validation capabilities compared to purpose-built markdown linting libraries.

• Does not host or mirror the content of linked awesome lists
• Does not provide a search or filtering interface beyond GitHub's native markdown rendering
• Does not automatically validate that linked URLs are alive or that linked repos meet quality criteria
• Does not accept lists about general-purpose topics without demonstrated community interest
• Does not provide versioning or changelogs for individual linked lists

• Avg cyclomatic complexity: ~1 — Repository contains almost exclusively markdown and shell scripts; cyclomatic complexity is effectively 1 across the codebase.
• Largest file: readme.md (600 lines)
• Estimated quality issues: ~2 — Minor issues limited to undocumented shell script logic and manual ordering conventions; no functional code quality problems exist.

• Monolithic content file (Low) — readme.md: All curated links live in a single large markdown file with no pagination or splitting, making navigation and merge conflicts harder as the list grows.
• Manual alphabetical ordering (Low) — readme.md: Sort order is enforced by human convention and linting rather than automated tooling, risking ordering drift over time.
• Undocumented linter logic (Medium) — .github/workflows/repo_linter.sh: Shell scripts with minimal inline comments make it hard for new contributors to understand what rules are being enforced.

• Maintainer review process (Process / Human) — All PRs require human maintainer approval against subjective quality criteria, creating a single-person bottleneck for a high-volume contribution repo.
• .github/workflows/repo_linter.sh (Tooling) — Limited automated validation means many quality checks still fall to manual review, reducing CI's effectiveness as a true gate.

The repo_linter.sh script checks the linked repository, not just the PR diff — so a PR adding a list that doesn't have a Table of Contents, the correct awesome badge (media/badge.svg), a license, or sufficient entries will fail CI automatically. The contributing.md explicitly states lists must have been around for at least 30 days and have backlinks. Submitting a list you personally created without community traction is a common rejection reason.

• Curated list curation standards — The entire contribution model is based on enforcing a specific quality bar (badge, ToC, license, backlink) — understanding what these standards are and why they exist is essential before submitting a PR.
• GitHub Actions shell-based CI — repo_linter.sh is invoked by main.yml to lint external URLs, demonstrating how bash scripts can be used as CI validators without any Node/Python dependencies.
• Pull request templates — pull_request_template.md is a GitHub feature that pre-populates PR descriptions with a checklist, used here as a lightweight gate to reduce maintainer review burden.
• EditorConfig — .editorconfig enforces consistent whitespace and encoding across contributors' editors, preventing invisible diff noise in markdown files.
• Gitattributes for line endings — .gitattributes normalizes line endings across OS environments, critical for a repo with hundreds of contributors on Windows/Mac/Linux.

• topics/awesome — GitHub's official topic page aggregating all repositories tagged 'awesome', the ecosystem this repo anchors.
• sindresorhus/awesome-lint — The companion CLI tool that automates awesome-list quality checks, directly used by list maintainers to validate their own repos before submission.
• jnv/lists — Alternative meta-list of internet lists, solving the same discoverability problem with a broader, less curated scope.
• sindresorhus/awesome-nodejs — Example of a canonical child awesome list maintained by the same author, showing the format and quality bar expected.
• bayandin/awesome-awesomeness — Predecessor/inspiration meta-list that predates this repo and influenced the awesome list format.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add automated broken-link checker to .github/workflows/main.yml

The existing main.yml workflow lints the repo structure via repo_linter.sh, but there is no automated check for dead/broken hyperlinks in readme.md (which contains hundreds of external links). Broken links are a chronic problem in awesome lists and a dedicated workflow step would catch them before merge, saving maintainers manual review time.

• [ ] Open .github/workflows/main.yml and inspect the current job steps to understand where to insert the new step
• [ ] Add a new job or step that uses a well-known action such as lychee-action (or gaurav-nelson/github-action-markdown-link-check) targeting readme.md and contributing.md
• [ ] Configure an exclusion list (e.g., .lycheeignore or inline config) for known false-positives like localhost URLs or sponsor badge URLs found in the README snippet
• [ ] Test the workflow locally using act or by pushing to a feature branch to verify it correctly flags a known dead link
• [ ] Update contributing.md to mention that link validity is enforced in CI so contributors know to check their links before submitting

Extend repo_linter.sh to validate that every listed entry in readme.md matches the required awesome-list formatting rules from awesome.md

awesome.md defines explicit formatting requirements (e.g., entries must have a description separated by ' - ', descriptions must end with a period, no trailing whitespace). The current repo_linter.sh focuses on repo-level checks but does not parse readme.md line by line to enforce these per-entry style rules. Adding this would automate what maintainers currently enforce manually during PR review.

• [ ] Read awesome.md thoroughly to extract the exact formatting rules (description separator, punctuation, capitalisation requirements)
• [ ] Open .github/workflows/repo_linter.sh and identify the existing check patterns to follow the same shell scripting conventions
• [ ] Add grep/awk/sed-based checks that scan each list entry line in readme.md for: missing ' - ' separator, description not ending with '.', and leading/trailing whitespace
• [ ] Emit a clear error message per violation that includes the offending line number and content, matching the style of existing error output in the script
• [ ] Add a test case by temporarily introducing a malformed line in readme.md, running the script locally, confirming it fails, then reverting
• [ ] Update contributing.md with a short note pointing contributors to these automated style checks so they can run the linter locally before submitting

Add a CONTRIBUTING quick-start section to pull_request_template.md referencing the specific checklists in contributing.md and create-list.md

The current pull_request_template.md exists but does not contain inline reminders that link to the specific checklist sections in contributing.md and create-list.md. Many PRs are closed because contributors miss steps (e.g., the requirement described in create-list.md to have 30+ days of repo history, or the awesome badge requirement). Embedding direct anchor links to those specific sections inside the PR template would reduce back-and-forth on every PR.

• [ ] Read pull_request_template.md in full to understand its current structure and what is already present
• [ ] Read contributing.md and create-list.md and identify the section anchors for the most-cited rejection reasons (e.g., the 'Requirements' section in contributing.md, the 'Your awesome list' checklist in create-list.md)
• [ ] Add a '## Before submitting' block at the top of pull_request_template.md with a short bullet list of direct markdown anchor links to those specific sections (e.g., [List requirements](contributing.md#requirements))
• [ ] Add a checkbox item reminding submitters that new lists must include the awesome badge (linking to the badge assets in media/badge.svg documented in media/readme.md)
• [ ] Verify the anchor links resolve correctly by previewing the template in a fork before opening the PR

1. Audit existing entries in readme.md for dead links (404s) and open a PR removing or replacing them — this is high-value maintenance work. 2. Add missing alt-text to any SVG badges in the media/ directory for accessibility compliance. 3. Improve repo_linter.sh to check for HTTPS vs HTTP links in submitted list READMEs, which is a quality signal not currently validated.

This repository is a static, documentation-only 'awesome list' with no application code, database interactions, or server-side logic, which significantly reduces its attack surface. There are no hardcoded secrets, no dependency manifests with known vulnerable packages, no Docker configurations, and no dynamic code execution paths. The primary residual risks are low-severity and relate to CI/CD supply chain hygiene (unpinned GitHub Actions), shell script robustness, reliance on externally hosted assets without integrity verification, the curation risk of community-submitted malicious URLs, and the absence of a formal vulnerability disclosure policy. Overall, the security posture is strong for this type of repository, with actionable improvements focused on CI pipeline hardening and community safety tooling.

• Low · External Resource Loading Without Subresource Integrity — readme.md. The readme.md references external SVG images and resources hosted on third-party domains (e.g., sindresorhus.com, depot.dev). These external resources are loaded without Subresource Integrity (SRI) checks, meaning if those third-party domains were compromised, malicious content could be served in place of the expected assets. Fix: Where possible, host critical assets locally within the repository (e.g., under the media/ directory). For externally hosted assets that cannot be moved, document the trust relationship and periodically verify asset integrity.
• Low · GitHub Actions Workflow May Use Unpinned Action Versions — .github/workflows/main.yml. The GitHub Actions workflow file at .github/workflows/main.yml may reference actions using mutable tags (e.g., @v3, @main) rather than pinned SHA commit hashes. This exposes the CI pipeline to supply chain attacks where a compromised action tag could execute arbitrary code in the workflow environment. Fix: Pin all GitHub Actions to specific immutable commit SHAs (e.g., uses: actions/checkout@<full-commit-sha>) instead of mutable version tags. Use tools like Dependabot or OpenSSF Scorecard to automate this enforcement.
• Low · Shell Script Without Explicit Security Hardening — .github/workflows/repo_linter.sh. The file .github/workflows/repo_linter.sh is a shell script used in CI. Without reviewing its full content, common risks include lack of 'set -euo pipefail' for strict error handling, unquoted variables susceptible to word splitting/globbing, and potential injection via externally sourced data (e.g., PR branch names or user-supplied input passed to shell commands). Fix: Add 'set -euo pipefail' at the top of the script. Quote all variable expansions. Sanitize or validate any externally supplied input (such as PR metadata) before using it in shell commands. Regularly audit the script for injection-prone patterns.
• Low · Open Redirect Risk via Unvalidated Outbound Links in Community-Contributed Content — readme.md, contributing.md. As an 'awesome list' repository, readme.md and contributing.md contain or encourage submission of numerous third-party URLs contributed by the community. While this is static content and does not represent a direct code-level vulnerability, malicious or phishing URLs could be inadvertently merged, misleading users who trust the curated list. Fix: Enforce automated link validation in CI (already partially addressed by the linter workflow) to detect known malicious domains. Implement a review checklist in pull_request_template.md that explicitly requires verification of link legitimacy. Consider integrating a URL safety API or blocklist check in the CI pipeline.
• Low · Missing SECURITY.md / Vulnerability Disclosure Policy — Repository root / .github/. The repository does not appear to include a SECURITY.md file defining a vulnerability disclosure policy or responsible disclosure process. This is a GitHub-recommended best practice and its absence means security researchers have no clear channel to report issues. Fix: Add a SECURITY.md file to the repository root or .github/ directory that outlines the supported versions, how to report a vulnerability (e.g., via GitHub private security advisories), and the expected response timeline.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sindresorhus/awesome shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sindresorhus/awesome repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sindresorhus/awesome.

What it runs against: a local clone of sindresorhus/awesome — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sindresorhus/awesome | Confirms the artifact applies here, not a fork | | 2 | License is still CC0-1.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sindresorhus/awesome. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sindresorhus/awesome.git
#   cd awesome
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sindresorhus/awesome and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sindresorhus/awesome(\\.git)?\\b" \\
  && ok "origin remote is sindresorhus/awesome" \\
  || miss "origin remote is not sindresorhus/awesome (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(CC0-1\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"CC0-1\\.0\"" package.json 2>/dev/null) \\
  && ok "license is CC0-1.0" \\
  || miss "license drift — was CC0-1.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "readme.md" \\
  && ok "readme.md" \\
  || miss "missing critical file: readme.md"
test -f "contributing.md" \\
  && ok "contributing.md" \\
  || miss "missing critical file: contributing.md"
test -f "create-list.md" \\
  && ok "create-list.md" \\
  || miss "missing critical file: create-list.md"
test -f "awesome.md" \\
  && ok "awesome.md" \\
  || miss "missing critical file: awesome.md"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sindresorhus/awesome"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.