> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Variation Author

> Interview the admin about how troubleshooting differs per client (printers, VPN, LOB apps…), then encode those differences as intent variations — arguments and replies per variation, with a test plan before activation. Answers the "the bot should answer differently for each client" workflow.

<Info>
  **Category:** Automation & Flows · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/automation-and-flows/variation-author/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Service & Ops Manager](/start-here/roles/service-ops-manager)

**Outcome:** Time & Cost Savings (Capacity)

**When to use:** An admin needs client-specific answers — "our VPN steps differ per client", "each client has a different printer setup", "the intent gives the wrong instructions for \<client>" — or wants existing variations reviewed and extended. Sibling of intent-builder: that builds the whole intent; this focuses on the interview -> variation -> test loop.

**Run it:** as a build task on request — you're authoring intent variations, not acting on tickets, so there's no Flow trigger for this one.

## Prompt

```
Turn "for <client A> the printers work like X but for <client B> it's Y" into properly
structured intent variations. ATTENDED and admin-only: intent and variation editing is
admin-scoped; if you can't write, do not attempt it — deliver the interview results and
variation table as a spec the admin can apply, and say that's the degradation.

1. Locate or create the base intent: list and open the existing intents to find it; if the
   concept doesn't exist at all, build the base (or hand off to intent-builder)
   before authoring variations. One intent per concept — if the interview reveals two
   genuinely different intents (VPN setup vs VPN broken), split them, don't overload
   variations.

2. Interview the admin — short, concrete questions, one dimension at a time:
   - Which situations need different answers? (per client, per site, per device model, per
     app version)
   - For each: what exactly differs — the steps, the contact to call, the tool name, the URL?
   - What happens when the differentiating fact is unknown mid-conversation? (ask the user,
     or fall back to the base reply)
   Capture answers verbatim where they become reply text; don't paraphrase technical steps.

3. Draft the variation set and SHOW IT as a table before touching anything: variation ->
   discriminating condition -> arguments it needs -> reply text. Get an explicit "yes".

4. Encode each variation: set its discriminating condition, the facts the intent must
   collect (e.g. <client>, <device model>), and the reply text. Keep the base/default
   variation as the safe fallback — the reply for "we
   don't know which case this is" must be safe for ALL clients; never leave the unknown case
   answerless or answered with one client's specifics. Client-specific reply text comes from
   the admin's own words or documentation — never invent client procedures, URLs, or contacts.

5. Test plan before activation: for each variation, 2–3 sample end-user utterances plus the
   expected variation match and reply; include at least one deliberately ambiguous utterance
   that must fall back to default. Walk the admin through it (or run it together) before the
   work is done. Apply the changes only after the plan passes. Replies are end-user-
   facing: plain, localizable, no idioms, no environment-specific identifiers.

6. Output: the final variation table, the test plan with results, and any follow-ups the
   interview surfaced but the admin deferred. Never activate on the member's behalf.
```


## Related topics

- [Intent Bulk Variation Update](/skill-library/automation-and-flows/intent-bulk-variation-update.md)
- [Post-Mortem & RCA Author](/skill-library/documentation/post-mortem-rca-author.md)
- [Skill Authoring Coach](/skill-library/automation-and-flows/skill-authoring-coach.md)