A Prompt Cheatsheet for Your Knowledge Base and Feedback
Two surfaces in your product are quietly going stale right now. One is the knowledge base — eleven articles, nine of them written in a single Saturday burst eighteen months ago. The other is the feedback you have collected: forty-odd responses, of which you have properly read maybe twelve. Neither is broken. Both are out of date, and out of date is worse than empty. An empty help centre sets no expectations; a stale one tells a customer, confidently and in your own brand colours, something that stopped being true in March.
The reason is not laziness. Both are maintenance surfaces, and maintenance work has no trigger. A ticket arrives and demands an answer. An error fires an alert. Nothing whatsoever happens when an article goes stale or a piece of feedback goes unread — which is exactly why nobody does it. Real work, real payoff, and no moment in the week when it becomes urgent enough to displace shipping.
What changes the economics is an assistant that has already read all of it. Once your helpdesk is wired into your editor over MCP, both stop being dashboards to visit and become things you ask questions about between commits. Here is the cheatsheet: finding what is missing, writing it, keeping it true — and then the other half, asking for feedback, reading it, and answering it.
Finding what is missing
Nobody writes good documentation from imagination. You write it from the thing you just typed by hand for the third time, which is why every prompt here points at real threads rather than at your idea of what people ask.
What are people asking in tickets that the knowledge base does not answer?
Which questions have we answered by hand more than twice? Rank them.
Group the last fifty tickets by topic. Which topics have no article?
Which of the longest threads were documentation problems rather than bugs?
Notice that none of these ask for an article. They ask for a list, because the gap analysis and the writing are different jobs, and doing both in one pass gets you four mediocre articles instead of one good one. Read the list, cross off the two that are really bug reports, and write the top item.
Helmdesk runs a KB Gap Analysis automation that does this on a schedule and files drafts into a review queue. The prompts above are the on-demand version, and the difference is real: the scheduled one catches drift you would never have gone looking for, the manual one lets you say ignore billing, I know about billing.
Search before you create
This is the single most valuable habit in the whole cheatsheet, so it gets its own section: every prompt that creates an article should begin by searching for one.
A near-duplicate article is worse than a missing one. Two articles half-covering "why did my export fail" split the ranking between them, so the search box surfaces whichever scores marginally higher and the reader gets the half that does not mention their case. You have not added coverage, you have added noise — and search, the thing that had to work, is precisely the thing you broke.
Turn the resolution on ticket 41 into an article — check for a duplicate first, leave it a draft.
Search for anything about webhook retries first — if there's a near match, update that instead.
What have we written that is still sitting in draft?
Draft this, then show me the two closest existing articles so I can decide whether to merge.
Two mechanics matter. First, search_articles only ever sees published articles, so a duplicate hunt through search cannot see your own drafts — list_articles includes them, and it answers "what did I forget to publish". Second, create_article defaults to draft, and that default is right. Publishing is a deliberate second step, because the published article is what your help centre hands a stranger with no context, and an agent writing docs unsupervised produces prose that is fluent, plausible and occasionally wrong.
Keeping it true
Articles do not rot evenly. They rot at the numbers — the fourteen-day window that became thirty, the plan name you changed, the menu path through a settings page you redesigned in the spring. Everything around those numbers stays perfectly accurate, which is what makes the wrong bit so convincing.
The refund window changed from 14 days to 30. Find every article that says 14 and fix it.
We renamed Projects to Workspaces. Find every article using the old name and update it.
Read this article against the current code in this repo and tell me what is no longer true.
This ticket contradicts our own docs. Which one is wrong?
The last two are worth stealing. Reading an article against the code that implements it is something only an assistant inside your repo can do, and it catches the drift that re-reading never will — the article reads fine, it is the product that moved. A ticket contradicting your own docs is a free audit: a customer already did the work of finding the stale paragraph.
One caution: update_article replaces the body rather than merging, so a fix-every-mention prompt is a rewrite, not a patch. Read the first two before you let it run through twenty.
The feedback half
Feedback has the same shape as documentation. Collected in a burst, genuinely valuable, read approximately never. There are three moves — asking, reading, answering — and most teams do the first, skip the second entirely, and are astonished that the third never happens.
Asking
Who closed a ticket recently and has never been asked for feedback? Draft a request each — show me first.
Ask last month's cancellations what made them leave. Draft the wording first.
Which feedback requests have we sent that nobody ever answered?
request_feedback emails the customer the moment it runs — it is one of the ten tools that reach a real person. Write the checkpoint into the prompt itself, draft, show me, then send, rather than trusting yourself to interrupt.
Reading
Summarise last quarter's feedback into themes, ranked by how often each came up.
Show me every response rated 3 or below, next to what the ticket before it was about.
Which feedback mentions something we already have an article about?
That last one joins the two halves of this post: a complaint about something already documented is not a product problem but a discoverability problem, and the fix is a link in an email template, not a sprint.
Answering
Draft a reply to this feedback conversation telling them what shipped since. Show me first.
Close every feedback conversation we've already answered elsewhere.
Replying to a feedback conversation emails the customer with a link back to the thread, exactly as a ticket reply does. Closing one emails nobody. Know which is which before you hand either to an agent working through twenty of them.
Fifteen minutes, not a project
Honestly: with four articles and six pieces of feedback, skip the cheatsheet and read them yourself over coffee. This starts paying when you can no longer hold the whole corpus in your head — somewhere around thirty articles or a hundred responses — which is also, conveniently, the point where you stopped reading it.
The gap analysis is a Monday question. The staleness sweep is fifteen minutes after any release that changed a number. The feedback read is monthly. That is the whole habit, and it works because you are not confronting a dashboard full of things you have not done — you are asking one question and getting one answer.
A knowledge base is not a pile of articles. It is a promise that what you wrote down is still true, and the only way to keep that promise is to make checking it something you can do in a sentence.
A knowledge base your assistant can read, search and fix
Hosted help centre, feedback conversations, and 73 MCP tools that let your editor do the maintenance you keep postponing.