Problem
Leadtype supports config-free generation fallbacks, but the recommended quickstart and leadtype init scaffold a comparatively large docs.config.ts for a one-page local docs site. The generated config requires users to understand navigation and the full llms.sections block model before they have written meaningful content.
That is the wrong point in the adoption curve to expose those controls. Blume demonstrates the value of an opt-in configuration model: defaults get a useful result running immediately, while explicit configuration remains available when a team needs curation.
Leadtype should keep its stronger agent and supply-chain model while reducing the amount of authored configuration on the common path.
Proposal
Make the single-repo local-docs path useful with either no config or a very small config:
import { defineDocsConfig } from "leadtype";
export default defineDocsConfig({
product: {
name: "Acme",
tagline: "Acme does one useful thing.",
},
});When values are omitted, derive sensible defaults from existing sources of truth:
- product name and tagline from
package.json where available;
- docs inventory and nested fallback navigation from the content tree/frontmatter;
- a useful
llms.txt overview and starting-points section from product identity plus resolved navigation;
- standard agent surfaces, output locations, and lint behavior from documented defaults.
Explicit navigation, llms.sections, product metadata, and every advanced option must continue to override the derived result.
CLI and docs changes
- Make
leadtype init emit the smallest stable config that still adds value.
- Move the full
llms.sections block model out of the first-screen quickstart and into customization guidance.
- Show a clear progression: zero config → basic identity/navigation → advanced agent surfaces → multi-repo orchestration.
- Add a command/output mode that shows which values were inferred and how to make them explicit.
Guardrails
- Derived navigation must be deterministic across machines.
- Primary agent entry points should not depend on arbitrary filesystem ordering.
- Inference must never overwrite or rewrite authored config.
- A warning should explain when inference is lossy or ambiguous and point to the explicit field.
- This issue should not turn Leadtype into a rendered site framework; host UI ownership remains unchanged.
Acceptance criteria
Problem
Leadtype supports config-free generation fallbacks, but the recommended quickstart and
leadtype initscaffold a comparatively largedocs.config.tsfor a one-page local docs site. The generated config requires users to understandnavigationand the fullllms.sectionsblock model before they have written meaningful content.That is the wrong point in the adoption curve to expose those controls. Blume demonstrates the value of an opt-in configuration model: defaults get a useful result running immediately, while explicit configuration remains available when a team needs curation.
Leadtype should keep its stronger agent and supply-chain model while reducing the amount of authored configuration on the common path.
Proposal
Make the single-repo local-docs path useful with either no config or a very small config:
When values are omitted, derive sensible defaults from existing sources of truth:
package.jsonwhere available;llms.txtoverview and starting-points section from product identity plus resolved navigation;Explicit
navigation,llms.sections, product metadata, and every advanced option must continue to override the derived result.CLI and docs changes
leadtype initemit the smallest stable config that still adds value.llms.sectionsblock model out of the first-screen quickstart and into customization guidance.Guardrails
Acceptance criteria
navigationorllms.sections.leadtype initemits a materially smaller starter config.