Proof of Value
If you want to know whether mdt is solving a real problem, this repository is the best example.
The project already uses source blocks from .templates/*.t.md to keep repeated content synchronized across multiple surfaces:
- root and crate READMEs
- crate-level Rust docs
- mdBook pages
That is the core value proposition in one repo: write shared content once, then fan it out wherever people actually read it.
1. README synchronization
The source block mdtCliUsage lives in .templates/overview.t.md.
It is consumed in multiple README-style surfaces:
That means the command list and diagnostics workflow stay aligned without copying edits by hand.
2. Source-doc synchronization
The source block mdtLspOverview also lives in .templates/api-and-install.t.md, but it fans out into both markdown and Rust source docs:
The source file uses a transformer chain so markdown content becomes Rust crate documentation comments:
#![allow(unused)]
fn main() {
//! <!-- {=mdtLspOverview|trim|linePrefix:"//! ":true} -->
//! <!-- {/mdtLspOverview} -->
}
The same pattern is used for:
This is the practical payoff: you do not maintain one explanation for README readers and a second explanation for API docs readers.
3. Docs-site synchronization
The mdBook docs also consume shared source blocks.
For example, mdtInlineBlocksGuide is reused in more than one docs page:
This keeps the conceptual explanation of inline blocks consistent across both a reference page and a guide page.
Why this matters
Without mdt, these edits drift in predictable ways:
- the README gets the newest wording
- the source-doc comment keeps an older explanation
- the docs site uses slightly different examples
- command lists diverge across pages
With mdt, one source update can refresh all of those targets in one run:
mdt update
mdt check
What to look at in this repo
If you are evaluating adoption, inspect these files together:
Shared sources
.templates/overview.t.mdand.templates/api-and-install.t.md
README targets
Source-doc consumers
Docs-site targets
The shortest convincing story
A good way to describe mdt to a teammate is:
We keep a few pieces of documentation repeated across our README, crate docs, and docs site.
mdtlets us define those pieces once, reuse them everywhere, and verify in CI that they never drift apart.
If that story matches your project, the tool is probably worth trying.