GO — Healthy across the board

• Last commit 2d ago
• 30+ active contributors
• Distributed ownership (top contributor 25% of recent commits)
• MIT licensed
• CI configured
• ⚠ No test directory detected
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

ossu/computer-science is a curated, structured curriculum document (primarily a large README.md) that maps out a complete, free, self-taught undergraduate-equivalent CS education using MOOCs from platforms like Coursera, edX, and MIT OpenCourseWare. It solves the problem of self-learners not knowing which courses to take, in what order, and to what depth — providing a sequenced path covering everything from intro programming through algorithms, systems (OSTEP), math, and advanced electives. The repo is a Jekyll-based GitHub Pages static site (_config.yml, _layouts/page.html, _includes/) with the main curriculum living in README.md. Supplementary course-specific guidance lives under coursepages/ (e.g., coursepages/ostep/, coursepages/spd/), and extra resources are in extras/. Images are in images/ and the site is served at a custom domain via CNAME.

Self-taught developers and career-changers who want a rigorous, structured CS education without enrolling in a traditional university — specifically people who can commit ~20 hours/week over ~2 years and want guidance on course sequencing, prerequisites, and depth of coverage.

This is one of the most starred curriculum repos on GitHub (50k+ stars) and has been actively maintained since ~2014, making it extremely mature for a documentation-only project. It has a CHANGELOG.md, structured GitHub Actions workflow (.github/workflows/delete-empty-issues.yml), and an issue template system (.github/ISSUE_TEMPLATE/request-for-comment-template.md), indicating organized governance. It is production-ready as a reference curriculum.

The primary risk is curriculum staleness — individual linked courses can be deprecated, paywalled, or removed from platforms like Coursera/edX without warning, making specific entries in README.md potentially broken at any time. There is no automated link-checking CI beyond deleting empty issues, and the project is community-maintained with no single authoritative maintainer, which can slow consensus on course replacements. No code dependencies means no supply-chain risk, but the content itself is the product and requires constant human curation.

Active work visible in the repo includes maintenance of the GitHub Actions workflow for issue hygiene (.github/workflows/delete-empty-issues.yml), ongoing RFC-style issue discussions via the request-for-comment issue template, and incremental updates to CHANGELOG.md. Coursepage-level documentation (e.g., coursepages/ostep/ with multiple project guides) is being expanded.

git clone https://github.com/ossu/computer-science.git && cd computer-science

To preview the Jekyll site locally:

gem install bundler jekyll bundle install bundle exec jekyll serve

Then open http://localhost:4000

Daily commands: bundle exec jekyll serve --livereload

Site renders from README.md and coursepages/ Markdown files via _layouts/page.html

• README.md — The primary curriculum document listing all courses, prerequisites, and learning paths — the single source of truth for the entire project.
• CONTRIBUTING.md — Defines contribution guidelines, criteria for adding/removing courses, and the RFC process every contributor must follow.
• CURRICULAR_GUIDELINES.md — Specifies the academic standards and principles used to evaluate and select courses for the curriculum.
• FAQ.md — Answers the most common questions about the curriculum scope, completion, and usage — essential context for understanding design decisions.
• .github/workflows/delete-empty-issues.yml — The only automation workflow in the repo, responsible for maintaining issue hygiene by deleting empty issues automatically.
• CHANGELOG.md — Tracks historical curriculum changes, helping contributors understand past decisions and avoid repeating discussions.

• README.md (Markdown, GitHub rendering) — Single authoritative source defining the complete curriculum structure, course links, and prerequisites.
  • Failure mode: Broken links to external courses leave students unable to find required material.
• Jekyll Static Site (Jekyll, Liquid templates, GitHub Pages) — Transforms markdown content into a navigable website hosted on GitHub Pages.
  • Failure mode: Misconfigured _config.yml or broken layout templates could render the site unusable.
• RFC Issue Template (GitHub Issue Templates, Markdown) — Enforces structured proposals for curriculum changes through GitHub Issues.
  • Failure mode: If bypassed, unreviewed changes could degrade curriculum quality.
• GitHub Actions Workflow (GitHub Actions, YAML) — Automates deletion of empty issues to reduce maintainer noise.
  • Failure mode: Workflow failure leaves empty issues undeleted, increasing maintainer burden.
• Course Pages (coursepages/) (Markdown) — Provides extended guidance for specific courses that require more context than a single table row.
  • Failure mode: Outdated course page content could mislead students about current course structure.

• Community Contributors → README.md — Submit PRs to update course listings following the RFC and contributing guidelines.
• README.md + coursepages/ → Jekyll Build — Markdown source files are processed by Jekyll into static HTML on each commit.
• Jekyll Build → GitHub Pages CDN — Built static assets are deployed and served globally to visitors.
• Visitors → External Course Platforms — Students follow links from the curriculum to enroll in courses on Coursera, edX, etc.
• GitHub Issue Events → delete-empty-issues.yml — Issue creation triggers the GitHub Actions workflow to check and delete empty issues.

Add or Replace a Course in the Curriculum

1. Open an RFC issue using the template to propose the change and gather community feedback (.github/ISSUE_TEMPLATE/request-for-comment-template.md)
2. Review curricular guidelines to confirm the proposed course meets academic standards (CURRICULAR_GUIDELINES.md)
3. Edit the relevant curriculum section in the main README, following existing table formatting with Name/Prerequisites/Intensity columns (README.md)
4. Add an entry to the changelog documenting what changed and why (CHANGELOG.md)

Add a Course-Specific Guidance Page

1. Create a new directory under coursepages/ named after the course (e.g., coursepages/my-course/) (coursepages/ostep/README.md)
2. Write a README.md in that directory following the structure of existing course pages with reading order, tips, and project guidance (coursepages/spd/README.md)
3. Link the new course page from the main curriculum README in the relevant course row (README.md)

Add a Supplementary Resource

1. Determine if the resource is a course, book/article, or practice problem to select the correct extras file (extras/courses.md)
2. Add the resource with a brief description to the appropriate extras file following existing formatting (extras/readings.md)

Modify the Static Site Layout

1. Update Jekyll site-level settings such as theme, title, or plugins (_config.yml)
2. Edit the base page layout template to change overall page structure (_layouts/page.html)
3. Edit navigation links shown across all pages (_includes/nav-items.html)

• Markdown — Human-readable, diff-friendly format ideal for community-maintained curriculum documents on GitHub.
• Jekyll + GitHub Pages — Zero-cost static site hosting tightly integrated with GitHub, requiring no backend infrastructure for a documentation-only project.
• GitHub Issues + RFC Template — Leverages existing GitHub tooling for structured community discussion and course change proposals without external tooling.
• GitHub Actions — Native CI/CD for lightweight automation tasks like deleting empty issues without requiring external services.

• All curriculum content in a single README.md

  • Why: Maximizes discoverability and simplicity for the primary use case of reading the curriculum on GitHub or the website.
  • Consequence: The file becomes very large and harder to navigate as the curriculum grows; search and linking within it becomes cumbersome.

• No backend or database; purely static content

  • Why: Eliminates operational burden, cost, and security surface area for what is fundamentally a curated list.
  • Consequence: Cannot support dynamic features like progress tracking, user accounts, or personalized recommendations without a separate app.

• RFC-based governance process for changes

  • Why: Ensures community consensus and prevents arbitrary course additions, maintaining curriculum quality.
  • Consequence: Slows down the pace of updates and can create friction for legitimate improvements.

• Does not host or provide any course content itself — all courses are externally linked
• Does not track student progress or issue certificates of completion
• Does not provide a login, user accounts, or any personalization
• Does not guarantee courses remain free or available — links may break over time
• Does not cover professional certifications or vocational training tracks

• Avg cyclomatic complexity: ~1 — The repository contains almost exclusively Markdown documentation with no executable code, so cyclomatic complexity is effectively zero.
• Largest file: README.md (650 lines)
• Estimated quality issues: ~2 — Quality issues are limited to the single GitHub Actions workflow file and Jekyll templates; the rest is prose documentation not subject to code quality analysis.

• Monolithic Content File (Medium) — README.md: The entire curriculum (hundreds of courses, all sections, prerequisites, and explanations) lives in a single very large Markdown file, making navigation and partial updates error-prone.
• No Link Validation Automation (High) — README.md: Hundreds of external course links have no automated checking workflow, meaning broken links can persist undetected for extended periods.
• Duplicated Structure in Course Pages (Low) — coursepages/: Each course page README duplicates similar sections (overview, how to use, resources) without a shared template, leading to inconsistent formatting across course pages.

• README.md (Process / Collaboration) — All curriculum updates funnel through a single file requiring manual review, creating a merge conflict hotspot for concurrent PRs.
• CONTRIBUTING.md + RFC process (Process / Governance) — The RFC-required governance model for any course change means updates are slow, with each change requiring extended community discussion before merging.

Jekyll requires a compatible Ruby version — check _config.yml for any version pins before running locally. The GitHub Pages rendering of README.md is the canonical view, but local Jekyll may render differently if _config.yml has GitHub Pages-specific plugins. Course links in README.md point to external platforms (Coursera, edX) that frequently move or paywall content — always verify a linked course is still freely accessible before recommending or relying on it.

• CS 2013 ACM/IEEE Curricular Guidelines — All course selections in README.md must map to these knowledge area standards — understanding them explains why specific courses are included or excluded.
• Operating Systems: Three Easy Pieces (OSTEP) — The OSTEP textbook and its xv6 projects are a core systems component of the curriculum with dedicated coursepages/ documentation covering specific project assignments.
• Jekyll Static Site Generation — The site rendering pipeline uses Jekyll with Liquid templates — understanding this explains how _layouts/ and _includes/ transform Markdown into the published GitHub Pages site.
• RFC (Request for Comment) Process — Curriculum changes are governed by a formal RFC issue process defined in .github/ISSUE_TEMPLATE/request-for-comment-template.md — bypassing it will get PRs rejected.
• Systematic Program Design (SPD) — The SPD course (HtC1x/HtC2x) is the primary intro programming recommendation and has substantial supplementary docs under coursepages/spd/ including DrRacket-specific setup instructions.

• ossu/data-science — Sister OSSU curriculum for data science, same format and community, often referenced alongside this repo.
• jwasham/coding-interview-university — Solves a similar 'self-taught CS structured learning' problem but focused specifically on coding interview prep rather than full CS depth.
• ForrestKnight/open-source-cs — A more condensed alternative CS curriculum in the same space, directly competing with OSSU for the same audience.
• prakhar1989/awesome-courses — A companion resource listing high-quality CS university courses, frequently cross-referenced when evaluating course additions to OSSU.
• P1xt/p1xt-guides — An early predecessor and alternative structured self-learning guide that influenced the format of OSSU curriculum tracks.

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 GitHub Actions workflow to validate all hyperlinks in README.md and extras/courses.md

The curriculum in README.md and extras/courses.md contains dozens of links to external course platforms (Coursera, edX, MIT OCW, etc.). These URLs frequently break or redirect as courses are retired or restructured. Currently .github/workflows only contains delete-empty-issues.yml, with no link-checking automation. A dead-link checker workflow would catch broken course URLs automatically on every PR and on a weekly schedule, keeping the curriculum trustworthy.

• [ ] Create .github/workflows/link-checker.yml using a well-supported action such as lycheeverse/lychee-action or gaurav-nelson/github-action-markdown-link-check
• [ ] Configure it to scan README.md, extras/courses.md, extras/readings.md, and all coursepages/**/README.md files
• [ ] Add an .lycheeignore or markdown-link-check config file to whitelist known-flaky domains (e.g. Coursera login-gated URLs) so the signal-to-noise ratio stays high
• [ ] Set the workflow to trigger on pull_request (targeting those markdown files) and on a weekly schedule via cron so regressions are caught over time
• [ ] Open the PR with a sample report showing at least one currently broken or redirected link found during testing

Create a dedicated coursepage for the 'Introduction to Computer Science' section (coursepages/intro-cs/README.md) mirroring the depth of coursepages/ostep/

The coursepages/ostep/ directory is a rich resource with six supplementary markdown files (reading order, project guides, scheduling notes, etc.) that give learners concrete guidance beyond what the main README says. By contrast, coursepages/intro-cs/README.md and coursepages/intro-programming/README.md exist as stubs. The 'Intro CS' and 'Intro Programming' sections are the entry point for every new learner, yet they lack the same scaffolding. Expanding these pages adds outsized value because they are the highest-traffic part of the curriculum.

• [ ] Audit coursepages/intro-cs/README.md and coursepages/intro-programming/README.md to understand what content is already present versus missing
• [ ] Study coursepages/ostep/README.md and its sibling files (Reading-order.md, Project-1B-initial-xv6.md, etc.) as a structural template
• [ ] Add a 'How to use this course' section explaining recommended pacing, prerequisite checks, and what 'done' looks like for the intro tier
• [ ] Add a 'Common pitfalls and FAQ' section drawing from issues/discussions in the repo where beginners repeatedly get stuck
• [ ] Add a 'Supplementary resources' section analogous to extras/readings.md but scoped to intro-level material (e.g., specific chapters of SICP or How to Design Programs that align with the recommended course)
• [ ] Submit a PR that updates both coursepages/intro-cs/README.md and coursepages/intro-programming/README.md and links them from the relevant anchors in README.md

Add a GitHub Actions workflow that enforces consistent Markdown formatting across all .md files using markdownlint

The repository has dozens of markdown files spread across README.md, CONTRIBUTING.md, CHANGELOG.md, FAQ.md, HELP.md, CURRICULAR_GUIDELINES.md, extras/, and coursepages/. There is no linting workflow in .github/workflows/ to enforce style consistency (heading levels, list formatting, line length, blank lines around headings). Inconsistencies already exist between files and are introduced in PRs. A markdownlint CI check would make reviewing curriculum PRs faster and keep the rendered GitHub Pages site clean.

• [ ] Create .github/workflows/markdown-lint.yml triggering on pull_request for any '**.md' path change
• [ ] Use the DavidAnson/mark

1. Audit all course links in README.md for broken or paywalled URLs and open a targeted RFC issue with evidence for each broken link. 2. Add a coursepages/ subdirectory for one of the courses currently listed in README.md that lacks supplementary guidance (e.g., coursepages/intro-programming lacks a space-invaders equivalent compared to coursepages/spd/space-invaders-instructions.md). 3. Add automated link-checking to .github/workflows/ using a tool like lychee or markdown-link-check to catch broken external course URLs in CI.

The ossu/computer-science repository is primarily a static educational content site hosted via GitHub Pages using Jekyll, with no backend services, databases, authentication systems, or complex application logic. This significantly limits the attack surface. No hardcoded secrets, credentials, or sensitive configuration files were identified in the file structure. There are no Docker configurations, API integrations, or dependency manifests introducing known CVEs. The identified vulnerabilities are all Low severity and relate to best-practice gaps: a deprecated CDN reference in a badge URL, missing HTTP security headers, lack of automated external link validation, unpinned GitHub Actions (potential supply chain risk), and the absence of a formal vulnerability disclosure policy. Overall, the security posture is strong given the nature of the project, but minor hardening measures around GitHub Actions pinning, security headers, and a disclosure policy are recommended.

• Low · External Badge/Resource Loading from CDN without Subresource Integrity (SRI) — README.md. The README.md loads an external badge image from 'cdn.rawgit.com' without Subresource Integrity (SRI) attributes. The rawgit.com CDN is deprecated and defunct, which could potentially result in broken resources or, if the domain were ever hijacked, malicious content injection in contexts where the README is rendered as HTML (e.g., GitHub Pages). Fix: Replace the deprecated cdn.rawgit.com URL with a current CDN or host the badge locally. When loading external resources in HTML contexts, use Subresource Integrity (SRI) hashes to ensure content authenticity.
• Low · Missing Security Headers in Jekyll/GitHub Pages Configuration — _config.yml, _includes/custom-head.html. The _config.yml and _includes/custom-head.html files do not appear to define Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, or other security headers. While GitHub Pages has some default protections, the absence of explicit security headers in the Jekyll configuration leaves the site more exposed to clickjacking and MIME-sniffing attacks. Fix: Add a Content Security Policy meta tag in _includes/custom-head.html to restrict resource origins. Consider using a custom domain with a CDN (e.g., Cloudflare) that allows setting HTTP security headers such as X-Frame-Options, X-Content-Type-Options, and Strict-Transport-Security.
• Low · Unvalidated External Links in Markdown Content — README.md, extras/courses.md, extras/other_curricula.md, coursepages/. Multiple markdown files (README.md, extras/courses.md, extras/other_curricula.md, coursepages/* etc.) contain numerous external hyperlinks to third-party educational platforms and resources. If any of these external sites are compromised or perform domain hijacking, users following these links could be directed to malicious content. There is no automated link-checking or safety validation in the CI/CD workflow visible beyond the delete-empty-issues workflow. Fix: Implement an automated link-checker in the GitHub Actions CI/CD pipeline (e.g., using 'lychee' or 'markdown-link-check') to regularly validate all external URLs and detect broken or potentially hijacked links. Add a disclaimer to users about verifying external links.
• Low · GitHub Actions Workflow Lacks Pinned Action Versions — .github/workflows/delete-empty-issues.yml. The .github/workflows/delete-empty-issues.yml workflow likely references GitHub Actions using mutable version tags (e.g., @v2, @v3) rather than pinned SHA commit hashes. This exposes the workflow to supply chain attacks where a compromised action version could execute malicious code in the context of the repository. Fix: Pin all GitHub Actions to specific commit SHAs (e.g., 'uses: actions/checkout@abc1234...') rather than mutable version tags. Use tools like Dependabot or OpenSSF Scorecard to audit and maintain pinned action versions.
• Low · No SECURITY.md or Vulnerability Disclosure Policy — Repository root. The repository does not appear to include a SECURITY.md file defining a responsible disclosure policy or security contact. This means that if a security researcher discovers a vulnerability related to this project (e.g., in linked resources or the GitHub Pages site), there is no clear channel for reporting it. Fix: Add a SECURITY.md file to the repository root that describes the supported versions, how to report security vulnerabilities privately, and the expected response timeline. GitHub supports this natively and will surface it in the Security tab.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

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/ossu/computer-science 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.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ossu/computer-science repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ossu/computer-science.

What it runs against: a local clone of ossu/computer-science — 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 ossu/computer-science | 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 ≤ 32 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ossu/computer-science(\\.git)?\\b" \\
  && ok "origin remote is ossu/computer-science" \\
  || miss "origin remote is not ossu/computer-science (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 "CURRICULAR_GUIDELINES.md" \\
  && ok "CURRICULAR_GUIDELINES.md" \\
  || miss "missing critical file: CURRICULAR_GUIDELINES.md"
test -f "FAQ.md" \\
  && ok "FAQ.md" \\
  || miss "missing critical file: FAQ.md"
test -f ".github/workflows/delete-empty-issues.yml" \\
  && ok ".github/workflows/delete-empty-issues.yml" \\
  || miss "missing critical file: .github/workflows/delete-empty-issues.yml"

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

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.