# Documentation Prompts Are Documentation Assets Governed Like Code A prompt that generates documentation, and that more than one person runs more than once, belongs under the same version control, review gate, and ownership as the documentation it produces. Burkes' prompt repository at Deutsche Bank (00:08:51) does this literally: each prompt is a markdown file with a description and usage instructions (00:14:43), additions enter by pull request, and each gets reviewed and tested before it's shared (00:10:21). She names the model at 00:09:36: treat prompts like docs-as-code, curated, versioned, reviewed. > [!quote] [00:09:36] > It works by treating docs by treating prompts like docs as code. So they're curated, they're versioned, they're reviewed. The ungoverned state she replaced had four stacked problems (00:06:40 to 00:08:07): everyone was ad hoc prompt engineering, nobody saved or shared prompts, results were inconsistent within and across teams, and the same documentation conversation with an agent recurred every 2 to 4 weeks. Her diagnosis at 00:08:07 is no governance and no shared institutional knowledge of how anyone used AI. The output is a first draft, not a final document (00:10:21), so review gates both the prompt and its output. The acceptance test is cross-repository consistency, not one good draft. She tested each shared prompt across 3 or 4 repositories building different products (00:21:11), and the oracle is the section structure a docs-as-code writer already knows a document of that type should contain (00:21:54). The portability rule that makes the test passable: no repository-specific information in a shared prompt; team-local prompts may carry it (00:22:36). Five personas organize the folders (developer, product owner, new joiner, two support tiers), chosen by who lacks codebase access and who is most starved of documentation (00:23:19). Style guides are a separate prompt class (developer, internal, external) that composes with any content prompt (00:13:12). Where it breaks. Throwaway exploratory prompts don't qualify; the rule is for reuse. A PR gate with no checklist is a formality, and the talk never publishes its review criteria. Testing is "trial and error" and different models shift the output (00:21:54), so a test run has to fix the model version or it measures drift instead of the prompt. Domain-specific content, regulatory vocabulary in a bank for instance, may make a repository-agnostic prompt too generic to be useful. The talk has no outcome data: no prompt count, no team count, no time saved. And a prompt that reads everything on main (00:25:26) and emits dependency maps with system names and addresses (00:15:28) needs a secrets-and-endpoints check in review, not just a prose check. <!-- atomicity: 1 idea ✓ --> ## Why This Matters Pick one documentation prompt you've pasted twice. Strip every repository identifier, run it against three codebases you have access to, and compare the section structure of the three outputs. If it holds, file it under version control with a one-line review note. That's the whole governance move, and it works in any IDE. ## Links - [[3. Resources/Permanent Notes/A Vetted Prompt Is a Starting Point to Refine Not a Finished Answer]] — contrasts: that note treats the library prompt as a baseline to iterate from; Burkes' shared prompt is a finished, tested asset whose refinement goes back through review. - [[3. Resources/Permanent Notes/AI Documentation Pipelines Need an Explicit Authority Source]] — extends: her repository declares source code on main as the source of truth (00:09:36, 00:25:26), which is the authority rule that note asks for, at the cost of ingesting unreleased work too. - [[3. Resources/Permanent Notes/Spec-Driven Development Turns Throwaway Prompts Into Durable System Memory]] — extends: same move one layer down, keeping the prompt itself as the versioned artifact instead of converting it to a spec. - [[3. Resources/Permanent Notes/Prompt Rules Decay With Model Versions Date Every Never]] — constrains: a governed prompt still decays per model release, so the cross-repository test has to rerun when the underlying model changes. - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — applies-in: the talk's answer to "will writers have jobs" is that the job moves from writing words to owning the prompts, review, and test that produce them. - [[3. Resources/MOCs/Events/Write the Docs Berlin 2026 MOC]] — applies-in: the conference map; Raleigh's judgment lanes are the human side of the same pipeline. - [[3. Resources/MOCs/Documentation & Technical Writing MOC]] — applies-in: the docs discipline map, "docs that agents read" cluster ## Source - [[3. Resources/Readwise/Articles/Writing Less, Owning More The Shift in Technical Writing - Whitney Burkes|Writing Less, Owning More: The Shift in Technical Writing - Whitney Burkes]] - https://www.youtube.com/watch?v=boZPKjyq7bw