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/williamfiset/Algorithms 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 5w ago
• 2 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits

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

What it runs against: a local clone of williamfiset/Algorithms — 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 williamfiset/Algorithms | 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 ≤ 64 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "williamfiset/Algorithms(\\.git)?\\b" \\
  && ok "origin remote is williamfiset/Algorithms" \\
  || miss "origin remote is not williamfiset/Algorithms (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 "BUILD.bazel" \\
  && ok "BUILD.bazel" \\
  || miss "missing critical file: BUILD.bazel"
test -f "MODULE.bazel" \\
  && ok "MODULE.bazel" \\
  || miss "missing critical file: MODULE.bazel"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
test -f ".gitignore" \\
  && ok ".gitignore" \\
  || miss "missing critical file: .gitignore"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 64 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~34d)"
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/williamfiset/Algorithms"
  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 comprehensive reference implementation library of classical algorithms and data structures in Java, with Bazel-based build system and video explanations on YouTube. It covers sorting, searching, graph algorithms, dynamic programming, balanced trees (AVL, Red-Black), and advanced topics like network flows and tree isomorphism—all with clean, educational code and accompanying slides. Monorepo with Bazel build system: source organized as src/main/java/com/williamfiset/algorithms/{category} (e.g., datastructures/balancedtree/, search/, sorting/), mirrored tests at src/test/java/ by category, with supporting resources: /references (academic papers), /slides (Keynote + PDF presentations with audio), /github/workflows for CI. BUILD.bazel and MODULE.bazel define all targets and dependencies.

Computer science students, competitive programmers, and junior engineers preparing for technical interviews or seeking to understand canonical algorithm implementations. Contributors are educators and algorithm enthusiasts maintaining a learning resource with video walkthroughs.

Mature and actively maintained: 1.4M+ lines of Java, comprehensive Bazel CI/CD via GitHub Actions (main.yml, readme-url-checker.yml), MIT-licensed, includes reference papers in /references (Sedgewick, network flows theory, tree isomorphism papers). The repository structure and badge presence (Bazel Tests, URL checker) indicate production-grade maintenance, though primary purpose is educational rather than commercial.

Low risk for learning/reference use, but minimal for production: single maintainer (williamfiset), no external dependencies visible in Bazel/MODULE.bazel, no npm/Maven central exposure. Risk is stagnation if maintainer becomes unavailable. Last visible updates in CI config suggest active maintenance, but no detailed commit history visible in file list.

Active maintenance via Bazel CI (main.yml) and automated URL validation (readme-url-checker.yml). No specific recent PR/issue data visible, but dependabot.yml indicates dependency monitoring is enabled. Educational content (slides, videos) links are actively checked.

git clone https://github.com/williamfiset/Algorithms.git && cd Algorithms && install Bazel from https://bazel.build/install, then bazel run //src/main/java/com/williamfiset/algorithms/search:BinarySearch to run a sample algorithm.

Daily commands: For Bazel: bazel run //src/main/java/com/williamfiset/algorithms/<subpackage>:<ClassName> (e.g., bazel run //src/main/java/com/williamfiset/algorithms/search:BinarySearch). For raw JDK: mkdir classes && javac -sourcepath src/main/java -d classes src/main/java/<path>.java && java -cp classes <qualified.name>. Run all tests: bazel test //src/test/...

• BUILD.bazel — Bazel build configuration defining all compilation targets and dependencies; required to understand how to compile and run any algorithm in the repo.
• MODULE.bazel — Bazel module dependencies and version pinning; essential for reproducible builds and dependency management across the codebase.
• README.md — Main project documentation explaining the repository's purpose, structure, and how to run implementations; the entry point for all contributors.
• .github/workflows/main.yml — CI/CD pipeline configuration for Bazel tests; defines how all algorithm implementations are validated on each commit.
• .gitignore — Specifies ignored files and directories; critical to avoid committing build artifacts, IDE files, or sensitive data.

• Algorithm implementations (Java, C++, Python, others) — Core source code files implementing data structures and algorithms in various languages; must compile, pass tests, and be clearly documented.
  • Failure mode: Implementation errors cause test failures; unclear code reduces educational value; missing edge case handling leads to incorrect results.
• Test suite (JUnit, GTest, pytest, language-native test frameworks) — Unit tests validating correctness of each algorithm implementation; must cover edge cases, performance characteristics, and expected behavior.
  • Failure mode: Insufficient test coverage allows bugs to merge; flaky tests block CI/CD; missing tests hide regressions.
• Build system (Bazel) (Bazel, MODULE.bazel, BUILD.bazel) — Orchestrates compilation of multi-language implementations, manages dependencies, and coordinates test execution across the repository.
  • Failure mode: Build configuration errors prevent compilation; dependency conflicts block builds; misconfigured rules cause test failures.
• Educational materials (Keynote, PowerPoint, PDF, Markdown) — Presentation slides, reference papers, and video metadata; provide conceptual explanations for algorithms and data structures.
  • Failure mode: Outdated or incorrect explanations confuse learners; missing references reduce credibility; broken links in documentation.
• CI/CD pipeline (GitHub Actions, Bazel, workflow YAML) — GitHub Actions workflows that automatically compile, test, and validate all changes on every commit to master branch.
  • Failure mode: Broken workflow configuration prevents validation; failed tests block merges; false positives disable early feedback.

• Developer → Git repository — Push algorithm implementation, tests, and documentation changes to a branch.
• Git repository → GitHub Actions CI/CD — Trigger main.yml workflow on commit to pull request or master branch.
• GitHub Actions → Bazel build system — Execute Bazel build and test commands to compile and validate implementations.
• Bazel build system → Test framework — Compile and run unit tests for each algorithm in its source language.
• Test results → GitHub workflow badge — Update CI/CD status indicator in README; pass or fail signal to contributors.
• Algorithm source code → Presentation slides & documentation — Code examples embedded in or linked from educational materials to maintain learning resources.
• Reference papers → Algorithm source code comments — undefined

Add a new algorithm implementation

1. Create a new source directory following the repo's structure (e.g., src/main/java/com/algorithms/sorting/ for sorting algorithms) (BUILD.bazel)
2. Implement the algorithm in your target language (Java, C++, Python, etc.) following the existing code style conventions ([new algorithm file])
3. Create corresponding unit tests in the parallel test directory structure (e.g., src/test/java/...) ([new test file])
4. Add a new Bazel target to BUILD.bazel in the appropriate directory to define compilation and test rules for your implementation (BUILD.bazel)
5. Update README.md with a link to your new algorithm in the appropriate category section (README.md)

Add educational material for an algorithm

1. Create a new PowerPoint/Keynote presentation in slides/datastructures/ or slides/constructivealgorithms/ following the naming convention (slides/datastructures/[category]/[AlgorithmName].pptx)
2. Export complementary PDF and PNG visual aids for the GitHub repository (slides/datastructures/[category]/[AlgorithmName].pdf)
3. Optionally add audio narration files (MP3/AIF) to slides/audio/ for enhanced learning (slides/audio/[narration].mp3)
4. Create a README.md in the algorithm's slide subdirectory explaining the materials and linking to the companion video (slides/datastructures/[category]/README.md)

Add a reference paper or academic resource

1. Download the academic paper or textbook excerpt related to an algorithm or data structure ([paper file])
2. Place the PDF in the references/ directory with a descriptive filename (e.g., references/TreeIsomorphism.pdf) (references/[PaperName].pdf)
3. Update references/README.md to include a brief description and link to the new reference material (references/README.md)
4. Link the reference from the algorithm's source code documentation or slide materials ([source code or slide file])

• Bazel — Provides fast, correct, and reproducible builds across multiple languages (Java, C++, Python) in a single unified build system.
• Multiple Languages (Java, C++, Python, etc.) — Demonstrates algorithm implementations in idiomatic styles for each language, allowing developers to learn language-specific patterns.
• GitHub Actions CI/CD — Automated testing on every commit ensures correctness and prevents regression of algorithm implementations.
• PDF slides and Keynote presentations — Companion visual and narrative explanations make algorithm concepts more accessible alongside code implementations.

• Multiple language implementations of the same algorithm

  • Why: Increases repository size and maintenance burden but provides language-specific learning and idiomatic code examples.
  • Consequence: Contributors must understand language conventions; harder to keep implementations synchronized; benefits users learning multiple languages.

• Education-first design with slides, videos, and references

  • Why: Makes the repo a learning platform rather than just a library, increasing engagement and educational value.
  • Consequence: Requires maintaining presentation materials alongside code; increases scope but justifies the YouTube companion channel.

• Bazel as the build system rather than Maven/Gradle/Cargo

  • Why: Enables polyglot builds and language-agnostic dependency management across all implementations.
  • Consequence: Steeper learning curve for contributors unfamiliar with Bazel; requires build configuration for each algorithm; enables reproducible cross-language builds.

• Not a production-ready library or package for direct inclusion in applications
• Not a real-time or high-performance optimization library (focuses on clarity and correctness over speed)
• Does not provide platform-specific implementations (iOS, Android, embedded) — implementations are general-purpose
• Not a formal university course or accredited educational program — educational materials are supplementary
• Does not include advanced parallel or GPU-accelerated algorithms — focuses on fundamental sequential implementations

Bazel required for standard workflow (no Maven/Gradle fallback easily visible). JDK 8+ mandatory. Raw javac compilation requires exact -sourcepath setup; common mistake is missing -sourcepath flag, causing package imports to fail. No explicit test data files visible—tests rely on algorithm correctness, not fixtures. Bazel cache invalidation can hide stale test results; use bazel clean if tests behave oddly.

• AVL Tree Rotations — AVLTreeRecursive.java is a primary implementation in this repo; understanding single/double rotations is essential for maintaining O(log n) balance in self-balancing BSTs
• Red-Black Tree Invariants — RedBlackTree.java is a core data structure here; color-based balancing is more complex than AVL but appears in production systems (TreeMap in Java stdlib)
• Network Flow and Min-Cost Max-Flow — Advanced graph algorithm topic with dedicated reference papers (mincost_maxflow.pdf, dinitz.pdf) in /references/; critical for real-world problems like transportation and scheduling
• Tree Isomorphism — Specialized topic with multiple reference papers (tree_isomorphism.pdf, TreeIsomorphism.pptx) in repo; relevant for structure matching and compiler optimization
• Aho-Corasick Algorithm — Exact string matching reference (AhoCorasick.pdf) in /references/; foundational for multi-pattern searching in bioinformatics and intrusion detection
• Bazel Build System — This repo uses Bazel exclusively (not Maven/Gradle); understanding BUILD.bazel targets and module resolution is required to compile and extend the codebase
• Dynamic Programming Memoization — Implicit in many algorithm implementations; competitive programming and interview prep heavily depend on recognizing DP substructure, a focus of this educational repo

• thealgorithms/Java — Parallel algorithm reference library in Java; overlapping coverage but different code style and organization—useful for cross-checking implementations
• sedgewick-algorithms/algs4 — Official Java implementations from Sedgewick's textbook (Algorithms 4th Edition); referenced in this repo's /references/ and foundational to many implementations here
• algorithmzoo/traversing-ocean — Graph algorithm visualization and interactive learning; complements williamfiset's video-first approach with visual debugging tools
• williamfiset/data-structures — Companion repo by same maintainer focusing on advanced data structures with animated explanations; direct extension of core algorithms here
• trekhleb/javascript-algorithms — Multi-language algorithm collection with JavaScript; similar educational goal and structure, useful for cross-language learners

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 comprehensive Bazel test coverage for all algorithm implementations

The repo has BUILD.bazel and MODULE.bazel configuration files but the file structure doesn't show explicit BUILD files for algorithm directories. With the main.yml GitHub Actions workflow running Bazel tests, there's likely incomplete test coverage. New contributors can add BUILD targets and corresponding _test files for algorithm implementations that lack proper test definitions, ensuring all code paths are validated in the CI pipeline.

• [ ] Identify algorithm directories without BUILD files or *_test.java files
• [ ] Create BUILD.bazel files with test targets for uncovered algorithms
• [ ] Add unit tests following existing test patterns in the repo
• [ ] Verify tests pass locally with bazel test ...
• [ ] Submit PR linking to specific algorithms that gained test coverage

Expand .claude.md and .gemini.md skill documentation with algorithm-specific guides

The repo has .claude/SKILL.md and .gemini/SKILL.md files that appear to be AI assistant configuration files, but they're incomplete. These could be enhanced with structured algorithm implementation patterns and common pitfalls for each data structure and algorithm in the repo. This helps AI tools (and contributors) understand the repo's conventions and implementation philosophy.

• [ ] Review existing content in .claude/SKILL.md and .gemini/SKILL.md
• [ ] Document implementation patterns used for sorting, graph, and dynamic programming algorithms
• [ ] Add common testing patterns observed in the repo's test files
• [ ] Link to corresponding reference PDFs in /references for algorithm details
• [ ] Update both .claude and .gemini subdirectories consistently

Create missing README.md files in algorithm subdirectories with video links and complexity analysis

The repo's main README references William Fiset YouTube companion videos for many algorithms, but individual algorithm directories lack README files with linked video URLs, time/space complexity analysis tables, and implementation notes. The references/ folder has PDFs but they're not systematically linked to code. Adding these READMEs (especially for high-traffic algorithms like graph algorithms, dynamic programming, and data structures) improves discoverability and maintainability.

• [ ] Identify top-level algorithm directories without README.md files
• [ ] For each, create a README.md with: algorithm name, description, YouTube video link (from main README), Big-O complexity table, and key implementation notes
• [ ] Reference relevant PDFs from /references folder where applicable (e.g., dinitz.pdf for flow algorithms, tree_isomorphism.pdf for tree algorithms)
• [ ] Include example usage code snippet pointing to actual implementation files
• [ ] Test that all YouTube links and PDF references are valid via the existing readme-url-checker.yml workflow

• Add missing unit tests for src/main/java/com/williamfiset/algorithms/datastructures/balancedtree/RedBlackTree.java (identified by examining repo structure—test file likely missing or sparse). Write comprehensive rebalance(), insert(), delete() test cases mirroring AVLTreeRecursive test coverage.
• Document BUILD.bazel targets for new contributors: create a CONTRIBUTING.md file explaining how to add a new algorithm (file structure, Bazel target naming, test requirements). Reference existing balanced tree targets as examples.
• Implement missing sorting algorithm variants (e.g., Shell sort, Comb sort) in src/main/java/com/williamfiset/algorithms/sorting/ and add corresponding Bazel BUILD targets + unit tests, following existing QuickSort/MergeSort patterns.

This repository is an educational algorithms and data structures collection with a strong security posture. No critical or high-severity vulnerabilities were identified in the provided file structure and configuration. The codebase appears to be a reference implementation project without external dependencies, web interfaces, or credential storage. The MIT license is appropriately declared. Minor recommendations focus on best practices for educational repositories.

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.