KB-Grounded Answer Drafting

skill

Draft ticket answers strictly from the org knowledge base, citing the article; never invent policy.

Download .md

KB-Grounded Answer Drafting

Draft accurate replies to support tickets by pulling the answer straight from the organization's published knowledge base (KB) and citing the exact article, instead of guessing at policy.

When to use

  • A customer ticket asks a question that a KB article likely already answers (refund windows, feature limits, setup steps).
  • You need a defensible, citable answer rather than a paraphrase from memory.
  • The ticket references a policy (billing, cancellation, SLA - service level agreement) that must be quoted, not invented.
  • A draft is needed for a human agent to review and send, not to auto-send.

Tools

  • browser-navigate - open the knowledge base's search page or a specific article URL.
  • browser-extract - pull the article's title, body text, and URL from the loaded page.
  • http-get - call the KB or helpdesk's REST (Representational State Transfer) API directly when one exists, instead of scraping the page.
  • write-file - save the drafted reply and its citations to a file for the human reviewer.

Playbook

  1. Read the ticket and identify the specific question the customer is asking (e.g. "can I get a refund after 30 days?").
  2. Search the KB first via the API when available: http-get against the org's helpdesk endpoint, e.g. GET https://api.helpdesk.example.com/v1/articles?query=refund+policy. Auth is injected by the org's Integration row for this host - never ask for, echo, or hardcode credentials.
  3. If no API is configured, use browser-navigate to open the KB site's search results page for the same query.
  4. Use browser-extract to pull the matching article's full text, title, and canonical URL.
  5. Confirm the article actually answers the customer's question - if it only partially covers it, note the gap rather than filling it in from assumption.
  6. Draft the reply using only wording and figures found in the article, and include an explicit citation line (article title + URL) at the end of the draft.
  7. Use write-file to save the draft reply plus its citation to the ticket's working file so the human reviewer can find it.
  8. If the ticket needs a change to the customer's account (refund, plan update) rather than just an answer, do not perform it yourself - flag it in the draft for the human agent to action.
  9. If the KB search returns nothing relevant, do not invent an answer: draft a short note stating no matching article was found and route the ticket to a human via send-message.

Failure modes

  • Treating a stale or superseded article as current - always check the article's last-updated date if the API/page exposes one, and flag uncertainty if it looks old.
  • Blending KB wording with your own inferred policy details - keep the draft strictly to what the article states.
  • Skipping the citation - an answer without a linked article is not KB-grounded and should not be sent.
  • Auto-sending the reply - drafts are for human review unless the org has explicitly opted into auto-send; on a 401/403 or missing Integration when calling the KB API, stop and message a human via send-message naming the service and scopes.

Done when

  • A draft reply exists, sourced only from a cited KB article, with the citation saved via write-file.
  • The draft is left for human review (or auto-sent only if explicitly configured), never sent silently.
  • Any question the KB could not answer is explicitly flagged rather than guessed.