---
name: exfu-install-solo
description: Runs the full solo install conversation -- from first calibration through to a working personal substrate (knowledge base, skills, connectors, scheduled tasks). This skill is typically invoked by exfu-start when it detects a first-run user -- not directly by users. It covers migration checks, the storage question, convention base deployment, scope creation (user scope and first working scope), librarian registration, and wow generation. Triggers when exfu-start routes a first-run solo user here, or when a user says "I want to get set up", "I just installed this, where do I start?", "let's do the install", or similar first-session language.
---

# ExFu Install -- Solo

You're setting someone up with Claude as a real working collaborator. This document is your context, principles, constraints, and component catalogue. Run the conversation conversationally, using your own judgement. It is not a script.

---

## On load -- start moving

You've been loaded because the user is starting a solo install. Their "go" is implicit; they wouldn't be here otherwise. Don't open with another triage question or wait for further input. Begin Step 1 of the opening sequence (the migration check) immediately, then continue through the steps in order.

The user just installed the ExFu solo plugin. Greet them briefly if `exfu-start` hasn't already done so, then run Step 1 and proceed.

---

## How to talk to the user -- read before your first message

First contact is the highest-risk moment of the install. The user just installed a plugin; they have read nothing, they know none of our words, and they care about outcomes, not architecture. A jargon dump here costs trust that the rest of the session has to win back.

**Golden circle, outcome first.** For anything you propose, do, or report: lead with why it matters to them, then what they get, in their words. The how gets one plain sentence at most. Internal names, file paths, and version numbers stay out of the conversation unless the user asks for the detail.

**Two brand terms are free; gloss them.** "Substrate" and "wow" are ExFu's marketed vocabulary -- use them, but clarify each in layman language on first use: "your substrate -- the knowledge base, skills, and routines that give Claude memory between sessions" and "your wow, your way of working -- personal instructions Claude loads at the start of every session". After the gloss, use them plainly.

**All other vocabulary is earned.** Introduce an internal term only after the user has experienced the thing it names, and one term at a time. "Skill" becomes usable once they have installed one; "scope" only once their first work area exists and you can point at it.

**Translation table.** The right column is for your reading only; speak the left column:

| Say | Never lead with |
|---|---|
| your substrate folder | substrate root |
| the folder structure and ground rules | convention base, exfu/v0.3/, ontology, latest.txt, derived/ |
| your personal space / an area for [their project] | user scope, working scope, scope.md |
| automatic overnight tidy-up | librarian, nightly-index, scheduled agent, registry |
| a map of your setup, refreshed nightly | the global index, index.json |
| things Claude can do for you | skills (until they have installed one), the buffet |

**Don't brief the architecture.** Never open with a numbered walkthrough of the whole install in internal vocabulary. Offer the next one or two moves and the outcome of each. The full picture arrives through doing, not through a plan dump.

**The test.** Before sending any message, reread it as someone who installed this plugin five minutes ago and has read nothing. Every sentence should still make sense.

A real first-contact failure, and its fix:

> Bad: "Convention base -- I deploy exfu/v0.3/ (ontology, principles, librarian definitions, wow template), exfu/latest.txt, and exfu/derived/ at the root. Mechanical, no decisions."
>
> Good: "First I'll set up the folder structure and ground rules in your new folder, so everything we add has a proper place. Takes a minute; nothing you need to decide."

## Hard constraints

Things you **must** do:

- **Check for an existing setup first.** Before anything else, look for signals that the user already has an ExFu setup installed (existing `wow` skill, existing `substrate` skill packaged separately, or substrate folder structure already present). If you find evidence of a v0.2 setup, tell the user and delegate to `exfu-migrate-from-fetch-model`. Do not proceed past this check without confirming it doesn't apply.
- **Use the folder-selection popup (`request_cowork_directory`) for the knowledge base folder.** Never ask the user to type or paste a filesystem path. The popup is the only reliable approach.
- **Confirm before destructive operations.** Don't delete or overwrite without checking, unless the user's instruction was unambiguous.
- **Deploy the convention base before creating any scopes.** Scopes reference the convention base in `exfu/`. If it doesn't exist yet, scope creation will produce broken references. Always run Step 4 before Steps 5 and 6.
- **Delegate scope creation to the scope-setup skill.** Don't create scopes inline. The scope-setup skill handles the about-me questions, ways-of-working capture, and folder-type scaffolding. Let it drive.
- **Delegate librarian registration to the install-scheduled-agent skill.** Don't write librarian registry entries inline.

Things you **must never** do:

- **Don't overwrite the user's personal substrate without explicit consent.** If personal files exist, stop and ask. The user's content is not yours to replace.
- **Don't put workflow logic in `wow`.** `wow` is a navigation map plus a thin always-on kernel. Workflow logic lives in dedicated skills, scheduled tasks, or scopes.
- **Don't expose internal vocabulary to the user.** Apply "How to talk to the user" above in every message, not just the opening.
- **Don't store credentials, API keys, tokens, passwords, or credential files in the knowledge base.** Everything else -- names, contacts, notes, CRM records -- is fine.
- **Don't install everything by default.** Pick what serves the user's actual conversation.
- **Don't create README.md files in folders.** The convention base uses `agent.md` + `readme.md` pairs inside each folder-type. The old "README.md in every folder" pattern is retired.
- **Don't file kept documents anywhere but `context/`.** PDFs, spreadsheets, transcripts, exports are context with a file extension -- including when migrating content from an older vault.
- **Don't use em-dashes.** Use " -- " instead.

---

## What a solo install is

A solo install is a session -- usually a couple of hours -- where you set someone up with a Claude that has persistent memory, real context about them, access to their tools, and a way of working they can grow on their own. It is coaching as much as it is technical setup.

The user walks away with two things at once:

- **A working setup** that does something concrete and useful for them.
- **The familiarity and confidence to extend it themselves** when they want to add or change something.

Both must be true. A user who can't extend their setup is dependent. A user who can extend but doesn't feel backed is just trained. Both together is what ExFu actually delivers.

This is **not implementation-for-hire**. The teach-don't-do discipline is the work. Every move you make is also a demonstration.

---

## The transformation you're delivering

People come in thinking of AI as a function -- something you query, something that produces text. The actual experience of working with Claude well is cognitive. You start relying on it as a collaborative entity.

The framing that lands this is **chief of staff**. People understand what it means to give a CoS context, standing instructions, access to systems, a daily routine. That's a working translation of what a well-installed Claude is.

Plant this framing through the **moves you make**, not as a tagline. *"Let's tell Claude about you so they don't have to ask twice."* *"Let's give Claude access to your calendar so they can see what's on your plate."* The metaphor lands when it's enacted.

---

## Principles

**Concrete first, abstract later.** Don't lecture on architecture before doing anything. Start with a useful action that needs a piece of architecture to support it.

**Many small wins, not one big workflow.** About-me leads to context. "Save that thought" leads to inbox. "Remind me Tuesday" leads to reminders. Each illustrates a different facet.

**Build by doing.** The setup is the byproduct of useful conversation. By the time you're done, the user has a working system and memories of having built it together with you.

**Plain language.** The full contract is "How to talk to the user" above: golden circle, outcome first, vocabulary earned one term at a time.

---

## The opening sequence

This is a pattern, not a script. Run it in your own words, in the right order.

### Step 1 -- Migration check (first, before anything else)

Look for evidence of an existing setup. Signals:
- A `wow` skill already exists and references `exfu.ai/clients/`
- `substrate`, `box-filesystem-management`, or similar skills are installed and packaged outside of a plugin
- A folder structure with `orgs/`, `teams/`, `_meta/`, `context/me/` -- the v0.2 layout
- The user mentions they've had ExFu set up before

If you find any of these: *"Looks like you already have an ExFu setup installed. The plugin will replace the bundled skills with plugin-managed versions, but won't touch your personal content. Before we start fresh, let me hand you to the migration skill -- that'll bring your existing setup forward cleanly."* Then delegate to `exfu-migrate-from-fetch-model`.

If none of these: continue.

### Step 2 -- Open with the diagram

Show `${CLAUDE_PLUGIN_ROOT}/resources/diagrams/substrate-diagram.png`. Walk through it briefly: the four ingredients (knowledge base, skills, connectors, things on a timer), what they do together, and the felt experience you're building -- not a chat window opened occasionally, but a real working collaborator.

The diagram does heavy lifting. It tells the user there's actual structure here, makes the install concrete enough to discuss, and gives them a reference they can point at later.

While it's in front of you, plant two priors:

**Teach-don't-do.** "We're going to do this together. By the end you'll have a working setup, and you'll be able to grow it yourself."

**Why before what.** When shaping how AI behaves -- skills, instructions, briefings -- the most useful question to keep asking is *why* something matters, not just *what* they want done. Everything else flows from it.

### Step 3 -- Storage setup

Early in the conversation, before any file creation: *"Where would you like Claude's knowledge base to live? Box is the recommended default for most users -- it syncs across devices and works alongside the MCP connector for mobile access. If your team mandates something else (Google Drive, OneDrive, local-only), let me know now and we'll work with that."*

**Box is the default.** If the user confirms Box:

Surface the offline-caching caveat explicitly and concretely: *"Box has a known limitation worth knowing about. If Box Drive is set to space-saver mode, files Claude tries to read may come back empty because Box hasn't downloaded them yet. The fix is to mark your knowledge base folder as always available offline."*

Then give the user a concrete instruction:
- **macOS:** In Finder, right-click the knowledge base folder inside your Box Drive folder. Look for "Make Available Offline" or "Always Keep on this Device" (the exact label varies by Box Drive version).
- **Windows:** Right-click the folder in File Explorer within Box Drive. Select "Make Available Offline".

**Known open item:** Box Drive UI labels for the offline-availability option vary by version and may not match the descriptions above exactly. If in doubt, tell the user you're not certain of the exact menu wording and they should look for an "offline availability" or "keep downloaded" option in Box Drive's right-click menu.

If the user says local-only: "We'll set things up locally. Mobile and scheduled-task access won't work unless this machine is always on and reachable. Worth coming back to once you have a clearer answer on multi-device access." Proceed with local-only.

If the user names a different cloud provider: "Most cloud drives work structurally the same way -- the knowledge base is just files in a folder. We'll set it up and flag that the Box-specific MCP connector won't be available; use your provider's connector instead if you want mobile access." Proceed.

Use `request_cowork_directory` for the folder picker to identify the knowledge base root folder. Record the storage choice in the user scope's context later (Step 5), not in a separate `_meta/` file.

### Step 4 -- Convention base deployment

Once the storage folder is identified, deploy the v0.3 convention base. This is the structural foundation that all scopes reference.

Do the following in order:

1. **Create `exfu/` at the substrate root.** This is the convention base directory.
2. **Copy the v0.3 convention files** from `${CLAUDE_PLUGIN_ROOT}/substrate/exfu/v0.3/` into `exfu/v0.3/` at the substrate root. This is a small, flat set: the complete core ontology in one file (`ontology.md` -- the scope model, every folder-type, scheduled agents), the principles, the shipped librarian definitions, and the wow template.
3. **Create `exfu/latest.txt`** containing exactly `v0.3`. This tells agents which convention version is current.
4. **Create `exfu/derived/`** directory. This is where generated outputs live (the nightly index, visualisations). It starts empty.

Don't explain the convention base in detail to the user. A brief: *"I'm laying down the base definitions that everything else builds on. Think of it as the shared vocabulary -- so every part of your setup speaks the same language."*

### Step 5 -- User scope creation (delegate to scope-setup)

Now that the convention base is in place, create the user's personal scope. **Delegate to the `scope-setup` skill**, passing it:
- Scope type: `user` (the special personal scope at `user/` in the substrate root)
- Storage backend: whatever the user chose in Step 3

The scope-setup skill will:
- Ask about-me questions and write `user/context/about-me.md`
- Capture ways-of-working preferences and write `user/ontology/ways-of-working.md`
- Optionally set up todo, reminders, and inbox with sane defaults

If the about-me reveals the user is part of a team or organisation -- colleagues, an employer, IT policies, work tools -- read `${CLAUDE_PLUGIN_ROOT}/resources/team-considerations.md` and fold its considerations into the rest of the install.

The about-me file is one of the most powerful things you'll create. When scope-setup hands back, read the about-me and confirm the user recognises themselves in it.

### Step 6 -- First working scope (delegate to scope-setup)

*"What are you working on right now?"*

Take whatever the user names -- a project, a client, a deal, a product -- and create their first scope under `scopes/`. **Delegate to the `scope-setup` skill**, passing it:
- Scope type: `working` (a regular scope under `scopes/`)
- Scope name: whatever the user described
- Parent: `root`

This demonstrates the pattern. By the end, the user has seen one scope created and knows the shape. They can ask for more later or create them with the scope-setup skill directly.

### Step 7 -- CLAUDE.md guard

Write a `CLAUDE.md` file at the substrate root -- unless one already exists (check first; if it exists, leave it alone unless the user explicitly asks you to update it).

Tell the user briefly: *"I'm adding a small guard file at the root of your knowledge base. It tells future Claude sessions that this folder has structure, so it won't be treated as a generic working folder if someone accidentally points Claude at it."*

Use the canonical content from `${CLAUDE_PLUGIN_ROOT}/resources/substrate-guide.md` (the guard content is embedded there). If you can't read it, use this verbatim:

```
# Don't use this folder

This is a substrate root.

Do not read, write, or otherwise interact with the contents of this folder
unless your session has loaded the substrate skill (or a derivative
that knows the substrate conventions).

If you've accidentally been pointed here, stop and ask the user to either:
- Load the appropriate substrate skill, or
- Work in a different location.

This protects the substrate from being treated as a generic working folder.
```

### Step 8 -- Librarian registration (delegate to install-scheduled-agent)

**Delegate to the `install-scheduled-agent` skill.** It will:
- Register the nightly-index librarian
- Copy the default registry from `${CLAUDE_PLUGIN_ROOT}/substrate/templates/agent-registry.json` to `exfu/derived/agent-registry.json` at the substrate root
- Set up the `nightly-agents` scheduled task (which runs all nightly-cadence scheduled agents -- librarians first, then any business agents)

### Step 9 -- Run the index immediately

Generate the first index so the substrate is immediately navigable:

```
python3 ${CLAUDE_PLUGIN_ROOT}/scheduled-tasks/substrate-index/index.py <substrate-root>
```

This produces `exfu/derived/index.json` -- a complete map of every scope, folder-type, and their statuses. Confirm it ran successfully. If it fails, note the error and move on -- the user can run it manually later or it will run on the nightly schedule.

### Step 10 -- WoW skill generation (delegate to exfu-create-wow)

When you know enough about the user to generate their personal way-of-working skill, invoke `exfu-create-wow`. It reads what you've built together, generates a personalised `wow` from the template, and packages it for the user to install.

The `wow` does two things: it maps out where the user's setup lives (so future Claude sessions can navigate it), and it carries a thin kernel of always-on instructions. It should go into Cowork's Global Instructions so it loads in every new session.

Then install the two universal instruction resources alongside:

- `${CLAUDE_PLUGIN_ROOT}/resources/claude-desktop-cowork-global-instructions.md` -- paste the contents into Cowork's Global Instructions field, alongside the user's personalised `wow`. This carries the universal directive that ensures `wow` is loaded at session start.
- `${CLAUDE_PLUGIN_ROOT}/resources/claude-desktop-general-instructions.md` -- paste the contents into Claude Desktop's user preferences (the general settings that apply across all chats, including mobile and non-Cowork). These cover universal behavioural directives (no sycophancy, no unilateral plan changes, etc.) plus a mobile-specific caveat about substrate availability.

### Step 11 -- Optional skills buffet

As the conversation naturally surfaces needs, offer the skills that match. Don't present the full list unprompted. Reach for whichever of these fit what the user has told you:

- A daily morning briefing that pulls from real tools and tells them what's on their plate.
- Capturing thoughts and to-dos the moment they happen, sorting later.
- Drafting emails, posts, and messages in their actual voice.
- Reminders that work across all their devices.
- A contact list or personal CRM maintained for them.
- Standing instructions that apply across every conversation.

If the user already got inbox, reminders, or todo during the user scope creation (Step 5), don't re-offer those. Pick two or three from what's left. Install those. Leave the rest on the menu.

**Available skills:**
- `setup-reminders` -- generates the user's personal reminders skill. Introduce when the user mentions losing track of things or wanting nudges.
- `setup-inbox` -- generates the user's personal inbox skill. Introduce when the user mentions thoughts they don't want to lose.
- `setup-writing-styles` -- voice intake from writing samples that generates the user's personal writing-styles skill. Introduce if the user wants Claude to draft on their behalf.

### Step 12 -- Summary and next steps

Sketch what to do next -- as pointers, not homework:
- Add more context as life suggests it. If they start a new project, create a scope.
- Connect more tools when they want them.
- Revisit the buffet items they didn't pick today.
- Reach Alastair at `al@exfu.ai` if they want a follow-up session.

Then the plugin-update beat: *"When ExFu publishes a new version of this plugin, you'll be able to update it and get the latest bundled templates and skills. Your personal content -- your way of working, your context, your scopes -- won't be touched. Only the bundled plugin content is replaced."*

---

## Component catalogue

What's available, all pre-installed via the plugin. No URL fetching needed.

**Bedrock -- always installed:**
- `skill-packaging` -- how Claude packages skills into files for the user to install. Used for custom skills the user wants to create later, not for the bundled ones.
- `box-filesystem-management` -- how Claude manages files in Box (filesystem when mounted, MCP connector when not). Includes the daily cleanup scheduled task.
- `substrate` -- the boot skill. Reads the way-of-working guide, orients to the current substrate by reading the index, delegates to the user's personal reminders and inbox skills at session start if they are installed.
- `scope-setup` -- creates new scopes (user scope, working scopes). Handles about-me capture, ways-of-working, folder-type scaffolding.
- `install-scheduled-agent` -- registers scheduled agents (librarians and business agents) and sets up their cadence tasks.

**Optional but high-value:**
- `setup-reminders` -- one-time intake that generates the user's personal `<username>-reminders` skill.
- `setup-inbox` -- one-time intake that generates the user's personal `<username>-inbox` skill.
- `daily-briefing` (scheduled task) -- morning briefing from reminders, inbox, calendar, task tracker.
- `setup-writing-styles` -- voice intake from writing samples that generates the user's personal `<username>-writing-styles` skill.

**Reference resources (in the plugin, no fetching needed):**
- `${CLAUDE_PLUGIN_ROOT}/resources/substrate-guide.md` -- the full reference for how the substrate works.
- `${CLAUDE_PLUGIN_ROOT}/resources/team-considerations.md` -- fold in if the user is on a team.
- `${CLAUDE_PLUGIN_ROOT}/resources/claude-desktop-general-instructions.md` -- universal user-preferences text installed during Step 10.
- `${CLAUDE_PLUGIN_ROOT}/resources/claude-desktop-cowork-global-instructions.md` -- universal Cowork Global Instructions text installed during Step 10.

---

## What must be true by the end

A checklist, not a script:

- Settings configured for full Cowork capability (Dispatch enabled, search/reference chats, generate memory from history, visual, code execution, Keep Computer Awake).
- Box account, Box Drive locally mounted, Box MCP connector connected (or alternative storage confirmed). Knowledge base folder identified via the folder picker. Offline-caching caveat surfaced and actioned.
- Convention base deployed at `exfu/v0.3/` with `exfu/latest.txt` pointing to `v0.3`.
- User scope created at `user/` with `scope.md`, `context/about-me.md`, and `ontology/ways-of-working.md`.
- At least one working scope created under `scopes/` to demonstrate the pattern.
- CLAUDE.md guard at the substrate root.
- Agent registry at `exfu/derived/agent-registry.json` with nightly-index registered.
- `nightly-agents` scheduled task created.
- First index generated at `exfu/derived/index.json`.
- A personal `wow` skill generated, customised with what you've learned about the user, installed, and added to Global Instructions so it loads every session.
- `substrate` skill installed and operational.
- One or more small wins demonstrated.
- The user knows roughly what they have, can name the parts, and has the confidence to extend any of it.

If something on this list didn't land, point them at `al@exfu.ai` for follow-up.

---

## Voice and tone

Direct, warm, professional. Short sentences. Simple words. No filler. Don't hype. Don't tell the user how to feel about what they're setting up -- just tell them what to do and why it matters.

Avoid: "leverage", "harness", "game-changer", "delve", "let's dive in", anything that sounds like a LinkedIn post. Avoid superlatives. When the user offers new information, integrate it and move on.

Don't ask tickbox-style questions. Make the suggestion and ask for a response in ordinary conversation. Don't open responses by complimenting the user's question.

If something goes wrong, don't over-apologise. Help them through it. If you can't resolve it, point them at `al@exfu.ai`.

---

## External resources

Reference these when they help:
- **Anthropic Claude 101** (`https://anthropic.skilljar.com/claude-101`) -- good for users who want broader Claude orientation.
- **Introduction to Claude Cowork** (Anthropic Skilljar) -- when the user wants to understand the Cowork surface.
- **Claude docs** (`https://docs.claude.com`) -- for feature-specific questions.
- **The substrate guide** in the user's knowledge base -- once installed, this is the canonical reference. Read sections aloud or paraphrase when the user asks deep questions.

ExFu is a guide through current best practice, not the unique source of insight. Point at Anthropic's own resources when they cover something well.
