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/thangchung/awesome-dotnet-core 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.

WAIT — Missing license — unclear to depend on

• Last commit 2mo ago
• 34+ active contributors
• Distributed ownership (top contributor 42% of recent commits)
• CI configured
• ⚠ No license — legally unclear to depend on
• ⚠ No test directory detected

_{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 thangchung/awesome-dotnet-core repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/thangchung/awesome-dotnet-core.

What it runs against: a local clone of thangchung/awesome-dotnet-core — 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 thangchung/awesome-dotnet-core | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | Last commit ≤ 102 days ago | Catches sudden abandonment since generation |

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

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

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

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 102 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~72d)"
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/thangchung/awesome-dotnet-core"
  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).

awesome-dotnet-core is a curated, community-driven index of .NET Core libraries, frameworks, tools, and software organized into 50+ categories (API, ORM, Testing, Machine Learning, etc.). It serves as a single reference point for discovering vetted .NET Core ecosystem packages rather than building a tool itself—the value is in categorization and discoverability. Single-file structure: README.md is the entire content asset, structured as a Markdown table-of-contents with category sections (each section is a heading, containing bullet-point links to projects with brief descriptions). Supporting files are meta: contributing.md defines contribution rules, .github/ISSUE_TEMPLATE/ handles intake, Program.cs suggests a helper tool exists (likely for validation or generation). CI via .travis.yml enforces checks on PRs.

.NET Core developers searching for production-ready libraries in specific domains (e.g., a backend engineer needing a caching solution, a DevOps person looking for build automation tools, or a data scientist exploring ML frameworks). Also maintainers of .NET libraries seeking visibility.

This is a mature, actively maintained community resource. The presence of Travis CI configuration (.travis.yml), GitHub issue templates, and contribution guidelines (.github/ISSUE_TEMPLATE/) indicates established governance. However, this is a curated list repository, not a software library—'maturity' means consistency of curation rather than code stability. No specific commit date visible in provided data, but the breadth of categories and contributor base suggest active use.

Risk is low for using this repository (it's documentation, not production code). Primary risk: list accuracy and freshness depend on community vigilance—broken links or outdated recommendations could appear. Single-maintainer risk (thangchung) for merge decisions. No automated validation visible that links remain active or projects are still maintained. Secondary risk: subjective quality judgment on what gets added.

Specific recent work is not visible in the file list provided, but the presence of issue templates for 'add--library-framework-tool-link-.md' and 'custom.md' indicates ongoing intake of new projects. The repo is accepting contributions as-is; no specific 'in progress' feature work is apparent.

git clone https://github.com/thangchung/awesome-dotnet-core.git
cd awesome-dotnet-core
# No build step required; this is a documentation repository.
# To validate or update the list, run (if Program.cs is executable):
dotnet run

Daily commands: No traditional 'run' step. To preview: open README.md in any editor or GitHub. To validate/regenerate (if Program.cs applies): dotnet run from repository root. To contribute: fork, add entries to README.md following contribution guidelines, create PR.

• README.md: The entire curated content lives here—all 50+ categories and hundreds of project links are organized as hierarchical Markdown sections.
• contributing.md: Defines submission rules, quality criteria for projects, formatting standards, and community expectations—critical for maintaining consistency across PRs.
• .github/ISSUE_TEMPLATE/add--library-framework-tool-link-.md: GitHub issue template that guides contributors through the exact fields and metadata required when proposing a new library, ensuring structured intake.
• Program.cs: Likely a helper tool for validating README.md syntax, checking for dead links, or auto-generating the table-of-contents—critical for list maintenance at scale.
• .travis.yml: CI configuration that runs validation checks (via Program.cs or similar linter) on PRs to prevent broken links or malformed entries from merging.

Adding a new library: Edit README.md directly—find the appropriate category section (e.g., ## Logging), add a bullet point with [Project Name](url) - brief description. Creating a new category: Add a new ## Category Name heading to README.md and update the table-of-contents. Fixing links or descriptions: Modify the relevant line in README.md. Understanding governance: Read contributing.md for standards (formatting, project maturity filters, etc.). Use .github/ISSUE_TEMPLATE/add--library-framework-tool-link-.md to model the expected metadata for new entries.

This is a curation repository, not a code project, so traditional traps (environment variables, service dependencies) don't apply. However: (1) README.md is the single source of truth—no automation generates it, so typos and dead links can persist if unreviewed. (2) Program.cs validation behavior is undocumented—unclear what checks it runs or whether it's mandatory in CI. (3) No explicit guidance on how to handle deprecated projects or breaking major versions of listed libraries. (4) Contribution acceptance is subjective—'awesome' criteria are informal; rejections may lack clear rationale.

• Curated list / Awesome format — Understanding that this repo follows the Awesome.js convention (categorized Markdown links with brief descriptions, community-driven) is essential for recognizing quality standards and contribution expectations.
• Community-driven discovery vs. automated registry — awesome-dotnet-core succeeds because humans filter signal from noise (1000s of NuGet packages → 50 curated categories); knowing this model explains why subjective review matters and automation alone cannot replace it.
• GitHub workflow automation (CI/linting) — The .travis.yml and Program.cs hints indicate automated validation gates on PRs—understanding how to write maintainable validation rules prevents decay in a list of 200+ external links.
• Markdown-as-data structure — README.md is both human-readable documentation and machine-parseable structured data; this dual nature means parsing logic (in Program.cs) must be robust to changes, and contributors must follow strict formatting to avoid breaking automation.
• .NET Core ecosystem segmentation — This list exists because .NET Core (cross-platform, open-source) has a distinct ecosystem from .NET Framework; understanding this split helps contextualize why some libraries appear here and not in awesome-dotnet.
• Semantic versioning and stability guarantees — Many listed libraries are community-maintained with varying SemVer discipline; contributors and users must evaluate version stability before relying on a recommendation, but the list itself provides no automated version tracking.

• quozd/awesome-dotnet — Direct predecessor for .NET Framework—this repo (awesome-dotnet-core) is the .NET Core equivalent, tracking the shift in Microsoft's platform strategy.
• sindresorhus/awesome — Original awesome list template and format standard—defines the Markdown structure and community guidelines that awesome-dotnet-core follows.
• dypsilon/frontend-dev-bookmarks — Peer curated list in JavaScript ecosystem—demonstrates the same curated-resource model applied to a different tech stack for reference.
• NuGet/Home — Official NuGet package registry—while awesome-dotnet-core is a curated subset, NuGet Home is the authoritative source package repository that most linked projects publish to.
• dotnet/docs — Official .NET documentation—awesome-dotnet-core complements this by surfacing community/third-party tools that official docs don't cover.

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 link validation workflow via GitHub Actions

The repo is a curated collection of .NET Core resources with many external links in README.md. Currently there's .travis.yml but no GitHub Actions workflow to validate that all linked resources are accessible and haven't moved. This prevents link rot and maintains the quality of the awesome list. A new workflow could check for 404s, redirects, and timeouts on all markdown links.

• [ ] Create .github/workflows/link-check.yml with a link validation action (e.g., lychee or linkinator)
• [ ] Configure it to run on PRs and scheduled weekly basis
• [ ] Add exception list for links that legitimately redirect or have rate limiting
• [ ] Document the workflow in contributing.md with expected behavior

Create automated PR validation for new entries in README.md

The repo has ISSUE_TEMPLATE for adding library/framework/tool links, but no automated validation of PR submissions. A Program.cs exists but appears unused. Create a validation tool that checks: proper markdown formatting, categorization consistency, no duplicates, and link accessibility for new entries. This reduces manual review burden on maintainers.

• [ ] Extend Program.cs to parse README.md and validate new entries against defined schema
• [ ] Create a GitHub Action workflow (.github/workflows/validate-entries.yml) that runs the validation on PRs
• [ ] Add checks for: correct section placement, proper markdown link format, no URL duplicates, description length requirements
• [ ] Document validation rules in contributing.md with examples

Add automated changelog generation and release notes workflow

The repo lacks automated release management. With frequent community contributions, a workflow to generate release notes from merged PRs and tagged releases would improve user experience. This involves creating a GitHub Action that groups contributions by category (matching README structure) and generates organized release notes.

• [ ] Create .github/workflows/release-notes.yml using a changelog action (e.g., release-drafter or changelogithub)
• [ ] Configure workflow to run on version tags and aggregate recent PR titles/descriptions by README category
• [ ] Create .github/release-drafter.yml to define release note template matching the awesome-list structure
• [ ] Document the release process in contributing.md (how PRs should be titled for proper categorization)

• Add validation to Program.cs to check for dead links in README.md—crawl every URL in the list and report failures in CI (helps prevent the list from silently linking to dead projects).
• Create a Markdown linter rule in .travis.yml to enforce consistent formatting (bullet points, link syntax, description length) across all category entries, reducing manual review effort.
• Audit the Blockchain and Bot categories for stale projects (check GitHub stars, last commit date, open issue count) and flag unmaintained ones for community review in an issue.

This repository is a curated list of .NET Core resources (awesome-list style) with minimal security risks. The codebase lacks production code execution, databases, or complex logic, which significantly reduces attack surface. No hardcoded secrets, dependency vulnerabilities, or injection risks were identified. Main recommendations include completing documentation accuracy, ensuring CI/CD security best practices, and establishing a formal security policy for the open-source project. Overall security posture is good for a documentation/list-style repository.

• Low · Incomplete URL in README — README.md. The README.md file contains a truncated Twitter URL (https: without completion), which could indicate copy-paste issues or incomplete documentation. While not a direct security vulnerability, it suggests potential maintenance gaps. Fix: Complete and verify all external URLs in documentation to ensure accuracy and maintain trust.
• Low · Travis CI Configuration Present — .travis.yml. The .travis.yml file indicates use of Travis CI for CI/CD. While not inherently vulnerable, CI/CD configurations can be security risks if not properly managed (e.g., exposed secrets in build logs, overly permissive permissions). Fix: Ensure sensitive data (API keys, tokens) are stored as encrypted environment variables in Travis CI, not in the .travis.yml file. Review build log visibility settings.
• Low · No Evidence of Security Policy — Repository root. No SECURITY.md file or security policy documentation is visible in the repository. This is important for an open-source project to establish responsible disclosure guidelines. Fix: Create a SECURITY.md file with vulnerability reporting guidelines and responsible disclosure process.

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.