Jokes on you AI: Turning the Tables - LLMs for Learning

1. Brainstorm Direction    What do you want to learn? Interactive questions
        │
        ▼
2. Scope It                What's new vs what you already know?
        │
        ▼
3. Design Curriculum       Phases, exercises, solutions
        │
        ▼
4. Set Up Project          Folder, CLAUDE.md, config files

> /creating-learning-project

What area are you interested in learning?

> I want to understand OAuth2 and security patterns better, at the same time I want to work more with mastra/agents

Nice. What's your current experience with auth?
  A) I've used API keys and tokens but never implemented OAuth myself
  B) I've done basic OAuth but want to go deeper
  C) Starting from scratch

> A

What kind of project would make this useful AND educational?
  A) GitHub notification agent - OAuth2 flow + API integration + agent workflows
  B) OAuth provider from scratch - deep security focus but less practical
  C) Multi-service auth gateway - broad but complex

I'd go with A. You get to implement the full authorization code flow,
work with a real API, and build something you'd actually use.

> A

What language do you want to build this in?
  A) TypeScript / Node.js
  B) Python
  C) Go

> A

So the curriculum would focus on:
  - OAuth2 authorization code flow (the main learning target)
  - Secure token storage patterns
  - GitHub API integration
  - Building an agent workflow on top

Things like basic TypeScript and API calls I'll keep light since
you're already familiar. Sound good?

> Yes, let's go with that!

# GitHub Notification Agent Curriculum

> **Goal:** Build an agent that triages GitHub notifications and sends relevant ones to Slack
> **Approach:** One continuous project, incremental exercises
> **End State:** Agent runs, fetches your GitHub notifications, filters out noise,
> uses LLM to decide what matters, posts to Slack

## Progress Overview

| Phase | Topic                  | Sessions |
| ----- | ---------------------- | -------- |
| 0     | TypeScript Setup       | 2-3      |
| 1     | GitHub OAuth2 Flow     | 2-3      |
| 2     | GitHub API Client      | 1-2      |
| 3     | Notification Filtering | 1-2      |
| 4     | Mastra Agent Workflow  | 2-3      |
| 5     | Slack Output           | 1        |
| 6     | Polish & Scheduling    | 1-2      |

## Learning Goals

**What's NEW (primary focus):**

- OAuth2 authorization code flow
- CSRF protection, back-channel token exchange
- Multi-step agent workflows with state passing
- Secure token storage patterns

**What you already know (won't repeat):**

- Mastra agent basics, tool creation
- Zod schemas, general TypeScript patterns

## Phase 1 - GitHub OAuth2 Flow

### Goal

Implement the OAuth2 authorization code flow to get a GitHub access token.

### Concepts

- OAuth2 authorization code flow
- State parameter and CSRF protection
- Code-to-token exchange (back-channel security)
- Secure token storage

### Exercise 1.1: Register GitHub OAuth App

1. Go to GitHub Settings > Developer Settings > OAuth Apps
2. Create a new OAuth App with callback URL http://localhost:3000/callback
3. Add credentials to your .env and update your config schema

### Exercise 1.2: Build Authorization URL

Create `src/auth/github.ts` with a function that constructs the GitHub
authorization URL with client_id, redirect_uri, scope, and state parameters.

> Stuck? See [Solution 1.2](#solution-12) at the bottom.

...

### Key Takeaway

OAuth2 authorization code flow: redirect user -> user consents ->
receive code -> exchange for token -> store securely.

> I implemented Exercise 1.3. Can you have a look?

Let me check your implementation.

[reads src/auth/server.ts]

Nice work on the server setup. The routing for `/` and `/callback` is clean,
and you're correctly extracting code and state from the query params.

One thing: you generate the state in `buildAuthUrl` but never store it.
When the callback comes in, what do you validate against? The state needs
to live somewhere between the redirect and the callback return.

Try storing it before the redirect, then checking it matches on callback.

[later]

> I'm stuck on exercise 1.4. I keep getting a 401 when I try to use the token.

Can you show me the request you're making?

> [pastes code]

The 401 isn't from the exchange itself - that actually succeeded. The problem
is upstream. Look at your headers: you're not setting `Accept: application/json`.
Without it, GitHub returns the token as a form-encoded string. Your JSON
parsing fails silently, you end up with an empty token, and that empty token
causes the 401 on the next API call.

> That fixed it. Why does the Accept header matter here?

GitHub's OAuth endpoint supports both form-encoded and JSON responses.
Without `Accept: application/json`, you get `access_token=abc&token_type=bearer`
as a form-encoded string. With it, you get proper JSON. Most tutorials skip this
detail and it causes exactly this kind of silent failure.

## My Role as Tutor Partner

- **Never provide solutions unprompted**
- **Review your code** - Point out what's working, suggest improvements
- **Explain concepts** - Help clarify when stuck
- **Ask guiding questions** - Help discover solutions
- **Reference the curriculum** - Keep aligned with learning objectives

## Current Progress

**Status:** Phase 1, Exercise 1.4
**Next up:** Exercise 1.5 (Secure Token Storage)
**Completed:** 0.1, 0.2, 0.3, 0.4, 0.5, 1.1, 1.2, 1.3

## Session Workflow

1. Read `curriculum.md` for current phase and exercise
2. Attempt the exercise yourself first
3. Ask me for guidance when stuck
4. Update progress in this file when exercise complete
5. Move to next exercise

> I just finished the OAuth2 state parameter exercise.
  Can you create an Anki card for this?

Front: What is the OAuth2 state parameter and why is it important?
Back: ...