New organization: Docs-as-Code Toolkit — does the world really need this?

[dieterbaier]

🚀 New organization: Docs-as-Code Toolkit — does the world really need this?

Short answer: probably not.

Long answer: I built it anyway.

---

Over the past weeks, I realized that I’m no longer working on “a few repos”.

What emerged instead is a small but growing ecosystem around a simple idea:

Treat documentation like software.

👉 You can also check my article on dieterbaier.eu (German)

---

🧠 Why this exists

Documentation projects often suffer from:

• "works on my machine"
• inconsistent tooling
• fragile pipelines
• disconnected content

I got tired of fixing the same problems again and again.

So I started putting things together:

• a reproducible Docker-based toolchain
• reusable AsciiDoc styling
• structured architecture knowledge assets
• ideas for automated linking and traceability
• and a real-world example tying it all together

---

🧩 What you’ll find here

This organization bundles these pieces into one place:

• docs-as-code → entry point and overview
• docs-toolbox → reproducible build environment
• architecture-knowledge-toolkit → semantic contracts, metadata conventions, templates, traceability, review workflows, and AI-assistable architecture work
• profile → real-world usage (website, CV, architecture docs - Personal Profile of Dieter Baier, the creator of this organisation)
• more to come (generators, styling, etc.)

---

Relationship to docToolchain

This project is not intended to compete with docToolchain.

docToolchain is a mature Docs-as-Code toolchain for building, converting, publishing, and integrating technical and software architecture documentation.

The Docs-as-Code Toolkit focuses on the layer above publishing: reproducible source workflows, structured architecture knowledge, metadata, traceability, reviewability, and automation-friendly conventions.

Both approaches can be combined. This toolkit can provide structured AsciiDoc sources and metadata, while docToolchain or similar tools render and publish the resulting documentation. At the same time, the docs-toolbox provides the necessary tools for local and CI-based rendering.

In short: we operate one layer above publishing.

---

🤔 Do we need another “Docs-as-Code” approach?

Maybe not.

But I believe we need:

• simpler setups
• more reproducibility
• less friction
• and better connected documentation

---

💬 Let’s talk

I’d love to hear:

• how you approach Docs-as-Code
• what annoys you most in documentation workflows
• what you would automate if you could

---

This is very much work in progress.

Let’s see where it goes.