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/neutraltone/awesome-stock-resources 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 all four use cases

• Last commit 3mo ago
• 10 active contributors
• CC0-1.0 licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 73% of recent commits
• ⚠ 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 neutraltone/awesome-stock-resources repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/neutraltone/awesome-stock-resources.

What it runs against: a local clone of neutraltone/awesome-stock-resources — 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 neutraltone/awesome-stock-resources | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 117 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "neutraltone/awesome-stock-resources(\\.git)?\\b" \\
  && ok "origin remote is neutraltone/awesome-stock-resources" \\
  || miss "origin remote is not neutraltone/awesome-stock-resources (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master 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 ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
test -f "Dangerfile" \\
  && ok "Dangerfile" \\
  || miss "missing critical file: Dangerfile"
test -f "Gemfile" \\
  && ok "Gemfile" \\
  || miss "missing critical file: Gemfile"

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

A curated, community-maintained markdown list of free stock photography, video, illustration, and design resource websites organized by license type and content category. The repository uses Ruby tooling and GitHub Actions CI to validate links and maintain quality, serving as a definitive discovery index for designers and developers seeking royalty-free creative assets. Flat markdown-based structure: README.md is the primary content file organized into 15+ categorical sections (Photography, Illustration, Videos, Fonts, Icons, etc.), each with subcategories by license type. Metadata validation happens via Ruby scripts in .github/workflows/main.yml and Dangerfile, with no application code—purely a curated index.

Designers, developers, and content creators who need quick access to vetted free stock resources (photos, videos, illustrations, icons, fonts) without sifting through SEO spam or paid alternatives. Contributors are open-source enthusiasts maintaining the curated list and validating broken links.

Actively maintained with GitHub Actions CI/CD pipeline (main.yml), Danger linting rules (Dangerfile), and structured contribution guidelines (CONTRIBUTING.md). The 'Awesome' badge and PayPal/Buy Me a Coffee donation links indicate a well-established, stable project with ongoing community engagement and regular updates.

Single maintainer (neutraltone) creates bus-factor risk for sustained maintenance. Risk is mitigated by the low technical complexity (pure markdown list, not code-heavy) and active community contributions. Main risk: link rot—hundreds of external resource URLs require periodic validation to remain useful.

Ongoing community PRs validating links, adding new resources to existing categories, and updating broken resource URLs. GitHub Actions workflow continuously checks markdown formatting and link integrity on each PR via the main.yml CI pipeline.

Clone the repo: git clone https://github.com/neutraltone/awesome-stock-resources.git && cd awesome-stock-resources. Review the README.md to explore categories. Install Ruby dependencies (if running local validation): bundle install. No server startup needed—this is a static curated list.

Daily commands: This is not a runnable application. To validate changes locally: bundle install to load dependencies, then run bundle exec danger pr <pr_url> to lint your contributions against Dangerfile rules. To build or deploy: review .github/workflows/main.yml for the CI pipeline that validates all PRs automatically.

• README.md — Primary entry point documenting the curated list structure, contribution guidelines, and all categorized stock resource links that form the repository's core value.
• CONTRIBUTING.md — Essential reference for all contributors defining submission standards, resource validation criteria, and pull request expectations.
• .github/workflows/main.yml — Automated validation pipeline that checks link integrity and enforces quality standards on every pull request.
• Dangerfile — Danger.js configuration that implements automated code review rules and validates contributions against repository standards.
• Gemfile — Ruby dependencies manifest specifying Danger and related tools needed for CI/CD validation workflows.

• README.md (Markdown) — Maintains the authoritative curated list of stock resources organized by type and license
  • Failure mode: Outdated, broken, or duplicate links; inconsistent formatting reduces discoverability
• CONTRIBUTING.md (Markdown) — Communicates submission standards, resource criteria, and PR expectations to contributors
  • Failure mode: Unclear guidelines lead to low-quality submissions and increased maintainer review burden
• .github/workflows/main.yml (GitHub Actions, Shell) — Executes automated validation on every PR to detect broken links and enforce quality gates
  • Failure mode: Misconfigured checks allow invalid resources; excessive timeouts delay PR feedback
• Dangerfile (Ruby, Danger gem) — Implements custom code review rules to ensure PR compliance with repository standards
  • Failure mode: Weak rules permit non-compliant submissions; overly strict rules block valid contributions
• Gemfile (Ruby, Bundler) — Specifies Ruby dependencies required for Danger and CI tooling
  • Failure mode: Missing or outdated gems break workflow; incompatible versions cause CI failures

• Contributor → GitHub Pull Request — Contributor adds new resource links or updates existing entries in README.md
• Pull Request → .github/workflows/main.yml — GitHub triggers CI workflow on new PR containing repository changes
• main.yml → Link Validator — Workflow executes scripts to fetch and validate all URLs in the diff
• main.yml → Dangerfile — Workflow runs Danger gem to execute custom validation rules on PR metadata and diff
• Link Validator + Dangerfile → GitHub PR Checks — Validation results (pass/fail) reported back to PR as GitHub status checks
• GitHub PR Checks → Maintainer — Maintainer reviews check results and contributor feedback to approve or request changes
• Merged PR → README.md (main branch) — Approved changes merged into main branch, updating the authoritative curated list
• README.md (main branch) → Users / Browsers — Users visit GitHub repository and browse the rendered curated list of stock resources

Add a New Stock Resource Link

1. Open README.md and locate the appropriate category (Photography, Illustration, Video, or Music) and license subcategory (CC0, Attribution Required, Public Domain, etc.) (README.md)
2. Add the resource as a markdown list item following the format: - [Site Name](URL) - Brief description of what it offers (README.md)
3. Ensure the resource URL is valid and the site meets the license requirements for the chosen category (CONTRIBUTING.md)
4. Create a pull request; the CI workflow in main.yml will automatically validate the link (.github/workflows/main.yml)

Modify Contribution Guidelines

1. Edit CONTRIBUTING.md to update submission requirements, resource criteria, or pull request processes (CONTRIBUTING.md)
2. Update Dangerfile if new automated validation rules are needed to enforce the changes (Dangerfile)
3. Submit a pull request for community discussion and approval (README.md)

Update or Fix Resource Information

1. Identify the broken or outdated link in the appropriate section of README.md (README.md)
2. Replace the URL or description with corrected information, maintaining alphabetical order and category structure (README.md)
3. Include the issue being fixed in the pull request description for reviewer context (README.md)

• GitHub (Git + Actions) — Native repository hosting with built-in CI/CD enables automated validation and community collaboration
• Markdown (README.md) — Human-readable format ideal for curated lists; renders natively on GitHub with no build step
• Danger + Ruby (Dangerfile, Gemfile) — Automates code review enforcement for pull request validation without custom scripting
• GitHub Actions Workflows — Cloud-native CI/CD eliminates infrastructure overhead for link validation and quality checks

• Markdown-only content with no database or CMS

  • Why: Simplicity and accessibility for community contributions; anyone can edit via GitHub UI
  • Consequence: Limited search/filter capabilities; consumers must browse README directly or use external tools

• Automated link validation in CI rather than periodic batch jobs

  • Why: Catches broken links immediately at contribution time with fast feedback
  • Consequence: Increases CI execution time per PR; may need timeout/retry logic for slow or blocked resources

• No authentication or gating mechanism for resource submission

  • Why: Lowers barrier to entry and encourages community-driven curation
  • Consequence: Requires maintainer review and Danger rules to prevent spam or low-quality additions

• Does not provide a searchable web interface; users browse curated lists directly
• Does not host or mirror stock resources; only aggregates links
• Does not handle user authentication or accounts
• Does not track resource metadata beyond name, URL, and license type
• Does not support real-time resource availability monitoring beyond CI validation

• Link rot risk from manual curation (Medium) — README.md (all resource links): Reliance on contributor and maintainer manual updates means broken links may persist until reported; no proactive dead-link detection between CI runs
• Scalability friction in flat Markdown structure (Low) — README.md: As the list grows, maintaining alphabetical order, consistency, and search-friendliness in a single Markdown file becomes harder; no programmatic indexing or metadata extraction
• Limited validation scope in CI (Low) — .github/workflows/main.yml: Workflow validates URLs but not resource relevance, license accuracy, or content quality; relies entirely on human review

• .github/workflows/main.yml (I/O-bound network requests) — Link validation must perform HTTP requests to all URLs in a PR; slow or rate-limited servers can timeout the workflow
• CONTRIBUTING.md review enforcement (Manual review process) — Guidelines are human-readable text; Danger rules only partially automate enforcement, so maintainer must manually review format compliance
• README.md size and discoverability (undefined) — All resources in a single file; no tagging, filtering, or full-

No environment variables or services required to read the list. However: (1) The CI pipeline (main.yml) likely uses a Ruby Danger API token for GitHub PR comments—required for CI to run but transparent to contributors. (2) Link validation in CI may fail due to rate-limiting or temporary outages of external resources; flaky tests on third-party URLs are expected. (3) Markdown format is strict: link format [text](url) must match patterns in Dangerfile; deviations will fail linting. (4) New categories or major restructuring should be discussed in an issue first to avoid breaking existing contribution workflows.

• sindresorhus/awesome — Parent project defining the 'Awesome' list standard and badge used by this repo; provides the meta-curated-list framework and community guidelines.
• awesome-selfhosted/awesome-selfhosted — Similar markdown-based curated list using GitHub Actions and Danger for validation; demonstrates patterns for maintaining large link collections.
• getify/You-Dont-Know-JS — Community-driven educational curated list in markdown with PR-based contributions; shows scalable workflow for crowdsourced content curation.
• EbookFoundation/free-ebooks — Parallel curated list project for free book resources; uses similar validation and link-checking patterns for maintaining 1000+ external resource links.
• neutraltone/AwesomeResource — Sister project by same maintainer exploring resource aggregation patterns; may share validation tooling or architectural insights.

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 link validation workflow to catch broken resources

The repo maintains a curated list of external stock resource links. Without automated link checking, broken links accumulate over time and harm user experience. The Dangerfile exists but appears unused. A GitHub Action workflow could validate all URLs in README.md on each PR and scheduled runs, preventing dead links from being merged.

• [ ] Create .github/workflows/link-check.yml with a job using a tool like linkcheck or urlchecker-go
• [ ] Configure it to run on PRs and weekly schedule to catch link rot
• [ ] Update Dangerfile to integrate link validation results into PR checks
• [ ] Document the process in CONTRIBUTING.md with instructions for local testing

Add structured metadata and validation for resource entries

The README currently lists resources in free-form markdown. Adding a structured data file (JSON/YAML) with resource metadata (name, URL, license type, last-verified date, category) would enable automated validation, sorting, and categorization. This supports future tooling and ensures consistency.

• [ ] Create resources.json or resources.yaml with schema for {name, url, license, category, verified_date, description}
• [ ] Add a build script or GitHub Action in .github/workflows/ to validate the JSON/YAML structure
• [ ] Update README.md to reference the structured file and document how to add resources
• [ ] Add validation rules in Dangerfile to enforce proper metadata on PRs modifying resource data

Add CHANGELOG.md and release tagging workflow

The repo lacks a CHANGELOG.md and appears to have no release versioning strategy. This makes it hard for users to track when resources are added/removed and for maintainers to communicate updates. Adding changelog automation and semantic versioning would professionalize the project.

• [ ] Create CHANGELOG.md following Keep a Changelog format with past entries reconstructed from git history
• [ ] Add a GitHub Action workflow (.github/workflows/release.yml) to automate changelog updates and git tags on merged PRs
• [ ] Update CONTRIBUTING.md with guidance on PR titles for automatic changelog categorization (feat:, fix:, etc.)
• [ ] Configure the workflow to bump version numbers and create GitHub releases automatically

• Add a 'Link Last Verified Date' column or automation to README.md resources to surface outdated links—audit a category (e.g., Photography CC0-license) by testing 10-15 URLs and updating broken ones with community comments.
• Extend the Dangerfile to catch common mistakes: enforce consistent capitalization in section headers, detect duplicate URLs across categories, and validate that all resources have a license statement. This improves data quality without modifying README content.
• Create a simple Ruby script (in /scripts) to extract all URLs from README.md, test them in bulk, and generate a report of broken links for batch fixing. Document the script in CONTRIBUTING.md so contributors can validate before submitting PRs.

This repository appears to be a curated list/documentation project with minimal security risks. The codebase contains primarily markdown documentation and configuration files. No critical vulnerabilities were identified. The main security considerations are related to external dependencies and CDN usage. The project would benefit from automated dependency scanning and ensuring proper lock files are maintained. Overall security posture is good for this type of project.

• Low · External CDN dependency for badge — README.md. The README uses a hardcoded CDN link (cdn.rawgit.com) for the awesome badge SVG. While this is a documentation file and not executable code, external CDN dependencies can be subject to availability issues or potential supply chain risks if the CDN is compromised. Fix: Consider hosting the badge locally or using a more reliable CDN with integrity checks. Monitor CDN health and consider using badge services with built-in security (e.g., shields.io).
• Low · Missing dependency audit configuration — Gemfile. The Gemfile is present but no lock file (.lock) or dependency audit configuration is visible in the file listing. This makes it difficult to ensure reproducible builds and track vulnerable dependencies. Fix: Ensure Gemfile.lock is committed to version control. Consider adding dependency scanning via Dependabot or similar tools in the GitHub workflow.

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.