1 min lesson
Support owns the docs - no over-the-fence handoff
Use "Keep the docs reopened in your Cursor instance and the writer handoff disappears" to describe the practical rule.
Step 1 of 2
Support owns the docs - no over-the-fence handoff
The old loop was slow: support spots a doc gap, logs a ticket, and a technical writer eventually picks it up. With the docs open in their own Cursor workspace, a support engineer can check whether something is documented, make the change, render the doc site to review it and open a PR - all off the same customer interaction. Updating docs is low-risk, high-agency, high-impact work, and it builds a tight feedback loop where the docs improve continuously based on what support actually hears from customers.
Keep the docs reopened in your Cursor instance and the writer handoff disappears - you ship the fix from the same interaction that surfaced it.
"It removes that sort of like fence in the middle... they can go and update the docs pretty much directly based off of a Cursor interaction."
Learn more
Full explanation
Guard knowledge-base quality on the intake side
Guard knowledge-base quality on the intake side
AI-generated content can quietly rot a knowledge base with slop - ancillary comments that explain the model's thinking but add nothing long term. Cursor keeps a team command called de-slop for exactly this: stripping the AI artifacts they don't want. For a KB, the instruction is to be verbose only where it earns its place and concise everywhere else. The preferred fix is a guardrail at intake, when someone submits a change, rather than auditing already-published content after the fact.
A standing team command removes the AI cruft, and the quality gate sits where changes enter - not as a post-hoc review of what's already live. A background agent can sweep the KB for improvements, but intake guardrails do more to keep it clean.
"We have a team command called de-slop which is our term for like getting rid of AI things that we don't necessarily want."
Because Cursor changes weekly, a doc that was right last month can be the thing that confuses a user today. A wrong doc is worse than no doc, because the user follows it, fails and files a more frustrated ticket. Treat doc freshness as part of every release: when a feature changes, the article changes with it.
When asked how you'd reduce ticket volume, don't say "write more docs." Say how you'd find what to write: "I'd cluster the last month of tickets, find the tallest cluster with no good article and write a symptom-first KB with an escalation path - then watch whether that cluster shrinks." That closes the loop and shows you measure deflection, not output.
Learn more
Optional practice