Jordan Onboarding

Claude Code + brx-programs setup checklist

0 / 19 complete April 2026

Brooks does before meeting

Pre-Meeting Setup

Get Jordan a Claude account Sign up at claude.ai with Jordan's email. He needs a Pro plan ($20/mo) for Claude Code access.

Claude is the AI that powers everything Jordan will use in this project. Think of it as his coding partner — he'll type what he wants in plain English, and Claude builds it. The Pro plan gives him access to Claude Code, the tool that connects Claude directly to the project files on his computer.

Create Jordan's scoped .env file Done — .env.jordan in brx-programs. Program keys only, no HubSpot PAT/Stripe/Slack.

An .env file is like a keychain — it holds the passwords and access keys that let the code connect to our databases. Jordan's version only has keys for program data (Exercise.com, Supabase workout tables). He doesn't have keys to contact data, payment data, or churn analysis — those stay with Brooks.

Verify tagger v2 on VPS Done — PM2 process online at tagger.brxperformance.cloud

The tagger is a web app where Jordan annotates athlete programs with training metadata (phase, intent, focus area). It's already live on our server. This check just confirms it's up and running before the meeting so we don't waste time troubleshooting.

Setup — 15-20 min

Technical Setup

Get Jordan's machine ready. This is mechanics — do it first so the real meeting isn't interrupted by install issues.

Install Claude Code + clone brx-programs Claude Code CLI, git configured with Jordan's GitHub account, repo cloned to ~/Documents/Coding/

Claude Code runs on Jordan's computer and connects Claude directly to the project files. "Cloning" downloads the full project from GitHub onto his machine. After this, he has all the code, context files, and history locally.

Help me install Claude Code on a new Mac. We need: Claude Code CLI, git configured with Jordan's GitHub account, and the brx-programs repo cloned to ~/Documents/Coding/. Jordan is a new team member with no dev tools installed yet.

Place .env file in the repo root Send .env.jordan via iMessage or AirDrop. Jordan saves it as brx-programs/.env

The .env file holds database credentials. Jordan's version only has keys for program data (Exercise.com, Supabase workout tables) — not contact data, payments, or churn analysis.

First Claude Code session — verify it works "Read CLAUDE.md and context/program_design.md" — Claude summarizes what it knows about BRX programming

Quick smoke test. Jordan sees Claude read the project and summarize his coaching philosophy back to him. Proves the setup works and shows Jordan that Claude already understands the BRX world.

Read CLAUDE.md and context/program_design.md. Summarize what this project does and what data is available in Supabase.

The real meeting — 3 outcomes

Three Things That Matter

Everything above is setup. These are the outcomes that actually need to happen in this meeting.

Outcome 1: Jordan can use Claude Code + GitHub independently

Build "Programs Expiring This Week" together The aha moment. Jordan describes what he wants, Claude builds it. Should take <15 min.

Jordan currently tracks who needs new programs manually. He asks Claude to build a script that checks the database and shows expiring programs. The goal: "I described what I wanted in plain English, and Claude built a working tool in minutes."

Build a Python script called expiring_programs.py that queries Supabase pw_workouts to find athletes whose programs end within the next 7 days. For each athlete, show their name, last workout date, stream (strength/throwing), and program length. Output as a clean table. Use the .env file for credentials.

Walk through branch + commit + push + PR Use the script they just built. Jordan sees the full cycle: branch, commit, push, open PR, Brooks reviews.

This is how two people work on the same project safely. Jordan makes changes on a "branch" (draft copy), then submits a "pull request" (hey Brooks, take a look). Nothing Jordan does can break the main version. Walk through it once together so the process feels familiar.

Take the expiring_programs.py script we just built, create a branch called jordan/expiring-programs, commit it, push it to GitHub, and create a pull request for Brooks to review. Explain each step as you go.

Done when: Jordan can explain what a branch, commit, push, and PR are in his own words, and has done each one at least once.

Outcome 2: Jordan gives real feedback on the Tagger v2

Open tagger.brxperformance.cloud together Walk through the interface: athlete list, phase view, annotation fields, "Capture Rule" feature

The tagger is the web app Jordan will use to annotate programs. It auto-detects phases and fills 80% of fields. Jordan adds reasoning. Walk through it together on a real athlete before asking for feedback.

Tag one program together, then get Jordan's honest feedback After tagging one athlete's program, ask: What feels like noise? What's missing? What would make this faster?

Jordan is the primary user. If a field feels useless, it'll get skipped. If something important is missing, we need to add it. If the flow is clunky, he won't use it consistently. Better to learn this now than after he's frustrated. The "Capture Rule" feature (WHEN/THEN/BECAUSE after saving) is new — get his reaction to that specifically.

Done when: Brooks has a list of what Jordan wants changed, removed, or added to the tagger. Jordan feels like the tool was built for him, not around him.

Outcome 3: Aligned on the rules process + roadmap

Show Jordan the 22 candidate rules Claude extracted Open candidate_rules.md — walk through 3-4 examples so he sees the WHEN/THEN/BECAUSE format and what "adjudication" means

Claude already extracted 22 rules from Jordan's Coaching Logic page. Jordan doesn't need to write rules from scratch — he reviews what Claude produced and says yes, no, or modify. Showing a few examples makes this concrete: "Here's a rule Claude thinks you follow. Is this right?"

Walk through the 3-month roadmap together Month 1: rules + tagging. Month 2: AI drafts + side-by-side comparison. Month 3: narrow go-live on common archetypes.

Jordan needs to see the full picture — not just "tag programs" but why. His tagging and rule reviews directly feed the AI that will eventually draft programs for him to review. The 3-month timeline sets expectations: we're not rushing, but we're also not in limbo. By June, the system should be generating drafts he can actually use for common athlete profiles.

Agree on which athlete archetypes to target first Data says "Premium, 17-18, position player, 4x/week" is the richest profile. Does Jordan agree that's the right starting point?

The system can't handle every athlete type from day one. We need to pick the 3-4 most common, most "templateable" profiles and nail those first. The backfill data suggests where to start, but Jordan knows which profiles are most repetitive vs which are always unique. This is a decision you make together.

Done when: Jordan understands his role (review rules, tag with reasoning, validate phases), knows the timeline, and has agreed on which archetypes to start with.

Jordan can do independently

After Meeting

Explore phase detection "Show me the phase detection view for athlete X" — get comfortable asking Claude about the data

We built an automated system that tries to detect what training phase each athlete is in (off-season throwing, strength focus, in-season maintenance, etc.) based on their workout data. Jordan knows these phases better than anyone. This is his chance to poke around, ask Claude to pull up specific athletes, and see if the auto-detection matches what he actually programmed. It's practice talking to Claude and also a quality check on the data.

Query Supabase for the phase detection view (pw_v2_phases) for a specific athlete. Pick one and show me their training phases across the year — what the auto-detection found for throwing vs strength phases.

Validate throwing phase hints Review schema_v2_phases.sql — are the auto-detected throwing phases accurate?

The phase detection uses rules like "if the block name contains 'throwing', it's a throwing phase." Those rules were our best guess — but Jordan is the expert. Here he reviews specific examples and tells Claude where the detection got it right or wrong. His feedback directly improves the system. This is where Jordan's domain knowledge becomes a real input to the product.

Read schema_v2_phases.sql and explain how throwing phases are auto-detected. Then pull 5 example athletes from pw_v2_phases and show me what phases were detected so I can check if they're accurate.

Annotate programs in the tagger tool Start tagging real programs with training metadata at tagger.brxperformance.cloud

This is the core ongoing task. Every program Jordan tags adds structured data to our system — training phase, intent, focus area, and more. Over time, this builds a library of "what good programs look like" that we can analyze for patterns. The more programs tagged, the smarter the system gets. Jordan can do this at his own pace whenever he has time.

Build something small on a branch Anything he wants — a report, a query, a tool. Get reps with the Claude Code + branch + PR workflow.

The goal here is just to get reps. Jordan picks something he's curious about — maybe "which exercises do I use most across all athletes?" or "show me all athletes who haven't had a program update in 30 days" — and asks Claude to build it. The specific thing doesn't matter. What matters is he goes through the full cycle on his own: ask Claude, build on a branch, submit a PR. Once he's done this a few times, it becomes muscle memory.

I want to build something in brx-programs. Create a new branch for me, and let's build [describe what you want]. When we're done, commit it and create a PR for Brooks to review.

Brooks follow-up

After Jordan's First Week

Review Jordan's first PR Check GitHub notifications or ask Claude "show me open PRs on brx-programs"

This closes the loop. Jordan submitted work, and now Brooks reviews it. You don't need to understand every line of code — Claude can summarize what changed and whether it looks good. The point is that Jordan knows his work gets seen and approved, and Brooks maintains quality control over what goes into the project. Once this cycle works smoothly, Jordan can move fast without Brooks being a bottleneck.

Show me any open PRs on the brx-programs repo. For each one, summarize what changed and whether it looks good to merge.

The End Goal

Build an AI-assisted system that generates a 90%-complete individualized training program from athlete data and coaching rules, with a coach review step before publishing. Think of it as: the system does the first draft, Jordan reviews and tweaks, then it gets pushed to the athlete on Exercise.com.

We just finished the "Capture" phase and are entering "Structure." The data infrastructure is built and Jordan's coaching philosophy is documented. Jordan's job now is to review candidate rules Claude already extracted from the Coaching Logic page (yes/no/modify), and tag programs in the tagger with his reasoning. Once we have ~15-20 approved rules and ~15-20 tagged programs, we build the generation engine.

How It Will Work: Three Tiers

Tier 1: Hard Guardrails

Non-negotiable safety and structural rules enforced automatically. Volume ceilings, age gates for barbell work, block structure order (Mobility→Power→Strength), rep range validation.

5-10 coded rules. If the AI violates one, the draft gets flagged before a coach sees it.

Tier 2: Structured Constraints

Coaching decision patterns that Jordan reviewed and approved. Progression logic, exercise substitution boundaries, throwing phase sequencing, training economy pairings.

10-15 rules. Claude extracted candidates from the Coaching Logic page — Jordan reviews yes/no/modify.

Tier 3: Narrative Context

Jordan's full coaching philosophy fed directly to the AI as context. The AI reads the Coaching Logic page for nuance, multi-dimensional tradeoffs, and the "everything is connected" approach.

Plus reference program retrieval — finding similar athletes' past programs as starting points.

// The full pipeline

1. Coach flags athlete as needing a program (HubSpot)

2. System pulls athlete profile (assessment, age, level, role, time of year)

3. Tier 1: Check hard guardrails (volume caps, age gates, block order)

4. Tier 2: Apply structured constraints (progression, substitution, phase rules)

5. Tier 3: AI reads coaching philosophy + finds similar past programs, generates draft

6. Jordan reviews, tweaks, approves

7. Program pushed to athlete on Exercise.com

What's Built vs. What's Not

Piece	Status	What it does
Workout data in Supabase	Done	155 athletes, 13K workouts, 47K blocks, 154K exercises synced. Expanding to ALL coaches (not just Jordan) for clients since Jan 2024.
Tagger tool	Done	Web app for annotating past programs with training context (phase, goals, constraints)
Phase auto-detection	Done	Automatically detects throwing/strength phases from block names and workout structure
Daily sync pipeline	Done	New programs from Exercise.com sync to Supabase automatically every day
Coaching Logic doc	Done	Jordan's full framework documented in Notion — all sections filled. Covers athlete variables, periodization, strength/throwing decisions, volume guidelines, training economy.
Candidate rules extracted	Ready for review	22 candidate rules (8 hard guardrails + 14 structured constraints) extracted from the Coaching Logic page. Jordan adjudicates yes/no/modify.
Reference program matching	Not built	The engine that finds the most similar past program for a new athlete
AI program generation	Not built	The AI that takes a reference program + rules and produces a draft
Exercise.com push	Not built	Automatically publishing the finished program to the athlete's account

Jordan's Three Jobs This Month

Job 1: Review Candidate Rules

Claude already extracted 22 coaching rules from the Coaching Logic page. Jordan reviews each one: yes (correct), no (wrong), or modify (close but needs adjustment).

Format: 30-minute sessions with Brooks

Target: 15-20 approved rules

Time: Weeks 1-2

Job 2: Tag Programs with Reasoning

Use the tagger to annotate programs. The tool auto-fills 80% of fields — Jordan adds the "why" (top decisions, what would change, constraints).

Tool: tagger.brxperformance.cloud

Target: 15-20 tagged programs with reasoning

Priority: Diverse profiles (different ages, seasons, in-gym vs remote)

Job 3: Validate Phase Detection

As part of tagging, confirm/correct the auto-detected phases. This IS validation — built into the tagger workflow.

Tool: tagger.brxperformance.cloud + Claude Code

What to check: Are the auto-detected throwing/strength/season labels accurate?

Time: Ongoing, 5-10 min per program

How Voice Notes Fit In

When Jordan writes a NEW program (not retroactive tagging), the plan is:

Jordan writes the program on Exercise.com as usual
He records a voice note in Notion explaining his thinking — why he chose this phase, what constraints drove the decisions, what he'd watch for next
The system automatically transcribes the voice note and parses it into structured fields
Those fields get saved to the same database as the tagger annotations

The voice note pipeline isn't built yet — it's the next piece after the rules documentation is in good shape.

What Is a Coaching Rule?

A coaching rule is a decision you make repeatedly when writing programs. It has three parts:

WHEN

The situation or condition

THEN

What changes in the program

BECAUSE

Why you make this change

You already apply these rules every time you write a program — they're just in your head. The goal is to get them into a format the system can learn from.

Example Rules

Injury Constraint

WHEN an athlete is returning from a shoulder injury

THEN eliminate overhead pressing, cap pulling volume at 2 sets, start throwing at plyo-intro phase regardless of calendar date

BECAUSE overhead loading under fatigue is the highest-risk movement for a compromised shoulder. Throwing restarts from scratch to rebuild tissue tolerance progressively.

Equipment Constraint

WHEN athlete is remote with DB-only equipment

THEN substitute all barbell compounds with DB equivalents (DB RDL for barbell deadlift, DB bench for barbell bench), add unilateral work to compensate for lower absolute load

BECAUSE DB max loads are lower than barbell, so we shift to higher rep ranges and single-leg/single-arm variations to maintain training stimulus.

Training Age + Season

WHEN athlete is a novice AND it's off-season

THEN keep exercises simple (DB-only, no barbell yet), focus on movement quality over load, program 3x/week max, use higher rep ranges (8-12)

BECAUSE novices build strength on anything — the priority is building movement competency and training habits before adding complexity. Barbell comes after ~1.5 years of consistent DB work.

Rule Categories to Work Through

These are the areas where rules matter most. You don't have to do them all at once — pick a category and talk through it with Claude.

Injury & Pain Rules

What changes for shoulder, elbow, back, hip, knee pain? What about returning-from-injury vs managing-chronic?

Equipment Substitution Rules

DB-only, bands-only, no rack, no mound — what swaps for what?

Season & Phase Transition Rules

How does volume/intensity change across off-season → pre-season → in-season? What triggers a phase change?

Training Age Progression Rules

When does an athlete graduate from bodyweight → DB → barbell? What determines exercise complexity?

Schedule & Frequency Rules

How does programming change for 2x/week vs 4x/week? What about athletes in-season with heavy game schedules?

Throwing Program Rules

How do you determine starting throwing phase? Ramp-up timelines? When to add/remove mound work?

Safety Guardrails

Things the system should NEVER do — exercises that are always wrong for certain conditions, red-line volume limits, etc.

How to Capture Rules (Jordan's Process)

You don't need to write these in any special format. Just talk to Claude naturally:

// Example conversation with Claude in brx-programs

Jordan: "I want to document my injury rules. When an athlete has elbow pain, here's what I change..."

Claude: [asks clarifying questions, structures it into WHEN/THEN/BECAUSE format, saves to rules file]

Jordan: "Actually, it depends on whether it's UCL or flexor mass. Let me break those apart..."

Claude: [updates the rule with sub-conditions, creates branch, opens PR]

Claude saves rules as structured files in the brx-programs repo. Each rule gets a file in rules/ that looks like this:

# rules/injury-shoulder.md

## Shoulder Pain — Returning from Injury

When: injury_status = "returning" AND pain_area includes "shoulder"

Then:

- Eliminate all overhead pressing

- Cap horizontal pulling to 2 sets

- Start throwing at plyo-intro regardless of calendar

- Add extra shoulder CARs to mobility section

Because: Overhead load under fatigue = highest risk for compromised shoulder...

Example athlete: [name] — October 2025, post-labrum, used this approach

Exceptions: If medical team clears overhead work, can reintroduce at 50% volume

I want to start documenting coaching rules for the program writer. Let's start with injury rules. Read the rules/ directory to see what we have so far, then ask me questions about what changes when an athlete has [shoulder/elbow/back/hip] pain. Structure my answers into WHEN/THEN/BECAUSE format and save them as rule files.

The Big Picture

Think of it like Google Docs, but for code:

Git = the version history system (like Google Docs' "Version history" sidebar). It lives on your computer and tracks every change ever made.
GitHub = the cloud copy (like the Google Drive link). It's where the "official" version lives online, and where everyone syncs to.
Repository (repo) = a project folder that Git is tracking. brx-programs is a repo.

The Key Concepts

Commits = save points

Every time you (or Claude) finish a chunk of work, you "commit" it — that's a snapshot of exactly what every file looks like at that moment. Each commit has a message like "Add phase detection for throwing programs." You can always go back to any commit.

Branches = parallel drafts

Imagine you photocopied the entire project folder and worked on the copy. That's a branch. The original is called main — it's the "real" version. When you create a branch called jordan/expiring-programs, you can make changes there without touching main. If something goes wrong, main is untouched.

Pull Request (PR) = "hey, I'm done — please review"

When you finish work on a branch, Claude creates a PR on GitHub. It shows exactly what changed — lines added in green, lines removed in red. Brooks looks at it, and either approves & merges (the changes get folded into main — one click) or comments ("change this part" and you revise).

Push = upload your commits to GitHub.
Pull = download the latest from GitHub to your computer.
Clone = copy the whole repo from GitHub to your computer for the first time.

How Our Workflow Looks

Jordan opens Claude Code in brx-programs/

"Build me a script that shows expiring programs"

Claude creates a branch: jordan/expiring-programs

Claude writes the code

Claude commits (saves) the work

Claude pushes the branch to GitHub

Claude creates a PR with a summary

Brooks gets a notification

Brooks opens the PR on GitHub

Reads the summary, sees the green/red diff

Clicks "Merge pull request"

Changes are now in main ✓

Jordan never touches main directly. Every change goes through a PR that Brooks approves. That's the safety net.

What Can Go Wrong (and Why It Won't)

Fear	Why it's fine
"I break everything"	You work on branches. `main` is untouched until Brooks merges.
"We both edit the same file"	Git detects this ("merge conflict") and forces you to pick which version wins. Claude handles this automatically.
"I lose work"	Every commit is permanent. You can undo any merge with one command. Git is basically an infinite undo button.
"I don't understand what changed"	PRs show a plain-English summary (Claude writes it) plus the exact line-by-line diff.

The 5 Commands You'll Actually Use

You won't type most of these — Claude does it. But good to know:

What you want	Command	Plain English
Get the latest changes	git pull	Download what's new from GitHub
See what's been happening	git log --oneline	Show me recent save points
Undo a bad merge	git revert <commit>	Create a new commit that undoes that one
See what changed this week	git log --oneline --since="1 week ago"	Self-explanatory
Check current state	git status	What files have changed since last save?

One Mental Model

Think of main as the published book. Branches are rough drafts. PRs are editor reviews. Commits are autosave snapshots within a draft. GitHub is the shared bookshelf where both of you can access everything.

Quick Reference

Key URLs

Tagger: tagger.brxperformance.cloud
Data Hub: data.brxperformance.cloud
GitHub: github.com/brxperformance/brx-programs

Jordan's Workflow

1. Open Claude Code in brx-programs/
2. Ask Claude to build something
3. Claude makes a branch + PR
4. Brooks reviews and merges

Checkboxes saved in your browser. Blue boxes explain the "why." Dark code blocks are prompts — click to copy into Claude.