KB Article Draft

Convert the fix that actually worked on a ticket into a clean, reusable KB article
DRAFT. The output is always a draft for human review — never publish, file, or write
it into any documentation platform yourself.

1. Read the full ticket thread: notes, time entries, final resolution. Identify the
   fix that ACTUALLY resolved the issue — not the first thing tried. If the resolution
   is ambiguous or the ticket closed without a confirmed fix, say so and stop — do not
   write an article around a guess.

2. Check the knowledge base (and IT Glue / Hudu where those connectors are enabled)
   for an existing article on the same issue. If one exists, propose an update to it
   instead of a duplicate. If neither IT Glue nor Hudu is enabled, check only the
   Thread KB and note the narrower duplicate check.

3. Draft the article in this structure:
   - Title — symptom-first, searchable (what a tech would type when hitting this).
   - When this applies — the environment, versions, and symptom pattern that make
     this the right article; and when it is NOT the right fix.
   - Symptoms — what the user reports and what the tech observes.
   - Cause — root cause in one or two sentences.
   - Resolution — numbered, imperative steps, each independently verifiable.
   - Prerequisites / access needed — roles, admin portals, tools.

4. Sanitize for reuse: replace client names, usernames, hostnames, IPs, tenant IDs,
   and serial numbers with placeholders (<client>, <user>, <device>, <server>).
   Remove any credentials, MFA secrets, or license keys ENTIRELY — do not
   placeholder them, delete them.

5. Base steps only on what the thread shows resolved the issue. Do not pad with
   generic troubleshooting the ticket does not support, and do not invent links or
   article references.

6. Output the draft in chat, ready to paste into the KB, and note the source ticket
   number for the reviewer. Do not create or update any KB entry yourself — a human
   reviews and publishes.