Adopt an existing content library

Use contentbit adopt before adding Contentbit to an established project. It scans Markdown, reports the current health findings, infers a link-resolution strategy, shows locale coverage for stable page keys, and prints setup files to review. It never writes source files or configuration.

contentbit adopt "content/**/*.{md,mdx}" --dry-run

With no glob, adoption looks for content/**/*.{md,mdx} from the current directory. Pass explicit globs when content lives elsewhere:

contentbit adopt "docs/**/*.md" "blog/**/*.mdx" --json

What adoption infers

• frontmatter coverage for slug, key, locale, titles, descriptions, and declared linksTo relationships
• a link strategy: global slugs, same-locale slugs, or locale-aware stable keys
• locale coverage for every key that has localized pages
• observed type values, common sections, and consistently present frontmatter as baseline SEO contract proposals

The terminal report includes a suggested contentbit.config.ts, high-confidence per-file frontmatter additions (a slug and title only when absent), and a reviewable contentbit.seo.config.ts baseline when pages use type. The baseline only includes observed common requirements; decide stricter section and block requirements with the people who own the content.

Review the integrity report

Adoption uses the same scan as Doctor and Studio. Before accepting the config proposal, review duplicate titles and descriptions, missing or multiple H1s, heading-level jumps, local route or Markdown links that do not resolve, and locale/key coverage findings.

After you create and adapt the proposed config, run the normal daily loop:

contentbit doctor --watch

The watch session reruns Doctor after changes in the directories that supplied the initial scan. Use ordinary contentbit doctor --strict-warnings in CI.