Как мы потеряли GitBook за 5 минут и нашли Gramax — open-source альтернативу, которую теперь используем сами

Один клик — и ваша документация может исчезнуть. Именно так и произошло с нами. Поэтому мы нашли open-source альтернативу, где данными владеем только мы — и никакой регион это не изменит.

https://habr.com/ru/articles/1019230/

#Gramax #GitBook #open_source #документация #docsascode #Markdown #Git #стартап #альтернатива_GitBook #командная_документация

Как мы потеряли GitBook за 5 минут и нашли Gramax — open-source альтернативу, которую теперь используем сами

Пишет об этом Product Manager команды: Котельникова Екатерина Андреевна. Сегодня расскажу об одном из тех моментов, которые случаются у каждой команды: ты что-то настраиваешь, радуешься, нажимаешь...

Хабр

I've been testing #zensical since I will have to migrate off of #mkdocs and #mkdocsmaterial.

Across 3 sites, I only had to change one line in the yaml files and run `zensical` instead of `mkdocs`. Total potential migration time for 3 sites, 10 minutes.

Why potential and not complete? Pending blog and OpenAPI spec support. Once those are released, I can finish testing and migrate.

@squidfunk looking good so far. Thanks!

#technology #tech #indieweb #blog #technicalwriting #docs #docsascode

"A few months into working with AI agents on a documentation project, I'd noticed some inconsistency in agent behaviors and decided to do some digging. Turns out the AGENTS.md file in our repo — the one telling agents how to behave, where things were, and what to escalate — had grown to over 800 lines, and a few people (or likely their agents) had added rules independently, some subtly contradicting each other.

The agents weren't broken. They were following instructions that didn't serve them well.

In a previous post, I argued that agent configuration files are documentation and that their formats, structures, and purposes map directly to work technical communicators already do. That post covered the what: five doc types (project descriptions, agent definitions, orchestration patterns, skills, and plans/specs) and why writers are well-positioned to create them.

This post goes further. These files are internal documentation, full stop. They encode how your team actually works. And if you don't manage them with the same rigor you'd apply to any internal doc set, they'll degrade in the same ways: outdated content, conflicting guidance, and gaps nobody notices until something breaks."

https://instructionmanuel.com/agentic-docs-are-internal-docs

#TechnicalWriting #AI #AIAgents #AgentConfigs #Documentation #DocsAsCode #LLMs #GenerativeAI #Markdown

Your Agent Configs Are Internal Docs. Manage Them That Way. | Instruction Manuel

Agentic docs are internal documentation banner

Word für Doku? Nein danke! Wir nutzen "Docs as Code" (IDE + Markdown).
Vorteile: ✅ Git-Versionskontrolle ✅ Forking & Team-Kollaboration ✅ Kein Vendor-Lock-in
Volle Kontrolle & Effizienz statt Versions-Chaos. Wie dokumentiert ihr? 👇
#DocsAsCode #IT

Indeed, we can't allow autopilot to head into a whirlwind...

"We may be doing docs-as-code, but docs are not code. Docs run on people, and people are a messy tangle of goals, skills, and emotions. When docs hit the brain, they meet varying expectations, knowledge levels, reading abilities, and needs. None of this can be reproduced or simplified to a single pattern, but good docs use structure and words wisely to produce the best possible linguistic shape that can land safely on most people’s heads. Only humans can decide whether that message is getting across in the right way.

Getting there is a balancing act between business needs, user needs, and your own. That’s the diplomatic tension that forces all good tech writers to slow down and consider all points of view in the room as if they were in the middle of a spaghetti Western standoff. Slowing down is a deliberate, necessary act in all crafts, and tech writing is no exception. No matter how fast LLMs can churn out drafts, they don’t understand the tension in tech writing, to which we’re adding AI itself as an additional consumer of docs.
(...)
The quality of the docs I produce is still high, I was saying. That’s because I’m not letting LLMs take the steering wheel, and because I’m building new habits around them: setting up guardrails, automating what can be automated, and keeping my hands on the decisions that matter. I can do that because I know what good docs look like, and because I’ve been doing this long enough to feel when something’s off. That intuition came from years of wrestling with products and watching users struggle with pages I thought were clear. AI can help me write faster. It cannot replace the slow accumulation of judgment that tells me when to stop."

https://passo.uno/real-cost-of-documentation/

#TechnicalWriting #SoftwareDocumentation #AI #DocsAsCode #GenerativeAI #LLMs #SoftwareDevelopment #AISlop #Programming #TechnicalCommunication #Documentation

The writing was always the cheap part

Last December, quite unrealistically, I took a solemn oath: I would not write again about AI for at least another year. I was growing tired with the incessant noise, the lack of stability, and the self-imposed stress of keeping up with all the attention we must spend on factoids such as how well an LLM can draw a pelican riding a bike, which bury the important aspects of our craft as if they were mere prompt flourish. With my passionate epistle, I thought I’d said all I had to say. I was wrong.

"Test your documentation site against the Agent-Friendly Documentation Spec.

Agents don't use docs like humans. They hit truncation limits, get walls of CSS instead of content, can't follow cross-host redirects, and don't know about quality-of-life improvements like llms.txt or .md docs pages that would make life swell. Maybe this is because the industry has lacked guidance - until now.

afdocs runs 21 checks across 8 categories to evaluate how well your docs serve agent consumers. 10 are fully implemented; the rest return skip until completed."

https://www.npmjs.com/package/afdocs

#TechnicalWriting #SoftwareDocumentation #AI #AIAgents #Afdocs #Markdown #DocsAsCode #LLMSTXT

afdocs

Test your documentation site against the Agent-Friendly Documentation Spec. Latest version: 0.5.0, last published: 17 minutes ago. Start using afdocs in your project by running `npm i afdocs`. There are no other projects in the npm registry using afdocs.

npm

SDD (Spec-Driven Documentation) – фреймворк для разработки технической документации в репозитории

По мере роста сложности программных систем документация становится не “сопроводительным текстом”, а инженерным активом, она участвует в принятии решений, согласовании требований, проектировании архитектуры, тестировании и эксплуатации. Однако на практике документация часто создаётся разрозненно, несколькими авторами, в несогласованных форматах. Это приводит к потере целостности и росту транзакционных издержек на коммуникации. В такой распределённой среде параллельно растёт применение AI-ассистирования при подготовке технических материалов, что повышает требования к формализации процесса и контролю качества создаваемых артефактов [1]. В программных проектах техническая документация представляет собой совокупность различных артефактов – требований, сценариев, диаграмм, описаний архитектуры и данных – распределённых между участниками и стадиями жизненного цикла. В условиях активного уточнения целей и решений, особенно на стадии исследовательско-опытных работ (research and development, R&D; далее – R&D), такие артефакты развиваются неравномерно, одни быстро детализируются и пересматриваются, другие остаются на уровне ранних гипотез. Это приводит к утрате целостности документационного контура, возникают противоречия между документами, различается уровень абстракции, дрейфует терминология, а изменения становятся трудно сопоставимыми друг с другом. Одновременно ослабевает трассируемость и затрудняется восстановление причинно-следственной цепочки “исходные данные → допущение → решение → требование → сценарий/диаграмма → проверка”, что увеличивает стоимость ревью и повышает риск ошибочных инженерных выводов [2–5].

https://habr.com/ru/articles/996526/

#техническая_документация #docsascode #SpecDriven_Documentation #спецификации #трассируемость_требований #жизненный_цикл_артефактов #критерии_готовности #управление_неопределённостью #Architectural_Decision_Records #AIагент

SDD (Spec-Driven Documentation) – фреймворк для разработки технической документации в репозитории

ВВЕДЕНИЕ По мере роста сложности программных систем документация становится не “сопроводительным текстом”, а инженерным активом, она участвует в принятии решений, согласовании требований,...

Хабр

More building with #hugo, it's not just for docs-sites, blogs and portfolios! I've been working on a project where I want to use Hugo to post a feed of in person events, so that people can add individual events to a calendar, learn about new events with RSS, etc. #events #docsascode #ssg #organizing

https://www.kevinrkuhl.com/blog/2026/02/generating-events-with-hugo/

Generating Event Feeds with Hugo

While I’ve been looking for my next professional thing, I’ve been working on a community organization side project. The idea is to support a community group with recurring events, allowing people to come together to share skills, knowledge, and build relationships. Ordinary human being stuff. But if you’ve been following my blog, you know that I have an opinionated view on social media. I’m begrudgingly planning on using Instagram to reach people, but I think that organizers and communicators should build things that are independent of major platforms. This lets you pick up and take the resources elsewhere if you need to. And when it comes to distributing information, I like platforms where people can subscribe and control how they get updates — where users pull rather than receive. This means I’m not responsible for adding or removing subscribers. You’re responsible for subscribing and filtering as a user.

Kevin R. Kuhl

Git в браузере. Расширяем возможности с помощью LFS

Привет, Хабр! Я Паша, разработчик

https://habr.com/ru/companies/gram_ax/articles/994384/

#git #libgit2 #lfs #webassembly #rust #ffi #emscripten #docsascode #opensource #localfirst

Git в браузере. Расширяем возможности с помощью LFS

Привет, Хабр! Я Паша, разработчик Gramax — Open Source платформы для управления документацией в подходе Docs as Code. В прошлой статье я рассказывал о том, как мы переводили наше приложение с...

Хабр

Как мы случайно сделали Semantic Wiki в Gramax

Всем привет! Меня зовут Катя, я развиваю Поехали!

https://habr.com/ru/companies/gram_ax/articles/993064/

#wiki #semantic_wiki #ontology #graph #knowledgebase #knowledge_management #база_знаний #управление_знаниями #управление_командой #docsascode

Как мы случайно сделали Semantic Wiki в Gramax

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для it-команд. В этой статье я расскажу, как мы решали довольно очевидную проблему связи знаний и случайно сделали штуку, у которой даже...

Хабр