agent-conveyor 0.1.19 → 0.1.21
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/README.md +24 -3
- package/dist/cli/typescript-runtime.js +207 -2
- package/dist/cli/typescript-runtime.js.map +1 -1
- package/package.json +2 -1
- package/plugin/agent-conveyor/plugin.json +16 -0
- package/plugin/agent-conveyor/skills/conveyor-check-status/SKILL.md +38 -0
- package/plugin/agent-conveyor/skills/conveyor-create-pair/SKILL.md +43 -0
- package/plugin/agent-conveyor/skills/conveyor-create-worker-set/SKILL.md +55 -0
- package/plugin/agent-conveyor/skills/conveyor-whats-next-nudger/SKILL.md +116 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "agent-conveyor",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.21",
|
|
4
4
|
"description": "Local agent manager/worker conveyor control plane for Codex sessions.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
|
@@ -24,6 +24,7 @@
|
|
|
24
24
|
"dist/",
|
|
25
25
|
"scripts/capture-static-html-screenshot.mjs",
|
|
26
26
|
"skills/**/*",
|
|
27
|
+
"plugin/**/*",
|
|
27
28
|
"scripts/serve-landing-page.mjs",
|
|
28
29
|
"README.md",
|
|
29
30
|
"docs/landing-page.html",
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "agent-conveyor",
|
|
3
|
+
"version": "0.1.21",
|
|
4
|
+
"description": "Codex operator skills for Agent Conveyor manager-worker setup.",
|
|
5
|
+
"skills": [
|
|
6
|
+
"conveyor-create-pair",
|
|
7
|
+
"conveyor-create-worker-set",
|
|
8
|
+
"conveyor-check-status",
|
|
9
|
+
"conveyor-whats-next-nudger"
|
|
10
|
+
],
|
|
11
|
+
"requires": {
|
|
12
|
+
"npmPackage": "agent-conveyor",
|
|
13
|
+
"sessionKind": "codex_app",
|
|
14
|
+
"ledger": "per_project"
|
|
15
|
+
}
|
|
16
|
+
}
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: conveyor-check-status
|
|
3
|
+
description: Check Agent Conveyor manager/worker or worker-set status from the current project's per-project ledger.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Conveyor Check Status
|
|
7
|
+
|
|
8
|
+
Use this skill when the operator asks for the status of an Agent Conveyor pair
|
|
9
|
+
or worker set from any project.
|
|
10
|
+
|
|
11
|
+
## Rules
|
|
12
|
+
|
|
13
|
+
- Operator-facing only.
|
|
14
|
+
- Codex app native sessions only.
|
|
15
|
+
- Use `.codex-workers/workerctl.db` under the current project unless the
|
|
16
|
+
operator explicitly provides another path.
|
|
17
|
+
- Do not inspect product code or private content.
|
|
18
|
+
- Treat ledger claims as claims unless backed by durable receipts.
|
|
19
|
+
- Prefer compact status receipts with exact next action.
|
|
20
|
+
|
|
21
|
+
## Commands
|
|
22
|
+
|
|
23
|
+
For a known task:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
TASK="example-task"
|
|
27
|
+
conveyor app-loop-status "$TASK" --path "$PWD/.codex-workers/workerctl.db" --json
|
|
28
|
+
conveyor app-autopilot status "$TASK" --path "$PWD/.codex-workers/workerctl.db" --json
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
For an unknown task, list candidate records first:
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
conveyor tasks --path "$PWD/.codex-workers/workerctl.db" --json
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Report manager and worker thread ids/titles, stale roles, inbox backlog,
|
|
38
|
+
heartbeat/autopilot state, dispatch health, and the exact next action.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: conveyor-create-pair
|
|
3
|
+
description: Create one visible Codex app manager and one visible Codex app worker for the current project using the globally installed Agent Conveyor CLI.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Conveyor Create Pair
|
|
7
|
+
|
|
8
|
+
Use this skill when the operator wants a Codex-app-only manager/worker pair
|
|
9
|
+
from any target project. This skill is operator-facing. Do not use tmux in this
|
|
10
|
+
tranche.
|
|
11
|
+
|
|
12
|
+
## Rules
|
|
13
|
+
|
|
14
|
+
- Treat the current working directory as the target project.
|
|
15
|
+
- Use `.codex-workers/workerctl.db` under the target project unless the
|
|
16
|
+
operator explicitly gives another path.
|
|
17
|
+
- Verify `conveyor` is available before setup:
|
|
18
|
+
`command -v conveyor && conveyor plugin-status --json`.
|
|
19
|
+
- If `conveyor` is missing or the plugin is stale, tell the operator:
|
|
20
|
+
`npm install -g agent-conveyor && conveyor install-plugin`.
|
|
21
|
+
- Use native Codex app thread tools when available to create visible manager
|
|
22
|
+
and worker threads.
|
|
23
|
+
- Do not inspect product code as part of pair setup.
|
|
24
|
+
- Generated manager and worker prompts must require visible session sections:
|
|
25
|
+
`CONVEYOR POLL`, `CONVEYOR RECEIVED`, `WORK`, `CONVEYOR SEND`, and
|
|
26
|
+
`DISPATCH`.
|
|
27
|
+
|
|
28
|
+
## Default Ledger
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
mkdir -p .codex-workers
|
|
32
|
+
LEDGER="$PWD/.codex-workers/workerctl.db"
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Operator Flow
|
|
36
|
+
|
|
37
|
+
1. Clarify the bounded task name only if the operator has not provided one.
|
|
38
|
+
2. Create one manager Codex app thread and one worker Codex app thread.
|
|
39
|
+
3. Run `conveyor create-disposable-binding` with the created thread ids and:
|
|
40
|
+
`--path "$PWD/.codex-workers/workerctl.db" --json`.
|
|
41
|
+
4. Return the manager thread title/id, worker thread title/id, ledger path,
|
|
42
|
+
task name, and exact status command:
|
|
43
|
+
`TASK="example-task"; conveyor app-loop-status "$TASK" --path "$PWD/.codex-workers/workerctl.db" --json`.
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: conveyor-create-worker-set
|
|
3
|
+
description: Create one visible Codex app manager and multiple visible Codex app workers for the current project using Agent Conveyor.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Conveyor Create Worker Set
|
|
7
|
+
|
|
8
|
+
Use this skill when the operator wants one Codex app manager supervising
|
|
9
|
+
multiple Codex app workers. This skill creates the set and bindings; it does
|
|
10
|
+
not run a campaign, Ralph loop, ship-it loop, or tmux workflow.
|
|
11
|
+
|
|
12
|
+
## Rules
|
|
13
|
+
|
|
14
|
+
- Operator-facing only.
|
|
15
|
+
- Codex app native sessions only.
|
|
16
|
+
- Use the current working directory as the target project.
|
|
17
|
+
- Use `.codex-workers/workerctl.db` under the target project by default.
|
|
18
|
+
- Create concise worker role names when the operator does not provide them.
|
|
19
|
+
- Do not inspect product code during setup.
|
|
20
|
+
|
|
21
|
+
## Default Ledger
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
mkdir -p .codex-workers
|
|
25
|
+
LEDGER="$PWD/.codex-workers/workerctl.db"
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## Operator Flow
|
|
29
|
+
|
|
30
|
+
1. Determine worker count and role labels.
|
|
31
|
+
2. Create one manager Codex app thread.
|
|
32
|
+
3. Create one worker Codex app thread per role.
|
|
33
|
+
4. For each worker role, create one Conveyor task and app-session binding:
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
TASK="example-worker-role-task"
|
|
37
|
+
WORKER_NAME="example-worker-role"
|
|
38
|
+
WORKER_THREAD_ID="created-worker-thread-id"
|
|
39
|
+
WORKER_THREAD_TITLE="Created Worker Thread"
|
|
40
|
+
MANAGER_NAME="example-manager"
|
|
41
|
+
MANAGER_THREAD_ID="created-manager-thread-id"
|
|
42
|
+
MANAGER_THREAD_TITLE="Created Manager Thread"
|
|
43
|
+
conveyor create-disposable-binding "$TASK" \
|
|
44
|
+
--worker "$WORKER_NAME" \
|
|
45
|
+
--manager "$MANAGER_NAME" \
|
|
46
|
+
--worker-codex-app-thread-id "$WORKER_THREAD_ID" \
|
|
47
|
+
--worker-codex-app-thread-title "$WORKER_THREAD_TITLE" \
|
|
48
|
+
--manager-codex-app-thread-id "$MANAGER_THREAD_ID" \
|
|
49
|
+
--manager-codex-app-thread-title "$MANAGER_THREAD_TITLE" \
|
|
50
|
+
--path "$LEDGER" \
|
|
51
|
+
--json
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
5. Return a setup receipt listing every task, worker role, thread id/title,
|
|
55
|
+
manager thread id/title, ledger path, and status command.
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: conveyor-whats-next-nudger
|
|
3
|
+
description: Run a bounded Agent Conveyor "what's next?" nudger loop for an existing Codex app manager/worker pair or worker set.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Conveyor What's Next Nudger
|
|
7
|
+
|
|
8
|
+
Use this skill when the operator wants an existing Agent Conveyor Codex app
|
|
9
|
+
manager/worker pair or worker set to continue through a bounded number of
|
|
10
|
+
manager-approved follow-up passes. This skill does not create sessions, publish,
|
|
11
|
+
schedule, push, open PRs, merge, or archive workers unless the operator
|
|
12
|
+
explicitly grants that separate authority.
|
|
13
|
+
|
|
14
|
+
## Rules
|
|
15
|
+
|
|
16
|
+
- Operator-facing only.
|
|
17
|
+
- Codex app native sessions only.
|
|
18
|
+
- Use `.codex-workers/workerctl.db` under the current project unless the
|
|
19
|
+
operator explicitly gives another path.
|
|
20
|
+
- Require a bounded loop count before continuing; default to 1 extra pass if
|
|
21
|
+
the operator says "one more" and 2 passes if the operator gives no count.
|
|
22
|
+
- Treat worker "done" and "what's next" suggestions as claims until the
|
|
23
|
+
manager verifies receipts.
|
|
24
|
+
- Continue only when the manager records concrete evidence and the proposed
|
|
25
|
+
next slice is in scope, reversible, and consistent with current authority.
|
|
26
|
+
- Keep manager closeout/control-plane proof out of worker acceptance criteria;
|
|
27
|
+
use it in the manager final report instead.
|
|
28
|
+
- Do not inspect private content, publish externally, or perform repo shipping
|
|
29
|
+
actions unless the existing task policy explicitly permits the narrow action.
|
|
30
|
+
- Keep visible Codex session sections for consumed work:
|
|
31
|
+
`CONVEYOR POLL`, `CONVEYOR RECEIVED`, `WORK`, `CONVEYOR SEND`, `DISPATCH`.
|
|
32
|
+
|
|
33
|
+
## Default Ledger
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
mkdir -p .codex-workers
|
|
37
|
+
LEDGER="$PWD/.codex-workers/workerctl.db"
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Operator Flow
|
|
41
|
+
|
|
42
|
+
1. Identify the task or campaign. If the task is unknown, list candidates:
|
|
43
|
+
|
|
44
|
+
```bash
|
|
45
|
+
conveyor tasks --path "$LEDGER" --json
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
2. Inspect current status before nudging:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
TASK="example-task"
|
|
52
|
+
conveyor app-loop-status "$TASK" --path "$LEDGER" --json
|
|
53
|
+
conveyor loop-status "$TASK" --path "$LEDGER" --json
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
3. Ask the manager, not the worker directly, to evaluate the completed pass and
|
|
57
|
+
choose one of:
|
|
58
|
+
- stop with verified evidence;
|
|
59
|
+
- request a narrow revision;
|
|
60
|
+
- ask the worker "what's next?" and continue for one bounded pass.
|
|
61
|
+
|
|
62
|
+
Use the manager's inbox or visible app wake path for the existing setup. If the
|
|
63
|
+
setup exposes `app-wakeup-plan` or `app-wakeup-dispatch`, prefer that prepared
|
|
64
|
+
wake path over ad hoc direct prompts:
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
conveyor app-wakeup-plan "$TASK" --path "$LEDGER" --json
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
4. When the manager approves another pass, queue exactly one continuation or
|
|
71
|
+
worker nudge with a narrow instruction and an iteration budget. Prefer loop
|
|
72
|
+
continuation for Ralph-loop tasks:
|
|
73
|
+
|
|
74
|
+
```bash
|
|
75
|
+
RUN="loop-run-id-from-loop-status"
|
|
76
|
+
NEXT_ITERATION="2"
|
|
77
|
+
conveyor enqueue-continue-iteration "$TASK" \
|
|
78
|
+
--loop-run "$RUN" \
|
|
79
|
+
--requested-iteration "$NEXT_ITERATION" \
|
|
80
|
+
--message "Manager approved one more pass. Before acting, print visible CONVEYOR sections, summarize the verified prior evidence, propose the next narrow slice, do the work only if in scope, then notify the manager with receipts." \
|
|
81
|
+
--path "$LEDGER" \
|
|
82
|
+
--json
|
|
83
|
+
conveyor dispatch --watch --watch-iterations 1 --interval 2 \
|
|
84
|
+
--dispatcher-id dispatch-local \
|
|
85
|
+
--path "$LEDGER" \
|
|
86
|
+
--json
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
If the task is not a Ralph loop, use the existing setup's generated
|
|
90
|
+
`enqueue-nudge-worker` or manager-approved assignment command instead. Do not
|
|
91
|
+
invent new shipping authority.
|
|
92
|
+
|
|
93
|
+
5. After each worker pass, require all of:
|
|
94
|
+
- durable worker-to-manager notification receipt;
|
|
95
|
+
- one Dispatch receipt routing that notification;
|
|
96
|
+
- manager verification of artifacts, tests, screenshots, dashboard records,
|
|
97
|
+
or other task-specific evidence;
|
|
98
|
+
- explicit manager decision: continue, revise, stop, or block.
|
|
99
|
+
|
|
100
|
+
6. Stop when the bounded pass count is exhausted, evidence is insufficient, the
|
|
101
|
+
next proposed slice is out of scope, or the manager recommends stopping.
|
|
102
|
+
Report a compact receipt with task, ledger, passes used, manager decision,
|
|
103
|
+
evidence checked, blockers, and the exact next action.
|
|
104
|
+
|
|
105
|
+
## Final Receipt
|
|
106
|
+
|
|
107
|
+
End with:
|
|
108
|
+
|
|
109
|
+
- `task`
|
|
110
|
+
- `ledger`
|
|
111
|
+
- `passes_requested`
|
|
112
|
+
- `passes_completed`
|
|
113
|
+
- `manager_decision`
|
|
114
|
+
- `evidence_checked`
|
|
115
|
+
- `blockers`
|
|
116
|
+
- `next_action`
|