showpane 0.4.14 → 0.4.16

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

@@ -25,7 +25,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
 
@@ -78,16 +78,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"
 ```
 
@@ -121,7 +118,7 @@ Soft delete is intentional. Nothing is truly destroyed. If the user changes thei
 
 ### Step 1: Identify the target portal
 
-The user must specify which portal to deactivate. If no slug is provided, ask: "Which portal do you want to deactivate? Run /portal list to see your portals."
+The user must specify which portal to deactivate. If no slug is provided, ask: "Which portal do you want to deactivate? Run /portal-list to see your portals."
 
 Do not proceed without a confirmed slug.
 
@@ -158,7 +155,7 @@ Expected success response:
 
 Expected error responses:
 
-- `portal_not_found`: The slug does not exist in this organization. Suggest `/portal list`.
+- `portal_not_found`: The slug does not exist in this organization. Suggest `/portal-list`.
 - `already_inactive`: The portal is already deactivated. Inform the user: "Portal '<slug>' is already inactive. No changes made."
 
 ### Step 4: Print confirmation
@@ -194,7 +191,7 @@ Depending on context:
 
 - "To reactivate this portal later, update the database record: set `isActive` to `true` on the ClientPortal with slug '<slug>'."
 - "To permanently remove the page files: `git rm -r src/app/(portal)/client/<slug>/` and commit."
-- "To see your remaining portals: /portal list"
+- "To see your remaining portals: /portal-list"
 
 ## What Deactivation Does NOT Do
 
@@ -207,7 +204,7 @@ Be explicit about what this skill does not touch:
 
 ## Edge Cases
 
-- **Portal with active share link**: Deactivation invalidates the link because the portal is no longer active. If the portal should stay active but all tokens must be revoked, rotate credentials with `/portal credentials <slug>`.
+- **Portal with active share link**: Deactivation invalidates the link because the portal is no longer active. If the portal should stay active but all tokens must be revoked, rotate credentials with `/portal-credentials <slug>`.
 - **Portal already inactive**: The script returns `already_inactive`. Do not treat this as an error -- just inform the user.
 - **Last remaining portal**: No special handling. The user can deactivate their last portal. The organization continues to exist with zero active portals.
 
@@ -222,7 +219,7 @@ Be explicit about what this skill does not touch:
 ## Error Handling
 
 - If the preamble fails, stop and display the error.
-- If the portal is not found, suggest `/portal list` to verify the slug.
+- If the portal is not found, suggest `/portal-list` to verify the slug.
 - If the database operation fails, show the error from stderr. Common cause: database connection issues.
 - If the user cancels, acknowledge cleanly and stop. Do not ask again.
 
@@ -243,9 +240,9 @@ cd $APP_PATH && npx tsx -e "
 "
 ```
 
-This is intentionally manual. There is no `/portal reactivate` skill in v1. Reactivation should be a deliberate choice, not a casual undo.
+This is intentionally manual. There is no `/portal-reactivate` skill in v1. Reactivation should be a deliberate choice, not a casual undo.
 
-**Option 2: Re-create the portal.** If the page files were deleted from git after deactivation, the simplest path is to run `/portal create <slug>` again. This creates new page files and a new database record. The old analytics data is tied to the old record and will not carry over.
+**Option 2: Re-create the portal.** If the page files were deleted from git after deactivation, the simplest path is to run `/portal-create <slug>` again. This creates new page files and a new database record. The old analytics data is tied to the old record and will not carry over.
 
 ## Audit Trail
 
@@ -261,7 +258,7 @@ If learnings are enabled, the skill records the deactivation event:
 {"skill":"portal-delete","key":"deactivated","insight":"whzan deactivated on 2026-04-07","confidence":10,"ts":"2026-04-07T15:00:00Z"}
 ```
 
-This helps other skills provide context. For example, `/portal status` can note when a portal was deactivated if the user asks about it.
+This helps other skills provide context. For example, `/portal-status` can note when a portal was deactivated if the user asks about it.
 
 ## Bulk Deactivation
 
@@ -274,7 +271,7 @@ If the user explicitly asks to "deactivate all portals" or "shut everything down
 Two operations can revoke client access, and they serve different purposes:
 
 - **Deactivation** (this skill): Removes the portal entirely from client view. New visitors see "not found". Existing sessions and share links stop working because the portal is inactive. Use when the client relationship has ended or the portal is no longer needed.
-- **Credential rotation** (`/portal credentials`): Changes the password and invalidates all tokens (sessions + share links). The portal remains active and accessible. Use when credentials may be compromised but the portal should stay live.
+- **Credential rotation** (`/portal-credentials`): Changes the password and invalidates all tokens (sessions + share links). The portal remains active and accessible. Use when credentials may be compromised but the portal should stay live.
 
 If the user wants to immediately revoke all access AND deactivate, the sequence is: rotate credentials first (to kill existing sessions immediately), then deactivate (to prevent new logins).
 

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

@@ -34,7 +34,7 @@ Soft delete is intentional. Nothing is truly destroyed. If the user changes thei
 
 ### Step 1: Identify the target portal
 
-The user must specify which portal to deactivate. If no slug is provided, ask: "Which portal do you want to deactivate? Run /portal list to see your portals."
+The user must specify which portal to deactivate. If no slug is provided, ask: "Which portal do you want to deactivate? Run /portal-list to see your portals."
 
 Do not proceed without a confirmed slug.
 
@@ -71,7 +71,7 @@ Expected success response:
 
 Expected error responses:
 
-- `portal_not_found`: The slug does not exist in this organization. Suggest `/portal list`.
+- `portal_not_found`: The slug does not exist in this organization. Suggest `/portal-list`.
 - `already_inactive`: The portal is already deactivated. Inform the user: "Portal '<slug>' is already inactive. No changes made."
 
 ### Step 4: Print confirmation
@@ -107,7 +107,7 @@ Depending on context:
 
 - "To reactivate this portal later, update the database record: set `isActive` to `true` on the ClientPortal with slug '<slug>'."
 - "To permanently remove the page files: `git rm -r src/app/(portal)/client/<slug>/` and commit."
-- "To see your remaining portals: /portal list"
+- "To see your remaining portals: /portal-list"
 
 ## What Deactivation Does NOT Do
 
@@ -120,7 +120,7 @@ Be explicit about what this skill does not touch:
 
 ## Edge Cases
 
-- **Portal with active share link**: Deactivation invalidates the link because the portal is no longer active. If the portal should stay active but all tokens must be revoked, rotate credentials with `/portal credentials <slug>`.
+- **Portal with active share link**: Deactivation invalidates the link because the portal is no longer active. If the portal should stay active but all tokens must be revoked, rotate credentials with `/portal-credentials <slug>`.
 - **Portal already inactive**: The script returns `already_inactive`. Do not treat this as an error -- just inform the user.
 - **Last remaining portal**: No special handling. The user can deactivate their last portal. The organization continues to exist with zero active portals.
 
@@ -135,7 +135,7 @@ Be explicit about what this skill does not touch:
 ## Error Handling
 
 - If the preamble fails, stop and display the error.
-- If the portal is not found, suggest `/portal list` to verify the slug.
+- If the portal is not found, suggest `/portal-list` to verify the slug.
 - If the database operation fails, show the error from stderr. Common cause: database connection issues.
 - If the user cancels, acknowledge cleanly and stop. Do not ask again.
 
@@ -156,9 +156,9 @@ cd $APP_PATH && npx tsx -e "
 "
 ```
 
-This is intentionally manual. There is no `/portal reactivate` skill in v1. Reactivation should be a deliberate choice, not a casual undo.
+This is intentionally manual. There is no `/portal-reactivate` skill in v1. Reactivation should be a deliberate choice, not a casual undo.
 
-**Option 2: Re-create the portal.** If the page files were deleted from git after deactivation, the simplest path is to run `/portal create <slug>` again. This creates new page files and a new database record. The old analytics data is tied to the old record and will not carry over.
+**Option 2: Re-create the portal.** If the page files were deleted from git after deactivation, the simplest path is to run `/portal-create <slug>` again. This creates new page files and a new database record. The old analytics data is tied to the old record and will not carry over.
 
 ## Audit Trail
 
@@ -174,7 +174,7 @@ If learnings are enabled, the skill records the deactivation event:
 {"skill":"portal-delete","key":"deactivated","insight":"whzan deactivated on 2026-04-07","confidence":10,"ts":"2026-04-07T15:00:00Z"}
 ```
 
-This helps other skills provide context. For example, `/portal status` can note when a portal was deactivated if the user asks about it.
+This helps other skills provide context. For example, `/portal-status` can note when a portal was deactivated if the user asks about it.
 
 ## Bulk Deactivation
 
@@ -187,7 +187,7 @@ If the user explicitly asks to "deactivate all portals" or "shut everything down
 Two operations can revoke client access, and they serve different purposes:
 
 - **Deactivation** (this skill): Removes the portal entirely from client view. New visitors see "not found". Existing sessions and share links stop working because the portal is inactive. Use when the client relationship has ended or the portal is no longer needed.
-- **Credential rotation** (`/portal credentials`): Changes the password and invalidates all tokens (sessions + share links). The portal remains active and accessible. Use when credentials may be compromised but the portal should stay live.
+- **Credential rotation** (`/portal-credentials`): Changes the password and invalidates all tokens (sessions + share links). The portal remains active and accessible. Use when credentials may be compromised but the portal should stay live.
 
 If the user wants to immediately revoke all access AND deactivate, the sequence is: rotate credentials first (to kill existing sessions immediately), then deactivate (to prevent new logins).
 

package/bundle/toolchain/skills/portal-deploy/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"
 ```
 

package/bundle/toolchain/skills/portal-dev/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"
 ```
 
@@ -119,7 +116,7 @@ If a process is listening on port 3000:
 
 3. If it's a different process, warn the user:
    > "Port 3000 is in use by another process (PID: <pid>). Options:"
-   > - Kill it: `kill <pid>` then re-run `/portal dev`
+   > - Kill it: `kill <pid>` then re-run `/portal-dev`
    > - Use a different port: `cd $APP_PATH && PORT=3001 npm run dev`
 
    Ask the user how to proceed. Do not kill processes without explicit permission.
@@ -245,9 +242,9 @@ Then show tips:
 
 ```
 Tips:
-  - Create a portal:   /portal create <slug>
-  - Edit a portal:     /portal update <slug>
-  - View all portals:  /portal list
+  - Create a portal:   /portal-create <slug>
+  - Edit a portal:     /portal-update <slug>
+  - View all portals:  /portal-list
   - Hot reload is ON:  edits to portal files appear instantly
   - Stop the server:   Ctrl+C in the terminal, or kill the process
 ```
@@ -291,7 +288,7 @@ The Next.js dev server watches all files under `src/` for changes. When you edit
 Portals in development can be accessed in two ways:
 
 1. **Direct URL**: Navigate to `http://localhost:3000/client/<slug>` — this bypasses authentication during local development if the portal doesn't have credentials set yet
-2. **Login page**: Navigate to `http://localhost:3000/client` — use this to test the full authentication flow with credentials created via `/portal credentials`
+2. **Login page**: Navigate to `http://localhost:3000/client` — use this to test the full authentication flow with credentials created via `/portal-credentials`
 
 The example portal at `/client/example` always works without authentication and is a useful reference while building new portals.
 

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

@@ -32,7 +32,7 @@ If a process is listening on port 3000:
 
 3. If it's a different process, warn the user:
    > "Port 3000 is in use by another process (PID: <pid>). Options:"
-   > - Kill it: `kill <pid>` then re-run `/portal dev`
+   > - Kill it: `kill <pid>` then re-run `/portal-dev`
    > - Use a different port: `cd $APP_PATH && PORT=3001 npm run dev`
 
    Ask the user how to proceed. Do not kill processes without explicit permission.
@@ -158,9 +158,9 @@ Then show tips:
 
 ```
 Tips:
-  - Create a portal:   /portal create <slug>
-  - Edit a portal:     /portal update <slug>
-  - View all portals:  /portal list
+  - Create a portal:   /portal-create <slug>
+  - Edit a portal:     /portal-update <slug>
+  - View all portals:  /portal-list
   - Hot reload is ON:  edits to portal files appear instantly
   - Stop the server:   Ctrl+C in the terminal, or kill the process
 ```
@@ -204,7 +204,7 @@ The Next.js dev server watches all files under `src/` for changes. When you edit
 Portals in development can be accessed in two ways:
 
 1. **Direct URL**: Navigate to `http://localhost:3000/client/<slug>` — this bypasses authentication during local development if the portal doesn't have credentials set yet
-2. **Login page**: Navigate to `http://localhost:3000/client` — use this to test the full authentication flow with credentials created via `/portal credentials`
+2. **Login page**: Navigate to `http://localhost:3000/client` — use this to test the full authentication flow with credentials created via `/portal-credentials`
 
 The example portal at `/client/example` always works without authentication and is a useful reference while building new portals.
 

package/bundle/toolchain/skills/portal-list/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"
 ```
 
@@ -97,7 +94,7 @@ If `skills/shared/platform-constraints.md` exists, read it once near the start o
 
 ## Overview
 
-This skill retrieves all portals belonging to the current organization and displays them as a formatted table in the terminal. It is the quickest way to see what portals exist, their status, and when they were last updated. It is also a good starting point before running other portal-specific skills -- users often run `/portal list` to find a slug before using `/portal analytics`, `/portal share`, or `/portal preview`.
+This skill retrieves all portals belonging to the current organization and displays them as a formatted table in the terminal. It is the quickest way to see what portals exist, their status, and when they were last updated. It is also a good starting point before running other portal-specific skills -- users often run `/portal-list` to find a slug before using `/portal-analytics`, `/portal-share`, or `/portal-preview`.
 
 ## Steps
 
@@ -141,7 +138,7 @@ Expected success response:
 
 If the script exits with a non-zero code, read stderr. Common errors:
 
-- `org_not_found`: The organization slug from config does not exist in the database. The user may need to re-run `/portal setup`.
+- `org_not_found`: The organization slug from config does not exist in the database. The user may need to re-run `/portal-setup`.
 - `database_error`: Connection issue. Check that DATABASE_URL is correct and the database is accessible.
 
 ### Step 2: Format as an ASCII table
@@ -176,18 +173,18 @@ PORTALS (Demo Company)
 ════════════════════════════════════════
   No portals yet.
   
-  Create your first portal: /portal create <slug>
+  Create your first portal: /portal-create <slug>
 ════════════════════════════════════════
 ```
 
-This guides new users toward the next action. If the user ran `/portal onboard`, they would have gone through this already, but many users will discover the CLI skill-by-skill.
+This guides new users toward the next action. If the user ran `/portal-onboard`, they would have gone through this already, but many users will discover the CLI skill-by-skill.
 
 ### Step 4: Add contextual hints
 
 After the table, provide brief contextual guidance based on what the list reveals:
 
 - **All portals active, credentials set**: No additional notes needed. The list is self-explanatory.
-- **Portal without credentials**: Append a note: "Portal 'example' has no credentials. Run /portal credentials example to set up access."
+- **Portal without credentials**: Append a note: "Portal 'example' has no credentials. Run /portal-credentials example to set up access."
 - **Inactive portals present**: "1 inactive portal not shown. Use --all to include inactive portals." (The `--all` flag can be passed to `list-portals.ts`.)
 - **Large number of portals (10+)**: Consider grouping or paginating. For now, just show all of them -- the terminal handles scrolling.
 
@@ -211,18 +208,18 @@ Pass these flags through to the `list-portals.ts` script if the user requests th
 - Format dates as `DD Mon YYYY` (e.g., "2 Apr 2026"). Do not show times in the list view -- they add clutter without value at this level.
 - Right-pad string columns for alignment. The table should look clean even with varying slug and company name lengths.
 - Use double-line box drawing (`═`) for outer borders and single-line (`─`) for the header separator.
-- If the response includes `tabCount`, do not show it in the default table. It is available for other skills (like `/portal status`) but too detailed for a list view.
+- If the response includes `tabCount`, do not show it in the default table. It is available for other skills (like `/portal-status`) but too detailed for a list view.
 - The footer line ("3 portals total") should always be present, even for a single portal ("1 portal total").
 
 ## Error Handling
 
 - If the preamble fails, stop and display the error. Do not attempt to query the database.
 - If the database query fails, show the error from stderr and suggest checking the connection: "Database query failed. Verify your DATABASE_URL is correct and the database is running."
-- If the org is not found, suggest re-running `/portal setup` to reconfigure.
+- If the org is not found, suggest re-running `/portal-setup` to reconfigure.
 
 ## Data Freshness
 
-The list data comes directly from the database at query time. It reflects the current state of all portals, including any changes made moments ago. There is no caching layer. If the user just created a portal with `/portal create`, it will appear in the list immediately.
+The list data comes directly from the database at query time. It reflects the current state of all portals, including any changes made moments ago. There is no caching layer. If the user just created a portal with `/portal-create`, it will appear in the list immediately.
 
 The `lastUpdated` timestamp reflects when the portal's database record was last modified. This includes credential changes, status changes, and metadata updates. It does NOT reflect when the portal's React source files were last edited -- file changes are tracked by git, not the database.
 
@@ -247,9 +244,9 @@ The list skill does not write learnings. It is a read-only query. However, if le
 Portals have two states in the database:
 
 - **Active** (`isActive: true`): The portal is accessible to clients. It appears in the default list view. This is the normal operating state.
-- **Inactive** (`isActive: false`): The portal has been deactivated via `/portal delete`. It is hidden from the default list view but still exists in the database. Page files may or may not still be in the repository.
+- **Inactive** (`isActive: false`): The portal has been deactivated via `/portal-delete`. It is hidden from the default list view but still exists in the database. Page files may or may not still be in the repository.
 
-There is no "draft" or "pending" state. A portal is either active or inactive. When `/portal create` runs, the portal is immediately active. If the user wants to prepare a portal before making it accessible, they should create it and set up credentials last -- the portal page exists but is behind the login gate.
+There is no "draft" or "pending" state. A portal is either active or inactive. When `/portal-create` runs, the portal is immediately active. If the user wants to prepare a portal before making it accessible, they should create it and set up credentials last -- the portal page exists but is behind the login gate.
 
 ## Response Format Details
 

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

@@ -10,7 +10,7 @@ allowed-tools: [Bash, Read, Glob, Grep]
 
 ## Overview
 
-This skill retrieves all portals belonging to the current organization and displays them as a formatted table in the terminal. It is the quickest way to see what portals exist, their status, and when they were last updated. It is also a good starting point before running other portal-specific skills -- users often run `/portal list` to find a slug before using `/portal analytics`, `/portal share`, or `/portal preview`.
+This skill retrieves all portals belonging to the current organization and displays them as a formatted table in the terminal. It is the quickest way to see what portals exist, their status, and when they were last updated. It is also a good starting point before running other portal-specific skills -- users often run `/portal-list` to find a slug before using `/portal-analytics`, `/portal-share`, or `/portal-preview`.
 
 ## Steps
 
@@ -54,7 +54,7 @@ Expected success response:
 
 If the script exits with a non-zero code, read stderr. Common errors:
 
-- `org_not_found`: The organization slug from config does not exist in the database. The user may need to re-run `/portal setup`.
+- `org_not_found`: The organization slug from config does not exist in the database. The user may need to re-run `/portal-setup`.
 - `database_error`: Connection issue. Check that DATABASE_URL is correct and the database is accessible.
 
 ### Step 2: Format as an ASCII table
@@ -89,18 +89,18 @@ PORTALS (Demo Company)
 ════════════════════════════════════════
   No portals yet.
   
-  Create your first portal: /portal create <slug>
+  Create your first portal: /portal-create <slug>
 ════════════════════════════════════════
 ```
 
-This guides new users toward the next action. If the user ran `/portal onboard`, they would have gone through this already, but many users will discover the CLI skill-by-skill.
+This guides new users toward the next action. If the user ran `/portal-onboard`, they would have gone through this already, but many users will discover the CLI skill-by-skill.
 
 ### Step 4: Add contextual hints
 
 After the table, provide brief contextual guidance based on what the list reveals:
 
 - **All portals active, credentials set**: No additional notes needed. The list is self-explanatory.
-- **Portal without credentials**: Append a note: "Portal 'example' has no credentials. Run /portal credentials example to set up access."
+- **Portal without credentials**: Append a note: "Portal 'example' has no credentials. Run /portal-credentials example to set up access."
 - **Inactive portals present**: "1 inactive portal not shown. Use --all to include inactive portals." (The `--all` flag can be passed to `list-portals.ts`.)
 - **Large number of portals (10+)**: Consider grouping or paginating. For now, just show all of them -- the terminal handles scrolling.
 
@@ -124,18 +124,18 @@ Pass these flags through to the `list-portals.ts` script if the user requests th
 - Format dates as `DD Mon YYYY` (e.g., "2 Apr 2026"). Do not show times in the list view -- they add clutter without value at this level.
 - Right-pad string columns for alignment. The table should look clean even with varying slug and company name lengths.
 - Use double-line box drawing (`═`) for outer borders and single-line (`─`) for the header separator.
-- If the response includes `tabCount`, do not show it in the default table. It is available for other skills (like `/portal status`) but too detailed for a list view.
+- If the response includes `tabCount`, do not show it in the default table. It is available for other skills (like `/portal-status`) but too detailed for a list view.
 - The footer line ("3 portals total") should always be present, even for a single portal ("1 portal total").
 
 ## Error Handling
 
 - If the preamble fails, stop and display the error. Do not attempt to query the database.
 - If the database query fails, show the error from stderr and suggest checking the connection: "Database query failed. Verify your DATABASE_URL is correct and the database is running."
-- If the org is not found, suggest re-running `/portal setup` to reconfigure.
+- If the org is not found, suggest re-running `/portal-setup` to reconfigure.
 
 ## Data Freshness
 
-The list data comes directly from the database at query time. It reflects the current state of all portals, including any changes made moments ago. There is no caching layer. If the user just created a portal with `/portal create`, it will appear in the list immediately.
+The list data comes directly from the database at query time. It reflects the current state of all portals, including any changes made moments ago. There is no caching layer. If the user just created a portal with `/portal-create`, it will appear in the list immediately.
 
 The `lastUpdated` timestamp reflects when the portal's database record was last modified. This includes credential changes, status changes, and metadata updates. It does NOT reflect when the portal's React source files were last edited -- file changes are tracked by git, not the database.
 
@@ -160,9 +160,9 @@ The list skill does not write learnings. It is a read-only query. However, if le
 Portals have two states in the database:
 
 - **Active** (`isActive: true`): The portal is accessible to clients. It appears in the default list view. This is the normal operating state.
-- **Inactive** (`isActive: false`): The portal has been deactivated via `/portal delete`. It is hidden from the default list view but still exists in the database. Page files may or may not still be in the repository.
+- **Inactive** (`isActive: false`): The portal has been deactivated via `/portal-delete`. It is hidden from the default list view but still exists in the database. Page files may or may not still be in the repository.
 
-There is no "draft" or "pending" state. A portal is either active or inactive. When `/portal create` runs, the portal is immediately active. If the user wants to prepare a portal before making it accessible, they should create it and set up credentials last -- the portal page exists but is behind the login gate.
+There is no "draft" or "pending" state. A portal is either active or inactive. When `/portal-create` runs, the portal is immediately active. If the user wants to prepare a portal before making it accessible, they should create it and set up credentials last -- the portal page exists but is behind the login gate.
 
 ## Response Format Details
 

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

@@ -83,16 +83,13 @@ fi
 
 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"
 ```
 
@@ -112,7 +109,7 @@ If `skills/shared/platform-constraints.md` exists, read it once near the start o
 
 ## 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:
@@ -169,15 +166,14 @@ Start with a compact welcome:
  ╚══════════════════════════════════════════╝
 ```
 
-Then explain the flow in plain language:
+Then use one short, friendly paragraph. Keep it concise and informal.
+
+Suggested shape:
 
-- local setup if needed
-- first draft
-- local preview
-- access setup
-- cloud publish
+- "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."
 
-Do not lead with prompt examples. This skill is the first-run default.
+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:
 
@@ -197,15 +193,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:
 
-- organization name
-- contact email
-- website/domain if available
+1. organization name, if it is not already obvious from the workspace setup
+2. contact email
+3. website/domain
+
+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.
 
@@ -213,9 +222,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
@@ -260,7 +280,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.
@@ -353,8 +373,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
 ════════════════════════════════════════
 ```
 
@@ -409,10 +429,10 @@ 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