When to use it
Use $adopt or /adopt after installing Blueprint into a repository with meaningful existing code. Use onboard instead for a fresh or early scaffold.
What it does
Adoption surveys the stack, routes, data model, features, tests, commands, existing Verify recipe, GitHub workflows, and conventions. It preserves the repository’s current checks, then asks focused questions about users, business intent, future direction, and ambiguous code.
It also asks whether Blueprint workflow files should be committed with the
repository or kept local through .gitignore. Committed mode is the default
recommendation because it keeps the workflow portable across machines and team
members. If local-only files are already tracked, adoption asks before
untracking them and never deletes the local copies.
Outputs
- A project plan that combines observable behavior with your stated intent
- A build plan with existing features checked and future work unchecked
- Coding standards that reflect the repository instead of template defaults
- A report of the existing testing and CI state
- A recorded Blueprint visibility choice with any approved ignore-rule changes
When equivalent automatic checks are missing, adoption points to $ci or /ci as an optional follow-up. It does not create or replace CI itself.
Review gate
The generated plans are proposals. Check feature names, shipped status, boundaries, and future order before generating the overview.
What it never does
Adoption does not rewrite the application, delete obsolete-looking code, replace CI, or merge changes. Its job is to describe the real starting point.