@the-open-engine-company/zeroshot 10.14.0 → 10.16.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.
- package/package.json +2 -2
- package/skills/zeroshot/SKILL.md +74 -2
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@the-open-engine-company/zeroshot",
|
|
3
|
-
"version": "10.
|
|
4
|
-
"description": "Runs coding agents as a graph: one agent implements, independent agents review, failures go to repair, and nothing ships until the checks pass. Works with Codex, Claude Code
|
|
3
|
+
"version": "10.16.0",
|
|
4
|
+
"description": "Runs coding agents as a graph: one agent implements, independent agents review, failures go to repair, and nothing ships until the checks pass. Works with Codex, Claude Code, GitHub Copilot and Pi.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"claude-code",
|
|
7
7
|
"codex",
|
package/skills/zeroshot/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: zeroshot
|
|
3
|
-
description: Use Zeroshot to prepare, run, observe, or troubleshoot explicit multi-agent software work locally or on Zeroshot Cloud. Apply when the user names Zeroshot or asks about its CLI; do not route ordinary local work into Zeroshot without that intent.
|
|
3
|
+
description: Use Zeroshot to prepare, run, observe, or troubleshoot explicit multi-agent software work locally or on Zeroshot Cloud. Apply when the user names Zeroshot, including 'zeroshot this' or 'zeroshot it' (this orchestrator, not one-shot prompting), or asks about its CLI; do not route ordinary local work into Zeroshot without that intent.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Zeroshot
|
|
@@ -43,9 +43,12 @@ another run. A failed Cloud run does not authorize silently implementing the tas
|
|
|
43
43
|
## Reuse profiles and connections
|
|
44
44
|
|
|
45
45
|
Prefer a saved profile over inventing a graph or runtime. Inspect its input, runtime, and delivery
|
|
46
|
-
behavior before constructing a run
|
|
46
|
+
behavior before constructing a run. Local profiles need no login; a local default profile applies
|
|
47
|
+
when a run names no profile, graph, or runtime:
|
|
47
48
|
|
|
48
49
|
```console
|
|
50
|
+
zeroshot profile list
|
|
51
|
+
zeroshot profile show NAME
|
|
49
52
|
zeroshot profile list --target cloud --scope user
|
|
50
53
|
zeroshot profile list --target cloud --scope org
|
|
51
54
|
zeroshot profile show NAME --target cloud --scope org
|
|
@@ -56,6 +59,69 @@ zeroshot connection list --target cloud --scope org
|
|
|
56
59
|
Do not assume a profile creates a pull request. `--pr` requests pull-request delivery and `--ship`
|
|
57
60
|
requests merge delivery when materializing a compatible template; use either only when intended.
|
|
58
61
|
|
|
62
|
+
## Run locally without a profile
|
|
63
|
+
|
|
64
|
+
When no saved profile fits and the user has not asked for Cloud, run the built-in
|
|
65
|
+
`software-change` graph locally. It needs no login beyond the harness you are running in.
|
|
66
|
+
|
|
67
|
+
1. The worker edits the selected folder in place. Stop if it has uncommitted changes, and start
|
|
68
|
+
from a fresh branch when the folder is a Git repository.
|
|
69
|
+
2. Write the shaped task to an input file outside the workspace, for example
|
|
70
|
+
`{"task": "Add JSON output to the status command and cover it with focused tests."}`.
|
|
71
|
+
3. Write a uniform runtime file for the harness you are running in, with your own model identifier
|
|
72
|
+
unless the user names another. Local Claude Code and Codex lanes reuse their native login:
|
|
73
|
+
|
|
74
|
+
```json
|
|
75
|
+
{ "harness": "claude", "provider": "anthropic", "model": "MODEL_ID", "effort": "high" }
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
```json
|
|
79
|
+
{ "harness": "codex", "provider": "openai", "model": "MODEL_ID", "effort": "high" }
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
4. Validate, then submit the same command without `--validate-only`. Add `--pr` or `--ship` only
|
|
83
|
+
when the user asked for delivery:
|
|
84
|
+
|
|
85
|
+
```console
|
|
86
|
+
zeroshot run --title "TASK" --template software-change \
|
|
87
|
+
--input INPUT.json --uniform-runtime-config RUNTIME.json --validate-only
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
5. Follow the run with `zeroshot status RUN_ID` and `zeroshot logs RUN_ID`. The user can watch it
|
|
91
|
+
in `zeroshot ui` at `http://127.0.0.1:4173/ui/`.
|
|
92
|
+
6. Report what each reviewer rejected and what each repair changed, not only the final state. If
|
|
93
|
+
the run exposed a gap the built-in reviewers do not cover, name one reviewer worth adding.
|
|
94
|
+
7. Offer to save the setup as the default, so later requests need no files:
|
|
95
|
+
|
|
96
|
+
```console
|
|
97
|
+
zeroshot profile set NAME --template software-change \
|
|
98
|
+
--uniform-runtime-config RUNTIME.json --default
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
## Adapt the graph
|
|
102
|
+
|
|
103
|
+
When the user wants to change what gets checked, start from the built-in graph rather than writing
|
|
104
|
+
one from scratch:
|
|
105
|
+
|
|
106
|
+
1. Export it with `zeroshot template show software-change > graph.json`.
|
|
107
|
+
2. Make the change the user asked for: add a reviewer with one job (security, an end-to-end test
|
|
108
|
+
that boots the app, design), or change the loop's `maxIterations`. Different models or harnesses
|
|
109
|
+
per node need a full `--runtime-config` plan instead of the uniform file. The
|
|
110
|
+
[review loop guide](https://the-open-engine.github.io/zeroshot/current/guides/review-loop/)
|
|
111
|
+
shows the node shapes and a cross-vendor plan.
|
|
112
|
+
3. Validate by replacing `--template software-change` with `--graph graph.json` in the run command
|
|
113
|
+
above, then run it.
|
|
114
|
+
4. Save it so later requests use it, with `--runtime-config PLAN.json` in place of the uniform file
|
|
115
|
+
when nodes use different models or harnesses:
|
|
116
|
+
|
|
117
|
+
```console
|
|
118
|
+
zeroshot profile set NAME --graph graph.json \
|
|
119
|
+
--uniform-runtime-config RUNTIME.json --default
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
5. When runs keep failing the same way, or a problem gets past the reviewers, suggest the reviewer
|
|
123
|
+
that would catch it and ask before changing the graph.
|
|
124
|
+
|
|
59
125
|
## Prepare the execution environment
|
|
60
126
|
|
|
61
127
|
Environments belong to a run, independently of its profile. A `local:NAME` profile can run on a
|
|
@@ -81,6 +147,12 @@ services. Both hooks rerun on resume, so startup must tolerate existing workspac
|
|
|
81
147
|
Checkpoints restore files and graph progress, not running services or agent conversations.
|
|
82
148
|
|
|
83
149
|
Put shared executables in `$ZEROSHOT_TOOLS/bin` and project dependencies in the workspace.
|
|
150
|
+
|
|
151
|
+
Snapshots include ignored directories such as `target/` and `node_modules/`. Without cloning or
|
|
152
|
+
reflinks, allow space for another full workspace copy during staging, plus checkpoint storage.
|
|
153
|
+
Before large or parallel runs on tight disks, warn users and suggest cleaning build artifacts or
|
|
154
|
+
keeping generated directories outside the workspace where practical.
|
|
155
|
+
|
|
84
156
|
Shell exports do not persist between hooks or agents; use `variables` for nonsecret values and
|
|
85
157
|
`connections` for required secret field names. Hook connections and node connections are separate.
|
|
86
158
|
On a direct Docker target, root setup changes the container shared by its runs.
|