@vatio-ai/skills 1.5.0 → 1.6.0

package/.claude-plugin/marketplace.json

@@ -5,7 +5,7 @@
     {
       "name": "vatio",
       "source": "./",
-      "description": "Build a Vatio agent from your coding agent, then fix what supervisors flag and prove it with evals."
+      "description": "Build a Vatio agent from your coding agent, then fix what supervisors report and prove it with evals."
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "vatio",
-  "description": "Build a Vatio agent from your coding agent, then fix what supervisors flag and prove it with evals.",
-  "version": "1.5.0",
+  "description": "Build a Vatio agent from your coding agent, then fix what supervisors report and prove it with evals.",
+  "version": "1.6.0",
   "author": { "name": "Vatio", "url": "https://vatio.ai" },
   "homepage": "https://vatio.ai/docs",
   "repository": "https://github.com/vatio-ai/skills",

package/README.md

@@ -5,7 +5,7 @@ Skills for the coding agent working on your [Vatio](https://vatio.ai) agent.
 | Skill | What it does |
 |---|---|
 | `vatio-init` | The first one in a project: looks at what is already there (a `vatio.yml` anywhere in the repository, the app's code) and recommends from it. With no agent yet, builds one: asks the owner what the code does not answer, writes `vatio.yml`, pushes it and hands over a link to try. With one, gets a developer who joined the project up to speed |
-| `vatio-improve` | Works through the replies your supervisors flagged in the inbox: reads `vatio flags`, fixes each cause on a branch, proves it with `vatio eval`, and opens a pull request |
+| `vatio-improve` | Takes every reply your supervisors reported in the inbox in one session: reads `vatio flags`, fixes each cause, `vatio push`, proves it with `vatio eval` (in the background in Claude Code) and publishes with `vatio publish` |
 | `vatio-share-session` | Sends the Claude Code session to the Vatio team when you ask it to, or offers to when the other two finish (send it, not now, or don't ask again), after showing you what goes (images left out, anything that looks like a secret redacted), with your feedback if you want to add some |
 
 The skills are short on purpose. They tell your coding agent when to reach for

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vatio-ai/skills",
-  "version": "1.5.0",
+  "version": "1.6.0",
   "description": "Agent skills for building and improving a Vatio agent from your coding agent: Claude Code, Codex, Cursor, Gemini CLI, Copilot and any agent that reads SKILL.md",
   "keywords": [
     "vatio",

package/skills/vatio-improve/SKILL.md

@@ -1,44 +1,44 @@
 ---
 name: vatio-improve
-description: Improve a Vatio agent from what its supervisors flagged. Use when asked to improve, fix or debug a Vatio agent, to work through flagged replies or wrong answers in production, or when a GitHub issue labelled vatio-flags arrives. Works in any directory with a vatio.yml.
+description: Improve a Vatio agent from what its supervisors reported. Use when asked to improve, fix or debug a Vatio agent, to work through reported or flagged replies or wrong answers in production, or when the daily Vatio email says there are open reports. Works in any directory with a vatio.yml.
 ---
 
-# Improve a Vatio agent from its flags
+# Improve a Vatio agent from its reports
 
-Supervisors flag wrong replies in the Vatio inbox and write what should have
-happened: a different answer, an action, or a tool the agent should have used
-or does not have. Vatio keeps the instructions for working them on the
-platform, so they are never out of date here. Start by reading them:
+Supervisors report wrong replies in the Vatio inbox and write what it should
+have said: a different answer, an action, or a tool the agent should have
+used or does not have. One session takes every open report. Vatio keeps the
+instructions for working them on the platform, so they are never out of date
+here. Start by reading them:
 
 ```bash
 vatio flags
 ```
 
 Run it from the directory with the workspace's `vatio.yml` (or below it). It
-prints every open flag — the conversation, each tool call with what the
+prints every open report — the conversation, each tool call with what the
 backend answered, and the supervisor's note — with how to work them at the
 top. Follow those instructions; they take precedence over anything below.
 
 In short:
 
-1. Group the flags by cause, and fix each cause where it lives: `vatio.yml`,
-   a knowledge entry, a tool, or the backend a tool calls. `vatio tools --env
-   live` shows each tool's error rate, timeouts and latency across every
-   conversation, and the calls that failed with what the backend answered: a
-   failing tool rarely gets flagged, because the agent apologizes and moves
+1. Group the reports by cause, and fix each cause where it lives:
+   `vatio.yml`, a knowledge entry, a tool, or the developer's backend a tool
+   calls. `vatio tools --env live` shows each tool's error rate, timeouts and
+   latency, and the calls that failed with what the backend answered: a
+   failing tool rarely gets reported, because the agent apologizes and moves
    on. Fix those too.
-2. Work on a git branch. `vatio push` deploys it to the branch's own
-   environment, never to live.
-3. Prove it with `vatio eval`: every flag made on live, or before the first publish, is an eval case, replayed against
-   the branch and judged. The report counts the open flags apart from the
-   regression cases. A fix is done when its flags pass and nothing that
-   passed on live now fails.
-4. Open a pull request with what you changed and the eval result. Name flags
-   by id (`F-7K2QX`), and report the open flags and the
-   regression cases as two counts, never one total. With no GitHub
-   repository connected, `vatio propose --env <branch> --title "…"
-   --summary-file why.md` instead: the workspace's owner accepts it from the
-   inbox, which publishes it. Never `vatio publish` it yourself.
+2. `vatio push`. It updates preview and runs no tests. No branch or
+   environment to set up: preview is the one.
+3. `vatio eval` tests every report against preview. It can take several
+   minutes, so in Claude Code start it with the Bash tool's
+   `run_in_background` and read its report when it finishes. Iterate (fix,
+   push, eval) until the reports pass and nothing that passes on live fails.
+   Name reports by id (`F-7K2QX`).
+4. Show the developer what passes now, and `vatio publish` once they agree:
+   it changes what visitors get. If it is refused, follow its message: it
+   says what to run. Never pass `--force` unless the developer explicitly
+   asks for it.
 5. If the digest, an error or the docs left you guessing, say so:
    `vatio feedback "what you were doing and what was missing"`.
 6. Last, in Claude Code, offer to send this session to the Vatio team, as

package/skills/vatio-init/SKILL.md

@@ -56,7 +56,7 @@ you recommend, and ask them to confirm.
   `vatio.yml` (what it is for, its tools, its knowledge, when it hands off)
   and recommend from what you see:
   - the folder differs from live: say so first, the repository may be behind;
-  - open flags in `vatio flags`: work them with the `vatio-improve` skill;
+  - open reports in `vatio flags`: work them with the `vatio-improve` skill;
   - tool calls failing in `vatio tools`: the fix is in the backend they call;
   - `workspace_forbidden`: they are not in the workspace yet, and the owner
     invites them from **Team** in the console.