@vatio-ai/skills 1.11.0 → 1.12.0
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.
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "vatio",
|
|
3
3
|
"description": "The Vatio plugin for Claude Code: build a conversational agent for your app with one prompt, then improve it daily with vatio-improve.",
|
|
4
|
-
"version": "1.
|
|
4
|
+
"version": "1.12.0",
|
|
5
5
|
"author": { "name": "Vatio", "url": "https://vatio.ai" },
|
|
6
6
|
"homepage": "https://vatio.ai/docs",
|
|
7
7
|
"repository": "https://github.com/vatio-ai/skills",
|
package/package.json
CHANGED
|
@@ -22,26 +22,34 @@ top. Follow those instructions; they take precedence over anything below.
|
|
|
22
22
|
|
|
23
23
|
In short:
|
|
24
24
|
|
|
25
|
-
1.
|
|
25
|
+
1. Read each report's **Diagnosis** first: it says whose it is to fix, from
|
|
26
|
+
what that turn did. **Your backend**: a tool call to it failed. **Your
|
|
27
|
+
agent**: everything answered and the reply was still wrong, so the fix is
|
|
28
|
+
in `vatio.yml`, knowledge or a tool's definition. **Vatio**: the model
|
|
29
|
+
provider or Vatio failed and Vatio wrote the reply itself. Do not change
|
|
30
|
+
the agent for those: tell the developer, who can remove the report, and
|
|
31
|
+
if they keep happening, `vatio feedback`.
|
|
32
|
+
2. Group the reports by cause, and fix each cause where it lives:
|
|
26
33
|
`vatio.yml`, a knowledge entry, a tool, or the developer's backend a tool
|
|
27
34
|
calls. `vatio tools --env live` shows each tool's error rate, timeouts and
|
|
28
35
|
latency, and the calls that failed with what the backend answered: a
|
|
29
36
|
failing tool rarely gets reported, because the agent apologizes and moves
|
|
30
37
|
on. Fix those too.
|
|
31
|
-
|
|
38
|
+
3. `vatio push`. It updates preview and runs no tests. No branch or
|
|
32
39
|
environment to set up: preview is the one.
|
|
33
|
-
|
|
40
|
+
4. `vatio eval` tests every report against preview. It can take several
|
|
34
41
|
minutes, so in Claude Code start it with the Bash tool's
|
|
35
42
|
`run_in_background` and read its report when it finishes. Iterate (fix,
|
|
36
43
|
push, eval) until the reports pass and nothing that passes on live fails.
|
|
37
|
-
|
|
38
|
-
|
|
44
|
+
A case marked "not tested (Vatio's side)" says nothing about your fix:
|
|
45
|
+
run `vatio eval` again. Name reports by id (`F-7K2QX`).
|
|
46
|
+
5. Show the developer what passes now, and `vatio publish` once they agree:
|
|
39
47
|
it changes what visitors get. If it is refused, follow its message: it
|
|
40
48
|
says what to run. Never pass `--force` unless the developer explicitly
|
|
41
49
|
asks for it.
|
|
42
|
-
|
|
50
|
+
6. If the digest, an error or the docs left you guessing, say so:
|
|
43
51
|
`vatio feedback "what you were doing and what was missing"`.
|
|
44
|
-
|
|
52
|
+
7. Last, in Claude Code, offer to send this session to the Vatio team, as
|
|
45
53
|
the `vatio-share-session` skill says. It starts with
|
|
46
54
|
`vatio share-session --should-ask`: if that prints `no`, say nothing.
|
|
47
55
|
|