showpane 0.4.14 → 0.4.16

package/bundle/toolchain/skills/portal-onboard/SKILL.md.tmpl

@@ -12,7 +12,7 @@ allowed-tools: [Bash, Read, Write, Edit, Glob, Grep]
 
 ## Overview
 
-`/portal onboard` is the canonical first-run workflow. It should feel like one
+`/portal-onboard` is the canonical first-run workflow. It should feel like one
 coherent wizard, not like the user is manually hopping between separate skills.
 
 The recommended shape is:
@@ -69,15 +69,14 @@ Start with a compact welcome:
  ╚══════════════════════════════════════════╝
 ```
 
-Then explain the flow in plain language:
+Then use one short, friendly paragraph. Keep it concise and informal.
 
-- local setup if needed
-- first draft
-- local preview
-- access setup
-- cloud publish
+Suggested shape:
 
-Do not lead with prompt examples. This skill is the first-run default.
+- "Let's get your first portal started."
+- "Who's it for, and what's the context? If you've got a call transcript, paste it in and I'll use that too."
+
+Keep the opening focused on the user's first portal. This skill is the first-run default, so the top of the flow should feel fast, calm, and immediately useful.
 
 Immediately save checkpoint:
 
@@ -97,15 +96,28 @@ If config exists, verify only the minimum first-run requirements before continui
 - local SQLite schema is ready
 - org exists or can be created
 
-Keep this phase minimal. For first-run onboarding, collect only the minimum
-company context needed to make the first portal feel real:
+Keep this phase minimal.
+
+If the local checks pass, move straight into the user's portal work without extra system narration.
+
+If there is already exactly one local organization and it clearly matches the
+workspace the user just created, treat the org basics as already captured.
+Do not create a separate "company context" phase just to re-ask the same setup
+details.
+
+Only ask for a missing field, and ask exactly one thing at a time.
+
+Recommended order for missing fields:
+
+1. organization name, if it is not already obvious from the workspace setup
+2. contact email
+3. website/domain
 
-- organization name
-- contact email
-- website/domain if available
+Do not batch these into a numbered questionnaire unless the user explicitly asks
+for the full checklist.
 
 Optional extras like brand color, phone number, or contact title belong in
-`/portal setup` later if needed.
+`/portal-setup` later if needed.
 
 If setup fails, stop with a concrete recovery step and keep the checkpoint.
 
@@ -113,9 +125,20 @@ Save checkpoint with phase `local-ready`.
 
 ### Phase 3: Choose the first-portal source
 
-Recommended order:
+Start with one short source question, not a menu.
+
+Recommended opening:
+
+- "Who's it for, and what's the context? If you've got a call transcript, paste it in and I'll use that too."
+
+Only branch after the user answers:
+
+- if they have a real transcript, ask whether to use Granola or paste it
+- if they do not, ask whether they want to start from notes or a template
+
+Only show the full menu if the user is unsure:
 
-1. recent Granola meeting if available
+1. recent Granola meeting
 2. pasted transcript
 3. short description of the client + meeting outcome
 4. template-only start
@@ -160,7 +183,7 @@ Recommended refinement prompts:
 - `Do you want the portal to feel more concise, more sales-focused, or more delivery-focused?`
 - `Should we add anything practical before preview — timeline, documents, or sharper next steps?`
 
-Apply the requested refinement inline, using the same patterns as `/portal update`
+Apply the requested refinement inline, using the same patterns as `/portal-update`
 without forcing the user to switch skills.
 
 If the user is happy with the first draft, move on immediately.
@@ -253,8 +276,8 @@ Show a compact final reference card:
   Cloud:  <hosted-url-or-publishing-status>
   Access: <hosted login / hosted share link / both>
 
-  Next: /portal update <slug>
-  Help: /portal list, /portal status
+  Next: /portal-update <slug>
+  Help: /portal-list, /portal-status
 ════════════════════════════════════════
 ```
 
@@ -309,9 +332,9 @@ to continue refining it or create a new portal. Recommend continuing unless the
 - Missing config is not a preamble failure here. It simply means setup starts from scratch.
 - If a step fails after useful progress, keep the checkpoint and tell the user exactly how to resume.
 - If the user wants to stop early, summarize the current state and point them to the next concrete skill:
-  - `/portal preview`
-  - `/portal credentials`
-  - `/portal share`
-  - `/portal deploy`
+  - `/portal-preview`
+  - `/portal-credentials`
+  - `/portal-share`
+  - `/portal-deploy`
 
 {{COMPLETION}}

package/bundle/toolchain/skills/portal-preview/SKILL.md

@@ -15,7 +15,7 @@ SHOWPANE_HOME="$HOME/.showpane"
 SHOWPANE_BIN="$SHOWPANE_HOME/bin"
 CONFIG="$SHOWPANE_HOME/config.json"
 if [ ! -f "$CONFIG" ]; then
-  echo "Showpane not configured. Run /portal setup first."
+  echo "Showpane not configured. Run /portal-setup first."
   exit 1
 fi
 
@@ -68,16 +68,13 @@ echo "TEL_PROMPTED: $TEL_PROMPTED"
 
 If output shows `JUST_UPGRADED <from> <to>`, tell the user Showpane was just upgraded and continue.
 
-If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal upgrade`.
+If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal-upgrade`.
 
-If `TEL_PROMPTED` is `no`, ask the user once about telemetry and then record the decision:
+If `TEL_PROMPTED` is `no`, default telemetry to `anonymous` without interrupting the flow. Do not mention telemetry unless the user asks.
 
-- anonymous — local analytics plus anonymous remote sync, with no stable device id
-- off — local analytics only, no remote sync
-
-After the user chooses, run:
+Run:
 ```bash
-"$SHOWPANE_BIN/showpane-config" set telemetry <anonymous|off>
+"$SHOWPANE_BIN/showpane-config" set telemetry anonymous
 touch "$SHOWPANE_HOME/.telemetry-prompted"
 ```
 
@@ -109,8 +106,8 @@ If the user specified a slug (e.g., "preview whzan"), use that slug directly.
 
 If no slug is provided, check how many portals exist:
 - If there is exactly one portal, use that one and mention it: "Opening your only portal: <slug>"
-- If there are multiple portals, ask: "Which portal do you want to preview? Run /portal list to see your portals."
-- If there are zero portals, say: "No portals found. Create one first with /portal create."
+- If there are multiple portals, ask: "Which portal do you want to preview? Run /portal-list to see your portals."
+- If there are zero portals, say: "No portals found. Create one first with /portal-create."
 
 For single-portal organizations, auto-selecting saves a round trip.
 
@@ -142,7 +139,7 @@ This handles deployed URLs, custom domains, and any other public preview target.
 
 If no server is detected and no app URL is configured, do not open the browser. Instead, inform the user:
 
-"No running server detected. Start the dev server with /portal dev, or set NEXT_PUBLIC_APP_URL in your .env file."
+"No running server detected. Start the dev server with /portal-dev, or set NEXT_PUBLIC_APP_URL in your .env file."
 
 ### Step 3: Open the URL in the browser
 
@@ -180,7 +177,7 @@ URL: http://localhost:3000/client/<slug>
 ```
 
 If the portal has credentials set up, remind the user:
-"Login with the credentials from /portal credentials <slug>. For external access, publish first with /portal deploy."
+"Login with the credentials from /portal-credentials <slug>. For external access, publish first with /portal-deploy."
 
 If the portal is the example portal (slug is "example"), no credentials are needed -- it is publicly accessible by design.
 
@@ -207,7 +204,7 @@ This order ensures that during development, the user always sees the latest loca
 - **Port conflict**: If port 3000 has a non-Showpane process running, `lsof` will still detect it and the URL will be wrong. This is unlikely in practice but worth noting. The user will see a different app in the browser and can correct by specifying the URL manually.
 - **WSL (Windows Subsystem for Linux)**: `xdg-open` may not work. On WSL, use `wslview` or `explorer.exe` instead. Detect WSL via `grep -qi microsoft /proc/version`.
 - **SSH/remote session**: If the user is connected via SSH, opening a browser on the remote machine does nothing useful. Detect this via the `SSH_CONNECTION` environment variable and print the URL instead: "You appear to be in an SSH session. Visit this URL on your local machine: <url>"
-- **Inactive portal**: If the portal is deactivated (`isActive: false`), the preview will show a "not found" page. Warn the user: "Portal '<slug>' is inactive. You'll see a not-found page. Reactivate it first or use /portal list to check status."
+- **Inactive portal**: If the portal is deactivated (`isActive: false`), the preview will show a "not found" page. Warn the user: "Portal '<slug>' is inactive. You'll see a not-found page. Reactivate it first or use /portal-list to check status."
 
 ## Error Handling
 
@@ -219,21 +216,21 @@ This order ensures that during development, the user always sees the latest loca
 
 When the portal opens in the browser, the client will see a login page (unless they have an active session or use a share link). Provide context about how to access the portal:
 
-- **Has credentials**: Remind the user of the username (derived from the slug). Do not display the password -- they can get it from `/portal credentials <slug>` if they need it.
-- **No credentials**: Warn that the portal will show a login page but there are no credentials to enter. Suggest running `/portal credentials <slug>` first.
+- **Has credentials**: Remind the user of the username (derived from the slug). Do not display the password -- they can get it from `/portal-credentials <slug>` if they need it.
+- **No credentials**: Warn that the portal will show a login page but there are no credentials to enter. Suggest running `/portal-credentials <slug>` first.
 - **Example portal**: The built-in example at `/client/example` is publicly accessible and does not require login. No credentials needed.
 
-If the user is previewing to check content before sharing with a client, suggest: "To see exactly what the client will see, open an incognito/private window. Your existing session cookies may affect the view. When the portal looks right, publish it with /portal deploy before sending anything externally."
+If the user is previewing to check content before sharing with a client, suggest: "To see exactly what the client will see, open an incognito/private window. Your existing session cookies may affect the view. When the portal looks right, publish it with /portal-deploy before sending anything externally."
 
 ## Previewing After Changes
 
-A common workflow is: edit portal content with `/portal update`, then preview to verify. If the dev server is running with Next.js hot reload, changes to the client component files will appear immediately without a page refresh.
+A common workflow is: edit portal content with `/portal-update`, then preview to verify. If the dev server is running with Next.js hot reload, changes to the client component files will appear immediately without a page refresh.
 
-If the user just ran `/portal update` and then `/portal preview`, mention: "If you don't see your changes, make sure the dev server is running so hot reload can pick them up."
+If the user just ran `/portal-update` and then `/portal-preview`, mention: "If you don't see your changes, make sure the dev server is running so hot reload can pick them up."
 
 ## Multiple Portals Preview
 
-If the user asks to "preview all portals" or "open all my portals", open each one in a separate browser tab. However, limit to 5 tabs maximum to avoid browser overload. If there are more than 5 portals, open the 5 most recently updated and note: "Opened the 5 most recently updated portals. Use /portal preview <slug> for specific portals."
+If the user asks to "preview all portals" or "open all my portals", open each one in a separate browser tab. However, limit to 5 tabs maximum to avoid browser overload. If there are more than 5 portals, open the 5 most recently updated and note: "Opened the 5 most recently updated portals. Use /portal-preview <slug> for specific portals."
 
 To open multiple tabs, run the open command for each URL sequentially:
 

package/bundle/toolchain/skills/portal-preview/SKILL.md.tmpl

@@ -22,8 +22,8 @@ If the user specified a slug (e.g., "preview whzan"), use that slug directly.
 
 If no slug is provided, check how many portals exist:
 - If there is exactly one portal, use that one and mention it: "Opening your only portal: <slug>"
-- If there are multiple portals, ask: "Which portal do you want to preview? Run /portal list to see your portals."
-- If there are zero portals, say: "No portals found. Create one first with /portal create."
+- If there are multiple portals, ask: "Which portal do you want to preview? Run /portal-list to see your portals."
+- If there are zero portals, say: "No portals found. Create one first with /portal-create."
 
 For single-portal organizations, auto-selecting saves a round trip.
 
@@ -55,7 +55,7 @@ This handles deployed URLs, custom domains, and any other public preview target.
 
 If no server is detected and no app URL is configured, do not open the browser. Instead, inform the user:
 
-"No running server detected. Start the dev server with /portal dev, or set NEXT_PUBLIC_APP_URL in your .env file."
+"No running server detected. Start the dev server with /portal-dev, or set NEXT_PUBLIC_APP_URL in your .env file."
 
 ### Step 3: Open the URL in the browser
 
@@ -93,7 +93,7 @@ URL: http://localhost:3000/client/<slug>
 ```
 
 If the portal has credentials set up, remind the user:
-"Login with the credentials from /portal credentials <slug>. For external access, publish first with /portal deploy."
+"Login with the credentials from /portal-credentials <slug>. For external access, publish first with /portal-deploy."
 
 If the portal is the example portal (slug is "example"), no credentials are needed -- it is publicly accessible by design.
 
@@ -120,7 +120,7 @@ This order ensures that during development, the user always sees the latest loca
 - **Port conflict**: If port 3000 has a non-Showpane process running, `lsof` will still detect it and the URL will be wrong. This is unlikely in practice but worth noting. The user will see a different app in the browser and can correct by specifying the URL manually.
 - **WSL (Windows Subsystem for Linux)**: `xdg-open` may not work. On WSL, use `wslview` or `explorer.exe` instead. Detect WSL via `grep -qi microsoft /proc/version`.
 - **SSH/remote session**: If the user is connected via SSH, opening a browser on the remote machine does nothing useful. Detect this via the `SSH_CONNECTION` environment variable and print the URL instead: "You appear to be in an SSH session. Visit this URL on your local machine: <url>"
-- **Inactive portal**: If the portal is deactivated (`isActive: false`), the preview will show a "not found" page. Warn the user: "Portal '<slug>' is inactive. You'll see a not-found page. Reactivate it first or use /portal list to check status."
+- **Inactive portal**: If the portal is deactivated (`isActive: false`), the preview will show a "not found" page. Warn the user: "Portal '<slug>' is inactive. You'll see a not-found page. Reactivate it first or use /portal-list to check status."
 
 ## Error Handling
 
@@ -132,21 +132,21 @@ This order ensures that during development, the user always sees the latest loca
 
 When the portal opens in the browser, the client will see a login page (unless they have an active session or use a share link). Provide context about how to access the portal:
 
-- **Has credentials**: Remind the user of the username (derived from the slug). Do not display the password -- they can get it from `/portal credentials <slug>` if they need it.
-- **No credentials**: Warn that the portal will show a login page but there are no credentials to enter. Suggest running `/portal credentials <slug>` first.
+- **Has credentials**: Remind the user of the username (derived from the slug). Do not display the password -- they can get it from `/portal-credentials <slug>` if they need it.
+- **No credentials**: Warn that the portal will show a login page but there are no credentials to enter. Suggest running `/portal-credentials <slug>` first.
 - **Example portal**: The built-in example at `/client/example` is publicly accessible and does not require login. No credentials needed.
 
-If the user is previewing to check content before sharing with a client, suggest: "To see exactly what the client will see, open an incognito/private window. Your existing session cookies may affect the view. When the portal looks right, publish it with /portal deploy before sending anything externally."
+If the user is previewing to check content before sharing with a client, suggest: "To see exactly what the client will see, open an incognito/private window. Your existing session cookies may affect the view. When the portal looks right, publish it with /portal-deploy before sending anything externally."
 
 ## Previewing After Changes
 
-A common workflow is: edit portal content with `/portal update`, then preview to verify. If the dev server is running with Next.js hot reload, changes to the client component files will appear immediately without a page refresh.
+A common workflow is: edit portal content with `/portal-update`, then preview to verify. If the dev server is running with Next.js hot reload, changes to the client component files will appear immediately without a page refresh.
 
-If the user just ran `/portal update` and then `/portal preview`, mention: "If you don't see your changes, make sure the dev server is running so hot reload can pick them up."
+If the user just ran `/portal-update` and then `/portal-preview`, mention: "If you don't see your changes, make sure the dev server is running so hot reload can pick them up."
 
 ## Multiple Portals Preview
 
-If the user asks to "preview all portals" or "open all my portals", open each one in a separate browser tab. However, limit to 5 tabs maximum to avoid browser overload. If there are more than 5 portals, open the 5 most recently updated and note: "Opened the 5 most recently updated portals. Use /portal preview <slug> for specific portals."
+If the user asks to "preview all portals" or "open all my portals", open each one in a separate browser tab. However, limit to 5 tabs maximum to avoid browser overload. If there are more than 5 portals, open the 5 most recently updated and note: "Opened the 5 most recently updated portals. Use /portal-preview <slug> for specific portals."
 
 To open multiple tabs, run the open command for each URL sequentially:
 

package/bundle/toolchain/skills/portal-setup/SKILL.md

@@ -73,16 +73,13 @@ echo "TEL_PROMPTED: $TEL_PROMPTED"
 
 If output shows `JUST_UPGRADED <from> <to>`, tell the user Showpane was just upgraded and continue.
 
-If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal upgrade`.
+If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal-upgrade`.
 
-If `TEL_PROMPTED` is `no`, ask the user once about telemetry and then record the decision:
+If `TEL_PROMPTED` is `no`, default telemetry to `anonymous` without interrupting the flow. Do not mention telemetry unless the user asks.
 
-- anonymous — local analytics plus anonymous remote sync, with no stable device id
-- off — local analytics only, no remote sync
-
-After the user chooses, run:
+Run:
 ```bash
-"$SHOWPANE_BIN/showpane-config" set telemetry <anonymous|off>
+"$SHOWPANE_BIN/showpane-config" set telemetry anonymous
 touch "$SHOWPANE_HOME/.telemetry-prompted"
 ```
 
@@ -140,7 +137,7 @@ When the user is inside a freshly generated Showpane project, the setup should:
 - Prefer the current working directory as `APP_PATH`
 - Skip any suggestion to clone the upstream Showpane repository
 - Auto-detect SQLite from DATABASE_URL (if it starts with "file:" it's SQLite)
-- Still ask for org name, contact details, and website URL
+- Reuse the existing workspace org name if it is already obvious, then ask for the next missing contact detail one at a time
 - Be concise — the user just ran `npx showpane` and wants to get going fast
 
 ### Step 3: Set the workspace mode
@@ -190,12 +187,17 @@ Do NOT proceed until the local schema is applied successfully.
 
 Ask the user for their organization details one at a time. Do not present all questions at once — guide them through the process conversationally.
 
-1. **Organization name** (required) — e.g., "Acme Consulting". This is the name that appears in portal headers alongside the client name.
+Before asking anything, check the local database. If there is already exactly one organization and it clearly matches the workspace the user just created, keep it as the default and do not ask for the organization name again unless the user wants to change it.
+
+If the org already exists with a real name, ask only for the next missing field.
+Do not restart the whole org questionnaire from the top.
+
+1. **Organization name** (required only if not already known) — e.g., "Acme Consulting". This is the name that appears in portal headers alongside the client name.
 2. **Contact name** (required) — the person who appears on portal footers as the point of contact, e.g., "Jane Smith". This is typically the account manager or sales rep.
 3. **Contact email** (required) — e.g., "jane@acme.com". Displayed in the portal footer as a mailto link.
 4. **Contact title** (optional, default: "Account Manager") — e.g., "Director", "Partner", "Client Success Lead". Shown next to the contact name in the portal footer.
 5. **Contact phone** (optional) — e.g., "+44 7700 900000". If provided, displayed alongside email in the portal footer.
-6. **Company website URL** (optional) — e.g., "acme.com". Used to auto-fetch the company logo via Clearbit.
+6. **Company website URL** — e.g., "acme.com". Ask for it plainly instead of framing it as optional. Used to auto-fetch the company logo via Clearbit.
    - If provided, fetch logo URL: `https://logo.clearbit.com/{domain}` and store in `Organization.logoUrl`
    - Also store the URL in `Organization.websiteUrl`
 7. **Contact avatar**: Auto-populated from the contact email via Gravatar. No need to ask — just use `getAvatarUrl(email, contactName)` from `app/src/lib/branding.ts` and store in `Organization.contactAvatar`
@@ -227,7 +229,7 @@ Validate the input is a valid hex color:
 
 Update the Organization record with `primaryColor` set to the validated hex value. The portal app reads this value and applies it via CSS custom properties (the `--primary` variable in the Tailwind theme).
 
-If the user says "skip" or "default", use `#1a1a1a`. Brand color can always be changed later by running `/portal setup` again.
+If the user says "skip" or "default", use `#1a1a1a`. Brand color can always be changed later by running `/portal-setup` again.
 
 ### Step 8: Telemetry reminder
 
@@ -279,8 +281,8 @@ Showpane setup complete!
   Telemetry:    anonymous
 
 Next steps:
-  1. Recommended first run:    /portal onboard
-  2. Fast repeat-user path:    /portal create <slug>
+  1. Recommended first run:    /portal-onboard
+  2. Fast repeat-user path:    /portal-create <slug>
   3. View the example portal:  open http://localhost:3000/client/example
 ```
 

package/bundle/toolchain/skills/portal-setup/SKILL.md.tmpl

@@ -54,7 +54,7 @@ When the user is inside a freshly generated Showpane project, the setup should:
 - Prefer the current working directory as `APP_PATH`
 - Skip any suggestion to clone the upstream Showpane repository
 - Auto-detect SQLite from DATABASE_URL (if it starts with "file:" it's SQLite)
-- Still ask for org name, contact details, and website URL
+- Reuse the existing workspace org name if it is already obvious, then ask for the next missing contact detail one at a time
 - Be concise — the user just ran `npx showpane` and wants to get going fast
 
 ### Step 3: Set the workspace mode
@@ -104,12 +104,17 @@ Do NOT proceed until the local schema is applied successfully.
 
 Ask the user for their organization details one at a time. Do not present all questions at once — guide them through the process conversationally.
 
-1. **Organization name** (required) — e.g., "Acme Consulting". This is the name that appears in portal headers alongside the client name.
+Before asking anything, check the local database. If there is already exactly one organization and it clearly matches the workspace the user just created, keep it as the default and do not ask for the organization name again unless the user wants to change it.
+
+If the org already exists with a real name, ask only for the next missing field.
+Do not restart the whole org questionnaire from the top.
+
+1. **Organization name** (required only if not already known) — e.g., "Acme Consulting". This is the name that appears in portal headers alongside the client name.
 2. **Contact name** (required) — the person who appears on portal footers as the point of contact, e.g., "Jane Smith". This is typically the account manager or sales rep.
 3. **Contact email** (required) — e.g., "jane@acme.com". Displayed in the portal footer as a mailto link.
 4. **Contact title** (optional, default: "Account Manager") — e.g., "Director", "Partner", "Client Success Lead". Shown next to the contact name in the portal footer.
 5. **Contact phone** (optional) — e.g., "+44 7700 900000". If provided, displayed alongside email in the portal footer.
-6. **Company website URL** (optional) — e.g., "acme.com". Used to auto-fetch the company logo via Clearbit.
+6. **Company website URL** — e.g., "acme.com". Ask for it plainly instead of framing it as optional. Used to auto-fetch the company logo via Clearbit.
    - If provided, fetch logo URL: `https://logo.clearbit.com/{domain}` and store in `Organization.logoUrl`
    - Also store the URL in `Organization.websiteUrl`
 7. **Contact avatar**: Auto-populated from the contact email via Gravatar. No need to ask — just use `getAvatarUrl(email, contactName)` from `app/src/lib/branding.ts` and store in `Organization.contactAvatar`
@@ -141,7 +146,7 @@ Validate the input is a valid hex color:
 
 Update the Organization record with `primaryColor` set to the validated hex value. The portal app reads this value and applies it via CSS custom properties (the `--primary` variable in the Tailwind theme).
 
-If the user says "skip" or "default", use `#1a1a1a`. Brand color can always be changed later by running `/portal setup` again.
+If the user says "skip" or "default", use `#1a1a1a`. Brand color can always be changed later by running `/portal-setup` again.
 
 ### Step 8: Telemetry reminder
 
@@ -193,8 +198,8 @@ Showpane setup complete!
   Telemetry:    anonymous
 
 Next steps:
-  1. Recommended first run:    /portal onboard
-  2. Fast repeat-user path:    /portal create <slug>
+  1. Recommended first run:    /portal-onboard
+  2. Fast repeat-user path:    /portal-create <slug>
   3. View the example portal:  open http://localhost:3000/client/example
 ```
 

package/bundle/toolchain/skills/portal-share/SKILL.md

@@ -18,7 +18,7 @@ SHOWPANE_HOME="$HOME/.showpane"
 SHOWPANE_BIN="$SHOWPANE_HOME/bin"
 CONFIG="$SHOWPANE_HOME/config.json"
 if [ ! -f "$CONFIG" ]; then
-  echo "Showpane not configured. Run /portal setup first."
+  echo "Showpane not configured. Run /portal-setup first."
   exit 1
 fi
 
@@ -71,16 +71,13 @@ echo "TEL_PROMPTED: $TEL_PROMPTED"
 
 If output shows `JUST_UPGRADED <from> <to>`, tell the user Showpane was just upgraded and continue.
 
-If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal upgrade`.
+If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal-upgrade`.
 
-If `TEL_PROMPTED` is `no`, ask the user once about telemetry and then record the decision:
+If `TEL_PROMPTED` is `no`, default telemetry to `anonymous` without interrupting the flow. Do not mention telemetry unless the user asks.
 
-- anonymous — local analytics plus anonymous remote sync, with no stable device id
-- off — local analytics only, no remote sync
-
-After the user chooses, run:
+Run:
 ```bash
-"$SHOWPANE_BIN/showpane-config" set telemetry <anonymous|off>
+"$SHOWPANE_BIN/showpane-config" set telemetry anonymous
 touch "$SHOWPANE_HOME/.telemetry-prompted"
 ```
 
@@ -108,7 +105,7 @@ Share links use HMAC-SHA256 signed tokens. The token encodes the portal slug, a
 
 ### Step 1: Identify the target portal
 
-The user must specify which portal to share. If no slug is provided, ask: "Which portal do you want to share? Run /portal list to see your portals."
+The user must specify which portal to share. If no slug is provided, ask: "Which portal do you want to share? Run /portal-list to see your portals."
 
 Do not proceed without a slug. Share links are portal-specific.
 
@@ -134,8 +131,8 @@ Expected success response:
 
 Expected error responses:
 
-- `portal_not_found`: The slug does not exist. Suggest `/portal list`.
-- `no_credentials`: The portal has no credentials set up. Share links require credentials because the token's validity is tied to the credential version. Suggest running `/portal credentials <slug>` first.
+- `portal_not_found`: The slug does not exist. Suggest `/portal-list`.
+- `no_credentials`: The portal has no credentials set up. Share links require credentials because the token's validity is tied to the credential version. Suggest running `/portal-credentials <slug>` first.
 - `no_auth_secret`: AUTH_SECRET is not set in the app's `.env`. The user needs to add one. Suggest: `openssl rand -base64 32` to generate a secret.
 - `no_app_url`: NEXT_PUBLIC_APP_URL is not set. The script cannot construct the full share URL. Ask the user what their portal's public URL is.
 
@@ -164,7 +161,7 @@ If the user has previously generated share links (check learnings for patterns),
 Share links are a convenience feature with intentional security trade-offs:
 
 - **No automatic expiry**: Links remain valid until credentials are rotated, the portal is deactivated, or AUTH_SECRET changes.
-- **Credential version binding**: Rotating credentials invalidates all outstanding share links. This is the revocation mechanism -- if a link is compromised, rotate credentials with `/portal credentials <slug>`.
+- **Credential version binding**: Rotating credentials invalidates all outstanding share links. This is the revocation mechanism -- if a link is compromised, rotate credentials with `/portal-credentials <slug>`.
 - **Single portal scope**: Each link grants access to exactly one portal. A share link for "whzan" cannot be used to access "acme".
 - **No re-use tracking**: The link can be used multiple times by anyone who has it. There is no per-user tracking on share links.
 
@@ -175,13 +172,13 @@ Do NOT log the share URL to learnings or telemetry. The URL contains the signed
 - Always display the full URL, never truncate or abbreviate it. The user needs to copy-paste it.
 - Make it clear that the link does not expire automatically and is revoked by credential rotation or portal deactivation.
 - Use double-line box drawing (`═`) for the border around the link.
-- If NEXT_PUBLIC_APP_URL is `http://localhost:3000`, warn the user immediately: "This is a local development URL. Do not send this to a client. Publish with /portal deploy first, then generate the share link again."
+- If NEXT_PUBLIC_APP_URL is `http://localhost:3000`, warn the user immediately: "This is a local development URL. Do not send this to a client. Publish with /portal-deploy first, then generate the share link again."
 
 ## Error Handling
 
 - If AUTH_SECRET is missing, this is a hard blocker. Explain that share links require a signing secret and provide the generation command: `openssl rand -base64 32`.
 - If the portal has no credentials, explain that share links are tied to credential versions and the user needs to set up credentials first.
-- If the script fails for any other reason, show the error message from stderr and suggest the user check their configuration with `/portal status`.
+- If the script fails for any other reason, show the error message from stderr and suggest the user check their configuration with `/portal-status`.
 
 ## Token Anatomy
 
@@ -214,15 +211,15 @@ The signature is computed using AUTH_SECRET from the app's `.env`. If AUTH_SECRE
 
 Common patterns for using share links in practice:
 
-**After publish**: Deploy the portal with `/portal deploy`, then generate a share link if you want a direct hosted access URL instead of asking the client to log in with credentials.
+**After publish**: Deploy the portal with `/portal-deploy`, then generate a share link if you want a direct hosted access URL instead of asking the client to log in with credentials.
 
 **For quick reviews**: If a colleague or stakeholder needs to see the portal but should not have permanent credentials, a share link is ideal. It can be reused and does not create a full operator login.
 
-**Re-sharing after content update**: If you update portal content with `/portal update`, publish the latest version if needed, then generate a fresh share link and send it.
+**Re-sharing after content update**: If you update portal content with `/portal-update`, publish the latest version if needed, then generate a fresh share link and send it.
 
 ## Learnings Integration
 
-After generating a share link, consider recording a learning entry if this is the first time sharing this portal. The learning helps other skills (like `/portal analytics`) provide better context:
+After generating a share link, consider recording a learning entry if this is the first time sharing this portal. The learning helps other skills (like `/portal-analytics`) provide better context:
 
 ```json
 {"skill":"portal-share","key":"share-event","insight":"whzan shared via link on 2026-04-07","confidence":10,"ts":"2026-04-07T14:30:00Z"}
@@ -236,15 +233,15 @@ Share links do not expire automatically in this version.
 
 The revocation mechanisms are:
 
-- rotate credentials with `/portal credentials <slug>`
-- deactivate the portal with `/portal delete <slug>`
+- rotate credentials with `/portal-credentials <slug>`
+- deactivate the portal with `/portal-delete <slug>`
 - rotate `AUTH_SECRET`
 
 ## Multiple Share Links
 
 Generating a new share link does not invalidate the previous one. Both links remain valid until credentials are rotated, the portal is deactivated, or AUTH_SECRET changes. This means the user can safely generate multiple links for the same portal (e.g., one for the client contact, one for their colleague) without affecting each other.
 
-If the user wants to revoke all outstanding share links immediately, the mechanism is credential rotation: `/portal credentials <slug>`. This bumps the credential version, which invalidates all tokens signed against the previous version.
+If the user wants to revoke all outstanding share links immediately, the mechanism is credential rotation: `/portal-credentials <slug>`. This bumps the credential version, which invalidates all tokens signed against the previous version.
 
 ## Completion
 

package/bundle/toolchain/skills/portal-share/SKILL.md.tmpl

@@ -21,7 +21,7 @@ Share links use HMAC-SHA256 signed tokens. The token encodes the portal slug, a
 
 ### Step 1: Identify the target portal
 
-The user must specify which portal to share. If no slug is provided, ask: "Which portal do you want to share? Run /portal list to see your portals."
+The user must specify which portal to share. If no slug is provided, ask: "Which portal do you want to share? Run /portal-list to see your portals."
 
 Do not proceed without a slug. Share links are portal-specific.
 
@@ -47,8 +47,8 @@ Expected success response:
 
 Expected error responses:
 
-- `portal_not_found`: The slug does not exist. Suggest `/portal list`.
-- `no_credentials`: The portal has no credentials set up. Share links require credentials because the token's validity is tied to the credential version. Suggest running `/portal credentials <slug>` first.
+- `portal_not_found`: The slug does not exist. Suggest `/portal-list`.
+- `no_credentials`: The portal has no credentials set up. Share links require credentials because the token's validity is tied to the credential version. Suggest running `/portal-credentials <slug>` first.
 - `no_auth_secret`: AUTH_SECRET is not set in the app's `.env`. The user needs to add one. Suggest: `openssl rand -base64 32` to generate a secret.
 - `no_app_url`: NEXT_PUBLIC_APP_URL is not set. The script cannot construct the full share URL. Ask the user what their portal's public URL is.
 
@@ -77,7 +77,7 @@ If the user has previously generated share links (check learnings for patterns),
 Share links are a convenience feature with intentional security trade-offs:
 
 - **No automatic expiry**: Links remain valid until credentials are rotated, the portal is deactivated, or AUTH_SECRET changes.
-- **Credential version binding**: Rotating credentials invalidates all outstanding share links. This is the revocation mechanism -- if a link is compromised, rotate credentials with `/portal credentials <slug>`.
+- **Credential version binding**: Rotating credentials invalidates all outstanding share links. This is the revocation mechanism -- if a link is compromised, rotate credentials with `/portal-credentials <slug>`.
 - **Single portal scope**: Each link grants access to exactly one portal. A share link for "whzan" cannot be used to access "acme".
 - **No re-use tracking**: The link can be used multiple times by anyone who has it. There is no per-user tracking on share links.
 
@@ -88,13 +88,13 @@ Do NOT log the share URL to learnings or telemetry. The URL contains the signed
 - Always display the full URL, never truncate or abbreviate it. The user needs to copy-paste it.
 - Make it clear that the link does not expire automatically and is revoked by credential rotation or portal deactivation.
 - Use double-line box drawing (`═`) for the border around the link.
-- If NEXT_PUBLIC_APP_URL is `http://localhost:3000`, warn the user immediately: "This is a local development URL. Do not send this to a client. Publish with /portal deploy first, then generate the share link again."
+- If NEXT_PUBLIC_APP_URL is `http://localhost:3000`, warn the user immediately: "This is a local development URL. Do not send this to a client. Publish with /portal-deploy first, then generate the share link again."
 
 ## Error Handling
 
 - If AUTH_SECRET is missing, this is a hard blocker. Explain that share links require a signing secret and provide the generation command: `openssl rand -base64 32`.
 - If the portal has no credentials, explain that share links are tied to credential versions and the user needs to set up credentials first.
-- If the script fails for any other reason, show the error message from stderr and suggest the user check their configuration with `/portal status`.
+- If the script fails for any other reason, show the error message from stderr and suggest the user check their configuration with `/portal-status`.
 
 ## Token Anatomy
 
@@ -127,15 +127,15 @@ The signature is computed using AUTH_SECRET from the app's `.env`. If AUTH_SECRE
 
 Common patterns for using share links in practice:
 
-**After publish**: Deploy the portal with `/portal deploy`, then generate a share link if you want a direct hosted access URL instead of asking the client to log in with credentials.
+**After publish**: Deploy the portal with `/portal-deploy`, then generate a share link if you want a direct hosted access URL instead of asking the client to log in with credentials.
 
 **For quick reviews**: If a colleague or stakeholder needs to see the portal but should not have permanent credentials, a share link is ideal. It can be reused and does not create a full operator login.
 
-**Re-sharing after content update**: If you update portal content with `/portal update`, publish the latest version if needed, then generate a fresh share link and send it.
+**Re-sharing after content update**: If you update portal content with `/portal-update`, publish the latest version if needed, then generate a fresh share link and send it.
 
 ## Learnings Integration
 
-After generating a share link, consider recording a learning entry if this is the first time sharing this portal. The learning helps other skills (like `/portal analytics`) provide better context:
+After generating a share link, consider recording a learning entry if this is the first time sharing this portal. The learning helps other skills (like `/portal-analytics`) provide better context:
 
 ```json
 {"skill":"portal-share","key":"share-event","insight":"whzan shared via link on 2026-04-07","confidence":10,"ts":"2026-04-07T14:30:00Z"}
@@ -149,14 +149,14 @@ Share links do not expire automatically in this version.
 
 The revocation mechanisms are:
 
-- rotate credentials with `/portal credentials <slug>`
-- deactivate the portal with `/portal delete <slug>`
+- rotate credentials with `/portal-credentials <slug>`
+- deactivate the portal with `/portal-delete <slug>`
 - rotate `AUTH_SECRET`
 
 ## Multiple Share Links
 
 Generating a new share link does not invalidate the previous one. Both links remain valid until credentials are rotated, the portal is deactivated, or AUTH_SECRET changes. This means the user can safely generate multiple links for the same portal (e.g., one for the client contact, one for their colleague) without affecting each other.
 
-If the user wants to revoke all outstanding share links immediately, the mechanism is credential rotation: `/portal credentials <slug>`. This bumps the credential version, which invalidates all tokens signed against the previous version.
+If the user wants to revoke all outstanding share links immediately, the mechanism is credential rotation: `/portal-credentials <slug>`. This bumps the credential version, which invalidates all tokens signed against the previous version.
 
 {{COMPLETION}}