entwineOpen source / Experimental 0.1.0
Project knowledge,
connected.
Turn the Markdown in your repository into navigable documentation, relationships, graphs, backlinks, validation, and structured context.
Read the documentationSee a live exampleOpen a project graph
Both sites are generated by Entwine from plain Markdown. Your Markdown remains the source of truth.
Project knowledge is fragmented.
It is spread across the README, docs, architecture notes, state files, decisions, specifications, and agent context. The connections between them disappear, and every newcomer, human or agent, reconstructs the same facts again.
Entwine follows the links you already write and turns the Markdown in your repository into one shared model of that knowledge.
Markdown
↓
Knowledge model
↓
Docs + Graph + ContextA convention for durable project knowledge.
Recommended, not required. Any Markdown still works. Custom filenames work too: a type in frontmatter is enough.
docs/
├── index.md what this is, where things are
├── architecture.md how it is structured today
├── state.md what is true right now
├── roadmap.md what is intended next
├── decisions/ what was decided, and why
└── specs/ what capabilities dostate is current reality; roadmap is future intent. Entwine recognizes each by path or metadata and shows which areas exist: presence, never a quality score. It complements README.md, AGENTS.md,SKILL.md, MCP, and OpenSpec instead of replacing them.Read the convention.
Humans and agents share one source.
The same Markdown feeds readable documentation with backlinks, a project graph, and a Knowledge overview for people, and structured context for agents. A tool can ask for the current state or the architecture directly instead of guessing which file to open.
entwine context --json labels every document with its role: architecture, state, roadmap, decision, spec, or other. There is no second parser, and no AI inside Entwine.
See it in the demo project: itsKnowledge overview shows what exists, and its graphshows how it connects.
Start here.
No account, documentation app, or configuration file.entwine build remains available for any custom hosting.
Entwine 0.1.0 is not published yet. Until its first release, build from a source checkout with Rust stable. Releases will provide npm install --global @entwine/cliand checksummed binaries onGitHub Releases.
entwine init- Scaffold the recommended project knowledge. Questions, not answers.
entwine dev- Read it locally. Rebuilds when Markdown changes.
entwine check- Validate links and metadata, and see which knowledge areas exist.
entwine setup- Automate validation and publishing with your Git provider.
# From a source checkout of Entwine
cargo install --path crates/entwine-cli
# In your own repository
entwine init
entwine dev
entwine check
entwine setup
# Or publish dist/ yourself
entwine buildLocal preview at localhost:4173. Refresh after edits.
Publish where your repository lives.
entwine setup generates validation and publishing for your Git provider, once. After that, the provider's own pipeline publishes. Entwine is not a hosted platform and stores no credentials.
- GitHub
- GitHub Pages
- GitLab
- GitLab Pages
- Bitbucket
- Provider-native static publishing
- Any Git
- dist/ on any static host
Documentation changes in a pull request are validated before merge. Existing CI is never overwritten, andentwine setup --dry-run changes nothing.Deployment details, including Bitbucket's one-time steps.
Small by design.
Clear at the boundaries.
Parse once, project many ways
A Rust engine compiles Markdown into one canonical knowledge model. Site, graph, and context all derive from it. The renderer is not the knowledge model.
Repository-native and stack-agnostic
Your application can use any language or framework. Generated documentation is static HTML and CSS, with no Entwine runtime in production.
Predictable, inspectable output
File-based routes. Stable ordering. Automatically derived backlinks. A linked SVG graph. Markdown or JSON context. No AI inference or network requests during builds.