Technical Email Course From a GitHub Repo

A technical email course from a GitHub repo is a syllabus compiled from README, /docs, and ADRs you ingest — not an LLM that "knows" the project from training data. HinterBuild's Cadensend is an open-source MIT email curriculum engine. One learning goal plus those sources becomes a cited series. Self-host it. There is no hosted signup. The MVP sends only to your verified address. Not marketing, CRM, or bulk email.

This post is the repo-shaped corpus: what to include, what to exclude (node_modules, jokes in issues, generated API dumps), how citations should open a file and heading, and how delivery stays exactly once. Clone Cadensend. Retrieval quality is RAG and LLM systems. Send quality is backend API engineering.

Key Takeaways:

• Point Cadensend at documentation paths, not the entire git history.
• README is an index, not a 30-issue course; Plan must impose outcome and prerequisites.
• Code samples in issues must cite the file version you ingested, not "typical Rust."
• Writer cannot browse GitHub on its own; you supply URLs or files.
• Self-hosted MIT. MVP: verified address only. No classroom blast.
• Re-ingest on release tags so the series does not teach last quarter's flags.

Table of Contents:

• Why Repos Make Terrible Chat Context and Good Courses
• What to Ingest From a Repository
• Plan a Course Against the File Tree
• Citations That Open Files, Not Vibes
• Worked Example: Cadensend Teaching Cadensend
• Version Pins, Tags, and Drift
• Delivery and Scope Limits
• Monorepos, Examples, and Tests That Should Not Teach
• Frequently Asked Questions

Why Repos Make Terrible Chat Context and Good Courses

Short answer: A repo is too big and too mixed. A series is a filter plus an order.

Dumping a repository into a long-context window looks convenient and fails in the same ways as naive RAG: tests, vendor code, and a witty CONTRIBUTING.md outrank the architecture note. That is why RAG pipelines return garbage. Embeddings will happily match "queue" in a changelog and a joke.

A course from a GitHub repo succeeds when you treat the tree as documentation with optional cited snippets, then run Plan / Ground / Write / Deliver. That is the same loop as turning documentation into email curriculum, except the canonical HTML might be MkDocs in docs/ plus a README.

Hallucinated public APIs of your library are worse than generic hallucination because the reader will open a PR. See LLM hallucination and avoid educational hallucination. Grounded newsletter writing is the citation compiler.

Cadensend is not GitHub Copilot and not a GitHub Action that emails the team. See product scope and open source email course platforms. HinterBuild: about.

GitHub's own repository documentation is a reminder that README, wikis, and Pages are different surfaces. Pick one corpus per series.

What to Ingest From a Repository

Short answer: Docs, ADRs, typed public APIs. Exclude generated noise and secrets.

Cadensend Ground: upload files or URLs. Structure-aware parse keeps headings, code fences, tables, and section anchors. Ingest is content-hash keyed and resumable — idempotency for bytes. Fetch needs SSRF controls; a README that links to http://169.254.169.254/ must not become a cloud metadata leak. Cadensend lists hardened ingestion on the product page.

Scoped retrieval: workspace + series filters before the vector store. A monorepo with five products will otherwise teach the wrong package. Diversify by source so one giant README cannot occupy every slot.

If the repo is your personal notes exported as Markdown, you want personal knowledge email series instead of pretending it is a library.

Plan a Course Against the File Tree

Short answer: Outcome first, files second, issues third.

Create Series fields still apply: includes, excludes, audience, cadence, timezone, tone. Example outcome: "Add a well-formed module to this library following our ADRs." Exclude: "internal billing package."

The planner (LangGraph-style validation) should fail if the outcome mentions "skip locked workers" and you did not ingest the file that explains them. Prerequisite order should not introduce the public HTTP handler before the domain types it returns.

Plan Studio: reorder, edit objectives, lock approved issues so regeneration of week 3 cannot smash week 1. That lock is the planning analog of send versions in exactly-once email delivery. Full graph language: curriculum design.

A 30-day programming series uses language docs as the repo. A library onboarding series uses your repo. Do not mix stdlib folklore into a project course unless you ingested those pages.

Cadence: three weekday mornings often beats daily for repo study (cadence and timezone).

Figure 1: Learning goal, exclusions, and cadence before any issue HTML exists.

Citations That Open Files, Not Vibes

Short answer: Source + chunk + anchor. Renderer emits the link. Model cannot footnote a file that was not retrieved.

Write stage: retrieve, write block AST, spec diagrams, critique, gate, revise with a hard cap. No raw HTML. No arbitrary network. No code execution. A poisoned markdown file cannot register a "clone and email the org" tool.

When an issue shows a code block, it should cite the path you ingested. If the model invents export function sendAll(), the gate should fail because that identifier never appeared in chunks. That is grounded writing applied to engineering.

Critique should flag version-shaped claims ("as of v4.2") without a retrieved release note. Educational hallucination is this class of bug.

Editorial workspace: inspect retrieved context, regenerate one section, diff. You will use this when README and docs/architecture.md disagree — surface the conflict rather than averaging it (RAG garbage often hides as a silent merge).

Figure 2: Series-scoped sources so a monorepo cannot leak the wrong package into an issue.

Worked Example: Cadensend Teaching Cadensend

Short answer: Goal "explain Plan/Ground/Write/Deliver well enough to run a local instance"; sources the public repo docs you actually clone.

You would ingest the README and any /docs in HinterBuild/cadensend, not "the internet's opinion of email courses." Exclusions: marketing ESPs, list growth, hosted signup myths.

Issues might be: series wizard fields; ingestion hashes; citation renderer; skip-locked send; timezone pair (UTC + IANA). Each issue cites a file. Delivery of those issues uses the same skip-locked queue the course is teaching — exactly once, skip locked.

MVP: your verified address. You are learning to operate the engine, not mailing a conference list. Compare tools in open source email course platforms.

If the "repo" is really a docs site, prefer URL ingest via docs-to-email.

Version Pins, Tags, and Drift

Short answer: Ingest a tag. Put the tag in the series brief. Re-ingest when you bump the tag.

Teaching main on Monday and main on Friday is how you get issues that contradict. Pin v0.x.y or a commit SHA in the source URLs. Content hashes will change when you bump; that is a new ingest, not a silent mutate.

Issue versions on the send side are separate: editing copy bumps issue_version so exactly-once keys still work (idempotency).

Do not let the writer fetch GitHub at send time. Send is a dumb job. Generation is earlier. Mixing them couples 07:00 to api.github.com.

Delivery and Scope Limits

Short answer: Postgres claim, record before provider, one verified recipient, self-host.

Cadensend Deliver: FOR UPDATE SKIP LOCKED, delivery row first, provider second. HinterBuild backend treats this as the only acceptable pattern for educational mail. Details: exactly-once, skip locked.

There is no hosted Cadensend. Clone and run. You pay LLM + email API + host.

Do not add co-workers as BCC to "share the course." That is list sending without consent features. Roadmap updates mention opt-in audiences later. Today: you.

Need this as an internal onboarding loop? Contact on GitHub docs as email courses. About. RAG. Backend. Product: Cadensend.

A personal knowledge vault can sit beside the repo as extra sources if you include it explicitly. A language 30-day track should usually stay on language docs, not on your app repo.

Monorepos, Examples, and Tests That Should Not Teach

Short answer: Teach the public surface. Cite examples only when they are the contract. Leave fixtures in the test tree.

Monorepos fail courses in a predictable way. Package A's README mentions "queue." Package B implements a different queue. Similarity search returns B into A's onboarding series. Series-scoped filters are necessary but not sufficient — you also need a path allowlist (docs/, packages/foo/README.md, adr/) and a denylist (**/testdata/**, **/fixtures/**, **/node_modules/**).

Example apps under examples/ are double-edged. They are excellent when the outcome is "clone the sample and change one handler." They are poison when they use deprecated APIs the library README already forbids. If you ingest them, put "examples are illustration, README is contract" in the series brief so critique can prefer README chunks on conflict — the same rule as avoiding educational hallucination.

Test names look like documentation to an embedding model: test_skips_locked_row. That is not a lesson. It is an assertion. Prefer ADRs and handbook prose for "why," tests only when you explicitly want a cited snippet of expected behavior.

CODEOWNERS and CODE_OF_CONDUCT almost never belong in a technical email course. They bloat the index and steal slots from the module graph in curriculum design.

Issue-to-file map (use this as a Plan Studio check):

Cadence for repo study is usually three weekday mornings (cadence), not a firehose of file-by-file dailies. Delivery stays exactly once. Grounded writing still compiles the body from chunks, not from "typical Go."

Frequently Asked Questions

Can Cadensend watch a GitHub repo and email me on every commit?

No. It is not a CI notifier or autonomous agent. You ingest sources and generate a planned series. Webhooks for email provider events are verified; they do not scrape GitHub.

Will it email my open-source users when I tag a release?

No. MVP sends only to your verified address. Release announcements to users belong in an ESP with consent. See open source email course platforms.

How do I keep private code off the LLM provider?

You are self-hosting and choosing the model endpoint. Redact secrets before ingest. Cadensend redacts prompts and source text from logs. Tenant isolation is enforced in queries, not in the prompt. Still: do not ingest .env.

Should I ingest the entire monorepo?

No. Filter to the documentation and public API surface for the package the outcome names. Otherwise retrieval is garbage.

Can the model run tests from the repo?

No. The writer has no code execution. Exercises are for you in a checkout. Citations tell you which file to open.

Is there a hosted signup to connect GitHub?

No. Self-host Cadensend. There is no hosted product account.

How does this differ from GitHub Copilot Chat on a repo?

Copilot is interactive and unscheduled. A technical email course is planned, gated, cited, and delivered once per issue version at a local time. Different job.

Who implements repo-to-curriculum for a platform team?

Contact HinterBuild. Related: about, RAG systems, backend API engineering.

Conclusion

A technical email course from a GitHub repo is a filtered corpus, a validated plan, cited issues, and exactly-once local delivery to you.

• Ingest docs and ADRs, not the whole tree.
• Pin a tag; re-ingest on purpose.
• Fail uncited APIs.
• Self-host MIT Cadensend; no lists.

Open Cadensend and the GitHub repo, or schedule a consultation. HinterBuild: about.

Connect with Abdul Sami on LinkedIn.

Related Articles

• Personal Knowledge Email Series From Notes
• Learn a Programming Language by Email in 30 Days
• Email Learning Cadence and Timezone That Gets Read
• Exactly-Once Email Delivery for Courses
• Turn Documentation Into Email Curriculum
• Open Source Email Course Platforms
• Grounded AI Writing for Newsletters
• Avoid AI Hallucination in Educational Content
• Curriculum Design for Email Modules and Prerequisites