Reset Dex for changed answers

If 04-Projects/ does not exist, this vault was never set up. Use setup instead.

If the user actually changed jobs or roles — new employer, new email domain, an old identity to archive — use change-job instead: it runs this same reset and then guides the passes a reset alone never touches (re-sorting people for the new domain, archiving old-role goals, priorities and projects, re-pointing open tasks). A reset by itself is the right lever only for changed preferences or answers within the same working life.

To turn a single room on or off, use manage-capabilities — it is a much smaller change than a full reset and never touches the rest of the profile.

Otherwise:

1. Tell the user what a reset does and does not do, and get an explicit yes before calling anything:

   "I'll walk you through the same questions as first-time setup and rewrite your profile — role, company, pillars, communication style, working week and rooms. Every setting you don't re-answer carries forward unchanged, and nothing you've written is deleted or moved: your notes, people, meetings and projects all stay exactly where they are. Want to go ahead?"

   Stop here if they decline.

2. Call start_onboarding_session(force_new=True) from onboarding-mcp. The force_new flag is what makes this a reset rather than resuming a half-finished setup. Know what it re-arms: the fresh session clears the calendar answer and the harness confirmation, so the flow's calendar step and harness-selection confirmation must both be replayed — finalize_onboarding refuses to run until each has been addressed again. Do not skip past them expecting the old answers to still count.

3. Read .claude/flows/onboarding.md and follow it as the single source of the conversation, exactly as setup does.

4. Before finalizing, call finalize_onboarding(dry_run=True) and show the user what it reports it would create, plus the profile_changes list — every profile setting that will change, old value → new value. Settings not in that list carry forward. Tell the user that on a vault that already completed onboarding, finalizing first takes a snapshot of the current profile, pillars and room choices — before anything is rewritten — so the reset can be checked afterwards and undone if it went wrong. Then call finalize_onboarding().

5. After finalizing, show the user the transition_verification summary from the finalize response — it reads "Changed (you chose): … Carried forward: N settings. Lost: none." Read it before relaying it: if it reports anything lost or changed outside their answers, say so plainly instead of declaring success, and offer restore_transition_capsule — preview first (it defaults to a dry run), then rerun it with dry_run=false if they want the two settings files put back exactly as they were. verify_transition re-runs the same check anytime against the snapshot named in the response.

What a reset actually changes

Say this honestly — do not promise more:

• Rewritten: System/user-profile.yaml, System/pillars.yaml, and the room set, through the onboarding MCP and core/capabilities.py.
• Carried forward: on a vault that completed onboarding, every profile setting the user does not re-answer keeps its current value — calendar connection, work email, working context, journaling, meeting sources, timezone, quarterly planning, entity-creation mode, analytics identity, and the rest. Rooms the user disabled stay disabled unless they are re-answered. In System/pillars.yaml, priority_limits survives, and a pillar kept under the same name keeps its keywords and description. Only a vault that never finished onboarding is rebuilt from the answers alone.
• Added if missing: any folders and starter files the new role needs. Finalizing only creates what is not already there.
• Left alone: every existing folder and file. A reset does not rename, merge or move your content. If the new role means you want Pipeline/ renamed to Portfolio/, that is a manual choice the user makes afterwards — offer to help, do not do it silently as part of the reset. The completion marker keeps its original setup date; the reset is recorded alongside it, not over it.
• Snapshotted and checked: before rewriting anything, finalize captures the current user-profile.yaml, pillars.yaml and room states, then verifies the result against the keys the re-answered steps were allowed to change. The snapshot stays in System/.dex/transition-capsules/ and can restore those two files exactly — it is not a backup of anything else.

Rules

This file deliberately contains no question script, no role list and no company-size list, so reset cannot fork away from setup. The roles, the area→role picker and every other question live in .claude/flows/onboarding.md; change them only there.

Never create folders, move files, or edit CLAUDE.md or System/user-profile.yaml by hand in this skill. core/provision.cjs, core.lifecycle.service and core/capabilities.py own all vault mutation, and the onboarding MCP owns all profile writes and their validation.

---

Track Usage (Silent)

Call the mark_feature_used tool on the dex-analytics MCP server with reset. This ticks the feature's box in System/usage_log.md, which is what /dex-level-up reads to recommend features that have not been tried. It writes locally and sends nothing, so it runs whether or not analytics is enabled.

Analytics (Silent):

Call track_event with event_name vault_reset and properties:

• (no properties)

This only fires if the user has opted into analytics. No action needed if it returns "analytics_disabled".