Dex Level Up

Purpose

Discover Dex capabilities you haven't used yet. No FOMO — this is your concierge showing you what's available so you can get full value from the system without missing features.

Step 1: Check Usage Log

Read System/usage_log.md to understand what features the user has adopted.

Step 2: Analyze Patterns

Look for natural progressions and gaps:

Progression Patterns

Daily → Weekly → Quarterly:

• Using /daily-plan but not /week-plan? → Suggest weekly planning
• Using /week-plan but not /quarter-plan? → Suggest quarterly goals

Meeting Capture → Relationship Tracking:

• Processing meetings but no person pages? → Suggest person pages
• Have person pages but not company pages? → Suggest processing meetings to auto-create company pages in 05-Areas/Companies/

Tasks → Projects:

• Managing tasks but no project pages? → Suggest project tracking
• Have projects but not using /project-health? → Suggest health checks

Basic → Advanced:

• Comfortable with core workflows? → Suggest journaling, learning capture
• Using all features consistently? → Suggest custom MCPs, system improvements

Role-Based Relevance

Prioritize suggestions based on user's role (from System/user-profile.yaml):

Product Managers:

• /product-brief for feature ideation
• Project tracking for initiative management
• Relationship tracking for stakeholder management

Engineering:

• Project tracking for sprint/milestone management

Sales/Customer Success:

• Person pages for customer context
• Relationship tracking for account management
• Meeting prep for sales calls

Leadership:

• Quarterly planning for strategic thinking
• Weekly reviews for team synthesis
• Learning capture for pattern recognition

Step 2.5: Check for Role-Specific Skills

After analyzing universal feature usage, check for role-specific skills:

Identify User's Role Group

1. Read System/user-profile.yaml → role field
2. Map role to role_group using this mapping:
   • product: Product Manager, CPO, Product Ops, Fractional CPO
   • sales: Sales, Account Executive, CRO, RevOps
   • marketing: Marketing, CMO
   • finance: Finance, CFO
   • engineering: Engineering, CTO, Solutions Engineering
   • customer_success: Customer Success, CCO
   • operations: Product Ops, RevOps, BizOps, Data/Analytics
   • leadership: CEO, Founder, C-Suite roles
   • design: Design
   • support: People (HR), Legal, IT Support, CHRO, CLO, CIO, CISO
   • advisory: Consultant, Coach, Venture Capital/Private Equity

Check Available Skills

1. List files in .claude/skills/_available/[role_group]/
2. For each available skill directory, read its SKILL.md and extract:
   • name (from frontmatter)
   • description (from frontmatter)
   • jtbd (from frontmatter)
   • time_investment (from frontmatter)

Check Installed Skills

1. List files in .claude/skills/
2. Cross-reference with available skills to determine which are not yet installed

Present Role Skills (if any uninstalled)

If there are uninstalled role-specific skills, include this section in the output:

---

## 💼 Role-Specific Skills for [Role Name]

You haven't installed role-specific skills yet. Here's what's available for [role_group] roles:

### /[skill-name]
**Job to be done:** [JTBD from frontmatter]
**Time investment:** [time_investment from frontmatter]

[Repeat for each available uninstalled skill]

---

**Want to install these skills?** 

Say:
- **"install all"** to add all [X] skills
- **"install [skill-name]"** to add specific skills
- **"tell me more about [skill-name]"** to learn more before installing

Official Capability Adoption

When the user says "install [skill]" or "install all", keep acting as a concierge and renderer. Every adoption goes through core.lifecycle.service version 1.0.0; this skill never writes, moves, or installs capability files itself.

1. Ask build_inventory_and_plan for the verified catalog plan. A dormant role skill is eligible only when its exact item id appears in that official plan. A skill from .claude/skills-custom/, another user-created location, or an unregistered source is not an official catalog item and must not be adopted through this route.
2. Render the catalog result in the same five-group order used by Dex Doctor and Dex Update, even when a group is empty:
   1. New and safe to adopt — action adopt
   2. Needs your review — action conflict; name the files Dex preserved
   3. Held back by you — action skip-held-back
   4. Could not be proved — action unknown; say no change will be made
   5. Already yours — action already-adopted, with its receipt-backed state
3. For the selected official item ids, ask build_and_preview_adoption for the exact preview and approval token. For "install all", request only the eligible official items the user was shown; a held-back or unproved item never changes the others.
4. Show the item name and version, every proposed file, whether each file is new or refreshed, and that vault-owned user files are outside the write set. Explain that the complete approved set will be one crash-safe transaction with a receipt that can support an exact rewind.
5. Ask one direct confirmation: “Adopt this exact capability preview?” An earlier request to install is not approval of a later concrete file list. If the preview or evidence changes, render the refusal and request a fresh preview instead of working around it.
6. Only after explicit confirmation, pass the unchanged preview and token to execute_approved_adoption. Do not synthesize, shorten, or reuse either value.
7. Ask read_lifecycle_state for the verified post-adoption state. Render the returned receipt: adopted items, transaction identifier, every receipt-declared file, snapshot reference, rewind acknowledgement availability, and any retention warning. Confirm installation only when the service returned a committed receipt and the refreshed state reports the item as adopted.

If the service refuses, explain why in ordinary language and stop with the vault untouched. There is no manual fallback. In a fresh session, normal presence-based skill discovery resolves the adopted capability from its service-written path; do not hand-wire activation, edit capability configuration, or create a second installation path.

Step 3: Integration Discovery

Check for connected integrations and surface opportunities the user may be missing.

Unused Capabilities (Already Connected)

Read System/integrations/config.yaml and check each enabled integration for underutilized features:

For each enabled integration, check if all capabilities are active:

• Gmail connected but email_followup: false? → "You have Gmail connected but haven't enabled follow-up detection. It flags emails waiting for replies — useful in /daily-plan."

• Gmail connected but newsletter_digest: false? → "Gmail is connected but newsletter digests aren't enabled. It summarizes your morning newsletters so you can skim instead of read."

• Todoist/Things connected but /process-inbox doesn't route to it? → "You have [Tool] connected but inbox processing doesn't route tasks to it yet. Want to enable two-way sync so tasks land in both places?"

• Jira connected but sprint_tracking: false? → "Jira is connected but sprint tracking isn't active. It would pull sprint items into your /daily-plan."

• Zoom connected but Granola also active? → "You have both Zoom and Granola — Granola already captures meetings. Zoom's main added value is scheduling. Working as expected?"

Present any findings as a section:

## Untapped Integration Features

You have [X] integrations connected. Here are features you haven't turned on yet:

- **Gmail follow-up detection** — Surfaces emails waiting for replies in your daily plan.
  → Enable: Edit `System/integrations/config.yaml` → `google-workspace.email_followup: true`

- **[Other unused feature]** — [Brief value prop].
  → Enable: [Specific instruction]

If all features of all connected integrations are active, skip this section.

Missing Integrations (Not Connected)

Run the integration concierge to find tools the user already works with but hasn't connected — it scans the vault for signals (mentions, links, email domains) and ranks them:

node .claude/hooks/integration-concierge.cjs

Parse the JSON output — the high_value tier holds items scoring 5 or higher, moderate_value holds the rest with any signal. Each entry carries a reason field naming the strongest evidence ("installed on your Mac", "already set up as an MCP server but not connected yet", or a mention count). Surface up to two, named specifically, using that reason:

## Tools You Could Connect

- **[shortName]** — [reason]. [value proposition]. Connect with `[setup]` ([setupTime]).

Lead with the high_value items; fall back to a single role-fit moderate_value suggestion only if there are no high_value hits. If nothing scores, don't force it — a generic "run /integrate-mcp to connect calendar, email, task apps (Todoist/Things/Trello), and more" line is enough. Keep it to high-signal suggestions only — don't overwhelm.