A fresh project starts with an empty head. aide records the architectural decisions a codebase has made, so a session and every agent in it argue from the same facts. But on day one there are no decisions, and you're back to either re-litigating the same conventions you settle on in every repo, or letting the agent quietly invent its own.
Blueprints are the fix: curated bundles of best-practice decisions you seed a project with in one command.
aide blueprint import go
That drops a set of idiomatic-Go decisions straight into the project's store: error handling, context use, table-driven tests, slog, golangci-lint, and so on. From that point they behave exactly like decisions you recorded by hand. They're injected into every session's context and enforced by all agents, so the conventions are present before the first line is written rather than discovered halfway through review.
Composable, not monolithic
The thing I like most is that blueprints stack. A blueprint can include others, so they compose along the grain of how projects are actually built:
# go, plus the CI/CD practices, plus the universals they both build on
aide blueprint import go-github-actions
go includes general (commits, PRs, dependency hygiene, secrets), general includes the documentation core, and go-github-actions layers the CI specifics on top. You ask for the leaf you want and the chain underneath comes with it. No copy-paste, no drift between a dozen repos that all meant to follow the same rules.
It detects what you're building
You don't even have to name them. --detect reads the project's markers and imports what fits:
$ aide blueprint import --detect
Detected: go, github-actions, go-github-actions
general 5 new
go 18 new
github-actions 7 new
go-github-actions 5 new
35 imported, 0 updated
A go.mod triggers the go pack; a .github/workflows/ directory triggers the github-actions label; the two together resolve the compound go-github-actions blueprint. It runs on the same project-marker index the grammar system uses, so a custom marker in your own .aide/grammars/ can trigger an org-specific blueprint automatically. Bootstrapping the house style across a fleet of repos becomes one command per repo.
Versioned, and it knows what it set
Seeding state is easy; keeping it honest later is the part that usually rots. Blueprints carry a version, and an import is careful about what it touches. Anything you set by hand is left alone. A decision a blueprint set earlier is upgraded only if the blueprint's version is newer and the content actually changed. Every imported decision is stamped decided_by: blueprint:<name>@<version>, so you can always tell the curated baseline from the calls you made yourself.
That provenance is what makes the whole thing safe to re-run. aide blueprint import --detect on an existing project is a no-op where nothing moved and a clean upgrade where the upstream advice improved, and it never quietly overwrites a decision you made deliberately.
Roll your own, share them across the team
The shipped blueprints are a starting point, not the ceiling. A blueprint is just a JSON file of decisions, so the more interesting use is writing your own: your team's conventions, the house style, the "we always do it this way, and here's the reasoning" rules that currently live in a wiki page nobody reads twice. Drop one in .aide/blueprints/ to override a shipped blueprint locally, or publish a whole set for everyone.
Sharing is deliberately boring. A registry is just a base URL that serves <name>.json files, so any static host works: an internal web server, an S3 bucket, a GitLab repo on the intranet. Point a project's config at it once,
// .aide/config/aide.json
{ "blueprints": { "registries": ["https://blueprints.corp.internal"] } }
and aide blueprint import acme-standards pulls your org's rules exactly the way go pulls the built-in ones. (There's a --registry= flag for one-offs, and you can import a bare URL too.)
The point, for a team, is that "the way we do things here" stops being tribal knowledge you hope new hires (and their AI assistants) absorb by osmosis. Write the guidelines, styles and general rules down once, host them where your devs already have access, and aide injects them into every session, so every human and every agent on the project works from the same rules without anyone having to remember to bring them up.
Why bother
The honest value isn't the import command, it's the curation. Writing down "use errors.Is, not string matching" once, well, with the reasoning attached, and then having it apply to every Go project you or an agent ever touch, is a different thing from remembering to say it each time. The blueprint is the decisions; the command is just how they arrive. Repo and the full blueprint list are on GitHub.