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/sagivo/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.

AVOID — Stale and unlicensed — last commit 4y ago

• 10 active contributors
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 69% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ 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 sagivo/algorithms repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sagivo/algorithms.

What it runs against: a local clone of sagivo/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 sagivo/algorithms | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1391 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sagivo/algorithms(\\.git)?\\b" \\
  && ok "origin remote is sagivo/algorithms" \\
  || miss "origin remote is not sagivo/algorithms (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"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "src/binary_search.rb" \\
  && ok "src/binary_search.rb" \\
  || miss "missing critical file: src/binary_search.rb"
test -f "src/merge_sort.rb" \\
  && ok "src/merge_sort.rb" \\
  || miss "missing critical file: src/merge_sort.rb"
test -f "src/longest_increasing_subsequence_nlogn.rb" \\
  && ok "src/longest_increasing_subsequence_nlogn.rb" \\
  || miss "missing critical file: src/longest_increasing_subsequence_nlogn.rb"
test -f "src/google-interview-tips.md" \\
  && ok "src/google-interview-tips.md" \\
  || miss "missing critical file: src/google-interview-tips.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1391 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1361d)"
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/sagivo/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 Ruby-based algorithms reference playground containing 60+ implementations of classic interview coding problems and data structures (sorting, dynamic programming, graph algorithms, tree traversal, string manipulation). It serves as a study guide for technical interview preparation, not a production library—each file is a self-contained solution demonstrating both the algorithm and common coding patterns in Ruby syntax. Flat structure with 60+ standalone algorithm files organized in two locations: root-level files (decode_ways.rb, move_zeroes.rb) and majority in src/ folder (src/merge_sort.rb, src/binary_search.rb, src/house-robber.rb, etc.). Each file is independent—no shared utilities, no module dependencies, no class hierarchy. Interview-tips markdown files (src/google-interview-tips.md, src/facebook-interview-tips.md) sit alongside code.

Software engineers preparing for technical interviews at major tech companies (Google, Facebook, LinkedIn, Twitter), and junior developers learning fundamental algorithms through well-commented Ruby implementations. The README explicitly targets job candidates who want to verify their own solutions or study common interview patterns.

Experimental/educational, not production-ready. The repo has 36,696 bytes of Ruby code across the src/ directory with no visible test suite, CI configuration, or dependency management (no Gemfile present). Commit recency and issue backlog are unknown from provided data, but the lightweight structure and broad problem coverage suggest active maintenance during interview seasons rather than continuous development.

High risk for production use (it's not intended for that). Single-maintainer (sagivo) with no visible GitHub Actions, RSpec tests, or dependency pinning means code quality is unvetted. Files like src/kmp.rb, src/dijkstra.rb, and src/tarjan.rb have no associated tests—subtle algorithm bugs could silently exist. The repo is a learning tool, not a library to integrate.

Unknown from provided data—no commit history, PR queue, or milestone information visible. Based on structure, likely dormant between interview seasons with sporadic updates when new LeetCode problems become interview favorites.

git clone https://github.com/sagivo/algorithms.git && cd algorithms && ruby src/binary_search.rb (No installation needed; Ruby stdlib only—no Gemfile or dependencies)

Daily commands: ruby src/<algorithm_name>.rb (e.g., ruby src/binary_search.rb). Each file is self-contained and executable. No test runner, dev server, or build step.

• README.md — Entry point documenting the repo's purpose as an algorithms playground for interview prep with links to company-specific interview tips.
• src/binary_search.rb — Foundational searching algorithm used as a building block in many advanced problems (e.g., longest_increasing_subsequence_nlogn.rb).
• src/merge_sort.rb — Core sorting algorithm that demonstrates proper divide-and-conquer pattern replicated across other solutions.
• src/longest_increasing_subsequence_nlogn.rb — Demonstrates optimized dynamic programming combined with binary search; represents the high-complexity solutions in this repo.
• src/google-interview-tips.md — Interview preparation guidance from actual Google interview experience; anchors the repo's purpose for job seekers.
• src/facebook-interview-tips.md — Company-specific interview insights complementing the meta-guidance on interview preparation philosophy.

Add a new classic algorithm

1. Create new .rb file in src/ directory with clear algorithm name (e.g., src/new_algorithm.rb) (src/[algorithm_name].rb)
2. Implement the algorithm with inline comments explaining time/space complexity and edge cases (src/[algorithm_name].rb)
3. Include at least one test case or example usage at the bottom of the file demonstrating the algorithm (src/[algorithm_name].rb)
4. Update README.md problems table with link to the new solution (if table exists) or add to the appropriate algorithm category comment (README.md)

Add a new interview tip document for a company

1. Create new markdown file in src/ following naming convention: src/[company]-interview-tips.md or src/[company]-interview.md (src/[company]-interview-tips.md)
2. Structure document with sections: Overview, Key Topics, Common Problems, Cultural Fit, and Tips (src/[company]-interview-tips.md)
3. Link to relevant algorithm solutions from src/ where applicable (src/[company]-interview-tips.md)
4. Update README.md to reference the new company guide in the intro or create a companies section (README.md)

Add an optimized variant of existing algorithm

1. Review existing algorithm file (e.g., src/longest_increasing_subsequence.rb) to understand baseline approach (src/[existing_algorithm].rb)
2. Create new variant file with improved complexity (e.g., src/longest_increasing_subsequence_nlogn.rb) following the naming pattern [algorithm]_[complexity].rb (src/[algorithm]_[variant].rb)
3. Add code comments comparing approach to baseline version and explaining optimization technique (binary search, greedy, memoization structure change) (src/[algorithm]_[variant].rb)
4. Include test cases showing both solutions produce identical results to verify correctness (src/[algorithm]_[variant].rb)

• Ruby — High readability for algorithm demonstrations; quick prototyping; interview candidates likely comfortable with multiple languages
• Markdown (.md) files — Interview tips and documentation are static; GitHub renders directly; no build system needed for guidance docs
• No framework/dependencies — Pure algorithmic focus without infrastructure noise; each .rb file is self-contained and portable for interview study

• Single language (Ruby) instead of polyglot examples

  • Why: Reduces cognitive load during learning; interview prep often targets one language per preparation cycle
  • Consequence: Language-specific optimizations (bitwise ops, iterator patterns) may not generalize; candidates must adapt to different languages for actual interviews

• No test framework (RSpec, Minitest) — tests inline in files or missing

  • Why: Maximizes code clarity and removes framework boilerplate; easier for interview candidates to copy-paste snippets
  • Consequence: No automated CI/test execution; correctness relies on manual review; scaling to 100+ problems becomes harder to maintain

• Store both baseline and optimized variants as separate files (e.g., longest_increasing_subsequence.rb vs longest_increasing_subsequence_nlogn.rb)

  • Why: Demonstrates evolution from naive to optimal; candidates see problem-solving progression
  • Consequence: Code duplication; harder to maintain consistency across variants; may confuse which version to prioritize

• No solution categorization by difficulty (Easy/Medium/Hard) in file names or README

  • Why: Avoids gatekeeping; encourages exploring
  • Consequence: undefined

No hidden traps—this is a read-reference repo with no runtime dependencies, config files, or services. No environment variables needed. Watch out for: some files may have subtle algorithm bugs (no tests to catch them), Ruby version compatibility unknown (uses basic syntax compatible with Ruby 2.0+), and file typo in 'binary_tree_tamplate.rb' (template misspelled).

• Dynamic Programming (Memoization & Tabulation) — Half the repo uses DP (coin-change.rb, knapsack.rb, house-robber.rb, unique_bsts.rb); interview cornerstone that distinguishes candidates
• Graph Traversal & Shortest Path (Dijkstra, DFS, BFS) — dijkstra.rb, tarjan.rb, and rmq.rb demonstrate graph algorithms critical for medium/hard interview problems
• Divide & Conquer (Merge Sort, Quick Sort) — merge_sort.rb and quicksort.rb are textbook examples; understanding recursion depth and partition strategy is essential
• String Pattern Matching (KMP Algorithm) — kmp.rb implements Knuth-Morris-Pratt; substring search appears in many interview variations (decode_string.rb uses this pattern)
• Backtracking & Recursion — brackets_combinations.rb, permutations.rb, powerset.rb, and unique_bsts.rb all use recursive backtracking; critical for combinatorial problems
• Greedy Algorithms & Exchange Argument — stocks.rb (buy/sell stock) and wiggle_subsequence.rb demonstrate greedy choice property; explains why local optimum works
• Topological Sorting & Strongly Connected Components (Tarjan's Algorithm) — tarjan.rb finds SCCs in directed graphs; advanced graph concept distinguishing senior-level interview candidates

• TheAlgorithms/Ruby — Same ecosystem (Ruby algorithms); more comprehensive test coverage and community contribution model
• donnemartin/system-design-primer — Complements interview prep with system design patterns beyond coding algorithm challenges
• kdn251/interviews — Multi-language interview problem collection; shows how these same algorithms are implemented in Python, Java, C++
• jwasham/coding-interview-university — Structured interview prep curriculum; this repo is a code reference for the algorithm portion of that study plan

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 RSpec unit tests for src/ algorithm files

The repo has 40+ Ruby algorithm implementations but no visible test suite. This is critical for a algorithms playground where correctness is paramount. Adding tests for core files like binary_search.rb, merge_sort.rb, longest_common_subsequence.rb, and dijkstra.rb would validate solutions and prevent regressions. This sets a pattern for future contributors.

• [ ] Create spec/ directory with spec_helper.rb
• [ ] Write comprehensive test cases for src/binary_search.rb covering edge cases (empty array, single element, not found)
• [ ] Write tests for src/merge_sort.rb and src/quicksort.rb with various input sizes
• [ ] Write tests for src/dijkstra.rb and src/longest_common_subsequence.rb
• [ ] Add .rspec config file and document test running in README

Move root-level algorithm files into src/ and reorganize by category

decode_ways.rb and move_zeroes.rb exist at the root level while 40+ others are in src/. This inconsistency hurts discoverability. Reorganizing into src/dynamic-programming/, src/sorting/, src/graphs/ subdirectories would make the playground more navigable and help users understand problem categories. Update README table to reflect new structure.

• [ ] Move decode_ways.rb and move_zeroes.rb into src/
• [ ] Create subdirectories: src/dynamic-programming/, src/sorting/, src/graphs/, src/bit-manipulation/, src/arrays/
• [ ] Categorize and move existing files: merge_sort.rb, quicksort.rb, insertion_sort.rb → src/sorting/
• [ ] Move dijkstra.rb, kruskal.rb, tarjan.rb → src/graphs/
• [ ] Move knapsack.rb, longest_common_subsequence.rb, coin-change.rb → src/dynamic-programming/
• [ ] Update README with new file structure and add table of contents by category

Complete and format the incomplete README problems table

The README ends with '| problem' suggesting an incomplete problems table. This table is essential for helping users navigate 40+ solutions. A complete table with links, difficulty levels, and topics would dramatically improve UX and SEO for this learning resource.

• [ ] Create comprehensive table with columns: Problem Name, File, Difficulty (Easy/Medium/Hard), Topic/Category
• [ ] Add links to each src/ file and root-level files
• [ ] Ensure all 42+ algorithm files are listed (check against file structure)
• [ ] Add brief 1-line description for each problem (e.g., 'Binary search implementation with O(log n) complexity')
• [ ] Organize table by difficulty or category for better learning progression

• Add RSpec test suite for src/binary_search.rb, src/merge_sort.rb, and src/quicksort.rb with edge cases (empty arrays, single element, duplicates)
• Add time/space complexity Big-O comments to all sorting files (insertion_sort.rb, shell_sort.rb, counting_sort.rb, merge_sort.rb) in consistent format
• Write a missing implementation guide: create src/lru_cache.rb (common interview problem, absent from repo) with both Dict+LinkedList approach and explanation comments

This is an educational algorithms repository with minimal security risk. The codebase contains no hardcoded secrets, SQL injection vectors, or external API calls visible. However, best practices could be improved by adding dependency management, input validation documentation, automated security scanning via CI/CD, and proper licensing. The repository appears to be intended for interview preparation and learning, not production use, which appropriately limits the scope of security concerns.

• Low · No Dependency Management File — Repository root - missing Gemfile/Gemfile.lock. The repository appears to be a collection of algorithm implementations in Ruby with no Gemfile, Gemfile.lock, or package management configuration visible. This makes it difficult to track and manage dependencies, though for an algorithms playground this is less critical. Fix: Consider adding a Gemfile to explicitly declare any dependencies and use bundle to manage them, even if the current codebase has minimal external dependencies.
• Low · No Input Validation Pattern Visible — src/phone.rb, src/decode_string.rb, and similar input-processing files. The algorithm implementations are educational in nature, but some files (e.g., phone.rb, decode_string.rb) may process user input without documented validation. While this is a learning repository, production use would be risky. Fix: Add input validation and sanitization documentation. Include guards for edge cases, null checks, and type validation in any implementations that may be adapted for production use.
• Low · No Security Testing or SAST Configuration — Repository root - missing CI/CD and security tool configuration. No visible CI/CD pipeline configuration (.github/workflows, .travis.yml, etc.), security testing frameworks, or static analysis tools configured to catch common Ruby vulnerabilities. Fix: Implement GitHub Actions or similar CI/CD with Brakeman (Rails security scanner) and RuboCop (linter) to automatically check for security issues in pull requests.
• Low · No License or Contribution Guidelines — Repository root - missing LICENSE and SECURITY.md files. The repository lacks a LICENSE file and security policy documentation, making it unclear how the code should be used and what security expectations exist. Fix: Add a LICENSE file (e.g., MIT) and create a SECURITY.md file documenting how to report security vulnerabilities responsibly.

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.