/change-job

name: change-job
description: "Guided job or role transition: re-run the setup questions with every unanswered setting carried forward and checked afterwards, re-sort people for the new work email domain, archive the old role's goals, priorities and projects (never deleted), re-point open tasks at the new pillars, and close with a ledger of what changed and how to undo each step. Use when the user says 'I changed jobs', 'I'm changing jobs', 'new role', 'new job', 'went full-time', or 'I'm now [role] at [company]'. Not for a preference change within the same job; use `reset`. Not for first-time setup; use `setup`."

Move a whole Dex vault from one role to the next without losing anything: the same setup questions, then people, planning, and tasks — each pass proposed before it runs, each pass skippable, nothing ever deleted.

The one rule that overrides everything

**Nothing is deleted, and nothing moves without a yes.** Every pass shows exactly what it will do for review before anything is applied. Old-role material is archived where the user can always find it — never removed. Skipping any pass is always a fine answer.

Step 0: Orient and promise

Read `System/user-profile.yaml` (read-only — never edit it from this skill) and note the current `role`, `company_size`, `email_domain` and, if present, the company name. These are the **old role** values the later passes need. Then lay out the whole transition in plain words and get an explicit yes.

Open in the user's own register: congratulate only if they've shown this is good news — a job change can also follow a layoff, and "Congratulations" lands badly there. When unsure, open neutrally:

> "A new role is a big shift — let's move Dex over with you. Here's what a job change involves — five steps, and you can skip any of them: > > 1. **Setup questions again.** The same questions as first-time setup. Every setting you don't re-answer carries forward unchanged. A snapshot of your current settings is taken first, and the result is checked against it afterwards — if anything was lost, you'll know, and the snapshot can put it back. > 2. **Re-sort your people.** Old colleagues and new ones are re-filed for your new work email — you see the full list before anyone moves. > 3. **Archive the old role's planning.** Quarter goals, week priorities and projects from the old role are archived, never deleted, and each project is your call: carry it, close it, or park it. > 4. **Re-point open tasks.** Tasks still aimed at retired pillars get re-pointed at the new ones, then groomed goal by goal. > 5. **Housekeeping.** A few one-line offers — refresh your working-patterns profile, review connections that mention the old employer. > > Nothing is deleted at any step. Ready to start with the setup questions?"

Stop here if they decline. If what changed is really just preferences within the same job, point at `reset` instead — it is the lighter lever.

Step 1: Setup questions with carry-forward

Delegate to the `reset` skill: read `.claude/skills/reset/SKILL.md` and follow its steps 2–5 exactly — `start_onboarding_session(force_new=True)`, then the conversation in `.claude/flows/onboarding.md` (the single source of every question; never restate the script here), then `finalize_onboarding(dry_run=True)` showing the `profile_changes` list (every setting that will change, old value → new value — settings not listed carry forward), then `finalize_onboarding()`.

After finalizing, relay the `transition_verification` summary word for word — it reads "Changed (you chose): … Carried forward: N settings. Lost: none." Note the snapshot id it names; the closing ledger needs it.

**If verification fails, stop the whole transition.** Do not run any later pass. Say:

> "The after-check found a problem: [the verification summary, word for word]. I'm stopping the transition here — none of the later steps will run. The snapshot taken before anything changed can put your settings files back exactly as they were. Want me to preview that restore?"

Offer `restore_transition_capsule` exactly as the reset skill describes it: preview first (it defaults to a dry run), then rerun with `dry_run=false` only if they confirm.

If the user skips this step, ask for the new work email domain in one line — the people pass needs it — and pass it explicitly in Step 2.

Step 2: Re-sort people for the new domain

Call `reroute_people()` from the Work MCP — it defaults to a dry run and to the email domain now in the profile. If Step 1 was skipped, pass `domains` with the domain the user gave. If the tool is missing or errors without a structured response, say the people re-sort could not be run in this vault version and move on — never move person pages by hand.

Show the returned plan in plain language before anything moves:

> "I re-checked [scanned] person pages against [domain]: > - [count] move to Internal — new colleagues, e.g. Priya Shah (priya@example.com matches the new domain) > - [count] move to External — people from the old company > - [count] are already where they belong > - [count] have no email recorded, so I won't guess — they stay put: [names] > [Any skipped pages, with the tool's reason, word for word.] > Apply these moves?"

On yes, call `reroute_people(dry_run=false)` and report the ledger honestly from the response: moved, relabeled, anything that failed (relay `warnings` word for word — a collision is skipped, never overwritten), and that the people index was rebuilt. Ambiguous pages are never moved; offer to add an email to a page so the next run can place it.

Step 3: Archive the old role's planning

**3a — goals and priorities.** Offer once:

> "Your quarter goals and week priorities still describe the old role. I can move both pages, whole, to `07-Archives/Role_Transitions/[YYYY-MM-DD]-[old-role]/` and start fresh ones from the blank starter. Nothing is deleted — moving the files back undoes it. Want me to?"

On yes: show the exact source → desti