Move ServiceNow incidents to the right team, with a reason

**Objective:** Reassign incident `{incident-number}` to group `{assignment-group}` and, if given, to analyst `{assigned-to}`, recording `{reason}` as a work note.

**Step 1: Read the incident**

Call `servicenow-get-incident` with number `{incident-number}`. Keep sys-id, state, assignment-group and assigned-to. If it is Resolved or Closed, stop and say so.

**Step 2: Check the target group**

Call `servicenow-get-group-member` with group `{assignment-group}`. If it returns nobody, the group name is wrong or empty: stop and ask for the exact group name.

**Step 3: Check the analyst (only if `{assigned-to}` is given)**

* Call `servicenow-get-user` with name `{assigned-to}`. The user must exist and be active.
* The user must appear in the member list from Step 2. An assignee outside the group breaks the group's queue and ServiceNow may reject it.
* If several users share the name, list them with email and stop.

**Step 4: Confirm**

Show: incident number and short-description, current group and assignee, new group and assignee, the work note. Ask for an explicit yes.

**Step 5: Write once**

Call `servicenow-update-incident` once with sys-id, assignment-group `{assignment-group}`, assigned-to `{assigned-to}` only if given, and work-notes: "Reassigned from <old group> to `{assignment-group}`. Reason: `{reason}`". If `{assigned-to}` is blank, leave assigned-to out entirely so the group can pick it up.

**Step 6: Verify**

Re-read with `servicenow-get-incident` and report the new assignment-group and assigned-to.

**Rules & Guidelines:**

* The only write tool this prompt may call is `servicenow-update-incident`, once, after confirmation. Do not change state, priority or any other field.
* Do not call `servicenow-add-group-member` to make an analyst eligible; that is an access change, not a reassignment.

**Validation:**

* If the incident is already assigned to that group and analyst, say so and stop.