You are about to build something new.

A new capability. A new bot. A new repository.

That moment carries weight. A blank repository is full of possibility, but it is also full of decisions. Folder structure. Naming conventions. Documentation. Guardrails. What belongs where. What future contributors will expect.

Without guidance, technical debt does not appear later. It starts immediately.

BotBot exists to make that first step lighter and the long term outcome stronger.

What BotBot really is

BotBot is the bot we use to build bots.

It scaffolds a clean, standard repository layout. It generates the essential assets that every serious bot should have. It installs shared helper files that prevent teams from reinventing the same utilities over and over.

But it does not stop there.

BotBot is designed to be repeatable. As standards improve, as patterns mature, and as the platform evolves, you can run BotBot again to bring your repository forward. Templates improve. Helper assets update. Conventions tighten. Your bots do not drift.

This is not just scaffolding. It is a baseline that evolves with you.

Starting well matters more than starting fast

Many developers are new to structured bot development. When there is no clear baseline, each repository becomes an experiment. Folder structures vary. Documentation is partial. Helper code is copied from wherever it was last seen.

Nothing looks obviously wrong at first. Over time, review friction increases. Onboarding slows. Agents struggle to interpret intent. Small inconsistencies compound.

BotBot changes the default.

When you create a new bot using the New Bot Setup path you can bring BotBot into that moment. Instead of improvising structure, you inherit a known good foundation. The repository starts organised. The intent is explicit. The conventions are visible.

You are free to focus on capability rather than housekeeping.

Agent ready from day one

Developers are increasingly working with agents inside their IDEs. Code review, refactoring, explanation, generation. All of it depends on the repository being legible.

BotBot scaffolds assets such as AGENTS.md and ensures a predictable repository structure so that agents have clear instructions and a consistent map to follow.

An agent can only be as effective as the context it is given. A well structured bot repository is not cosmetic. It directly affects how safely and productively developers can collaborate with automation.

BotBot makes that structure the default rather than an afterthought.

Golden paths, not guesswork

BotBot also includes the Paths metamodel.

This is significant.

The Paths metamodel allows you to define golden paths inside your bot. Not loose documentation. Not tribal knowledge. Structured, versioned guidance that shows other developers how to use, extend, and operate the capability correctly.

Instead of telling someone how a bot should be used, you model the path. You make the right way visible and repeatable.

As more teams build bots, this becomes critical. Consistency is not enforced through policy. It is encoded into the platform.

What you get when you install BotBot

When you install BotBot from the Marketplace, you are installing more than a template.

You receive a structured repository layout, core documentation assets, shared helper files, scaffolding pipelines, and the Paths metamodel. Together they form a baseline for building bots that are consistent, reviewable, and maintainable.

It is a small install with long term impact.

Where to next

If you are creating a new bot, start with BotBot.

Use it in the New Bot Setup path. Scaffold your repository properly. Define your golden paths. Keep your structure aligned as BotBot evolves.

Starting something new always carries cognitive load. BotBot removes the unnecessary part of that load and lets you focus on what actually matters.

Build the capability. Let the baseline take care of itself.