The specialist tools available in your Ward6AI workspace. Proof Check and the Reference & Claim Checker each come in a Ward 6 and a Ward 7 version; install the one that matches your brand silo. The Document Element Extractor, Email Drafter and Word Document Formatter are single, brand-agnostic skills.
Learn how to add a new skill to your workspace, or remove one you no longer need.
The source documents your skills draw on, and which skill uses each one.
Proof Check reviews a finalised, design-ready document against your house style (spelling, punctuation, style, references and terminology) and flags every issue it finds for the writer to review, without changing the document itself.
When a medical writer has a finalised PDF (or Word document) ready for sign-off, Proof Check reads the text against the Ward house style, the references style and the brand's approved terminology, and produces a Word report listing each issue in document order, with the page, a short description, the rule it relates to, and a confidence level.
It works through a fixed checklist of rules one at a time and shows that audit at the end, so you can see every rule was checked. It is review-only: it identifies and locates issues but never rewrites the document. The writer makes every editorial decision. Install the Ward 6 version for Ward 6 brands (Veltassa and Maviret) and the Ward 7 version for Ward 7 brands (Kisqali and Kesimpta).
Upload the finalised PDF (or Word document) straight into the chat and ask for a proof check, for example: "Run a proof check on this." If the file already lives in your Knowledge Base, you don't need to upload it again, just name it: "Run a proof check on Veltassa_eDM_v3.pdf from the knowledge base." The skill confirms the brand with you before it starts.
You'll get a Word report back in the chat, listing every issue in document order with its page, a short description, the rule it relates to and a confidence level, plus an audit table at the end. It only flags and locates issues; it never changes your file.
Some sources carry no usable page numbers — compressed or interactive PDFs, e-detailers and IVAs often have no embedded pagination, or the runtime's physical page numbers don't match the piece's own pages. When a page number wouldn't help you find an issue, Proof Check switches to a section-based locator: each finding is located by the main section from the piece's navigation, then the nearest preceding heading, then any other cue (panel, callout, slide label). The opening summary states explicitly that the document has no reliable page numbers and that locations are given as section then nearest heading.
Skill documentation:
The Reference & Claim Checker cross-checks every product claim in a draft against the brand's approved claims library, flagging the issues that matter for MLR review, before the draft reaches the reviewer.
For a draft going through Medical, Legal and Regulatory (MLR) review, the tool matches each substantive product claim against the approved claims library and checks six things: missing references, mismatched citations, missing qualifiers, unknown claims (not in the library), disallowed claims (such as superlatives), and citation-format inconsistencies.
It produces a Word report grouping the findings by type (with the matched library entry, what is cited versus what the library expects, and a suggested action for each), plus an audit table confirming every approved claim was checked. Like Proof Check it is review-only, comes in Ward 6 and Ward 7 versions, and needs the brand's approved claims library loaded to run.
Upload the draft (PDF or Word) into the chat, or name a file that's already in your Knowledge Base, and ask for a check. Tell it the audience so it can apply the channel rules, for example: "Run a reference and claim check on this HCP detail aid," or "Run a reference and claim check on Kisqali_detail_aid.pdf from the knowledge base." The skill confirms the brand with you before it starts.
You'll get a Word report back in the chat, grouping the findings by type, with the matched library entry, what is cited versus what the library expects, and a suggested action for each, plus an audit table confirming every approved claim was checked. Like Proof Check, it is review-only and never changes your draft.
Skill documentation:
The Document Element Extractor turns a finalised, approved document into a structured, reusable breakdown. It pulls out every claim with the qualifiers and references that substantiate it, plus a deduplicated reference list, the mandatory prescribing information, footnotes and abbreviations, ready to seed a claims library or repurpose into new materials.
Given any finalised, approved document (a Product Information, an approved claims list, a study summary, an eDM, a detail aid or a patient brochure), the extractor reads the text and produces a Word document organised around claims. Each claim is shown with the qualifiers and references that support it, alongside deduplicated lists of references, the mandatory prescribing information, footnotes and abbreviations. The references are also provided as copy-and-paste EndNote and RIS blocks at the end, ready to import into a reference manager.
It assumes the document is already approved and does not check claims for compliance; that is the Reference & Claim Checker's job. Like the other skills it is review-only: every extracted element must be verified against the source document before it is added to a library or reused.
Upload a finalised, approved document (PDF or Word) into the chat, or name one that already lives in your Knowledge Base, and ask it to extract the elements, for example: "Extract the elements from this," or "Pull out the claims and references from Veltassa_PI.pdf from the knowledge base."
You'll get a Word document back in the chat: a claim-by-claim breakdown with qualifiers and references, the deduplicated reference list, the mandatory text, footnotes and abbreviations, plus the EndNote and RIS export blocks at the end. It only reads and reorganises the source; it never changes your original document.
Skill documentation:
The Email Drafter generates an early, labelled HCP email draft — Standard, Veeva Approved Email or eWizard — from your brand's approved claims library and voice guide. One brand-agnostic skill handles every Ward 6 and Ward 7 brand.
Drafting an email means juggling the template's structure and limits, the brand voice, the audience and the approved messaging all at once. The Email Drafter produces a first draft that honours the chosen template, pulling every claim only from the approved claims library and flagging anything the brief implies but the library doesn't support, rather than inventing it.
Every element is labelled — Subject lines, Preheader, Header, Body, CTA, Citations, Mandatories — so you can see how each piece maps to the template, and so the draft flows straight into the Word Document Formatter. For two or more audiences it produces one draft each plus a cross-version comparison table. It drafts only; checking and formatting are other skills' jobs.
Ask it to “draft an email”, “draft a VAE” or “draft an eWizard email”. It detects the brand, then asks once for the template, audience segment(s), the email's goal, any images to place, and whether you want icon suggestions.
You'll get a Word document back: a header showing what was loaded, the per-audience drafts with every element labelled, a cross-version comparison table where relevant, and a gaps-and-flags section. It's an early draft for the medical writer to refine before MLR.
Skill documentation:
The Word Document Formatter applies Ward house style to a labelled draft and returns a publish-ready Word document — cover sheet, header and footer, per-element styling and page numbering. One brand-agnostic, ward-aware skill handles every Ward 6 and Ward 7 brand.
Writers produce drafts marked up with bracketed tags like [Head], [Body], [Callout] and [CTA] that show the hierarchy but carry no formatting; the studio then re-keys them by hand. This skill does that re-keying automatically, preserving the writer's copy verbatim and adding only formatting and document structure.
It supports six document types (HCP email, EDM, detail aid, eDA brief, case study, training) plus a generic fallback, each with its own cover, header and footer. Anything it can't classify confidently is given best-guess formatting and flagged, both inline and in an opening summary. Images become text placeholders for the studio to source.
Submit a labelled draft and ask to “format this draft” or “apply Ward house style”. It detects the brand, then asks once for the ward, document type and any missing cover-sheet details.
You'll get a publish-ready Word document: a cover sheet, an opening summary listing the document type and every flagged item, the formatted body, a running header where the document type uses one, a footer with live page numbers, and the mandatories block. Run Proof Check or the Reference & Claim Checker on the result before MLR.
The skill adds visible subheads ahead of each multi-item section (Subject lines, Preheader options, Footnotes, References, Mandatories) so two numbered lists in a row are never ambiguous. Single-item blocks already typed by their element (Header, Subhead, Body, Callout, CTA) are not double-labelled.
When a draft contains more than one audience version — typical of an Email Drafter output with both a GP and an Oncologist version — the skill emits a heading at the start of each version (“Draft: GP”, “Draft: Oncologist”) and groups that version's blocks beneath it. Source order within each version is preserved exactly as the writer composed it.
Skill documentation: