showpane 0.4.13 → 0.4.15
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -1
- package/bundle/meta/scaffold-manifest.json +10 -10
- package/bundle/scaffold/VERSION +1 -1
- package/bundle/scaffold/prisma/seed.ts +40 -35
- package/bundle/scaffold/src/__tests__/portal-contracts.test.ts +7 -0
- package/bundle/scaffold/src/app/(portal)/client/example/example-client.tsx +1 -2
- package/bundle/scaffold/src/app/(portal)/client/page.tsx +5 -4
- package/bundle/scaffold/src/app/page.tsx +43 -6
- package/bundle/scaffold/src/components/portal-shell.tsx +23 -0
- package/bundle/scaffold/src/lib/portal-contracts.ts +33 -0
- package/bundle/toolchain/CLI_VERSION +1 -0
- package/bundle/toolchain/TELEMETRY_CONFIG.json +4 -0
- package/bundle/toolchain/VERSION +1 -1
- package/bundle/toolchain/bin/ensure-cloud-project-link.ts +34 -1
- package/bundle/toolchain/bin/showpane-config +108 -29
- package/bundle/toolchain/bin/showpane-telemetry-log +84 -0
- package/bundle/toolchain/bin/showpane-telemetry-sync +212 -0
- package/bundle/toolchain/bin/showpane-update-check +130 -0
- package/bundle/toolchain/skills/SKILL.md.tmpl +13 -0
- package/bundle/toolchain/skills/VERSION +1 -1
- package/bundle/toolchain/skills/portal-analytics/SKILL.md +60 -38
- package/bundle/toolchain/skills/portal-analytics/SKILL.md.tmpl +192 -0
- package/bundle/toolchain/skills/portal-create/SKILL.md +65 -67
- package/bundle/toolchain/skills/portal-create/SKILL.md.tmpl +264 -0
- package/bundle/toolchain/skills/portal-credentials/SKILL.md +66 -49
- package/bundle/toolchain/skills/portal-credentials/SKILL.md.tmpl +198 -0
- package/bundle/toolchain/skills/portal-delete/SKILL.md +63 -41
- package/bundle/toolchain/skills/portal-delete/SKILL.md.tmpl +194 -0
- package/bundle/toolchain/skills/portal-deploy/SKILL.md +57 -47
- package/bundle/toolchain/skills/portal-deploy/SKILL.md.tmpl +452 -0
- package/bundle/toolchain/skills/portal-dev/SKILL.md +65 -47
- package/bundle/toolchain/skills/portal-dev/SKILL.md.tmpl +228 -0
- package/bundle/toolchain/skills/portal-list/SKILL.md +64 -43
- package/bundle/toolchain/skills/portal-list/SKILL.md.tmpl +181 -0
- package/bundle/toolchain/skills/portal-onboard/SKILL.md +331 -162
- package/bundle/toolchain/skills/portal-onboard/SKILL.md.tmpl +340 -0
- package/bundle/toolchain/skills/portal-preview/SKILL.md +65 -44
- package/bundle/toolchain/skills/portal-preview/SKILL.md.tmpl +171 -0
- package/bundle/toolchain/skills/portal-setup/SKILL.md +79 -60
- package/bundle/toolchain/skills/portal-setup/SKILL.md.tmpl +227 -0
- package/bundle/toolchain/skills/portal-share/SKILL.md +69 -47
- package/bundle/toolchain/skills/portal-share/SKILL.md.tmpl +162 -0
- package/bundle/toolchain/skills/portal-status/SKILL.md +58 -37
- package/bundle/toolchain/skills/portal-status/SKILL.md.tmpl +196 -0
- package/bundle/toolchain/skills/portal-update/SKILL.md +60 -46
- package/bundle/toolchain/skills/portal-update/SKILL.md.tmpl +269 -0
- package/bundle/toolchain/skills/portal-upgrade/SKILL.md +55 -33
- package/bundle/toolchain/skills/portal-upgrade/SKILL.md.tmpl +164 -0
- package/bundle/toolchain/skills/portal-verify/SKILL.md +69 -14
- package/bundle/toolchain/skills/portal-verify/SKILL.md.tmpl +224 -0
- package/bundle/toolchain/skills/shared/preamble.md +30 -126
- package/bundle/toolchain/skills/shared/runtime-principles.md +25 -0
- package/bundle/toolchain/templates/sales-followup/sales-followup-client.tsx +1 -1
- package/dist/index.js +79 -14
- package/package.json +5 -2
|
@@ -0,0 +1,340 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: portal-onboard
|
|
3
|
+
description: |
|
|
4
|
+
Canonical first-run wizard for Showpane. Use this for the first portal, for
|
|
5
|
+
guided onboarding, or any "walk me through it" request. It owns the end-to-end
|
|
6
|
+
first-run story: local setup, draft creation, preview, access setup, and the
|
|
7
|
+
hosted publish handoff. (showpane)
|
|
8
|
+
allowed-tools: [Bash, Read, Write, Edit, Glob, Grep]
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
{{PREAMBLE}}
|
|
12
|
+
|
|
13
|
+
## Overview
|
|
14
|
+
|
|
15
|
+
`/portal-onboard` is the canonical first-run workflow. It should feel like one
|
|
16
|
+
coherent wizard, not like the user is manually hopping between separate skills.
|
|
17
|
+
|
|
18
|
+
The recommended shape is:
|
|
19
|
+
|
|
20
|
+
1. orient the user
|
|
21
|
+
2. verify local setup
|
|
22
|
+
3. choose the best source for the first draft
|
|
23
|
+
4. create the portal draft
|
|
24
|
+
5. make one or two practical refinements
|
|
25
|
+
6. preview locally
|
|
26
|
+
7. choose how the client will access it
|
|
27
|
+
8. publish to Showpane Cloud
|
|
28
|
+
9. show a compact final summary
|
|
29
|
+
|
|
30
|
+
Keep the tone direct and calm. Use short phase transitions. Re-ground the user at
|
|
31
|
+
each phase so they always know what is happening next.
|
|
32
|
+
|
|
33
|
+
## Interaction Style
|
|
34
|
+
|
|
35
|
+
For decisions that materially change the flow, use recommendation-first language.
|
|
36
|
+
The pattern should look like this:
|
|
37
|
+
|
|
38
|
+
1. one sentence re-grounding the current phase
|
|
39
|
+
2. one sentence on the recommended choice and why
|
|
40
|
+
3. a short list of concrete options
|
|
41
|
+
|
|
42
|
+
Example:
|
|
43
|
+
|
|
44
|
+
`We have local setup ready. Next we need the best source for your first draft.`
|
|
45
|
+
|
|
46
|
+
`Recommended: use a real transcript if you have one — it gives the strongest first portal on the first pass.`
|
|
47
|
+
|
|
48
|
+
`Options: recent Granola meeting, pasted transcript, short description, or start from template.`
|
|
49
|
+
|
|
50
|
+
Do not ask more than one meaningful question at a time unless the answers are tightly coupled.
|
|
51
|
+
|
|
52
|
+
## Wizard Phases
|
|
53
|
+
|
|
54
|
+
### Phase 0: Resume or restart
|
|
55
|
+
|
|
56
|
+
If a checkpoint exists:
|
|
57
|
+
|
|
58
|
+
- show the saved phase and portal slug if present
|
|
59
|
+
- recommend resume
|
|
60
|
+
- if the user restarts, delete the checkpoint and begin from Phase 1
|
|
61
|
+
|
|
62
|
+
### Phase 1: Orientation
|
|
63
|
+
|
|
64
|
+
Start with a compact welcome:
|
|
65
|
+
|
|
66
|
+
```
|
|
67
|
+
╔══════════════════════════════════════════╗
|
|
68
|
+
║ SHOWPANE — First Portal Wizard ║
|
|
69
|
+
╚══════════════════════════════════════════╝
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
Then use one short, friendly paragraph. Keep it concise and informal.
|
|
73
|
+
|
|
74
|
+
Suggested shape:
|
|
75
|
+
|
|
76
|
+
- "Let's get your first portal started."
|
|
77
|
+
- "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."
|
|
78
|
+
|
|
79
|
+
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.
|
|
80
|
+
|
|
81
|
+
Immediately save checkpoint:
|
|
82
|
+
|
|
83
|
+
```bash
|
|
84
|
+
mkdir -p "$HOME/.showpane/checkpoints"
|
|
85
|
+
printf '%s\n' '{"phase":"orientation","startedAt":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' > "$HOME/.showpane/checkpoints/portal-onboard.json"
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### Phase 2: Local readiness
|
|
89
|
+
|
|
90
|
+
If `CONFIG_PRESENT: false`, run the `portal-setup` flow inline.
|
|
91
|
+
|
|
92
|
+
If config exists, verify only the minimum first-run requirements before continuing:
|
|
93
|
+
|
|
94
|
+
- app path exists
|
|
95
|
+
- dependencies exist or can be installed
|
|
96
|
+
- local SQLite schema is ready
|
|
97
|
+
- org exists or can be created
|
|
98
|
+
|
|
99
|
+
Keep this phase minimal.
|
|
100
|
+
|
|
101
|
+
If the local checks pass, move straight into the user's portal work without extra system narration.
|
|
102
|
+
|
|
103
|
+
If there is already exactly one local organization and it clearly matches the
|
|
104
|
+
workspace the user just created, treat the org basics as already captured.
|
|
105
|
+
Do not create a separate "company context" phase just to re-ask the same setup
|
|
106
|
+
details.
|
|
107
|
+
|
|
108
|
+
Only ask for a missing field, and ask exactly one thing at a time.
|
|
109
|
+
|
|
110
|
+
Recommended order for missing fields:
|
|
111
|
+
|
|
112
|
+
1. organization name, if it is not already obvious from the workspace setup
|
|
113
|
+
2. contact email
|
|
114
|
+
3. website/domain
|
|
115
|
+
|
|
116
|
+
Do not batch these into a numbered questionnaire unless the user explicitly asks
|
|
117
|
+
for the full checklist.
|
|
118
|
+
|
|
119
|
+
Optional extras like brand color, phone number, or contact title belong in
|
|
120
|
+
`/portal-setup` later if needed.
|
|
121
|
+
|
|
122
|
+
If setup fails, stop with a concrete recovery step and keep the checkpoint.
|
|
123
|
+
|
|
124
|
+
Save checkpoint with phase `local-ready`.
|
|
125
|
+
|
|
126
|
+
### Phase 3: Choose the first-portal source
|
|
127
|
+
|
|
128
|
+
Start with one short source question, not a menu.
|
|
129
|
+
|
|
130
|
+
Recommended opening:
|
|
131
|
+
|
|
132
|
+
- "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."
|
|
133
|
+
|
|
134
|
+
Only branch after the user answers:
|
|
135
|
+
|
|
136
|
+
- if they have a real transcript, ask whether to use Granola or paste it
|
|
137
|
+
- if they do not, ask whether they want to start from notes or a template
|
|
138
|
+
|
|
139
|
+
Only show the full menu if the user is unsure:
|
|
140
|
+
|
|
141
|
+
1. recent Granola meeting
|
|
142
|
+
2. pasted transcript
|
|
143
|
+
3. short description of the client + meeting outcome
|
|
144
|
+
4. template-only start
|
|
145
|
+
|
|
146
|
+
If Granola MCP is unavailable, skip it silently and move on.
|
|
147
|
+
|
|
148
|
+
If the user only has a rough brief, recommend `sales-followup` as the default
|
|
149
|
+
template for the first portal unless the engagement is clearly onboarding or consulting.
|
|
150
|
+
|
|
151
|
+
Save checkpoint with:
|
|
152
|
+
|
|
153
|
+
- `phase: "source-selected"`
|
|
154
|
+
- `sourceType`
|
|
155
|
+
- `template`
|
|
156
|
+
|
|
157
|
+
### Phase 4: Create the first draft
|
|
158
|
+
|
|
159
|
+
Run the `portal-create` flow inline, but frame it as part of the wizard, not as
|
|
160
|
+
a separate command.
|
|
161
|
+
|
|
162
|
+
During this phase:
|
|
163
|
+
|
|
164
|
+
- suggest a slug if needed
|
|
165
|
+
- prefer a real company/client name in the portal
|
|
166
|
+
- prefer useful structure over completeness
|
|
167
|
+
- aim for a credible first draft, not a perfect final artifact
|
|
168
|
+
|
|
169
|
+
If the slug is taken, treat that as a soft retry, not a failure.
|
|
170
|
+
|
|
171
|
+
Save checkpoint with:
|
|
172
|
+
|
|
173
|
+
- `phase: "draft-created"`
|
|
174
|
+
- `portalSlug`
|
|
175
|
+
- `companyName`
|
|
176
|
+
|
|
177
|
+
### Phase 5: Practical refinements
|
|
178
|
+
|
|
179
|
+
Do not ask the user to invent a whole redesign. Ask for one or two high-signal refinements only.
|
|
180
|
+
|
|
181
|
+
Recommended refinement prompts:
|
|
182
|
+
|
|
183
|
+
- `Do you want the portal to feel more concise, more sales-focused, or more delivery-focused?`
|
|
184
|
+
- `Should we add anything practical before preview — timeline, documents, or sharper next steps?`
|
|
185
|
+
|
|
186
|
+
Apply the requested refinement inline, using the same patterns as `/portal-update`
|
|
187
|
+
without forcing the user to switch skills.
|
|
188
|
+
|
|
189
|
+
If the user is happy with the first draft, move on immediately.
|
|
190
|
+
|
|
191
|
+
Save checkpoint with phase `draft-refined`.
|
|
192
|
+
|
|
193
|
+
### Phase 6: Local preview
|
|
194
|
+
|
|
195
|
+
Run the `portal-preview` flow inline.
|
|
196
|
+
|
|
197
|
+
If no dev server is running, start it using the `portal-dev` instructions first.
|
|
198
|
+
|
|
199
|
+
Tell the user exactly what to inspect:
|
|
200
|
+
|
|
201
|
+
- does the overall story feel right?
|
|
202
|
+
- are next steps clear?
|
|
203
|
+
- are obvious documents or dates missing?
|
|
204
|
+
|
|
205
|
+
If the user requests a small content fix after preview, make it and preview again.
|
|
206
|
+
Keep this loop tight. Do not let it become an open-ended editing session.
|
|
207
|
+
|
|
208
|
+
Save checkpoint with phase `previewed`.
|
|
209
|
+
|
|
210
|
+
### Phase 7: Access setup
|
|
211
|
+
|
|
212
|
+
Ask how the client should access the hosted portal after publish.
|
|
213
|
+
|
|
214
|
+
Recommended first-run choice:
|
|
215
|
+
|
|
216
|
+
- publish first, then choose the hosted access method
|
|
217
|
+
- keep credentials available as the default fallback
|
|
218
|
+
|
|
219
|
+
Important rule: share links still require portal credentials to exist, because
|
|
220
|
+
share links are tied to credential versioning.
|
|
221
|
+
|
|
222
|
+
So the flow is:
|
|
223
|
+
|
|
224
|
+
1. run `portal-credentials` inline
|
|
225
|
+
2. show the credentials once
|
|
226
|
+
3. explain that external sharing starts with `portal-deploy`
|
|
227
|
+
4. if the user wants a direct hosted access link after publish, plan to run `portal-share`
|
|
228
|
+
|
|
229
|
+
Never write the password into the checkpoint or learnings.
|
|
230
|
+
|
|
231
|
+
Save checkpoint with phase `access-ready` and `accessMode`.
|
|
232
|
+
|
|
233
|
+
### Phase 8: Publish to Showpane Cloud
|
|
234
|
+
|
|
235
|
+
Run the `portal-deploy` flow inline.
|
|
236
|
+
|
|
237
|
+
This phase is part of onboarding by default. Do not treat publish as an optional
|
|
238
|
+
afterthought unless the user explicitly says they want to stop at local preview.
|
|
239
|
+
|
|
240
|
+
If cloud auth is missing:
|
|
241
|
+
|
|
242
|
+
- tell the user to run `showpane login`
|
|
243
|
+
- after login completes, resume from the checkpoint
|
|
244
|
+
|
|
245
|
+
If deploy returns `organization_required`:
|
|
246
|
+
|
|
247
|
+
- explain that the user needs to start billing/workspace creation in Showpane Cloud
|
|
248
|
+
- send them to checkout
|
|
249
|
+
- resume after checkout
|
|
250
|
+
|
|
251
|
+
If deploy returns `organization_not_ready`:
|
|
252
|
+
|
|
253
|
+
- surface the readiness detail directly
|
|
254
|
+
- distinguish between:
|
|
255
|
+
- billing inactive
|
|
256
|
+
- provisioning still running
|
|
257
|
+
- provisioning unhealthy/failed
|
|
258
|
+
- workspace incomplete
|
|
259
|
+
- send the user to the relevant settings or checkout action
|
|
260
|
+
- keep the checkpoint so they can resume publish instead of restarting the wizard
|
|
261
|
+
|
|
262
|
+
If publish succeeds and the user wants a hosted direct-access link, run `portal-share` inline next.
|
|
263
|
+
|
|
264
|
+
Save checkpoint with phase `published` once the hosted URL is live or clearly accepted for publish.
|
|
265
|
+
|
|
266
|
+
### Phase 9: Final summary
|
|
267
|
+
|
|
268
|
+
Show a compact final reference card:
|
|
269
|
+
|
|
270
|
+
```
|
|
271
|
+
════════════════════════════════════════
|
|
272
|
+
First portal complete
|
|
273
|
+
|
|
274
|
+
Portal: <slug> (<company>)
|
|
275
|
+
Local: http://localhost:3000/client/<slug>
|
|
276
|
+
Cloud: <hosted-url-or-publishing-status>
|
|
277
|
+
Access: <hosted login / hosted share link / both>
|
|
278
|
+
|
|
279
|
+
Next: /portal-update <slug>
|
|
280
|
+
Help: /portal-list, /portal-status
|
|
281
|
+
════════════════════════════════════════
|
|
282
|
+
```
|
|
283
|
+
|
|
284
|
+
Rules:
|
|
285
|
+
|
|
286
|
+
- never include the password in the final summary
|
|
287
|
+
- include the hosted share URL only if it exists and the user explicitly asked for it after publish
|
|
288
|
+
- if publish is still finalizing, say so plainly instead of pretending it is live
|
|
289
|
+
|
|
290
|
+
After the final summary, delete the checkpoint:
|
|
291
|
+
|
|
292
|
+
```bash
|
|
293
|
+
rm -f "$HOME/.showpane/checkpoints/portal-onboard.json"
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
## Flow Control
|
|
297
|
+
|
|
298
|
+
This wizard is sequential, but it is state-aware.
|
|
299
|
+
|
|
300
|
+
Rules:
|
|
301
|
+
|
|
302
|
+
- verify existing state before redoing work
|
|
303
|
+
- allow resume from any saved phase
|
|
304
|
+
- retry soft failures like slug conflicts or slow dev-server startup
|
|
305
|
+
- stop on hard failures like missing app path, broken schema setup, or cloud deploy errors that require user action
|
|
306
|
+
- keep the user in one coherent workflow instead of telling them to manually switch commands unless recovery requires it
|
|
307
|
+
|
|
308
|
+
## Existing State Checks
|
|
309
|
+
|
|
310
|
+
Check these before deciding to skip or rerun a phase:
|
|
311
|
+
|
|
312
|
+
1. setup/config present
|
|
313
|
+
2. local org exists
|
|
314
|
+
3. portal already exists for the selected slug
|
|
315
|
+
4. credentials already exist
|
|
316
|
+
5. local dev server is running
|
|
317
|
+
6. cloud access token exists
|
|
318
|
+
|
|
319
|
+
If a portal already exists and clearly looks like the same first-run draft, ask whether
|
|
320
|
+
to continue refining it or create a new portal. Recommend continuing unless the user says otherwise.
|
|
321
|
+
|
|
322
|
+
## Conventions
|
|
323
|
+
|
|
324
|
+
- The wizard owns the first-run story. Do not redirect first-time users to freeform prompting unless they explicitly want it.
|
|
325
|
+
- Keep transitions to one sentence whenever possible.
|
|
326
|
+
- Prefer `recommended` over `optional` language when there is a clear best path.
|
|
327
|
+
- Use the cloud dashboard as a supporting surface for billing/provisioning, not as the main first-portal creation surface.
|
|
328
|
+
- If you mention manual prompting at all, position it as the faster repeat-user path.
|
|
329
|
+
|
|
330
|
+
## Error Handling
|
|
331
|
+
|
|
332
|
+
- Missing config is not a preamble failure here. It simply means setup starts from scratch.
|
|
333
|
+
- If a step fails after useful progress, keep the checkpoint and tell the user exactly how to resume.
|
|
334
|
+
- If the user wants to stop early, summarize the current state and point them to the next concrete skill:
|
|
335
|
+
- `/portal-preview`
|
|
336
|
+
- `/portal-credentials`
|
|
337
|
+
- `/portal-share`
|
|
338
|
+
- `/portal-deploy`
|
|
339
|
+
|
|
340
|
+
{{COMPLETION}}
|
|
@@ -11,14 +11,17 @@ allowed-tools: [Bash, Read]
|
|
|
11
11
|
Before doing anything else, execute this block in a Bash tool call:
|
|
12
12
|
|
|
13
13
|
```bash
|
|
14
|
-
|
|
14
|
+
SHOWPANE_HOME="$HOME/.showpane"
|
|
15
|
+
SHOWPANE_BIN="$SHOWPANE_HOME/bin"
|
|
16
|
+
CONFIG="$SHOWPANE_HOME/config.json"
|
|
15
17
|
if [ ! -f "$CONFIG" ]; then
|
|
16
|
-
echo "Showpane not configured. Run /portal
|
|
18
|
+
echo "Showpane not configured. Run /portal-setup first."
|
|
17
19
|
exit 1
|
|
18
20
|
fi
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
21
|
+
|
|
22
|
+
APP_PATH=$("$SHOWPANE_BIN/showpane-config" get app_path 2>/dev/null || python3 -c "import json; d=json.load(open('$CONFIG')); print(d.get('app_path',''))" 2>/dev/null)
|
|
23
|
+
DEPLOY_MODE=$("$SHOWPANE_BIN/showpane-config" get deploy_mode 2>/dev/null || python3 -c "import json; d=json.load(open('$CONFIG')); print(d.get('deploy_mode','local'))" 2>/dev/null || echo "local")
|
|
24
|
+
ORG_SLUG=$("$SHOWPANE_BIN/showpane-config" get orgSlug 2>/dev/null || python3 -c "import json; d=json.load(open('$CONFIG')); print(d.get('orgSlug','') or d.get('org_slug',''))" 2>/dev/null || true)
|
|
22
25
|
APP_PATH="${SHOWPANE_APP_PATH:-$APP_PATH}"
|
|
23
26
|
if [ -f "$APP_PATH/.env" ]; then set -a && source "$APP_PATH/.env" && set +a; fi
|
|
24
27
|
DATABASE_URL="${DATABASE_URL:-}"
|
|
@@ -26,20 +29,26 @@ if [ ! -d "$APP_PATH/node_modules/.prisma" ]; then
|
|
|
26
29
|
echo "App dependencies not installed. Run: cd $APP_PATH && npm install"
|
|
27
30
|
exit 1
|
|
28
31
|
fi
|
|
29
|
-
|
|
32
|
+
|
|
33
|
+
SKILL_DIR="${SHOWPANE_TOOLCHAIN_DIR:-$SHOWPANE_HOME/current}"
|
|
30
34
|
SKILL_VERSION=$(cat "$SKILL_DIR/VERSION" 2>/dev/null || echo "unknown")
|
|
31
|
-
|
|
32
|
-
|
|
35
|
+
_UPD=$("$SHOWPANE_BIN/showpane-update-check" 2>/dev/null || true)
|
|
36
|
+
[ -n "$_UPD" ] && echo "$_UPD" || true
|
|
37
|
+
mkdir -p "$SHOWPANE_HOME/sessions" "$SHOWPANE_HOME/analytics" "$SHOWPANE_HOME/checkpoints"
|
|
38
|
+
touch "$SHOWPANE_HOME/sessions/$PPID"
|
|
39
|
+
find "$SHOWPANE_HOME/sessions" -mmin +120 -type f -delete 2>/dev/null || true
|
|
40
|
+
TEL=$("$SHOWPANE_BIN/showpane-config" get telemetry 2>/dev/null || echo "anonymous")
|
|
41
|
+
TEL_PROMPTED=$([ -f "$SHOWPANE_HOME/.telemetry-prompted" ] && echo "yes" || echo "no")
|
|
42
|
+
_TEL_START=$(date +%s)
|
|
43
|
+
_SESSION_ID="${PPID:-0}-$(date +%s)"
|
|
44
|
+
|
|
45
|
+
LEARN_FILE="$SHOWPANE_HOME/learnings.jsonl"
|
|
33
46
|
[ -f "$LEARN_FILE" ] && echo "LEARNINGS: $(wc -l < "$LEARN_FILE" | tr -d ' ') loaded" || echo "LEARNINGS: 0"
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
_RECENT=$(grep '"event":"completed"' "$HOME/.showpane/timeline.jsonl" 2>/dev/null | tail -3 | grep -o '"skill":"[^"]*"' | sed 's/"skill":"//;s/"//' | tr '\n' ',' | sed 's/,$//' || true)
|
|
47
|
+
if [ -f "$SHOWPANE_HOME/timeline.jsonl" ]; then
|
|
48
|
+
_RECENT=$(grep '"event":"completed"' "$SHOWPANE_HOME/timeline.jsonl" 2>/dev/null | tail -3 | grep -o '"skill":"[^"]*"' | sed 's/"skill":"//;s/"//' | tr '
|
|
49
|
+
' ',' | sed 's/,$//' || true)
|
|
38
50
|
[ -n "$_RECENT" ] && echo "RECENT_SKILLS: $_RECENT"
|
|
39
51
|
fi
|
|
40
|
-
|
|
41
|
-
# Search relevant learnings
|
|
42
|
-
LEARN_FILE="$HOME/.showpane/learnings.jsonl"
|
|
43
52
|
if [ -f "$LEARN_FILE" ]; then
|
|
44
53
|
_LEARN_COUNT=$(wc -l < "$LEARN_FILE" 2>/dev/null | tr -d ' ')
|
|
45
54
|
echo "LEARNINGS: $_LEARN_COUNT entries"
|
|
@@ -49,23 +58,39 @@ if [ -f "$LEARN_FILE" ]; then
|
|
|
49
58
|
fi
|
|
50
59
|
fi
|
|
51
60
|
|
|
52
|
-
|
|
53
|
-
SHOWPANE_TIMELINE="$HOME/.showpane/timeline.jsonl"
|
|
61
|
+
SHOWPANE_TIMELINE="$SHOWPANE_HOME/timeline.jsonl"
|
|
54
62
|
mkdir -p "$(dirname "$SHOWPANE_TIMELINE")"
|
|
55
63
|
echo '{"skill":"portal-preview","event":"started","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$SHOWPANE_TIMELINE" 2>/dev/null
|
|
64
|
+
echo "SHOWPANE: v$SKILL_VERSION | MODE: $DEPLOY_MODE | APP: $APP_PATH"
|
|
65
|
+
echo "TELEMETRY: $TEL"
|
|
66
|
+
echo "TEL_PROMPTED: $TEL_PROMPTED"
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
If output shows `JUST_UPGRADED <from> <to>`, tell the user Showpane was just upgraded and continue.
|
|
70
|
+
|
|
71
|
+
If output shows `UPGRADE_AVAILABLE <old> <new>`, tell the user a newer Showpane toolchain is available and recommend `/portal-upgrade`.
|
|
72
|
+
|
|
73
|
+
If `TEL_PROMPTED` is `no`, default telemetry to `anonymous` without interrupting the flow. Do not mention telemetry unless the user asks.
|
|
74
|
+
|
|
75
|
+
Run:
|
|
76
|
+
```bash
|
|
77
|
+
"$SHOWPANE_BIN/showpane-config" set telemetry anonymous
|
|
78
|
+
touch "$SHOWPANE_HOME/.telemetry-prompted"
|
|
56
79
|
```
|
|
57
80
|
|
|
58
|
-
If RECENT_SKILLS is shown, suggest the likely next skill:
|
|
81
|
+
If `RECENT_SKILLS` is shown, suggest the likely next skill:
|
|
59
82
|
- After portal-create → suggest /portal-preview
|
|
60
|
-
- After portal-preview → suggest /portal-deploy
|
|
83
|
+
- After portal-preview → suggest /portal-deploy
|
|
61
84
|
- After portal-deploy → suggest /portal-status or /portal-verify
|
|
62
|
-
- After portal-setup → suggest /portal-create
|
|
63
|
-
- After portal-credentials → suggest /portal-
|
|
64
|
-
- After portal-update → suggest /portal-deploy
|
|
85
|
+
- After portal-setup → suggest /portal-onboard for a first run, or /portal-create for the fast path
|
|
86
|
+
- After portal-credentials → suggest /portal-deploy before external sharing
|
|
87
|
+
- After portal-update → suggest /portal-preview or /portal-deploy
|
|
65
88
|
|
|
66
|
-
If RECENT_LEARNINGS is shown, review them before proceeding.
|
|
67
|
-
|
|
68
|
-
|
|
89
|
+
If `RECENT_LEARNINGS` is shown, review them before proceeding. Apply them where relevant but do not mention them unless they materially affect the current task.
|
|
90
|
+
|
|
91
|
+
Read `skills/shared/runtime-principles.md` once near the start of the skill and apply the relevant product defaults.
|
|
92
|
+
|
|
93
|
+
If `skills/shared/platform-constraints.md` exists, read it once near the start of the skill and apply only the relevant limits.
|
|
69
94
|
|
|
70
95
|
## Overview
|
|
71
96
|
|
|
@@ -81,8 +106,8 @@ If the user specified a slug (e.g., "preview whzan"), use that slug directly.
|
|
|
81
106
|
|
|
82
107
|
If no slug is provided, check how many portals exist:
|
|
83
108
|
- If there is exactly one portal, use that one and mention it: "Opening your only portal: <slug>"
|
|
84
|
-
- If there are multiple portals, ask: "Which portal do you want to preview? Run /portal
|
|
85
|
-
- If there are zero portals, say: "No portals found. Create one first with /portal
|
|
109
|
+
- If there are multiple portals, ask: "Which portal do you want to preview? Run /portal-list to see your portals."
|
|
110
|
+
- If there are zero portals, say: "No portals found. Create one first with /portal-create."
|
|
86
111
|
|
|
87
112
|
For single-portal organizations, auto-selecting saves a round trip.
|
|
88
113
|
|
|
@@ -114,7 +139,7 @@ This handles deployed URLs, custom domains, and any other public preview target.
|
|
|
114
139
|
|
|
115
140
|
If no server is detected and no app URL is configured, do not open the browser. Instead, inform the user:
|
|
116
141
|
|
|
117
|
-
"No running server detected. Start the dev server with /portal
|
|
142
|
+
"No running server detected. Start the dev server with /portal-dev, or set NEXT_PUBLIC_APP_URL in your .env file."
|
|
118
143
|
|
|
119
144
|
### Step 3: Open the URL in the browser
|
|
120
145
|
|
|
@@ -152,7 +177,7 @@ URL: http://localhost:3000/client/<slug>
|
|
|
152
177
|
```
|
|
153
178
|
|
|
154
179
|
If the portal has credentials set up, remind the user:
|
|
155
|
-
"Login with the credentials from /portal
|
|
180
|
+
"Login with the credentials from /portal-credentials <slug>. For external access, publish first with /portal-deploy."
|
|
156
181
|
|
|
157
182
|
If the portal is the example portal (slug is "example"), no credentials are needed -- it is publicly accessible by design.
|
|
158
183
|
|
|
@@ -179,7 +204,7 @@ This order ensures that during development, the user always sees the latest loca
|
|
|
179
204
|
- **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.
|
|
180
205
|
- **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`.
|
|
181
206
|
- **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>"
|
|
182
|
-
- **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
|
|
207
|
+
- **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."
|
|
183
208
|
|
|
184
209
|
## Error Handling
|
|
185
210
|
|
|
@@ -191,21 +216,21 @@ This order ensures that during development, the user always sees the latest loca
|
|
|
191
216
|
|
|
192
217
|
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:
|
|
193
218
|
|
|
194
|
-
- **Has credentials**: Remind the user of the username (derived from the slug). Do not display the password -- they can get it from `/portal
|
|
195
|
-
- **No credentials**: Warn that the portal will show a login page but there are no credentials to enter. Suggest running `/portal
|
|
219
|
+
- **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.
|
|
220
|
+
- **No credentials**: Warn that the portal will show a login page but there are no credentials to enter. Suggest running `/portal-credentials <slug>` first.
|
|
196
221
|
- **Example portal**: The built-in example at `/client/example` is publicly accessible and does not require login. No credentials needed.
|
|
197
222
|
|
|
198
|
-
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."
|
|
223
|
+
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."
|
|
199
224
|
|
|
200
225
|
## Previewing After Changes
|
|
201
226
|
|
|
202
|
-
A common workflow is: edit portal content with `/portal
|
|
227
|
+
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.
|
|
203
228
|
|
|
204
|
-
If the user just ran `/portal
|
|
229
|
+
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."
|
|
205
230
|
|
|
206
231
|
## Multiple Portals Preview
|
|
207
232
|
|
|
208
|
-
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
|
|
233
|
+
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."
|
|
209
234
|
|
|
210
235
|
To open multiple tabs, run the open command for each URL sequentially:
|
|
211
236
|
|
|
@@ -229,15 +254,11 @@ No portal slug or URL is included in telemetry. The event only records that a pr
|
|
|
229
254
|
|
|
230
255
|
## Completion
|
|
231
256
|
|
|
232
|
-
As a final step, log skill completion:
|
|
257
|
+
As a final step, log skill completion and telemetry:
|
|
233
258
|
|
|
234
259
|
```bash
|
|
235
260
|
echo '{"skill":"portal-preview","event":"completed","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$HOME/.showpane/timeline.jsonl" 2>/dev/null
|
|
261
|
+
_TEL_END=$(date +%s)
|
|
262
|
+
_TEL_DUR=$(( _TEL_END - ${_TEL_START:-_TEL_END} ))
|
|
263
|
+
"$HOME/.showpane/bin/showpane-telemetry-log" --skill "portal-preview" --duration "$_TEL_DUR" --outcome success --session-id "${_SESSION_ID:-}" 2>/dev/null || true
|
|
236
264
|
```
|
|
237
|
-
|
|
238
|
-
## Related Skills
|
|
239
|
-
|
|
240
|
-
- `/portal dev` -- start the local development server
|
|
241
|
-
- `/portal share` -- generate a link that works for anyone, not just the local machine
|
|
242
|
-
- `/portal deploy` -- deploy to production so the portal is accessible externally
|
|
243
|
-
- `/portal credentials` -- get or rotate login credentials for the portal
|