# OS Scaffolding Template Kit

**How to spin up a new Trainer OS from zero.**

Every future `{name}-os` repo starts here. This kit encodes the Hooks-OS pattern into a copy-paste template so onboarding a new Trainer OS customer takes days, not months.

Applied to: `patterson-os` · `youngblood-os` · every future Tier 03 client.

---

## The kit · 5 template files

| File | Purpose |
|------|---------|
| **[repo-structure.md](repo-structure.md)** | Folder layout · what goes where · why |
| **[template-CLAUDE.md](template-CLAUDE.md)** | Auto-loading business context template |
| **[template-config.md](template-config.md)** | System configuration template |
| **[template-data.md](template-data.md)** | Data folder pattern per business type |
| **[template-skills.md](template-skills.md)** | Skills catalog pattern + starter skills |

---

## The scaffolding sequence

### Day 0 · Prerequisites confirmed

- Signed engagement agreement ([template](../hooks-trainer-os/agreement.md))
- Setup fee paid
- Kickoff meeting held ([agenda template](../hooks-trainer-os/kickoff.md))
- Client's `feedback/voice-rules-v1.md` first draft exists

### Day 1 · Create the repo

```bash
# Replace {name} with the trainer's slug (e.g., patterson, youngblood, hooks)
gh repo create kcumby2-wq/{name}-os --private --description "Trainer OS for {Full Name}"
git clone https://github.com/kcumby2-wq/{name}-os
cd {name}-os
```

### Day 2 · Apply the scaffolding

Copy each template file into the new repo:

```bash
# From the fbtrainer-tojcampaign folder
cp docs/onboarding/os-scaffolding/template-CLAUDE.md ../{name}-os/CLAUDE.md
cp docs/onboarding/os-scaffolding/template-config.md ../{name}-os/config.md

# Create folder structure
cd ../{name}-os
mkdir -p data/{athletes,deals,projects,events,inbound} feedback goals skills workflows output
touch improvements.md README.md
```

### Day 3-5 · Customize each file

Replace every `{{PLACEHOLDER}}` in the template files with trainer-specific info. See individual template files for what needs to be filled in.

### Day 6-7 · Load initial context

- Import voice patterns from client's IG / YouTube / past content into `feedback/voice-rules-v1.md`
- Import athlete list into `data/athletes/`
- Import existing deals into `data/deals/`
- First workflow: `workflows/weekly-monday-brief.md`

### Day 8-14 · Voice training run

- Client sends 30-min voice memo (from kickoff)
- Kyron converts to structured voice rules
- First `improvements.md` entry committed
- First automated task run (weekly Monday brief)
- Client reviews output · gives corrections
- Corrections become new voice rules → committed → OS gets smarter

### Day 15-30 · Tool integration

- Wire Optimum Grading → private-labeled to client's brand
- Wire Prospect Edge → configured for client's target athlete profile
- Wire College Directory → set up saved searches

### Day 30 · Soft launch

- OS is live and running
- Weekly Monday check-ins begin
- 30-day tuning window closes at day 60

---

## The 6-Level architecture (mapped to folders)

Every Trainer OS is a physical instance of the 6 AI Agent Levels:

| Level | Folder / File | Trainer OS scope |
|-------|--------------|------------------|
| **1 · MCP** | `data/` | Connections to external tools (booking, socials, CRM), plus stored data |
| **2 · Single-Agent** | `CLAUDE.md` | The auto-loading business context |
| **3 · Skills** | `skills/` | Reusable capabilities (voice rules · templates · frameworks) |
| **4 · Multi-Agent** | `workflows/` | Parallel funnels running as coordinated agents |
| **5 · Agentic RAG** | `data/` + `skills/` (combined retrieval) | Agent decides what to search + how to use it |
| **6 · Memory** | `feedback/` + `improvements.md` | Corrections become permanent rules |

Every folder gets scaffolded on Day 2. Content lives in it from Day 3+.

---

## Template file usage

Each template file has `{{PLACEHOLDER}}` markers that MUST be filled in before the OS runs. Never ship an OS to a client with `{{PLACEHOLDER}}` still in the file.

### Naming conventions

- **Files:** kebab-case for regular files (`voice-rules-v1.md`), UPPERCASE for system files (`CLAUDE.md`, `README.md`, `SYSTEM.md`)
- **Folders:** lowercase, plural (`athletes/`, `deals/`, `workflows/`)
- **Voice rule versions:** `voice-rules-v1.md`, `voice-rules-v2.md` — never overwrite, always append with version bump

### Commit conventions

- **Data updates:** `data: add athlete {name}` or `data: update deal {id}`
- **Skill updates:** `skill: add {skill-name}` or `skill: refine {skill-name}`
- **Voice rules:** `voice: add rule "{rule summary}"` or `voice: revise rule "{...}"`
- **Feedback loop:** `feedback: {trainer} corrected {topic}` — commits both the correction AND the resulting rule change

---

## Patterson-OS + Youngblood-OS priority

Both repos already exist as private stubs. Once Hooks is formally signed:

- **Week 5-6 after Hooks sign:** Kyron approaches Patterson with the same kit as Hooks (agreement + invoice + kickoff)
- **Week 7-8:** If Patterson signs, apply this scaffolding
- **Week 9-10 after Hooks sign:** Kyron approaches Youngblood
- **Week 11-12:** If Youngblood signs, apply this scaffolding

At month 3 from Hooks kickoff: potentially 3 flagship Trainer OS customers · $45K setup + $6K/mo baseline recurring = **$117K first-year revenue from Trainer OS alone.**

---

## What NOT to include in scaffolding

- ❌ Client-specific data (athletes, deals, testimonials) — those come Day 3+ from the client
- ❌ Voice patterns from other clients (Hooks' voice ≠ Patterson's voice) — start fresh every time
- ❌ Pre-configured tools (Optimum Grading etc.) — those integrate Day 15-30 per client
- ❌ Case study drafts — case study is a Month 3 deliverable, not Day 1

---

## Change log

| Date | Change | By |
|------|--------|-----|
| 2026-07-12 | Scaffolding kit created from Hooks-OS pattern | Kyron + Claude |