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/github/explore 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.

GO — Healthy across the board

• Last commit 2d ago
• 19 active contributors
• Distributed ownership (top contributor 31% of recent commits)
• CC-BY-4.0 licensed
• CI configured
• Tests present
• ⚠ Non-standard license (CC-BY-4.0) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

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

What it runs against: a local clone of github/explore — 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 github/explore | Confirms the artifact applies here, not a fork | | 2 | License is still CC-BY-4.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 ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of github/explore. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/github/explore.git
#   cd explore
#
# 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 github/explore and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(CC-BY-4\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"CC-BY-4\\.0\"" package.json 2>/dev/null) \\
  && ok "license is CC-BY-4.0" \\
  || miss "license drift — was CC-BY-4.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 "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "_config.yml" \\
  && ok "_config.yml" \\
  || miss "missing critical file: _config.yml"
test -f "Rakefile" \\
  && ok "Rakefile" \\
  || miss "missing critical file: Rakefile"
test -f ".github/workflows/lint.yml" \\
  && ok ".github/workflows/lint.yml" \\
  || miss "missing critical file: .github/workflows/lint.yml"
test -f ".github/workflows/test.yml" \\
  && ok ".github/workflows/test.yml" \\
  || miss "missing critical file: .github/workflows/test.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 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
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/github/explore"
  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).

github/explore is a Jekyll-powered static site that houses GitHub's curated Topics and Collections—community-edited pages that categorize repositories, developers, organizations, articles, and videos by theme. It transforms Markdown files in _topics/ and collections/ into discoverable landing pages that appear on github.com/topics and github.com/collections, allowing developers to explore projects by subject area. Two-directory content structure: _topics/ contains individual Topic YAML/Markdown files (e.g., each topic is one file), and collections/ is organized by collection slug with index.md and optional images (e.g., collections/ai-agents/index.md, collections/clipboard-managers/clipboard-managers.png). Jekyll processes these via _config.yml and Liquid templates, outputting static HTML served from the github.io CDN. Linting (.rubocop.yml) and validation workflows enforce content consistency.

Open-source community maintainers and GitHub staff who curate thematic collections (like 'devops-tools' or 'ai-agents'); contributors who suggest edits to existing Topic descriptions or create new curated collection pages; and ultimately, millions of developers browsing GitHub Topics and Collections to find projects to learn from or contribute to.

This is a stable, actively maintained production system. It runs Jekyll builds via .github/workflows/jekyll_build.yml and lint checks automatically on every PR, indicating mature CI/CD infrastructure. The 43.5k lines of Ruby and extensive workflow automation (conflict detection, triage commenting, stale issue management) show it's a well-governed repository powering a core GitHub.com feature used daily by millions.

Risk is low: it's a static site generator with minimal runtime dependencies (Bundler-managed, visible in Gemfile.lock), no complex services, and strong governance (CODEOWNERS present, dependabot.yml configured for automated updates). The main risk is community moderation—curated content requires editorial review, so low contributor bandwidth could cause stale collections. No single-maintainer risk apparent from the workflow setup.

The repository is actively maintained with automated workflow enforcement: jekyll_build.yml validates every PR, lint.yml runs RuboCop checks, collections-renames.yml handles collection slug changes, and explore-triage-commenter.yml automates community triage. The presence of dependabot.yml indicates ongoing dependency updates. Recent focus includes collection expansion (50+ collections visible) and community contribution infrastructure.

# Clone and setup
git clone https://github.com/github/explore.git
cd explore
rvm use $(cat .ruby-version)  # or use rbenv
bundle install

# Run tests
bundle exec rubocop

# Build and preview locally (Jekyll)
bundle exec jekyll serve

Daily commands:

bundle install
bundle exec jekyll serve
# Site available at http://localhost:4000

For linting: bundle exec rubocop validates code style.

• CONTRIBUTING.md — Essential guide for all contributors explaining how to propose edits to topics and curate new collections.
• _config.yml — Jekyll configuration that defines site metadata, build settings, and collection definitions for the entire explore site.
• Rakefile — Build automation and task definitions that orchestrate linting, testing, and deployment workflows.
• .github/workflows/lint.yml — Automated linting workflow that validates all topic and collection markdown formatting and structure on each PR.
• .github/workflows/test.yml — Test suite runner that executes Ruby-based validation tests to ensure topic/collection compliance with repository standards.
• .rubocop.yml — Linting configuration that enforces code style standards for all Ruby scripts in the repository.
• README.md — Entry point explaining the repository's purpose, topics vs collections distinction, and local setup instructions.

• Content Curation Layer (_topics/ & collections/) (Markdown, YAML frontmatter) — Markdown files containing topic descriptions, collection metadata, and curated repository lists
  • Failure mode: Malformed markdown/YAML blocks Jekyll build; invalid repository URLs break links in published collections
• Build & Validation System (Rakefile, RuboCop, GitHub Actions) (Ruby, RuboCop, GitHub Actions workflows) — Enforces content quality, formatting consistency, and structural compliance before publication
  • Failure mode: Broken validation rules allow malformed content; missing tests let invalid files merge
• Static Site Generator (Jekyll, _config.yml) (Jekyll, Liquid templates, YAML) — Transforms markdown content into publishable HTML and manages site-wide settings, collections, and layout
  • Failure mode: Jekyll config errors prevent site build; broken template references leave pages unpublished
• CI/CD Orchestration (.github/workflows/) — undefined

Add a New Collection

1. Create a new directory under collections/ with your collection name (e.g., collections/my-new-collection/) (collections/my-new-collection/index.md)
2. Create index.md in the new directory with required frontmatter: name, description, image (optional), and a repos array with curated GitHub URLs (collections/my-new-collection/index.md)
3. Optionally add a .png image (400x200px recommended) in the same directory for the collection card (collections/my-new-collection/my-new-collection.png)
4. Run bundle exec rubocop to validate YAML/markdown formatting before committing (.rubocop.yml)
5. Open a PR with your new collection; automated workflows will lint and test the changes (.github/workflows/lint.yml)

Add or Edit a Topic Page

1. Locate or create a markdown file in _topics/ directory (e.g., _topics/machine-learning.md) with the topic slug name (_topics)
2. Add frontmatter with title, description, display_name, short_description, and a curated list of related_topics and featured repositories (_topics)
3. Follow the markdown structure: use H2 headers for major sections like 'Getting started', 'Trending repositories', and 'Related topics' (_topics)
4. Run bundle exec rubocop to ensure all linting rules pass before submitting (.rubocop.yml)
5. Submit a PR; GitHub Actions will automatically validate formatting and structure compliance (.github/workflows/test.yml)

Validate Changes Locally Before PR

1. Install dependencies by running bundle install in the repository root (Gemfile)
2. Run bundle exec rubocop to lint all Ruby and markdown files for style violations (.rubocop.yml)
3. Run bundle exec rake (or specific test tasks in Rakefile) to run full validation suite (Rakefile)
4. Optionally run jekyll serve locally (via _config.yml settings) to preview the site before publication (_config.yml)

• Jekyll — Static site generator ideal for hosting curated content pages on GitHub Pages; minimal complexity, fast builds, and supports markdown-based content
• GitHub Actions — Native CI/CD for linting, testing, and validation on every PR without external dependencies; tight integration with GitHub repository workflows
• Ruby + RuboCop — Established Ruby toolchain for enforcing consistent markdown/YAML formatting and custom validation rules across 600+ files
• CC-BY-4.0 License — Permissive open content license allowing community curation and reuse while maintaining attribution

• Static site (Jekyll) rather than dynamic backend

  • Why: Simplicity, cost, and GitHub Pages hosting; no server infrastructure needed
  • Consequence: Collection/topic updates require PR merge and rebuild cycle; no real-time updates or user-generated content

• Manual curation via PRs rather than automated discovery

  • Why: Ensures quality and thematic coherence of collections; prevents spam and low-quality repositories
  • Consequence: Scaling curation effort requires more community contributors; not suitable for auto-aggregation use cases

• Markdown files as source-of-truth rather than database

  • Why: Version control transparency, easy contribution, no external dependencies
  • Consequence: Complex queries (e.g., 'find all collections containing repo X') require full file scan; limited search capabilities

• Real-time topic/collection discovery or analytics
• User authentication or personalized recommendations
• Automated repository aggregation or scraping
• Dynamic UI features beyond static Jekyll rendering
• Support for private or restricted collections

No hidden traps specific to this repo. It's a straightforward Jekyll site: Jekyll and RuboCop gems are Bundler-managed, _config.yml is the single source of truth for build config, and all validation is explicit in .github/workflows/. Content files must follow YAML frontmatter conventions (visible in existing files) and Markdown syntax. The .ruby-version file pins Ruby version, so ensure you match it (rvm use or rbenv local). No environment variables, external services, or complex state required.

• Jekyll static site generation — This repo is entirely Jekyll-based; understanding how Jekyll processes Markdown/YAML into HTML and how Liquid templates work is mandatory for any content or structure change
• Liquid templating — The 2.5k lines of Liquid code in the repo render Topics and Collections dynamically; you'll encounter Liquid in layout files and custom filters
• YAML frontmatter — Every Topic and Collection file begins with YAML metadata (title, description, image, etc.); correct frontmatter syntax is enforced by linting and required for Jekyll to render pages
• GitHub Actions workflows — Six distinct workflows (.github/workflows/*.yml) automate building, linting, conflict detection, and PR triage; understanding the pipeline is essential to know why your PR passes or fails
• RuboCop linting — RuboCop enforces style consistency across YAML and Markdown files via .rubocop.yml config; PRs must pass linting or the build fails
• Content curation and community governance — This repo is fundamentally about human-curated discovery; understanding the editorial process (pull requests, code review, CODEOWNERS) is as important as technical skills for meaningful contributions
• Static site deployment via GitHub Pages — The built site is served from a GitHub Pages CDN (evidenced by CNAME file); knowing how Jekyll outputs are published ensures you understand the full pipeline from content to live website

• github/linguist — Detects and categorizes programming languages across repositories; used by Topics/Collections to identify language-focused content
• github/gitignore — Companion community-curated repo following the same model: crowd-sourced content (gitignore templates) validated and published by GitHub, mirrors the governance pattern of explore
• github/choosealicense.com — Another GitHub-maintained educational site that curates and explains open-source licensing; similar Jekyll-based static-content architecture
• jekyll/jekyll — The core static site generator that powers github/explore; understanding Jekyll's template rendering and build system is essential for modifying site structure
• ruby/rubocop — The linter used in lint.yml and .rubocop.yml to enforce code and content style; exploring RuboCop rules will help you pass CI validation

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 schema validation tests for collection and topic YAML frontmatter

The repo contains 100+ collection and topic markdown files with YAML frontmatter, but there's no automated validation that these files follow a consistent schema. The test.yml workflow exists but likely doesn't validate frontmatter structure. This prevents inconsistent metadata (missing descriptions, invalid authors, malformed arrays) from being merged. A new test should validate required fields, data types, and format for all files in _topics/ and collections/*/index.md.

• [ ] Create a new Ruby test file (e.g., spec/schema_validator_spec.rb or tests/frontmatter_test.rb) that loads and parses YAML from all collection and topic markdown files
• [ ] Define a schema validator that checks for required fields (title, description, etc.) and validates field types and formats
• [ ] Integrate the new test into the existing .github/workflows/test.yml so it runs on every PR
• [ ] Document the expected YAML structure in CONTRIBUTING.md with examples from existing collections

Add automated link validation workflow for collection and topic references

Collections reference repositories, developers, and articles via URLs in their index.md files, but there's no CI check to catch broken or misformatted links. The .github/workflows/ directory has linting and jekyll_build.yml, but no dedicated link checker. A new workflow could validate that all external URLs are reachable and that GitHub repo references exist, preventing dead links from being published.

• [ ] Create a new GitHub Actions workflow file (.github/workflows/link-validation.yml) that runs on PRs
• [ ] Use an existing link-checking action (e.g., lychee, urlchecker-action, or a custom Ruby script) to validate all URLs in collections/ and _topics/ directories
• [ ] Configure the action to allow GitHub API rate limit workarounds and skip URLs that are intentionally excluded (e.g., localhost)
• [ ] Document any link validation rules or exclusions in CONTRIBUTING.md

Add image optimization and validation workflow for collection artwork

The repo contains collection-specific images (e.g., collections/clipboard-managers/clipboard-managers.png, collections/fantasy-consoles/fantasy-consoles.png) but there's no automated check for image quality, file size, or naming consistency. A new workflow could enforce image standards (max file size, required dimensions, correct naming convention) to keep the repo lean and ensure consistent visual presentation.

• [ ] Create a new GitHub Actions workflow (.github/workflows/image-validation.yml) that runs on PRs modifying files in collections/
• [ ] Add checks for: PNG/JPG file format enforcement, maximum file size (e.g., 500KB), minimum dimensions (e.g., 1200x630 for social sharing), and filename consistency with collection slug
• [ ] Optionally integrate an image optimization tool (e.g., ImageOptim, tinypng via action) to automatically optimize images or suggest optimizations in PR comments
• [ ] Update CONTRIBUTING.md with image submission guidelines, including required dimensions and format

• Add missing descriptions or improve existing Topic descriptions in _topics/ by researching relevant repositories and community consensus, then opening a PR with your edits to _topics/{topic-slug}.md.
• Create a new Collection for an underrepresented category (e.g., 'rust-web-frameworks' or 'game-dev-engines') by creating collections/{new-slug}/index.md with YAML frontmatter, a curated description, and 5–10 hand-picked repository links following the pattern in existing collections like collections/ai-agents/index.md.
• Add missing images to Collections lacking visual thumbnails: locate Collections in collections/ without a .png file and create or contribute a 400×300 icon, adding it as collections/{slug}/{slug}.png (see collections/clipboard-managers/clipboard-managers.png for the format).

The GitHub Explore repository demonstrates a reasonable security posture for a static content/documentation repository. No critical vulnerabilities were identified. The codebase contains primarily markdown content and configuration files with no apparent hardcoded secrets, SQL injection, or XSS risks. Dependabot is already configured for dependency management. Primary recommendations include: (1) ensuring Ruby dependencies are regularly audited via 'bundle audit', (2) establishing a formal security policy, and (3) maintaining comprehensive documentation of security practices. The repository's static nature and lack of dynamic content handling significantly reduces the attack surface.

• Low · Missing Dependency Security Auditing — Gemfile, Gemfile.lock. No dependency security audit information was provided. The Gemfile and Gemfile.lock files exist but their contents are not available for analysis. Without visibility into the Ruby gem dependencies, potential vulnerable package versions cannot be assessed. Fix: Regularly run 'bundle audit' to check for known vulnerabilities in dependencies. Implement automated dependency scanning in CI/CD pipeline using tools like Dependabot (already configured) or similar vulnerability scanners.
• Low · Incomplete README Security Information — README.md. The README.md file appears to be truncated, potentially missing important security or configuration information that should be documented for contributors and maintainers. Fix: Ensure README.md is complete and includes security best practices for contributors, such as how to handle sensitive data and security reporting procedures.
• Low · No Security Policy Defined — Repository root. There is no SECURITY.md or security policy file visible in the repository to define vulnerability disclosure procedures or security guidelines for contributors. Fix: Create a SECURITY.md file documenting the vulnerability disclosure process and security guidelines. Reference it in the README.

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

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

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