Add blog post: What It Looks Like When Your Docs Keep Up With Your Product

src/content/blog/technical/how-teams-keep-docs-up-to-date-with-promptless.mdx

@@ -0,0 +1,67 @@
+---
+title: What It Looks Like When Your Docs Keep Up With Your Product
+subtitle: Published March 2026
+description: >-
+  Three real workflows from teams using Promptless that show what changes when
+  your tooling handles detection, context gathering, and the first draft.
+date: '2026-03-26T00:00:00.000Z'
+section: Technical
+hidden: false
+---
+import BlogRequestDemo from '@components/site/BlogRequestDemo.astro';
+
+What does it look like when your docs keep up with your product, without you
+spending half your day hunting for what changed?
+
+Most docs tools solve distribution. They give you a nice site, interactive API
+explorers, maybe a search bar that works. That's real value, but it assumes the
+hard part is presentation. The actual hard part is knowing what needs to be
+written and keeping it honest as the product moves underneath you. That is the
+work that eats your week, and that is the problem we built Promptless to solve.
+
+We have been working with teams like Helm, Vitess, Basis, and Vellum over the
+past few months, and there are three workflows that keep surprising me with how
+much they change the shape of a writer's day.
+
+The first is just eliminating the classic "I didn't know that changed" problem.
+Many of our customers love the awareness Promptless gives them of what changed,
+and how it changed. Promptless watches every PR across their repos, and when an
+engineer changes how auth works or deprecates a parameter, the tech writer does
+not find out from a support ticket three weeks later. A writer gets a drafted
+update with citations back to the PR, the relevant Slack discussion, the
+engineer's own description of the change. Review it, ask Promptless for changes,
+manually edit it, published. The feedback loop between code change and
+doc update collapses to hours.
+
+The second is something Basis is doing that (completely unexpected to me)! They
+dump their customer call transcripts into a Git repository, and Promptless
+monitors that repo and maintains internal documentation around what all their
+customers are doing, what they are asking about, what keeps coming up, how the
+product is actually being used out in the field. An internal knowledge base that
+builds itself from conversations, and because it lives in their own repo in a
+format they control, they are building all kinds of internal agents to make use
+of it. They would get way less value from throwing all that data
+into a third party system and hope third party agents can do something useful
+with it.
+
+The third is about scale. Helm had community translations of their docs across
+ten languages, but most were incomplete or out of date, and would be a big ask
+for their writers to bring them all current by hand. So two writers spent about
+five iterations over eight hours "teaching" Promptless how to do the work (its
+just skills, which if you read this blog you know is just another kind of docs).
+They started with a style guide which was not good enough. But they got feedback
+in about 35 minutes, so they iterated and fixed the problems. They added a
+glossary, then more language-specific instructions for how to handle existing
+translations, keep what was still good, update what had drifted, and fill in the
+gaps. By the end of that process the writers had 10 playbooks that Promptless
+could execute for 10 languages over the 110 pages of Helm V3 docs. So in one
+day, 10 PRs opened. Then over the next three weeks the community reviewed and
+merged them one by one. Pretty clever use case we didn't build for.
+
+This is what's possible when your writers have a power tool that rewards
+the craft, not just a platform that makes things look nice.
+
+If you want to see what this looks like for your team, book a quick 15-min demo
+with one of our engineers. 30-day free trials!
+
+<BlogRequestDemo />