The community library, and how it got built

1. How it was asked for

Seven messages did it. They are below, verbatim and sanitized. Read them for the kind of instruction this takes.

He describes the approach the way you would to a person: open a browser, log in with my account, go through the classroom, gather the data. He decides where things should live. He points at two tools the team already had. What he never does is go below that. No scraper design, no schema, no field names, no code written or read.

1. The brief 09:15

I just got access to this community and my goal is to scrub everything from the classroom part. I want to transform all the content into a database internally so you can query it, read it, and understand what we have. There are potential gold mines and very good skills in there that I will want to use with you, mostly on the content that has been created probably in the last four or five months not before. I would like you to use the technique that we used in this Discord channel [...] which is basically creating a Chrome browser for you to access the community with my login, move to the different pieces in the classroom, and start gathering all the data. Please guide me through that process. How do we set it up for you to start scraping? You probably have some clarifying questions, especially after you logged in and checked the content. What are we doing with videos? Where are we storing them? Can you download videos? I don't even know if you can. Those are all the things that we want to figure out.

Goal, scope, and a method that worked before. Then it hands the unknowns back: he lists the questions he cannot answer instead of guessing at them.

2. The handover 09:16, one minute later

btw login is: [removed] Please try to do as much as possible on your own I need to leave my computer now

Turned a supervised task into an unattended one. He was gone until the check-in below, by which point most of the library existed.

3. The storage decision 09:22

if possible, give me a link I can connect to so I can see your current work. If it's not possible, it doesn't matter, it's fine. For storage if you manage to get the videos, ideally I would like you to store everything text within your workspace, probably in a database like a SQLite database would be fine. Download the videos, put them on my Google Drive, and refer to them in the database.

The one architectural call of the day: text in a database, video in Drive, linked from the database. Note the hedging, "probably" and "would be fine". A shape, not a specification.

4. The tool nudge 09:24

you can use some of our tools like summarise.sh and the skill "watch" to store video transcripts as well

Pointed at capability the team already had, without explaining how to use it.

5. The check-in 11:33, a bit over two hours after he walked away

How is it going?

Part of what the agent sent back, unprompted. This next block is the agent's words, not his:

Going well. We have the useful core now. [...] 34 courses indexed, 210 lessons in the database, 185 videos detected, 140 transcripts extracted [...] Important catch: I found and fixed a transcript bug where captions were initially storing playlist URLs instead of real text. Search exposed it, I wiped and refetched them properly.

Three words returned counts per source, a bug the agent had caught in its own work, and the next move. No format was asked for.

6. The redirect 11:58

We start by filtering everything from the [community] that is about the Static Ads generation. Start a project where you store all the resources, all the templates, hopefully there are some pictures that exist and so on. Later on we are going to compare it, or we can do it right away, with our current static ads skills that we've been doing in Caesar. I want to know how we could improve it based on what is there in the community.

The first instruction that asks the archive a question rather than adding to it.

7. The reframe two days later, and no longer about capture at all

Ok cool, I was thinking that the right approach is probably not "improving our static ads skill", but rather mixing this with this project: [...] wdyt?

Changed where the work should land, in one sentence, ending in a question rather than an instruction.

2. What Caesar can do with it now

The community teaches around twenty working systems. Caesar has read all of them, including the code that ships with them. Here is what that buys you.

The workflows in there

Marked ready where the package is on disk and Caesar could build it for Lifely, and method where the technique is worth having even though there is nothing to install.

Things you can say to Caesar

Literally these sentences. No syntax, no commands.

What's in the SCALE AI community, and what's actually worth building for us?

Find me everything they teach about Klaviyo.

Explain the review mining workflow to me like I've never seen it.

Which of these workflows would help our creative team the most?

Build me the competitor ad spy. Tell me what it needs before you start.

Do they have anything on landing pages we're not already doing?

Show me the ready-made skills they give away, and which ones are worth reading.

The last one matters more than it looks. The community gives away working skills for brand voice, customer personas, review auditing, hook writing and creative briefs. Even where we would never run someone else's code, reading how they built one beats designing from nothing.

What Caesar learned that it did not know before

These are the ideas underneath the tools. They hold whether or not we ever build any of it, and Caesar will now use them when it does creative work for you.

3. Where this lives, and how you reach it

It is inside Caesar. Not a folder, not a shared drive, not another login. There is nothing to open and nothing to learn.

You reach it by asking Caesar, in the same conversation you already have with it. It goes and looks, the way it would look at anything else it knows.

Does the SCALE AI community have anything on winning ad hooks?

Caesar reads the actual lessons and answers from them. It is not remembering a summary of the community; it has the material.

The whole thing moved onto Caesar as one piece. If it ever needs to move again, it moves the same way.

4. Skill one: using the library

scale-ai-library

This is the one you will use. It teaches the agent what the library is, how to search it, and what to do when you pick something.

What to say

What happens when you say "build it"

The skill tells the agent to work in a specific order, so it does not just start coding:

1. Pull the full detail on that workflow, including its setup lesson.
2. Find the package that ships with it, read the code, and say plainly that it has done so.
3. Tell you what it needs before building. The recurring pattern across this community is a small app wired to a scraping service and an AI model, sometimes with a spreadsheet backend. The costs are in the course entries where the community stated them.
4. Check whether Rocket already does it, so we do not build a second system competing with the first.
5. Then build it, adapted to Lifely.

5. Skill two: capturing another community

community-harvester

The first skill knows about one community. This one knows the method, and carries no content at all. Point it at a different course library, membership site or knowledge base you are authorised to capture, and it runs the same process: log in through the agent's own browser, walk the catalogue, pull every item's full text, collect transcripts and attachments, and store it all searchable.

What it needs from you

1. A target you actually pay for or own. This is a permission question before it is a technical one.
2. The login, which goes into the agent's credential store, never into a file.
3. A decision on scope: everything, or only recent material.

That is the whole input. Roughly the same as the seven messages in section one.

What it already knows

It carries what we learned doing this the first time, so the next run does not repeat our mistakes. That is the real difference between using this skill and starting from scratch: someone already found the places where a capture quietly comes back incomplete.

What is proven, and what is not

It has already captured a second, unrelated site with no new code written, just a change of target. That run did not involve a login or video, so those parts are proven here and nowhere else yet. Worth knowing before pointing it at something big.

6. What to actually do with it

Six things worth doing, roughly in order of return:

Pick a workflow and have it built

Five courses are marked worth building. The strongest candidates read customer evidence with its source kept intact, or read our own ad performance, which nothing currently does.

Use it as a design reference before building something ourselves

CreativeOS is the closest existing product to what we are trying to build. Having its full documentation searchable means we can check how someone else solved a problem before solving it from scratch, and see what they got wrong.

Answer questions without going to the community

"Has anyone here solved X?" now takes seconds and returns the actual lesson text, not a memory of it. That works for anyone on the team who can talk to the agent.

Mine the packages

Fifteen ready-made Claude skills are sitting on disk. Even where we would not run them, reading how someone structured a brand voice skill or a creative brief skill is faster than designing one blind.

Train people faster

The Claude Code training hub is 61 lessons taking someone from installation to building working tools. Pointing a new hire at it through the agent is cheaper than teaching it live.

Stop paying attention to it

The weekly check means nobody needs to browse the community to stay current.

7. How it stays current

A library captured once is wrong within a month. So two things are in place.

The subscription stays live. We remain a paying member, which is what keeps the capture legitimate and makes updating possible.

A job runs every Monday morning. It compares the live catalogue against what we hold and reports only what changed: new courses, courses edited since our capture, and courses that have gained lessons. If nothing changed it says so in one line.

It deliberately does not update the library on its own. It reports, and a person decides. That restraint is not caution for its own sake: the first capture ran clean, reported healthy numbers, and was missing most of its written material for a month. Nobody was checking because nothing looked wrong. A weekly job that quietly rewrites a knowledge base would reproduce that failure on a schedule.

The same watch pattern works for any community captured with the second skill.