davekilleen / reset

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 eventname `vaultreset` and properties:

• (no properties)

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