L3 Academy

Module 1: What is L3 Platform?

Understand the big picture — what L3 Platform does and why it exists.

Estimated time: 10 minutes

The Big Picture

L3 Platform is the operating system for Loop3 Studio's engineering operations. It's a monorepo that houses the tooling, automation, and infrastructure that makes every Loop3 project — and every client project — run consistently.

Think of it this way: Loop3 manages engineering for multiple clients (Anthos Capital, Greylock, Khosla Ventures, and others). Each client has multiple repos. Without L3 Platform, every repo would need its own workflows, its own Claude configuration, its own issue conventions. That's a maintenance nightmare. L3 Platform solves this by centralizing everything and distributing it automatically.

Two Pillars

The platform has two major subsystems:

1. The Distribution Engine (.ops/)

This is the operational backbone. It's not a running service — it's the tooling that ensures every registered repo receives standardized files automatically:

  • GitHub Actions workflows — Claude Code automation, issue standardization, Linear project assignment
  • Claude Code skills — lifecycle conventions, issue routing rules, project-specific skills
  • Configuration files — Claude settings, .claudeignore, git hooks

The key concept: .ops/ is the canonical source of truth. You never edit .github/workflows/ or .claude/ directly in any repo. Those are installed copies. When you change a template in .ops/, the sync engine distributes it to all registered repos.

2. The Data Platform (platform/)

This is the running software Loop3 operates:

  • platform/app/ — The admin UI at platform.loop3.ai. Built with Vite, React, Clerk, and TanStack Query. Features the Meeting Review tool for extracting action items from transcripts.
  • platform/ingestion/ — The serverless ticket ingestion API. Receives webhooks from Marker.io and Notion, uses Claude to classify and standardize issues, and creates GitHub Issues in the correct repo.
  • platform/academy/ — This training platform you're reading right now.

The Monorepo Structure

l3-platform/
├── .ops/                  ← Distribution engine (canonical templates)
│   ├── workflows/         ←   GitHub Actions templates
│   ├── skills/            ←   Claude Code skills
│   ├── configs/           ←   settings.json, claudeignore, hooks
│   ├── sync.yml           ←   Central repo registry
│   ├── sync.sh            ←   Sync script
│   └── install.sh         ←   First-time repo setup
├── .claude/               ← Installed skills (synced from .ops/)
├── .github/               ← Installed workflows (synced from .ops/)
├── platform/
│   ├── app/               ← Platform admin UI (Vite + React)
│   ├── ingestion/         ← Ticket ingestion API (Vercel Functions)
│   └── academy/           ← L3 Academy (Fumadocs + Next.js)
└── infra/                 ← Infrastructure-as-code (future)

The Central Registry: sync.yml

The file .ops/sync.yml is the single source of truth for the entire distribution system. It maps:

  • Which repos are registered (currently 16 repos across Loop3, Greylock, Khosla, Anthos, Emergence, and Greybull)
  • Which files each repo receives (workflows, skills, configs)
  • Which Linear team each repo belongs to
  • Which GitHub token to use for cross-org access

When the ingestion service receives a bug report, it reads this registry to figure out which repo the issue belongs to. When the sync engine runs, it reads this registry to know where to push files.

How It Connects to Client Repos

Every client repo listed in sync.yml is a managed target. The sync engine distributes files to them automatically via PRs. Here's a sample of registered repos:

ClientReposLinear Prefix
Greylockdata-intel-fe, data-intel-be, chrome-extension, + more[GL]
Khosla Ventureskv-internal-crm-fe, kv-internal-crm-be, kv-sync-service[KV]
Anthos Capitalgrowth-ai, anthos-data-stack, snapshots-mcp, Lodestone[AC]
Emergence Capitalsyd[EC]
Greybull Stewardshipcompass-fe, compass-be[GS]
Loop3 Studiol3-platform[L3]

Check Your Understanding

What is the canonical source of truth for managed files (workflows, skills, configs)?
What does the ingestion service use to determine which repo an issue belongs to?

Checkpoints

I've read the root CLAUDE.md in the monorepo
I've browsed the .ops/ directory structure
I've opened sync.yml and found my team's repos

Module Assessment

Module Assessment

1. What are the two main pillars of L3 Platform?

2. Where should you edit a GitHub Actions workflow template?

3. How many repos are currently registered in sync.yml?