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/lucasgomide/videos-pt.br-tecnologia 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 — Stale — last commit 1y ago

• 27+ active contributors
• Distributed ownership (top contributor 31% of recent commits)
• MIT licensed
• CI configured
• ⚠ Stale — last commit 1y ago
• ⚠ 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 lucasgomide/videos-pt.br-tecnologia repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/lucasgomide/videos-pt.br-tecnologia.

What it runs against: a local clone of lucasgomide/videos-pt.br-tecnologia — 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 lucasgomide/videos-pt.br-tecnologia | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 442 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "readme_checker_test.rb" \\
  && ok "readme_checker_test.rb" \\
  || miss "missing critical file: readme_checker_test.rb"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
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 442 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~412d)"
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/lucasgomide/videos-pt.br-tecnologia"
  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 list of Brazilian YouTube channels and streaming platforms focused on technology, development, and programming content—all in Portuguese. It's organized by topic (databases, backend, frontend, mobile, AI, security, infrastructure, etc.) and serves as a discovery tool for Portuguese-speaking developers seeking educational tech content. Flat structure: README.md is the primary content file organized into sections via markdown headers (Banco de Dados, Desenvolvimento Back-End, etc.). readme_checker_test.rb is a Ruby test suite validating README structure. Workflows in .github/workflows/main.yml automate CI checks on pull requests. No complex application code—purely a list + validation system.

Portuguese-speaking software developers and students who want to discover Brazilian tech educational channels, learn from local creators, and contribute to a community-driven resource without language barriers.

Actively maintained with a GitHub Actions CI/CD pipeline (workflows/main.yml), contributing guidelines (CONTRIBUTING.md), and organized structure following the Awesome project standard. The project has been public for several years and accepts community PRs, suggesting stable, albeit lightweight, maintenance. Verdict: actively developed community resource — not a production software project, but well-structured and trustworthy.

Standard open source risks apply.

The repository appears actively maintained with GitHub Actions CI enabled and contributor guidelines documented. Pull requests are processed to add/update channel listings and maintain the table of contents. Specific recent activity not visible from file listing, but the CI/CD presence indicates ongoing quality checks on submissions.

git clone https://github.com/lucasgomide/videos-pt.br-tecnologia.git
cd videos-pt.br-tecnologia
bundle install  # Install Ruby dependencies
bundle exec ruby readme_checker_test.rb  # Run validation tests

Daily commands: Not a runnable application. To validate contributions locally: bundle exec ruby readme_checker_test.rb. To preview README changes: render the markdown in any viewer. To propose changes: edit README.md, test with the Ruby validator, then open a PR.

• README.md — Primary documentation listing Brazilian tech YouTube channels; defines the project's scope and contribution guidelines that all PRs must follow.
• CONTRIBUTING.md — Establishes contribution standards and pull request expectations that every contributor must understand before submitting changes.
• readme_checker_test.rb — Ruby test suite that validates README formatting and channel data integrity; blocks invalid PRs from merging.
• .github/workflows/main.yml — CI/CD pipeline configuration that runs automated checks on every PR; must pass before merge.
• Gemfile — Ruby dependency manifest; defines test framework and linting tools required to validate contributions locally.

• README.md Content Layer (Markdown) — Curated list of Brazilian tech YouTube channels organized by category with descriptions and links
  • Failure mode: Invalid markdown syntax blocks PR merge; human reviewers must verify channel relevance and accuracy
• readme_checker_test.rb Validator (Ruby, Test framework) — Automated test suite that parses README.md and validates structure (link format, markdown syntax, required fields)
  • Failure mode: If validation fails, CI blocks PR; contributor must fix formatting before resubmit
• GitHub Actions CI Pipeline (GitHub Actions, YAML workflow config) — Orchestrates test execution on every PR; reports pass/fail status back to GitHub UI
  • Failure mode: If workflow fails to trigger, PR review is delayed; manual intervention may be needed
• Pull Request Review Process (GitHub PR interface) — Human reviewers ensure channel quality, relevance, and compliance with CONTRIBUTING.md guidelines
  • Failure mode: If reviewer capacity is low, PRs may stall; no automated merge option available

• Contributor → README.md — Contributor edits markdown file to add/update channel entries
• README.md → GitHub Repository — Markdown changes pushed to Git; triggers webhook
• GitHub → GitHub Actions CI — Webhook fires; CI pipeline starts as per main.yml config
• GitHub Actions → readme_checker_test.rb — CI environment executes Ruby test suite against README.md
• readme_checker_test.rb → GitHub PR Status — Test results (pass/fail) reported back to PR status checks
• GitHub PR Status → Human Reviewer — Reviewer sees automated test results; can approve/request changes
• Human Reviewer → master branch — Approved PR merged; README.md is now live on GitHub

Add a New YouTube Channel to the List

1. Open README.md and locate the appropriate category section (e.g., 'Frontend', 'Backend', 'DevOps') (README.md)
2. Add a new list entry with channel name, description, and URL in markdown format following existing channel entries (README.md)
3. Ensure the channel name, description, and URL are properly formatted (markdown link syntax) (README.md)
4. Commit, push, and create a pull request; the readme_checker_test.rb will automatically validate format (.github/workflows/main.yml)

Update or Fix Channel Information

1. Locate the channel entry in README.md that needs updating (README.md)
2. Modify the channel URL, description, or metadata while maintaining markdown consistency (README.md)
3. Verify no markdown syntax errors exist (readme_checker_test.rb will catch issues) (readme_checker_test.rb)
4. Submit PR; automated CI will validate the change before merge (.github/workflows/main.yml)

Add or Update Contribution Guidelines

1. Review and update CONTRIBUTING.md with new submission criteria or process changes (CONTRIBUTING.md)
2. Update .github/PULL_REQUEST_TEMPLATE.md if the PR template needs to reflect new requirements (.github/PULL_REQUEST_TEMPLATE.md)
3. Create and submit PR with clear rationale for guideline changes (CONTRIBUTING.md)

• Ruby + Rake/Test — Lightweight scripting language ideal for quick README validation; minimal dependencies suitable for an Awesome-style repository
• GitHub Actions — Native CI/CD integration with GitHub; zero external infrastructure required; perfectly suited for validating community-driven content
• Markdown — Human-readable, Git-friendly format for documenting channel lists; enables easy version control and collaborative editing

• No database backend; content stored in README.md

  • Why: Simplicity and discoverability; GitHub markdown renders directly in browser; all history tracked via Git
  • Consequence: Limited query capability; must manually maintain list order; no dynamic filtering/search on platform

• Ruby-based validation instead of multi-language CI checks

  • Why: Fast feedback loop; minimal dependencies; Ruby readily available on GitHub Actions runners
  • Consequence: New contributors must understand Ruby test syntax; limited to Ruby ecosystem for future enhancements

• Manual PR review process

  • Why: Ensures quality curation; prevents spam channels; maintains human judgment on relevance
  • Consequence: Slower merge cycle; potential bottleneck if reviewer capacity is limited; scalability depends on maintainer availability

• Does not provide API access to channel data
• Does not host or stream video content
• Does not implement user authentication or accounts
• Does not provide real-time channel updates or scraped metadata
• Does not support multi-language channel descriptions beyond Portuguese

• Avg cyclomatic complexity: ~2 — Codebase is intentionally simple: markdown content, basic Ruby tests, and standard GitHub Actions workflow. No complex algorithms, data structures, or business logic.
• Largest file: README.md (150 lines)
• Estimated quality issues: ~1 — No automated linting or code style enforcement; readme_checker_test.rb lacks comments and modular test cases; scale and maintainability could improve with test refactoring

• Single test file for all validation (Low) — readme_checker_test.rb: All README validation logic consolidated in one file; no separation of concerns (parsing, validation, formatting rules)
• Manual channel ordering and curation (Medium) — README.md: No automated sorting or duplicate detection; relies entirely on human discipline to maintain list integrity
• No schema validation for channel entries (Medium) — readme_checker_test.rb: Test checks syntax but not semantic validity (e.g., channel URL must be valid YouTube link, description length bounds)

• Human reviewer approval step (Process bottleneck) — No automated merge; all PRs require manual review by maintainer(s); throughput depends on reviewer availability
• readme_checker_test.rb execution (Performance bottleneck (minor)) — Single test file runs serially; no parallelization; fast now but will slow as test suite grows

No hidden infrastructure traps—this is a static list with tests. However: (1) Channel URLs must be valid and currently active; the test suite likely validates 200-level HTTP responses. (2) Tag format is strict: backticks and commas must match exactly per the validation regex in readme_checker_test.rb. (3) Section headings must match the table of contents anchors or markdown navigation breaks. (4) Pull requests will fail CI if the test suite detects malformed entries, so run bundle exec ruby readme_checker_test.rb locally before pushing.

• Awesome Project Standard — This repo follows the Awesome template for curated lists; understanding the structure (sections, tags, badge format, TOC anchors) is essential for contributing correctly and ensuring CI passes.
• GitHub Actions CI/CD Automation — The repo uses GitHub Actions to validate every PR; knowing how to read and run .github/workflows/main.yml helps you understand what the test suite checks and why your PR might fail.
• Markdown Validation via Regex — The readme_checker_test.rb file likely uses regex patterns to validate markdown formatting (links, tags, heading structure); understanding regex is useful for debugging validation failures.
• Community Curation & Moderation — This project relies on community submissions (PRs) and curator discretion to maintain quality; understanding open-source governance helps you propose channels responsibly and handle disagreements.
• Link Rot & URL Validation — As a list of external resources, this repo faces the challenge of broken/stale links; the test suite likely includes HTTP checks, and contributors must verify channels still exist and are active.

• sindresorhus/awesome — The parent project and template that this repository is based on; defines the Awesome standard for curated lists.
• EbookFoundation/free-programming-books — Parallel curated resource for free programming books and learning materials; similar community-driven model and useful for developers seeking complementary educational content alongside videos.
• getify/You-Dont-Know-JS — Another community-maintained, Portuguese-translated educational resource; developers using this repo will recognize the same philosophy of free, high-quality Brazilian tech education.
• carolsoaressantos/awesome-resources — Related resource by one of the co-creators (Carol) of this repo; likely contains overlapping or complementary curated links for Brazilian developers.
• glaucia86/awesome-pt-br — Another curated awesome list by Glaucia (mentioned in CONTRIBUTING.md as a co-maintainer); focuses on Portuguese-language resources and will appeal to the same audience.

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.

Enhance readme_checker_test.rb with comprehensive validation tests

The repo has a readme_checker_test.rb file but based on the partial file structure, it appears to be a single test file. This should be expanded to validate the README.md structure more thoroughly - checking for broken links, validating channel entries format, ensuring proper markdown syntax, and verifying that all listed channels are still active. This directly supports the repo's core mission of maintaining a curated list of Brazilian tech channels.

• [ ] Expand readme_checker_test.rb to test for dead links in YouTube channel URLs
• [ ] Add validation for consistent README.md formatting (channel name, description, link format)
• [ ] Add test to verify no duplicate channel entries exist
• [ ] Integrate expanded tests into .github/workflows/main.yml to run on every PR

Create automated PR template guidance for channel submissions

The repo has .github/PULL_REQUEST_TEMPLATE.md but given this is a community-driven list of channels, the template should guide contributors on exactly what information is required (channel name, category/tech focus, brief description, subscriber count verification). This reduces review friction and improves submission quality from the Brazilian dev community.

• [ ] Update .github/PULL_REQUEST_TEMPLATE.md with checklist for channel submissions (channel active, category, description, language verification)
• [ ] Add field for submitter to confirm channel content is tech/development focused
• [ ] Add reminder to check for duplicates using the validation from readme_checker_test.rb

Add GitHub Action workflow to periodically validate channel accessibility

The repo maintains a list of YouTube channels that may go inactive or have URLs change. Create a new workflow (separate from main.yml) that runs weekly to ping all channel URLs and report any that become inaccessible, helping maintainers keep the list fresh and valuable. This is specific to .github/workflows/ directory.

• [ ] Create .github/workflows/channel-health-check.yml with schedule trigger (weekly)
• [ ] Use a script to parse README.md for YouTube URLs and test accessibility (HTTP 200 status)
• [ ] Generate an issue automatically if dead channels are found
• [ ] Add a Ruby script to support this validation (parallels existing readme_checker_test.rb approach)

• Expand database/NoSQL section with underrepresented creators: The list exists but likely has gaps—research underrated Brazilian channels teaching MongoDB, PostgreSQL, or Redis and open an issue proposing 3–5 new additions with descriptions and tags.
• Add a 'Podcasts' or 'Community Events' category: Currently the list focuses on YouTube channels; adding a new top-level section for Brazilian tech podcasts or recurring webinars (e.g., São Paulo Dev meetups) would diversify the resource. Open an issue proposing the structure and initial entries.
• Validate and refresh all channel links + update descriptions: Some older channels may have been renamed, deleted, or gone dormant; audit a section (e.g., Desenvolvimento Front-End), confirm each URL still works, update tags/descriptions to reflect current content, and submit a PR with link fixes.

This is a low-risk repository containing a curated list of Brazilian technology YouTube channels. The codebase has minimal security exposure as it appears to be a static documentation/list repository without complex dependencies or code execution. No hardcoded secrets, injection vulnerabilities, or critical infrastructure issues were identified from the provided file structure. Primary recommendations focus on establishing security best practices: adding a SECURITY.md policy and ensuring complete documentation. The Ruby/GitHub Actions infrastructure appears properly configured with minimal security concerns for this type of project.

• Low · Missing CONTRIBUTING.md Security Guidelines — CONTRIBUTING.md. The CONTRIBUTING.md file exists but its content was not provided. Security-focused contribution guidelines should document responsible disclosure procedures for security vulnerabilities found in the project. Fix: Add a security policy section to CONTRIBUTING.md or create a SECURITY.md file that outlines how contributors should report security vulnerabilities responsibly.
• Low · No SECURITY.md Policy Present — Repository root. There is no SECURITY.md file defining how security vulnerabilities should be reported. This is a best practice for any public repository. Fix: Create a SECURITY.md file with vulnerability reporting guidelines, contact information, and response timeline expectations.
• Low · Incomplete README Content — README.md. The README.md file appears truncated (ends with 'Agradecimentos especiais pa'), which may indicate incomplete documentation or encoding issues. Fix: Ensure README.md is complete and properly formatted. Verify file encoding and content integrity.

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.