Change Job

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 → destination for each file first. Create 07-Archives/Role_Transitions/<YYYY-MM-DD>-<old-role-slug>/ (date = today, slug = the old role lowercased, spaces to hyphens) and move 01-Quarter_Goals/Quarter_Goals.md and 02-Week_Priorities/Week_Priorities.md there under their own names. If a destination file already exists, stop on that conflict and keep both versions — never overwrite. Then reseed the live files from this skill's own starters: copy references/quarter-goals-starter.md to 01-Quarter_Goals/Quarter_Goals.md and references/week-priorities-starter.md to 02-Week_Priorities/Week_Priorities.md, replacing {{WEEK_START_DATE}} with the coming Monday's date. A page that doesn't exist (room off, or never created) gets one calm line and is skipped — no error tone.

3b — projects, one at a time. Walk each page in 04-Projects/, never as a batch. For each:

"[Project name] — last touched [date]. Carry it into the new role (no change), close it (archive to 07-Archives/Projects/ with a one-line outcome), or park it (marked on hold, left in place)?"

Every project gets its own answer — never apply one blanket yes to the rest. Close = move the page to 07-Archives/Projects/ keeping its filename, adding the completion date and a one-line outcome at the top. Park = add **Status:** Parked (role transition YYYY-MM-DD) at the top of the page and leave it where it is. Nothing is deleted under any answer.