@mkterswingman/5mghost-wonder 0.0.10 → 0.0.11
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
CHANGED
|
@@ -7,9 +7,9 @@ description: Use this skill when the user wants to install or set up wonder, say
|
|
|
7
7
|
|
|
8
8
|
## Skill version
|
|
9
9
|
|
|
10
|
-
This skill matches **wonder 0.0.
|
|
10
|
+
This skill matches **wonder 0.0.11**.
|
|
11
11
|
|
|
12
|
-
Once the CLI is installed in Step 1, run `wonder --version`. If the output does not equal `0.0.
|
|
12
|
+
Once the CLI is installed in Step 1, run `wonder --version`. If the output does not equal `0.0.11`, the CLI on disk has drifted from the skill text loaded in this session. Ask the user to run `/update-5mghost-wonder`, then **start a fresh AI session** (`/exit` and re-enter, or open a new chat) — skill text already loaded into a running session does not refresh after `wonder update`, even though the file on disk has been replaced.
|
|
13
13
|
|
|
14
14
|
After a successful first install, also remind the user to start a fresh AI session before invoking `/use-5mghost-wonder` for the first time. The skill files were just written to disk; the current session never loaded them.
|
|
15
15
|
|
|
@@ -79,18 +79,27 @@ Check current cookie status:
|
|
|
79
79
|
wonder wecom status
|
|
80
80
|
```
|
|
81
81
|
|
|
82
|
-
If expired or
|
|
82
|
+
If the cookie is expired, missing, invalid, or the check gets 401/403, do not
|
|
83
|
+
give the user a manual cookie-export path. Ask the user whether now is a
|
|
84
|
+
convenient time to open the browser for WeCom login. If they confirm, run the
|
|
85
|
+
CLI yourself:
|
|
83
86
|
|
|
84
87
|
```bash
|
|
85
88
|
wonder wecom cookie
|
|
86
89
|
```
|
|
87
90
|
|
|
88
|
-
This
|
|
91
|
+
This is expected to launch the local Chrome/Edge browser login page via CDP and
|
|
92
|
+
block until the user logs in or scans the QR code in WeCom mobile. When the
|
|
93
|
+
command returns, verify:
|
|
89
94
|
|
|
90
95
|
```bash
|
|
91
96
|
wonder wecom status
|
|
92
97
|
```
|
|
93
98
|
|
|
99
|
+
Never ask the user to install Cookie-Editor, export JSON, paste a cookie
|
|
100
|
+
string, run `wonder wecom cookie` themselves, or use `wonder wecom set-cookie`
|
|
101
|
+
unless the user explicitly asks for a manual/dev/CI cookie path.
|
|
102
|
+
|
|
94
103
|
---
|
|
95
104
|
|
|
96
105
|
## Step 4 — Detect and install docx skill (for the AI you are running in)
|
|
@@ -7,9 +7,9 @@ description: Use this skill when the user shares a URL containing "doc.weixin.qq
|
|
|
7
7
|
|
|
8
8
|
## Skill version
|
|
9
9
|
|
|
10
|
-
This skill matches **wonder 0.0.
|
|
10
|
+
This skill matches **wonder 0.0.11**.
|
|
11
11
|
|
|
12
|
-
In the Session Initialization step below, after running `wonder --version`, compare the output to `0.0.
|
|
12
|
+
In the Session Initialization step below, after running `wonder --version`, compare the output to `0.0.11`. If they differ, the loaded skill text and the CLI on disk are out of sync. Stop, tell the user to run `/update-5mghost-wonder`, and then **start a fresh AI session** (`/exit` and re-enter, or open a new chat) before trying again. `wonder update` rewrites the skill files on disk, but skill text already loaded into the current session does not auto-refresh.
|
|
13
13
|
|
|
14
14
|
## Session Initialization (first use only per session)
|
|
15
15
|
|
|
@@ -19,26 +19,36 @@ The **first time** you encounter a WeCom document URL in a session, run these ch
|
|
|
19
19
|
# 1. Check for updates
|
|
20
20
|
wonder update
|
|
21
21
|
|
|
22
|
-
# 2. Confirm the CLI version matches this skill's expected version (0.0.
|
|
22
|
+
# 2. Confirm the CLI version matches this skill's expected version (0.0.11)
|
|
23
23
|
wonder --version
|
|
24
24
|
|
|
25
25
|
# 3. Check WeCom cookie status
|
|
26
26
|
wonder wecom status
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
## Cookie refresh behavior
|
|
30
|
+
|
|
31
|
+
If `wonder wecom status`, `wonder read <url>`, or any WeCom request reports
|
|
32
|
+
that the cookie is expired, missing, invalid, or got 401/403, do not give the
|
|
33
|
+
user a manual cookie-export path. Ask the user whether now is a convenient time
|
|
34
|
+
to open the browser for WeCom login. If they confirm, run the CLI yourself:
|
|
30
35
|
|
|
31
36
|
```bash
|
|
32
37
|
wonder wecom cookie
|
|
33
38
|
```
|
|
34
39
|
|
|
35
|
-
|
|
40
|
+
`wonder wecom cookie` is expected to launch the local browser login page. Wait
|
|
41
|
+
for the user to complete the browser login or QR scan, then verify:
|
|
36
42
|
|
|
37
43
|
```bash
|
|
38
44
|
wonder wecom status
|
|
39
45
|
```
|
|
40
46
|
|
|
41
|
-
Proceed only after cookie is valid
|
|
47
|
+
Proceed only after the cookie is valid, then retry the original `wonder read`
|
|
48
|
+
command. Never ask the user to install Cookie-Editor, export JSON, paste a
|
|
49
|
+
cookie string, run `wonder wecom cookie` themselves, or use
|
|
50
|
+
`wonder wecom set-cookie` unless the user explicitly asks for a manual/dev/CI
|
|
51
|
+
cookie path.
|
|
42
52
|
|
|
43
53
|
---
|
|
44
54
|
|