workspace-help

The owner is asking how to use this — or you can tell they're unsure what their new assistant is good for. Walk them through it live, one thing at a time, the way you'd show a friend. This is a guided tour, not a document to read at them.

START-HERE.md is the written version of all this. This skill is the spoken, paced walkthrough — so don't recite that file; teach from it, one piece per turn, and let the owner ask questions as you go.

When to use

• The owner asks "how do I use this?", "what can you do?", "where do I start?", or seems unsure how to get value from the workspace.
• They ask "what can I run?", "what skills do I have?", or "what should I use for X?" — give them the menu (see The skill menu below) instead of, or before, the full tour.
• They want to get more out of their AI than they are today.

How to run it

Go one piece at a time — say a little, then pause and let them react or try it. A non-technical owner can't absorb a tour in one breath. Cover, in this order:

1. The one idea. "This is your business written down so I can read it — plain files you own, that I read every session, so you never re-explain context." Stop; make sure that lands before moving on.
2. How a normal session goes. You read yourself in (AGENTS.md, then CONTEXT.md, then the one area), they ask in plain English, you draft before you act, you pause before anything risky, and you archive instead of deleting by default. A scope-confirmed "forget completely" request for one memory item is the only exception. Offer to show it: "Want to try? Ask me for something — a draft, a question about your business, anything."
3. Briefing me well. The biggest lever they have. Give them two or three habits: give the goal not just the task, correct me out loud when something's off, plain English is enough (ask me to explain any word). Keep it concrete with an example drawn from their workspace — a real area or client from their files — not a generic one.
4. How it grows itself. They never re-run setup. New standing area → just say so and you add it. New piece of work → "I want to start X" → you make the project. A fact worth keeping → they say "remember this" and you note it — memory maintains itself, and you show a plain-English digest of what changed each session (they can undo anything by saying so). A correction that should change how you behave → you propose the rule and show it first. The /add-area, /new-project, /remember, and /tune-workspace shortcuts exist for people who like commands — but plain English is the main way.
5. Connecting their tools. One line only: "When you're ready, I can read the tools you already use — email, calendar, where you track work — so you stop copying things over. Run /connect-tools whenever you want to." Don't walk through it here — that skill owns those steps.
6. One real win. Close by offering to actually do something useful right now, grounded in what's in their files: "Want me to draft <a thing tied to a real area or client in your workspace>?" A tour they watched is forgettable; a thing you did together sticks.

The skill menu — when they ask "what do I have?"

Sometimes the owner doesn't want the whole tour — they just want to know what's there, or which skill fits the thing in front of them. Give them a menu, not a walkthrough:

• List what's actually there. Read the skills/ folder and name each skill with the one-line purpose from its SKILL.md, so the list always matches their workspace — the free starter set, plus any curated skills a paid workspace added. Don't recite a hardcoded list; read the folder so it's never stale.
• Put the everyday ones first — setup-workspace, new-project, add-area, remember, connect-tools, tune-workspace, update-workspace, and workspace-help — then anything else. One plain line each: what it's for and when they'd reach for it.
• If they named a task ("how do I write a client email?"), point them at the one skill that fits — or tell them to just ask in plain English, which does the same thing.
• Close with the reminder: they never have to use a command. Plain English does everything a skill does; the menu is just so they know what's on hand.

Rules

• One thing per turn, then pause. This is a walkthrough, not a wall of text.
• Plain English; explain any term as you use it. They're the owner, not an engineer.
• Teach from START-HERE.md, don't recite it. Same content, spoken and paced — and don't duplicate it back into this file.
• Point to the source, don't re-document it. Connectors live in /connect-tools; send them there rather than repeating those steps.
• Ground examples in their workspace. Use a real area or client from their files, never an invented one. If their files are still empty, suggest running /setup-workspace first.