12:37Nate Herk | AI Automation · Review
Fable 5.1 vs Fable 5: Same Prompt, Same App, $700 Apart
One orchestrator prompt, two agentic coding models, and a blind-judged scorecard that says the cheaper build won anyway.
September 3rdThe argument in one line.
The viral REA repo doesn't invent a new idea, it packages reverse engineering into a disciplined five-step framework so an agent rebuilds a feature from confirmed evidence instead of guessing.
Read if. Skip if.
READ IF YOU ARE…
- You already use an AI coding agent and want a repeatable process for cloning a specific feature from an app you admire, instead of describing it in words.
- You want to understand why showing an agent concrete references (past content, a competitor's UI, a sample report) produces better output than a generic instruction.
- You're evaluating whether a trending open-source agent tool is worth the setup time versus just prompting your agent directly.
SKIP IF…
- You want a step-by-step install and setup tutorial for the REA repo itself; this video explains the concept and shows results, not the installation process.
- You're looking for the legal specifics of what reverse engineering a commercial app is and isn't allowed to touch; the video flags the risk but doesn't go deep on it.
The full version, fast.
REA (Reverse Engineer Anything) is an MCP tool that lets an AI coding agent inspect an existing app's files and running behavior, then rebuild a chosen feature from what it actually finds. The creator tested it across five rebuilds, including his own Loom-style screen recorder, and distills the underlying process into five steps: pick one feature (not the whole app), route by what the target is built with, read the generated summary before the full analysis, label every finding as seen, inferred, or unknown, then rebuild and test against the findings. The core lesson applies beyond coding: giving an agent a concrete example of the output you want beats describing a goal in words, because a specific reference gives the agent something to check its work against instead of guess at.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:52
01 · Reverse Engineer Anything
Cold open naming the viral REA repo and its central claim: an agent can study an app's feature and rebuild it, rather than guessing from a generic prompt.
00:52 – 03:14
02 · Better AI Outputs With References
Pre-REA examples of the same principle: an agent matched the creator's own Instagram reel editing style after studying 30 of his best reels, and Opus recreated a Jordan Watkins motion-design edit after analyzing it frame by frame.
03:14 – 05:20
03 · Rebuilding App Features
Four feature rebuilds shown side by side with their originals: a Loom-style screen recorder (Herk Recorder), a Sandcastles-inspired content analyzer, and an AIS Eval Studio built with ideas taken from Langfuse. A free Scrollcraft website-design skill is pitched mid-chapter.
05:20 – 07:36
04 · How REA Works
The recipe-and-cake framing: a company keeps its source code (the recipe) locked away, but the installed app (the cake) is still inspectable. Decompiling is explained as tasting and breaking the cake down, and one investigation is shown running from question to evidence to a rebuilt, tested version.
07:36 – 11:09
05 · A Five-Step REA Workflow
The five steps walked through in order: pick a feature, route by build, summary first, seen/inferred/unknown, rebuild and test, each shown against the Loom-camera-bubble example.
11:09 – 12:57
06 · Limits and Caveats
Four limits: REA can only see what's on your own computer, some app types need extra setup, output quality depends on the underlying AI model, and there are explicit legal limits against copying exact code or assets.
12:57 – 14:58
07 · Results and Final Takeaways
A head-to-head test where the REA-assisted agent finished slower but produced a better result, the repo's star count as a sign of momentum, and a closing reframe that reverse engineering isn't new, it now just has a repeatable process.
Lines worth screenshotting.
- An AI model isn't especially creative on its own, but it executes a precisely specified target extremely well, so the leverage is in how concretely you define that target.
- Pointing an agent at an existing app and saying 'copy this feature' functions as a complete product spec without ever having to type out the spec by hand.
- A reference-based request beats a goal-based request: 'rebuild this specific result' gives an agent constraints that a generic ask like 'make something good' never provides.
- Showing an agent 30 of your own best-performing pieces of content produces a closer style match than describing the style in words.
- A feature rebuild targets underlying behavior, not appearance: a cloned screen recorder can look nothing like the original and still reproduce how its camera bubble moves and resizes.
- An investigation runs in a fixed loop: state the target behavior, let the agent inspect the app's files, surface the evidence, then build and test a version from it.
- One real investigation's full technical analysis ran past a gigabyte of data, which is why the workflow reads a generated summary first instead of the whole analysis every time.
- Every finding gets labeled seen, inferred, or unknown before anything is built on top of it, and treating an inferred guess as a confirmed fact is called out as where rebuilds go wrong.
- The tool can only analyze what's reachable on your own computer or in files you already have access to. It cannot reach a company's private servers or locked-away source code.
- Result quality is bounded by whichever AI model is actually writing and inspecting the code, not by the framework itself, so the same investigation can produce different results depending on the model.
- There's an explicit line against copying exact code or assets from the original app. The process is meant to produce your own implementation of a behavior, not a copy of someone else's work.
- In a side-by-side test, the coding agent using the reverse-engineering workflow finished slower than the one that didn't, but produced a noticeably better result.
- The practice of reverse engineering a result you admire predates this specific tool by years. What's new is a structured, repeatable framework an agent can follow for it.
- The same instinct, finding something proven to work and understanding why, applies to a recurring report or a workflow just as much as it applies to cloning software.
A framework for giving agents real references
AGENT BRIEFING METHOD
A five-step framework turns a vague request into a specific, evidence-backed brief an agent can actually execute and check its own work against, whether or not you ever touch the REA repo itself.
01Reverse Engineer Anything
- A tool doesn't have to be conceptually new to go viral. It just has to package an existing practice into a repeatable framework an agent can follow.
- AI models aren't especially creative on their own, but they execute a clearly specified target extremely well. The leverage is in how precisely that target is defined.
02Better AI Outputs With References
- Showing an agent 30 of your own best-performing pieces of content and asking it to study them produces a closer style match than describing the style in words.
- A reference-based request beats a goal-based request: naming a specific result gives an agent constraints that a generic ask like "make something good" never will.
- The same reverse-engineering instinct applies outside of coding, to a recurring report, a landing page, or any repeatable deliverable you want an agent to match.
03Rebuilding App Features
- A feature rebuild targets behavior, not appearance: a screen-recorder clone can look nothing like the original and still reproduce how its camera bubble moves and resizes.
- A rebuild is a starting point, not a finished product. An honest side-by-side comparison can rate a rebuild as close but not yet equal to the source.
- Taking inspiration can be scoped narrowly. Grabbing "the best core features and how they work" from a reference tool is different from cloning it wholesale.
04How REA Works
- A company keeps its source code locked away, but the installed app is still inspectable, so an agent can study the running app without ever seeing the original code.
- An investigation runs in a fixed loop: state the target behavior, let the agent inspect the app's files, surface the evidence, then build and test a version from it.
- A rebuild comes out well in proportion to how concrete the request is. A vague ask forces the agent to guess, while a cited, evidence-backed brief gives it something to verify against.
05A Five-Step REA Workflow
- Picking one narrow feature or behavior to study, rather than an entire app, is what makes a target something an agent can actually verify.
- Identifying what a target is built with, before choosing inspection tools, matters because the right tool depends on the platform.
- Reading a generated summary before the full technical analysis exists specifically so an agent doesn't have to re-read a gigabyte of findings every time.
- Labeling every finding as seen, inferred, or unknown before building on it prevents the most common failure mode: treating a guess as a confirmed fact.
- Building is followed by testing and iterating against the findings, not shipping once a first version compiles.
06Limits and Caveats
- The tool can only analyze what's actually reachable on your own computer or in files you already have access to, not a company's private servers.
- Some application types need extra setup before an agent can inspect them at all, so not every target is equally fast to start on.
- Result quality is bounded by whichever AI model is actually writing and inspecting the code, not by the framework itself.
- There's an explicit line against copying exact code or assets from the original app. The process should produce your own implementation of a behavior, not a copy.
07Results and Final Takeaways
- In a side-by-side test, the agent using the reverse-engineering workflow finished slower but produced a noticeably better result than the one that didn't.
- The practice of reverse engineering a result you admire predates this specific tool by years. What's new is a structured, repeatable framework an agent can follow for it.
- Finding something that's already proven to work well and understanding why it works is the same move whether the target is an app, a workflow, or a piece of content.
Terms worth knowing.
- REA (Reverse Engineer Anything)
- An open-source MCP tool that lets an AI coding agent inspect an existing app's files and runtime behavior, then rebuild a chosen feature from what it actually finds, rather than guessing.
- MCP
- Model Context Protocol, a plug-in standard that gives an AI coding agent new tools, such as the ability to inspect a binary or a running app, beyond what it can do by default.
- Decompiling
- Working backward from a finished, running app to figure out how it behaves, as opposed to the forward process of a company writing the original source code.
- Seen, inferred, unknown
- A three-way label applied to every finding during an investigation: seen means confirmed in the files, inferred means a reasonable guess from the evidence, unknown means it couldn't be determined at all.
- Route by build
- The workflow step where the agent identifies what an app's platform is built with, such as Electron, native, web, or mobile, before choosing which inspection tools to use.
- PRD
- Product requirements document, a written spec of what to build. The video's premise is that pointing an agent at an existing app's feature can substitute for writing one by hand.
Things they pointed at.
04:33toolLangfuse
Lines you could clip.
00:00
“So this GitHub repo right here, reverse engineer anything, has been absolutely blowing up.”
03:15
“Essentially what you've done is you've given the agent a very, very specific PRD, but instead of you having to type out the exact PRD with all the specs, you're just saying, look at the app, that's your PRD.”
12:16
“You can't just assume that, oh, because you gave your AI model this repo, it's just going to build everything magically.”
14:18
“The concept of reverse engineering isn't anything new. You've probably been doing it in your workflow without even realizing it.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogy
So this GitHub repo right here, reverse engineer anything, has been absolutely blowing up. Matthew Berman himself said software is done. Now he's kind of joking a little bit.
This narrative has been around for, you know, over a year since vibe coding has really taken off, but there is some truth to it. Because the idea of reverse engineer anything is that you see a feature you like on some sort of app or software that already exists, and then you can have your agents using the frameworks inside of here, understand how that functionality works, and then actually just go ahead and recreate it.
So today I wanted to quickly talk about how this actually works and why I don't think this is anything really that new. And because of that, how you can use this and also the right mindset to be able to actually. build things way better.
So I've been playing around with this REA repo and I've built games, I've built software, I've built different tools and apps and just tested out a bunch of things. And it is very impressive. But as I was going through and testing it out and using it, I realized that it's not anything new.
And we have probably been doing this for a long time. I definitely have been doing this for a long time. The way that I think about it is that AI is not really that creative.
It can't really think outside the box, but if you give it a very clear vision, it can execute on that for you really well. And if we take a look at some examples that I've actually built. a while before this GitHub repo existed, you'll see what I mean.
On the left, we have my human edited Instagram reels. I'm gonna mute this real quick so I can actually play it, but you can see the vibe, right? You've got B -roll, you've got different font colors, you've got shimmers, you've got different types of animations.
And what I did in order to make a skill that now edits my Instagram reels. is I had it go watch like 30 of my best performing Instagram reels. And now we get this style on the right, which looks pretty much identical, the same sorts of different colors and fonts and vibe and animations and all of this kind of stuff.
And now this just lives inside of a skill. And the point is, what I had to do here was I couldn't say, hey, I want you to build me an Instagram editing skill that has this sort of vibe and does these sort of transitions. No, what I did is I said, hey, look at these videos.
analyze all of these frame by frame and understand what's going on under the hood. And that's essentially me decompiling my human edited real style. Here's another example with a motion edit.
On the left was one from Jordan Watkins, and you can see that it's really, really well done. And he said, I'd love to see AI try and recreate this. So I was like, huh, let's see what it can do.
So I downloaded the video, gave it to Opus and said, hey, analyze this frame by frame, understand what's going on and how it works and why it works like this. And then build me a skill around it and show me that you can edit a video similar to it. The one on the left is still better with motion design and sound design.
a little bit better. But the thing is Opus could not have thought of this. This is such a creative design that I don't think Claude or any AI could have created it.
But because I'm showing it, this is what I want. Analyze it. Now build it for me.
It was able to do a much better job. And when I've talked to you guys about how to build the best skills. This is exactly what I preach.
I preach reverse engineering the output. If you want to build a Friday report, have it look at five examples of good Friday reports because now it knows exactly what you want. I've talked a lot about how communicating your intent has to be specific.
If you give an agent a generic goal, it's going to give you a generic result. So this whole idea of reverse engineering anything and having it specifically look at an app that you want to recreate and then copying the features from it. That is way more specific.
Essentially what you've done is you've given the agent a very, very specific PRD, but instead of you having to type out the exact PRD with all the specs, you're just saying, look at the app, that's your PRD. I've done this with landing pages, you know, taking elements or animations or designs from other landing pages. Here was an example of one that I did with Glido.
I've done this with apps, right? Like you can see right here, I've got this thing right here, which is basically the Loom clone that I made from. Using this repo right like I had it look at loom.
I had to understand how it can work with like the different bubbles You can see it does the recording countdown. It might not work because my face cam is recording Right, right somewhere else. So I'll play a clip real quick.
Alright, so I just wanted to test out how this actually works to make sure that This is like a decent software. I'm gonna see if I can pause this and now we can go ahead and keep on rolling I can move this thing around I can also make it smaller or larger while I'm recording. That's very nice.
And let's go ahead and stop and see what happens But the thing that's important to realize is that we didn't clone Loom. This is a very different looking app.
We didn't clone like all of the exact UI and the design elements. We cloned the functionality. We understood how does the little bubble work?
How can you move it around? How can you change the window that you're recording, right? Like we talked about this sort of stuff and we had to analyze that sort of stuff.
Loom obviously records and stores your things in the cloud, in Loom's cloud, but this one is just local. So it's storing these files in my own folder inside of this app called Herc Recorder. I also pointed this at Sandcastles and had it inspect the functionality and understand and research how it works and what it does.
And then it gave me basically my own version of Sandcastles and I just had to connect my API key. So it helps me analyze Instagram content and analyze my own content. And you can also see this is true with something like our AIS Eval Studio, which lets us actually eval our automations.
We took a lot of inspiration here from Langfuse and we understood how they work, how they show things, how they run the things. And now we have our own version right here. And it's not a carbon copy, of course, but we had it.
look at and grab some of the best core features and how they work and why. Real quick, guys, I've got this completely free website design skill that I'm giving away. I use this for every single website that I build, including our AI Automation Society site, which I think is pretty slick, and I absolutely love this website.
It's called Scrollcraft, and it understands things like scroll -driven animations and layering, but also it has things in there like taste, typography, spacing, depth. It's just a really good website design skill in general, and it's completely free, so the link for this will be down in the description, but let's get back to the video.
So I guess the point I'm trying to make there is reverse engineering has been around for a long, long time. But the reason why this repo is blowing up is because this repo gives your agents a very practical and thought through framework for decompiling and iterating in order to actually create what you want to create. And if you haven't been using your agents in that way, where you show them the end goal and then help them sort of work backwards to get there, to build the skills, to give you a better output, then you definitely should start thinking about this, not just when you're trying to build apps or software, but when you're just driving your day -to -day and you're building skills.
So let me just break down real quick, real simply, what actually this is and how it works. So REA, reverse engineer, anything. It helps your AI agent study something.
and then help you build it. So let's take a look at like a recipe, a bakery example. So let's say the bakery has a cake that you love.
You order it every week and you love it. And you wanted to reverse engineer the cake to get the recipe because the recipe is locked away. It's the bakery's IP and they don't give it away.
So you buy a cake, the bakery ships the end result to you and they use the recipe to make that obviously. Now, you inside of your kitchen, you can actually , you can taste it, you can try to look at it under a microscope, and you're essentially trying to reverse engineer the recipe from that cake. And this is the process of decompiling, which means you're actually tasting it, you're inspecting it, you're trying to break it down to figure out what are the different code blocks and what is the actual letters in here that make the cake.
And there's where you get sort of like your own sort of trial and error, where you're building and you're comparing and you're trying to iterate on it until you hit the end result. So what happens is, if we take that example of loom, you can ask your agent, hey, use reverse engineer anything and go figure out how lube's camera bubble work so we can work that into our own screen recording app.
Your agent would then inspect the files and inspect the functionality of the app. It would look through the evidence, it would build its own version, and then you iterate until it basically matches up in terms of functionality. And like I said, it comes out so well because you're pointing it at an end result.
You're not saying, hey, make me a cake. You're saying, make me this very specific example of cake that tastes like this with this much density and it has this type of frosting and... this many layers.
It's just way more specific of a request. So this whole doc that kind of walks through and explains some of this, I will link in my FreeSchool community for completely free if you guys want to grab it, as well as this doc, which just kind of goes through like how to get the most out of it. Because what I found after building a bunch of stuff is it's so hard to just say, hey, go reverse engineer Loom.
It's easier to pick out features. So you use Loom for a little bit and maybe it's like, okay, I want to build this myself. What are the best features of Loom that I like?
Or, you know, I want to rebuild my CRM. What are the features of, you know, Salesforce or whatever I use that I really, really like? Okay, now we use our agent to go pick out those specific features, investigate them, decompile them, and then bring them over to our own app.
And then what I did kind of for fun is I had cloud code with the reverse engineer anything framework, reverse engineer, the reverse engineer anything repo to basically help me figure out how it works better so that I can. use it better and point my agents at it better and instruct them better with it. So here is what we have, five main steps that I want you guys to think about when you're using this repo.
Pick a feature, route by build, summary first, scene inferred unknown, and then rebuild and test. So we already talked about this one a little bit, right? Not just pointing at the whole app, but pointing at specific behavior and functionality.
Now from there, thinking about routing by build, which means what the app is built with. kind of picking the tools for that. So once you understand what sort of app or software you're looking at and how it actually exists, then you might be able to change the way or alter the way that the agent thinks about analyzing it to use the right tools.
And this isn't something that I know off the top of my head. I would just make sure I'm giving the agent that context of you should be thinking about this sort of stuff when it comes to like the tech stack. Now, number three is about summary first.
So what happens is REA will basically analyze the whole app and give you a bit of a summary. But the whole analysis for Loom, for example, was over a gigabyte. So basically the full analysis has turned into a shorter summary for Cloud to actually fully read through.
And it's things like what it works, how this thing does what it does, and what it couldn't yet figure out. And then what happens is it kind of breaks that down more granularly down to the modules and to the traces. But you don't want to have to rerun that entire summary, which is something that you could easily get caught in the loop of if you're not being careful about how you instruct it, because this is already saved locally within this project or somewhere in your files.
Now, this fourth one's really important, which is once it starts to dig through and understand what's going on, Claude should be tagging these as seen, inferred, or unknown. And these are basically three different categories, meaning seen are things that Claude actually found and were cited. So for Loom, 11 custom native add -ons, it found it and it understands how they work.
inferred is things that, oh, the data and the code kind of points to this being the way that it works, but this is kind of more of a guess. We don't actually know for a fact. And the reason why this one's so important is because if you accept some of these guesses and assumptions that Claude might be bringing back, and then you build on top of them as if they're fact, you can get into some pretty messy situations.
And then of course, we have things that are completely unknown. REA couldn't see it inside of the native recorder or inside of the app that you're actually using or looking at. And so it's these types of things that you're able to do with this reverse engineering, anything framework and repo that if you just natively said, Hey, Claude, go look at this app, research it, investigate it, and then build it.
That's where there's a big difference on like how professional and I guess structured this process feels when you use this repo. And then of course, this is the most important part of any build process is the rebuilding and the testing. So now you're taking all these findings that you had.
grabbed and then you're building on top of them and you're not just building but you're also going through and you're iterating and you're actually testing these things out you're having it run these test cases you're having it actually process things so it's not just built but it's actually ran and tested and then iterated on rather than just you know shipping something once because it seems like it's done.
Now, the last things I want to talk about here is that you should never be copying exact code or assets. There are definitely some legal limits here when you are deeply inspecting what's going on. But for the most part, you also have to remember that you're only looking at, or cloud code or whatever AI you're using, is only looking at things that actually exist already and that you can grab.
Meaning, you know, you're not going to be telling this thing to hack into like Loom's server or to some app and software's like... private IP code base, you probably couldn't even get in there, but you're not going to tell your AI to go hack into it. You're having it analyze what it can already see in your local files, or if you have an API, whatever it may be, it's just inspecting how it already works and what already lives there.
And this whole process of decompiling is something that people are already doing because it's literally there, it's public, it's in your hands. But humans obviously go through it a lot slower than what an agent would do. And also...
most of the humans out there, I definitely couldn't read through code and read through all these traces and decompile it and then build my own app based on that. The next thing is that some apps require different types of setup, based on, we talked a little bit earlier on where they actually live and thinking about the tech stack and thinking about how you need to set that up.
And then of course, at the end of the day, The results that you're going to get from this thing are based on the AI model that's actually writing the code and inspecting the code. So you can't just assume that, oh, because you gave your AI model this repo, it's just going to build everything magically.
But what I do think is cool about that is let's say you have this software that you were building with Opus 5 .5, and maybe you want to try with Sonnet 5 .5, and it wasn't possible earlier. But now if Sonnet 5 .5 has all of this data that has been done based on this investigation, maybe Sonnet 5 .5 could build this for you now, and you could build this for a lot cheaper.
than if you were running Opus the whole time. So those are a couple of things that I wanted to talk about. I will link all of this in my FreeSchool community and I will drop this repo in the description of this video if you wanna check it out.
You could also just Google search for it or go on X and it will probably be the first thing you see. So anyways, now what I think is interesting about this is a couple of things. When I gave two different coding agents the same prompt, except for one of them used the repo and one of them didn't, the one that didn't use the repo always finished first, but the one that used the repo finished slower, but was much better results.
Because like I said, they were able to use these frameworks inside of the REA repo that understand how to break things down a little bit better. It's this whole REA investigation flow, which is what makes this so popular, I guess.
This thing really is trending quick. It's got 192K stars. If I refresh, we're gonna go up to what?
195, 196K. And this was probably 30 minutes ago that I last refreshed this. Now, something else that I think is really interesting is Coding agents are just going to get better at this.
I think that this whole idea of reverse engineering, now that this framework has been blowing up on X, I wouldn't be shocked if the next version of Opus and Fable and Astra and Sol and the other models have this baked in a little bit better. But anyways, really cool tool. It definitely helps people that don't come from a formal...
programming or software engineering background, build things that feel a bit more professionally built. And remember, the concept of reverse engineering isn't anything new. You've probably been doing it in your workflow without even realizing it.
We're able to just basically give our agents a much more specific PRD without having to go through that painful process of building a PRD because we already have a role model that we're looking at of like, this is what we want. Now let's build it. So I hope that that all made sense.
I hope that you can now sort of think about reverse engineering in a different lens, which is it's not just about reverse engineering software apps. It's about reverse engineering processes and skills and things that are actually going on in your day -to -day or in your business. Go out there, find someone who's done something really well and proven that they can do it well.
and then understand why that worked and how it applies to your context, to your personal workflows. So that was the video for today. I hope you guys enjoyed.
You learned something new. I hope that all made sense. If it did, please give it a like.
It helps me out a ton. And as always, I appreciate you guys making it to the end of the video. And I'll see you on the next one.
Thanks, everyone.
The Hook
The bait, then the rug-pull.
A GitHub repo called Reverse Engineer Anything has been blowing up, prompting one creator to call software development itself "done." This video tests that claim across five real rebuilds and pulls out the five-step process underneath the hype.
Named ideas worth stealing.
08:01list
The Five-Step REA Workflow
- Pick a feature
- Route by build
- Summary first
- Seen, inferred, unknown
- Rebuild and test
A sequence for directing an agent to study and rebuild one specific app behavior: narrow the target to a single feature, identify the platform it's built with, read a generated summary before the full analysis, label every finding by confidence, then build and test against the findings rather than shipping on the first pass.
Steal forany brief for an AI coding agent that needs to copy a specific feature instead of guessing at an entire app
09:38concept
Seen, Inferred, Unknown
A three-way confidence label applied to every finding during an investigation, so a confirmed fact, a reasonable guess, and a genuine unknown never get treated the same way when the agent builds on top of them.
Steal forany AI research task where guesses need to stay clearly separated from confirmed facts before you build on them
How they asked for the click.
VERBAL ASK
04:53link
“the link for this will be down in the description”
A free, unrelated product (the Scrollcraft website-design skill) is pitched mid-video, then the creator explicitly says "let's get back to the video" to resume the main topic without losing the thread.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
AFFILIATECommission earned if you click.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
