library 📚

A library of past Generate NU projects, written up for inspiration — not just "here's what we built" but "here's how it's architected and why we made the calls we made."

The goal: when a TL is kicking off a new project, they can browse real
examples of architecture and design decisions from projects that came
before, instead of starting from a blank page (or being scared to open the
one repo that's actually really well documented).

Further intentions: a new-project skill that can be used by new TLs to find existing patterns and use previous lessons from Generate in building their own project.

What's here

• [projects/](projects) — one markdown file per past project, grouped by cohort (projects/fall2025/, projects/spring2023/, etc.), focused on architecture and key design decisions. Written by Claude reading the project's repo cold (code, commit history, PRs) — not by whoever built it — so the write-up reflects what the codebase actually communicates, the same way a new TL encountering it would read it.
• [guides/](guides) — human-written docs on how we work as a team: CI/CD, testing, dev environment setup, ticket planning, deploy practices.

This is a docs-only repo for now — no build tooling, no CI, no generation scripts. Once there's a solid set of project write-ups, the next step is a Claude skill that can search this library for inspiration; that comes after there's content worth pointing it at.

Contributing a project write-up

These are written by Claude, not by the project's original author:

1. Point Claude at the project's repo (code, commit history, PRs — no interviewing the people who built it) and have it fill in [projects/TEMPLATE.md](projects/TEMPLATE.md) for that project — overview, tech stack, architecture, key design decisions, what worked / what it'd change.
2. Save it as projects/<cohort>/<project-name>.md, e.g. projects/fall2025/sac.md. Use whatever cohort naming the project actually ran under (fall2025, spring2023, ...); create the folder if it doesn't exist yet.
3. Open a PR. No reviewer tagging — whoever opens it can tag someone manually if it makes sense.

Contributing a guide

Add a markdown file to guides/ about something you've learned running projects — CI/CD setup, testing approach, how you scope tickets, whatever you'd tell a new TL. No template required. Open a PR.