The note system that finally made my bot projects move

Why hello Reader,

Have you ever fixed a bot bug, felt like a genius for twelve minutes, then hit the same problem again two weeks later and realized you remember nothing?

Yeah. Same.

I’d hit a bug, or want to add a new behavior. I’d go hunting for an answer, fix it, and move on.

But I didn’t really own the idea.

So when the same problem came back, I couldn’t explain it. I couldn’t reuse it. I couldn’t even guide Claude cleanly.

I’d end up relearning it. Again.

It wasn’t that I lacked information. I had plenty.

I had a retention and reuse problem.

So here’s the behind the scenes system I use to research, retain, and actually reuse what I learn while building bots.

Just in time learning, not just in case

I’m a big believer in just in time learning.

If I learn something inside a project, apply it immediately, and see it change bot behavior, it sticks.

The missing piece is keeping that learning reusable later, without hoarding links like a squirrel hiding chestnuts.

This system has three parts. Each one does one job.

1. Capturing ideas while I’m learning

Most of my input comes from YouTube, articles, newsletters, and papers.

I use Readwise Reader to highlight moments that make me stop and think.

If I can picture using it in a bot, I tag it.

2. Resurfacing ideas so they don’t disappear

Highlights alone aren’t enough. If I never see them again, they might as well not exist.

The main Readwise app (referral link) brings those highlights back over time using spaced repetition.

When I see an idea outside the original context, I can ask, “Is this still useful?”

If yes, it moves forward.

3. Turning highlights into reusable knowledge

This is where Obsidian comes in.

Obsidian is plain markdown files with a nice interface. No lock in. No weird ecosystem.

When a highlight graduates into Obsidian, I do one thing that matters most.

I rewrite it in my own words.

That act of writing is where the learning actually sticks.

It’s tempting to paste a highlight into Claude and ask for a summary. I don’t recommend doing that first.

If I use AI here, it’s after I write my version.

I’ll ask, “Here’s how I understand this. Did I miss anything important?”

Then I compare. Sometimes I steal a clearer phrase. Sometimes I ignore it. The note still stays mine.

Why this matters for building bots

Because these notes don’t just sit in Obsidian.

They’re plain text, which means I can:

• Drop them into a project folder
• Feed them to an LLM as context
• Reuse them when designing new behaviors
• Link ideas together like a private wiki

Over time, this becomes a working memory for my projects.

A system that makes my bots move.

You can check out my showcase of my system below

🛠️ Workshop.log

⌨️ Next Commit

​Princess-Mika-Test dropped a proxy hatchery in PiG_Bot’s natural wall, somehow calculating where the wall would go on any particular map blocking production and allowing a Zerg rush 😑

What I’d try next:

• Send a single probe to defend the spot until it’s time to build. Downside though is this will keep a mining probe occupied, leading to loss mining time, for something that might happen
• Send all my probes down to attack the hatchery as a response—this could also work against planetary rushes. Yes, still loss mining time but they would lose the hatchery resources

What do you think?

▶️ In the loop

​

Stop Debugging Your SC2 AI the Hard Way

One of my biggest pains in building a bot is … yea you guessed it debugging. But you don’t have to suffer like I did. I walk you through this new plugin lets you see your bots thinking and help you spot issues faster

​​

​

May the Bugs Be Ever In your Favour🪲

Email Preference:​
​Unsubscribe | Update your profile | 600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246