shiply-cli 0.20.1 → 0.20.2
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/package.json +1 -1
- package/skill/SKILL.md +19 -7
package/package.json
CHANGED
package/skill/SKILL.md
CHANGED
|
@@ -64,14 +64,25 @@ POST https://shiply.now/api/v1/auth/device/poll
|
|
|
64
64
|
```
|
|
65
65
|
|
|
66
66
|
The response is one of `{status:"pending"}` (keep polling at `interval`s),
|
|
67
|
-
`{status:"approved", api_key:"shp_...", slug_claimed:"..."}` (
|
|
68
|
-
|
|
69
|
-
click), `{status:"expired"|"denied"|"consumed"}` (stop). Cap your polling at
|
|
67
|
+
`{status:"approved", api_key:"shp_...", slug_claimed:"..."}` (PERSIST the key —
|
|
68
|
+
see "Save the key" below — the site is now permanent; Allow does both jobs in
|
|
69
|
+
one click), `{status:"expired"|"denied"|"consumed"}` (stop). Cap your polling at
|
|
70
70
|
the announced `expires_in` and respect `interval` — don't tight-loop.
|
|
71
71
|
|
|
72
72
|
After approval, every future publish uses `Authorization: Bearer <api_key>`
|
|
73
73
|
and the user's dashboard shows their sites without any further claiming.
|
|
74
74
|
|
|
75
|
+
### Save the key — so EVERY future site is seamless (do this once)
|
|
76
|
+
|
|
77
|
+
Write the key to **`~/.shiply/credentials`** as `{"apiKey":"shp_..."}` (chmod
|
|
78
|
+
600) — the exact file the shiply CLI reads. This is what makes "one Allow, ever"
|
|
79
|
+
work: from then on every publish (any site, any project, ANY FUTURE SESSION)
|
|
80
|
+
sends `Authorization: Bearer <key>` automatically and lands owned in the user's
|
|
81
|
+
dashboard — no re-authorizing, no claim step, zero clicks. An env var alone
|
|
82
|
+
(`SHIPLY_API_KEY`) works for the current shell but does NOT survive a new
|
|
83
|
+
session — the credentials file is what makes it permanent. `shiply login` writes
|
|
84
|
+
this file for you; if you publish over raw HTTP, write it yourself.
|
|
85
|
+
|
|
75
86
|
## When the user pastes you something shiply-shaped, do this
|
|
76
87
|
|
|
77
88
|
These are the patterns you will see. Match the input, run the action — do not
|
|
@@ -94,10 +105,11 @@ ask the user to repeat themselves or explain.
|
|
|
94
105
|
as `https://shiply.now/claim/<slug>?token=<claimToken>` from those fields.
|
|
95
106
|
Either way, also suggest `shiply login` so future publishes mint to their
|
|
96
107
|
account directly — that's the long-term fix and how the dashboard works.
|
|
97
|
-
- **User says "I have an API key now, use it from now on"** →
|
|
98
|
-
`
|
|
99
|
-
`Authorization: Bearer <key>` on every future publish.
|
|
100
|
-
are then permanent and appear in their dashboard
|
|
108
|
+
- **User says "I have an API key now, use it from now on"** → persist it to
|
|
109
|
+
`~/.shiply/credentials` (`{"apiKey":"shp_..."}`, chmod 600 — see "Save the
|
|
110
|
+
key" above), then send `Authorization: Bearer <key>` on every future publish.
|
|
111
|
+
All future sites are then permanent and appear in their dashboard
|
|
112
|
+
automatically — across sessions, with no re-authorizing.
|
|
101
113
|
- **User opens an `https://shiply.now/auth/XXXX-YYYY` URL you printed** → no
|
|
102
114
|
action from you; they're on the device-flow consent screen. Keep polling
|
|
103
115
|
`poll_url` (see "First publish on a new machine" above). The poll response
|