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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agent-conveyor",
3
- "version": "0.1.19",
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`