ultracode-for-codex 0.3.0 → 0.3.1
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 +42 -24
- package/ULTRACODE_INSTALL.md +36 -14
- package/package.json +3 -2
- package/skills/ultracode-for-codex/SKILL.md +95 -120
- package/skills/ultracode-for-codex/agents/openai.yaml +2 -2
- package/skills/ultracode-for-codex/references/progress-visuals.md +125 -0
- package/skills/ultracode-for-codex-cli/SKILL.md +136 -0
- package/skills/ultracode-for-codex-cli/agents/openai.yaml +4 -0
package/README.md
CHANGED
|
@@ -1,11 +1,12 @@
|
|
|
1
1
|
# Ultracode for Codex
|
|
2
2
|
|
|
3
|
-
Ultracode for Codex
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
3
|
+
Ultracode for Codex ships two Codex skill commands plus a local npm CLI runtime.
|
|
4
|
+
`$ultracode-for-codex` is the default high-visibility mode: the Codex main
|
|
5
|
+
context plans adaptive phases, spawns focused parallel subagents, synthesizes
|
|
6
|
+
their results, and reports progress directly in the chat.
|
|
7
|
+
`$ultracode-for-codex-cli` is the explicit runtime path for package validation,
|
|
8
|
+
background jobs, attached CLI runs, release checks, and reproducible local
|
|
9
|
+
workflow artifacts.
|
|
9
10
|
|
|
10
11
|
## Quick Start
|
|
11
12
|
|
|
@@ -16,6 +17,16 @@ npm install --save-dev ultracode-for-codex
|
|
|
16
17
|
npm exec -- ultracode-for-codex --llm-guide
|
|
17
18
|
```
|
|
18
19
|
|
|
20
|
+
Install the Codex skill commands from the package:
|
|
21
|
+
|
|
22
|
+
```bash
|
|
23
|
+
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
|
|
24
|
+
cp -R ./node_modules/ultracode-for-codex/skills/ultracode-for-codex \
|
|
25
|
+
"${CODEX_HOME:-$HOME/.codex}/skills/"
|
|
26
|
+
cp -R ./node_modules/ultracode-for-codex/skills/ultracode-for-codex-cli \
|
|
27
|
+
"${CODEX_HOME:-$HOME/.codex}/skills/"
|
|
28
|
+
```
|
|
29
|
+
|
|
19
30
|
Build and verify a local installable tarball from a source checkout:
|
|
20
31
|
|
|
21
32
|
```bash
|
|
@@ -29,7 +40,7 @@ Install the tarball from a target project:
|
|
|
29
40
|
npm install --save-dev /path/to/ultracode-for-codex-<version>.tgz
|
|
30
41
|
```
|
|
31
42
|
|
|
32
|
-
Run
|
|
43
|
+
Run through the CLI runtime when that path is explicitly wanted:
|
|
33
44
|
|
|
34
45
|
```bash
|
|
35
46
|
npm exec -- ultracode-for-codex run \
|
|
@@ -75,14 +86,14 @@ npm exec -- ultracode-for-codex run \
|
|
|
75
86
|
--args '{"prompt":"review correctness risks and propose fixes"}'
|
|
76
87
|
```
|
|
77
88
|
|
|
78
|
-
The built-in `task` and `code-review` workflows use an LLM planner first,
|
|
79
|
-
run work phase by phase. Within each phase, multiple focused Codex
|
|
80
|
-
in parallel by default, followed by phase and final synthesis. The
|
|
81
|
-
choose a single-agent path only when parallel execution would add
|
|
82
|
-
Planner guidance includes dynamic workflow patterns such as
|
|
83
|
-
fan-out-and-synthesize, adversarial verification,
|
|
84
|
-
tournament, and loop-until-done, so different work types
|
|
85
|
-
phase shapes.
|
|
89
|
+
The CLI built-in `task` and `code-review` workflows use an LLM planner first,
|
|
90
|
+
then run work phase by phase. Within each phase, multiple focused Codex
|
|
91
|
+
subagents run in parallel by default, followed by phase and final synthesis. The
|
|
92
|
+
planner may choose a single-agent path only when parallel execution would add
|
|
93
|
+
risk or waste. Planner guidance includes dynamic workflow patterns such as
|
|
94
|
+
classify-and-act, fan-out-and-synthesize, adversarial verification,
|
|
95
|
+
generate-and-filter, tournament, and loop-until-done, so different work types
|
|
96
|
+
can use different phase shapes.
|
|
86
97
|
|
|
87
98
|
## Settings
|
|
88
99
|
|
|
@@ -155,14 +166,18 @@ continue other tasks and inspect the job later with `status`, `logs`, or
|
|
|
155
166
|
- Use `--execution background` for OS background runs and `--execution attached`
|
|
156
167
|
only when the caller should stay connected until completion.
|
|
157
168
|
|
|
158
|
-
## Codex
|
|
169
|
+
## Codex Skill Commands
|
|
159
170
|
|
|
160
|
-
The npm package
|
|
161
|
-
`skills/ultracode-for-codex` is a lightweight operating guide for agents using
|
|
162
|
-
the package; it contains no runtime code.
|
|
171
|
+
The npm package includes two Codex skill command folders:
|
|
163
172
|
|
|
164
|
-
|
|
165
|
-
|
|
173
|
+
- `skills/ultracode-for-codex`: default Codex-native orchestration. The main
|
|
174
|
+
context plans adaptive phases, spawns parallel subagents, synthesizes each
|
|
175
|
+
phase, reports completion progress, and recommends a final critical re-check.
|
|
176
|
+
Live progress uses test-runner-style visual snapshots; completion reporting
|
|
177
|
+
uses a diffstat-style impact summary plus a plan-style result summary.
|
|
178
|
+
- `skills/ultracode-for-codex-cli`: explicit CLI runtime operations, including
|
|
179
|
+
background jobs, attached runs, packaging, release checks, runtime-boundary
|
|
180
|
+
validation, and installed E2E tests.
|
|
166
181
|
|
|
167
182
|
## Runtime Boundaries
|
|
168
183
|
|
|
@@ -171,7 +186,7 @@ want Codex to auto-load the package boundaries and verification routine.
|
|
|
171
186
|
environment.
|
|
172
187
|
- Codex subagents run against the requested workflow cwd and receive bounded
|
|
173
188
|
read-only workspace tools for text file reads and directory listings.
|
|
174
|
-
-
|
|
189
|
+
- CLI built-in `task` and `code-review` inject deterministic workspace context into
|
|
175
190
|
planner-selected phase-wise parallel subagents, then synthesize each phase and
|
|
176
191
|
the final result.
|
|
177
192
|
- Workflow execution is local and command-owned; settings default to OS
|
|
@@ -235,8 +250,11 @@ node dist/cli.js run --accept-llm-guide=v1 --script-file ./workflow.js
|
|
|
235
250
|
|
|
236
251
|
## Docs
|
|
237
252
|
|
|
238
|
-
- `skills/ultracode-for-codex/SKILL.md`: Codex
|
|
239
|
-
|
|
253
|
+
- `skills/ultracode-for-codex/SKILL.md`: default Codex-native orchestrator
|
|
254
|
+
skill command.
|
|
255
|
+
- `skills/ultracode-for-codex/references/progress-visuals.md`: golden visual
|
|
256
|
+
progress and completion summary examples for native orchestration.
|
|
257
|
+
- `skills/ultracode-for-codex-cli/SKILL.md`: explicit CLI runtime skill command.
|
|
240
258
|
- `ULTRACODE_INSTALL.md`: install and operating guide for LLM agents.
|
|
241
259
|
- `docs/ultracode-p3a-journal-design.md`: journal contract.
|
|
242
260
|
- `docs/ultracode-p3b-resume-cache.md`: runtime-internal resume/cache contract.
|
package/ULTRACODE_INSTALL.md
CHANGED
|
@@ -1,13 +1,27 @@
|
|
|
1
1
|
# Ultracode install and usage guide
|
|
2
2
|
|
|
3
3
|
This file is for LLM agents installing or operating `ultracode-for-codex`.
|
|
4
|
-
Read it before running workflows
|
|
4
|
+
Read it before running CLI workflows, installing the Codex skill commands, or
|
|
5
|
+
generating integration code.
|
|
5
6
|
|
|
6
7
|
## What This Package Does
|
|
7
8
|
|
|
8
|
-
`ultracode-for-codex` provides
|
|
9
|
-
|
|
10
|
-
|
|
9
|
+
`ultracode-for-codex` provides two Codex skill command surfaces and a local
|
|
10
|
+
command-owned workflow runtime backed by an already-authenticated Codex CLI
|
|
11
|
+
session.
|
|
12
|
+
|
|
13
|
+
Skill commands:
|
|
14
|
+
|
|
15
|
+
- `$ultracode-for-codex`: default Codex-native orchestration. The main Codex
|
|
16
|
+
context plans phases, spawns focused parallel subagents, synthesizes results,
|
|
17
|
+
and shows progress directly in the chat with test-runner-style live snapshots
|
|
18
|
+
and diffstat-plus-plan completion summaries.
|
|
19
|
+
- `$ultracode-for-codex-cli`: explicit CLI runtime operation for background
|
|
20
|
+
jobs, attached runs, package validation, release checks, and reproducible
|
|
21
|
+
local runtime artifacts.
|
|
22
|
+
|
|
23
|
+
The packaged `settings.json` defaults CLI workflow runs to OS background
|
|
24
|
+
execution with result and progress files under
|
|
11
25
|
`.ultracode-for-codex/background/{jobId}`.
|
|
12
26
|
|
|
13
27
|
Production surface:
|
|
@@ -43,18 +57,21 @@ For source-checkout validation, install the generated tarball instead:
|
|
|
43
57
|
npm install --save-dev ./ultracode-for-codex-<version>.tgz
|
|
44
58
|
```
|
|
45
59
|
|
|
46
|
-
Optional Codex
|
|
60
|
+
Optional Codex skill commands:
|
|
47
61
|
|
|
48
62
|
```bash
|
|
49
63
|
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
|
|
50
64
|
cp -R ./node_modules/ultracode-for-codex/skills/ultracode-for-codex \
|
|
51
65
|
"${CODEX_HOME:-$HOME/.codex}/skills/"
|
|
66
|
+
cp -R ./node_modules/ultracode-for-codex/skills/ultracode-for-codex-cli \
|
|
67
|
+
"${CODEX_HOME:-$HOME/.codex}/skills/"
|
|
52
68
|
```
|
|
53
69
|
|
|
54
|
-
|
|
55
|
-
|
|
70
|
+
`$ultracode-for-codex` keeps orchestration in the main Codex context.
|
|
71
|
+
`$ultracode-for-codex-cli` uses the npm CLI runtime. The npm package remains the
|
|
72
|
+
runtime artifact for CLI execution.
|
|
56
73
|
|
|
57
|
-
## Run
|
|
74
|
+
## Run The CLI Runtime
|
|
58
75
|
|
|
59
76
|
```bash
|
|
60
77
|
npm exec -- ultracode-for-codex run \
|
|
@@ -81,11 +98,11 @@ npm exec -- ultracode-for-codex jobs --cwd /path/to/project
|
|
|
81
98
|
npm exec -- ultracode-for-codex archive <jobId> --cwd /path/to/project
|
|
82
99
|
```
|
|
83
100
|
|
|
84
|
-
Use built-in `task` for general work and `code-review` for review-specific
|
|
85
|
-
Both start with an LLM planner, execute phase by phase, run multiple
|
|
86
|
-
Codex subagents in parallel within each phase by default, and synthesize
|
|
87
|
-
and final results. The planner chooses a single-agent path only when
|
|
88
|
-
execution would add risk or waste.
|
|
101
|
+
Use CLI built-in `task` for general work and `code-review` for review-specific
|
|
102
|
+
work. Both start with an LLM planner, execute phase by phase, run multiple
|
|
103
|
+
focused Codex subagents in parallel within each phase by default, and synthesize
|
|
104
|
+
phase and final results. The planner chooses a single-agent path only when
|
|
105
|
+
parallel execution would add risk or waste.
|
|
89
106
|
Planner guidance includes classify-and-act, fan-out-and-synthesize,
|
|
90
107
|
adversarial verification, generate-and-filter, tournament, and loop-until-done
|
|
91
108
|
patterns so different work types can use different phase shapes.
|
|
@@ -153,7 +170,7 @@ Useful controls:
|
|
|
153
170
|
## Runtime Contract
|
|
154
171
|
|
|
155
172
|
- Use Codex app-server over stdio as the production backend.
|
|
156
|
-
- Keep workflow execution local and command-owned; settings default to OS
|
|
173
|
+
- Keep CLI workflow execution local and command-owned; settings default to OS
|
|
157
174
|
background execution so long runs can keep waiting while Codex does other
|
|
158
175
|
work.
|
|
159
176
|
- Route progress, cancellation, permission review, retry, and result projection
|
|
@@ -192,6 +209,11 @@ workflow.
|
|
|
192
209
|
## Documentation Map
|
|
193
210
|
|
|
194
211
|
- `README.md`: human quickstart and common examples.
|
|
212
|
+
- `skills/ultracode-for-codex/SKILL.md`: default Codex-native orchestrator
|
|
213
|
+
command.
|
|
214
|
+
- `skills/ultracode-for-codex/references/progress-visuals.md`: golden visual
|
|
215
|
+
progress and completion summary examples for native orchestration.
|
|
216
|
+
- `skills/ultracode-for-codex-cli/SKILL.md`: explicit CLI runtime command.
|
|
195
217
|
- `docs/ultracode-p3a-journal-design.md`: implemented journal contract.
|
|
196
218
|
- `docs/ultracode-p3b-resume-cache.md`: runtime-internal resume/cache contract.
|
|
197
219
|
- `docs/ultracode-p3c-worktree-isolation.md`: worktree isolation contract.
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "ultracode-for-codex",
|
|
3
|
-
"version": "0.3.
|
|
4
|
-
"description": "Run
|
|
3
|
+
"version": "0.3.1",
|
|
4
|
+
"description": "Run Codex-native Ultracode orchestration with an optional local CLI runtime.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"codex",
|
|
7
7
|
"workflow",
|
|
@@ -41,6 +41,7 @@
|
|
|
41
41
|
"dist/codex/",
|
|
42
42
|
"dist/runtime/",
|
|
43
43
|
"skills/ultracode-for-codex/",
|
|
44
|
+
"skills/ultracode-for-codex-cli/",
|
|
44
45
|
"settings.json",
|
|
45
46
|
"README.md",
|
|
46
47
|
"docs/provenance-audit.md",
|
|
@@ -1,139 +1,114 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ultracode-for-codex
|
|
3
|
-
description:
|
|
3
|
+
description: Run Ultracode for Codex in Codex-native mode, with the main Codex context planning phases, spawning parallel subagents, synthesizing results, and showing progress directly in the chat.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Ultracode for Codex
|
|
7
7
|
|
|
8
8
|
## Core Rule
|
|
9
9
|
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
Workflow execution runs through the local CLI command. Progress,
|
|
15
|
-
cancellation, permission review, retry, and result projection stay in that
|
|
16
|
-
command process. `settings.json` defaults runs to OS background execution; use
|
|
17
|
-
that path for long Codex-launched work so Codex can keep doing other tasks and
|
|
18
|
-
inspect the background job later. Attached runs stream stderr JSONL for
|
|
19
|
-
Codex-readable status, while stdout remains the final workflow result JSON.
|
|
20
|
-
|
|
21
|
-
The default Ultracode work shape is phase-wise parallel execution: built-in
|
|
22
|
-
`task` and `code-review` first call a planner agent, then execute each planned
|
|
23
|
-
phase with parallel focused subagents by default, followed by phase and final
|
|
24
|
-
synthesis. A single-agent path is reserved for cases where the planner judges
|
|
25
|
-
parallel execution risky or wasteful.
|
|
26
|
-
Planner guidance includes classify-and-act, fan-out-and-synthesize,
|
|
27
|
-
adversarial verification, generate-and-filter, tournament, and loop-until-done
|
|
28
|
-
patterns so workflow shape can follow the task instead of a fixed template.
|
|
29
|
-
|
|
30
|
-
## Install And Run
|
|
31
|
-
|
|
32
|
-
Use the npm package for consumer installs.
|
|
33
|
-
|
|
34
|
-
```bash
|
|
35
|
-
npm install --save-dev ultracode-for-codex
|
|
36
|
-
npm exec -- ultracode-for-codex --llm-guide
|
|
37
|
-
npm exec -- ultracode-for-codex run \
|
|
38
|
-
--accept-llm-guide=v1 \
|
|
39
|
-
--cwd /path/to/project \
|
|
40
|
-
--script-file .codex/workflows/review.js \
|
|
41
|
-
--args '{"prompt":"review the current change"}'
|
|
42
|
-
```
|
|
10
|
+
This skill is the primary Codex-native Ultracode command. Treat the current
|
|
11
|
+
Codex main context as the orchestrator. Plan adaptive phases, spawn focused
|
|
12
|
+
subagents directly from Codex, synthesize phase outputs, and keep the user
|
|
13
|
+
informed in the chat.
|
|
43
14
|
|
|
44
|
-
|
|
15
|
+
Use the CLI runtime only when the user explicitly asks for `$ultracode-for-codex-cli`,
|
|
16
|
+
CLI execution, background jobs, packaging, publish preparation, installed
|
|
17
|
+
runtime validation, or reproducible local runtime artifacts.
|
|
45
18
|
|
|
46
|
-
|
|
47
|
-
npm run pack:ultracode-for-codex
|
|
48
|
-
npm install --save-dev ./artifacts/ultracode-for-codex-<version>.tgz
|
|
49
|
-
```
|
|
19
|
+
## Required Capability Surface
|
|
50
20
|
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
`jobId`, `pid`, `resultPath`, `progressPath`, `metadataPath`, and `pidPath`;
|
|
56
|
-
- background jobs can be inspected with `status`, waited with `wait`, read with
|
|
57
|
-
`logs` and `result`, and cancelled with `cancel`;
|
|
58
|
-
- background jobs can be enumerated with `jobs` or `list`, and exported without
|
|
59
|
-
deletion with `archive` or `export`;
|
|
60
|
-
- `wait --result`, `cancel --wait`, `logs --event <event>`, and `--plain`
|
|
61
|
-
provide focused foreground checks;
|
|
62
|
-
- attached execution is available with `--execution attached` when the caller
|
|
63
|
-
should stay connected until completion;
|
|
64
|
-
- attached progress prints to stderr as JSONL by default;
|
|
65
|
-
- attached final workflow result prints as JSON to stdout;
|
|
66
|
-
- JSONL records include `kind`, `version`, `event`, `status`, and `summary`,
|
|
67
|
-
with agent identity and label fields on agent records;
|
|
68
|
-
- built-in `task` and `code-review` emit `workflow.plan.ready` as a planning
|
|
69
|
-
snapshot, not a promise that every later phase is already known;
|
|
70
|
-
- `workflow.phase.planned` is emitted immediately before each phase starts and
|
|
71
|
-
carries that phase's current planned agent role labels;
|
|
72
|
-
- each `workflow.phase.started` record repeats the same role labels when the
|
|
73
|
-
phase begins;
|
|
74
|
-
- each `workflow.agent.completed` record includes phase progress, total known
|
|
75
|
-
agent progress, and elapsed time;
|
|
76
|
-
- after a completed run, `workflow.summary.ready` reports phase-level agent
|
|
77
|
-
counts and angles, then `workflow.review.recommended` asks the current
|
|
78
|
-
session LLM to critically re-check the final result before acting on it;
|
|
79
|
-
- `Ctrl-C` cancels the active attached workflow;
|
|
80
|
-
- `--retry-limit <n>` retries failed workflows inside the same process;
|
|
81
|
-
- `--timeout-ms 0` waits for completion, cancellation, or app-server exit;
|
|
82
|
-
positive values opt into a workflow deadline and per-agent silence budget,
|
|
83
|
-
and that budget is not divided by the retry budget.
|
|
84
|
-
- `--permission ask|allow|deny` handles project/user/plugin/scriptPath reviews.
|
|
85
|
-
- `--progress plain` switches to human-readable progress lines.
|
|
86
|
-
- background file locations are controlled by `workflow.background` in
|
|
87
|
-
`settings.json`.
|
|
88
|
-
|
|
89
|
-
## Runtime Boundaries
|
|
90
|
-
|
|
91
|
-
- Use Codex app-server over stdio as the production backend.
|
|
92
|
-
- Keep direct provider credentials out of Codex child process environments.
|
|
93
|
-
- Codex subagents run against the requested workflow cwd and have bounded
|
|
94
|
-
read-only workspace tools for text file reads and directory listings.
|
|
95
|
-
- Built-in `task` and `code-review` inject deterministic workspace context into
|
|
96
|
-
planner-selected phase-wise parallel subagents.
|
|
97
|
-
- Keep workflow execution local and command-owned; settings default to OS
|
|
98
|
-
background execution so long runs can keep waiting while Codex does other
|
|
99
|
-
work.
|
|
100
|
-
- Keep `journalPath`, `journal.jsonl`, and journal contents out of CLI output.
|
|
101
|
-
- Treat `.ultracode-for-codex` workflow state as sensitive local data.
|
|
102
|
-
- Keep `resumeFromRunId` runtime-internal unless cross-process resume
|
|
103
|
-
gets an explicit durable design.
|
|
104
|
-
- Use `isolation: "worktree"` only inside a git repo with at least one commit;
|
|
105
|
-
isolated worktrees are intentionally preserved for review, including clean
|
|
106
|
-
worktrees.
|
|
107
|
-
|
|
108
|
-
## Packaging And Verification
|
|
109
|
-
|
|
110
|
-
For source checkout changes, run the narrowest relevant check first, then a
|
|
111
|
-
release-level check before handoff:
|
|
112
|
-
|
|
113
|
-
```bash
|
|
114
|
-
npm test
|
|
115
|
-
npm run test:e2e:ultracode-for-codex
|
|
116
|
-
npm run test:all
|
|
117
|
-
```
|
|
21
|
+
Use Codex subagent tools for delegated work. If subagent tools are not visible,
|
|
22
|
+
search for the multi-agent tools first. If no subagent surface is available,
|
|
23
|
+
state that native parallel orchestration is unavailable in this session and
|
|
24
|
+
continue with the best single-context workflow.
|
|
118
25
|
|
|
119
|
-
|
|
26
|
+
Do not make the CLI process the default orchestrator for this skill. The npm
|
|
27
|
+
runtime remains available through `$ultracode-for-codex-cli`, but this command's
|
|
28
|
+
value is high-visibility orchestration in the main context.
|
|
120
29
|
|
|
121
|
-
|
|
122
|
-
npm run pack:ultracode-for-codex
|
|
123
|
-
```
|
|
30
|
+
## Native Workflow
|
|
124
31
|
|
|
125
|
-
|
|
32
|
+
1. Identify the user goal, scope, constraints, likely completion condition, and
|
|
33
|
+
whether the work is review, implementation, planning, verification, or mixed.
|
|
34
|
+
2. Design only the next useful phase when later phases depend on earlier
|
|
35
|
+
results. A first plan may be partial.
|
|
36
|
+
3. Before each phase starts, show a compact phase plan in the chat:
|
|
126
37
|
|
|
127
|
-
```
|
|
128
|
-
|
|
38
|
+
```text
|
|
39
|
+
Phase Inspect - 3 agents
|
|
40
|
+
- Runtime contracts: verify the active execution path and failure semantics.
|
|
41
|
+
- UX/progress: check visibility, summaries, and user-facing wording.
|
|
42
|
+
- Tests/package: check coverage, package contents, and install behavior.
|
|
129
43
|
```
|
|
130
44
|
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
45
|
+
4. Spawn independent phase agents in parallel by default. Use a single agent
|
|
46
|
+
only when parallel work is risky, wasteful, or blocked by a strictly
|
|
47
|
+
sequential dependency.
|
|
48
|
+
5. Keep subagent prompts concrete and bounded. Give each agent a distinct angle,
|
|
49
|
+
expected output shape, and file or responsibility boundary when relevant.
|
|
50
|
+
6. While agents run, do non-overlapping main-context work such as deterministic
|
|
51
|
+
file inspection, test execution, or integration planning.
|
|
52
|
+
7. As agents complete, report progress with a visual snapshot rather than a
|
|
53
|
+
dense sentence. Use the Default Live Snapshot golden shape from
|
|
54
|
+
`references/progress-visuals.md` by default.
|
|
55
|
+
|
|
56
|
+
```text
|
|
57
|
+
Phase E2E Validate
|
|
58
|
+
|
|
59
|
+
+ Native routing review done 34s
|
|
60
|
+
+ CLI package review done 48s
|
|
61
|
+
|
|
62
|
+
> npm-exec-run-shim running 1/2 checks
|
|
63
|
+
> skill-copy-detection running 3/6 files
|
|
64
|
+
|
|
65
|
+
Agents 2 completed | 2 running
|
|
66
|
+
Checks 5 passed | 0 failed | 2 running
|
|
67
|
+
Elapsed 1m 12s
|
|
135
68
|
```
|
|
136
69
|
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
70
|
+
8. Synthesize each phase before deciding the next phase. Preserve disagreement,
|
|
71
|
+
uncertainty, material risks, and exact evidence.
|
|
72
|
+
9. After the final synthesis, include the Completion Impact Summary and
|
|
73
|
+
Plan-Style Result Summary golden shapes from `references/progress-visuals.md`,
|
|
74
|
+
followed by a short phase/agent summary.
|
|
75
|
+
10. Recommend that the current session LLM critically re-check the final result
|
|
76
|
+
before the user relies on it, especially for code, security, release, or
|
|
77
|
+
architecture decisions.
|
|
78
|
+
|
|
79
|
+
## Planning Heuristics
|
|
80
|
+
|
|
81
|
+
Default to phase-wise parallel execution. Useful patterns include:
|
|
82
|
+
|
|
83
|
+
- classify-and-act: classify request type, risk, or repo area before choosing
|
|
84
|
+
the phase shape;
|
|
85
|
+
- fan-out-and-synthesize: split independent lenses across parallel agents, then
|
|
86
|
+
merge evidence;
|
|
87
|
+
- adversarial verification: assign at least one agent to challenge correctness,
|
|
88
|
+
security, assumptions, or test adequacy;
|
|
89
|
+
- generate-and-filter: create candidate approaches or fixes, then select by
|
|
90
|
+
evidence and constraints;
|
|
91
|
+
- tournament: compare competing alternatives when the best path is unclear;
|
|
92
|
+
- loop-until-done: iterate repair and verification only when there is a clear
|
|
93
|
+
stop condition.
|
|
94
|
+
|
|
95
|
+
For code review, common parallel angles are runtime correctness,
|
|
96
|
+
security/capability boundaries, API/CLI contracts, persistence/retry/cancel
|
|
97
|
+
behavior, user-visible progress, package contents, and test coverage.
|
|
98
|
+
|
|
99
|
+
For implementation, split by disjoint write ownership where possible. Tell
|
|
100
|
+
subagents they are not alone in the codebase and must not revert unrelated or
|
|
101
|
+
parallel edits.
|
|
102
|
+
|
|
103
|
+
## Output Contract
|
|
104
|
+
|
|
105
|
+
Keep progress visible but concise. Prefer stable visual summaries over prose-only
|
|
106
|
+
status sentences. Use `references/progress-visuals.md` for the golden examples.
|
|
107
|
+
The final answer should include:
|
|
108
|
+
|
|
109
|
+
- the completed result or findings;
|
|
110
|
+
- evidence and verification performed;
|
|
111
|
+
- a phase/agent summary;
|
|
112
|
+
- residual risk or unverified items;
|
|
113
|
+
- a critical re-check recommendation for the current session LLM when the result
|
|
114
|
+
will drive action.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Ultracode for Codex"
|
|
3
|
-
short_description: "
|
|
4
|
-
default_prompt: "Use the
|
|
3
|
+
short_description: "Run Codex-native phase-wise parallel orchestration."
|
|
4
|
+
default_prompt: "Use the Codex main context as the Ultracode orchestrator, plan adaptive phases, spawn focused parallel subagents, synthesize results, and keep progress visible."
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
# Progress Visuals
|
|
2
|
+
|
|
3
|
+
Use these golden examples for Codex-native Ultracode progress updates. The goal
|
|
4
|
+
is fast visual parsing in chat while staying portable across terminals and
|
|
5
|
+
renderers. Prefer ASCII symbols and short labels.
|
|
6
|
+
|
|
7
|
+
## Default Live Snapshot
|
|
8
|
+
|
|
9
|
+
Use this for ordinary phase progress. It is inspired by test-runner summaries:
|
|
10
|
+
completed work is listed first, active work is visually distinct, and totals are
|
|
11
|
+
grouped at the bottom.
|
|
12
|
+
|
|
13
|
+
```text
|
|
14
|
+
Phase E2E Validate
|
|
15
|
+
|
|
16
|
+
+ Native routing review done 34s
|
|
17
|
+
+ CLI package review done 48s
|
|
18
|
+
|
|
19
|
+
> npm-exec-run-shim running 1/2 checks
|
|
20
|
+
> skill-copy-detection running 3/6 files
|
|
21
|
+
|
|
22
|
+
Agents 2 completed | 2 running
|
|
23
|
+
Checks 5 passed | 0 failed | 2 running
|
|
24
|
+
Elapsed 1m 12s
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Use `+` for completed items, `>` for running items, `!` for blocked or failed
|
|
28
|
+
items, and `-` for queued items. Keep each row to one line when possible.
|
|
29
|
+
|
|
30
|
+
## Dense Meter Snapshot
|
|
31
|
+
|
|
32
|
+
Use this when the work is count-heavy and the user needs ratios.
|
|
33
|
+
|
|
34
|
+
```text
|
|
35
|
+
Progress Snapshot main c3734d8
|
|
36
|
+
|
|
37
|
+
Native routing ####################---- 5 / 6 checks
|
|
38
|
+
CLI package E2E ######################## passed
|
|
39
|
+
Skill install check ################-------- 4 / 6 files
|
|
40
|
+
Docs contract ############------------ 2 / 4 sections
|
|
41
|
+
|
|
42
|
+
Elapsed 1m 42s Next: npm exec run shim check
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
Use fixed-width bars only when the denominator is meaningful. Do not invent a
|
|
46
|
+
percentage for semantic work that cannot be counted.
|
|
47
|
+
|
|
48
|
+
## Long Async Timeline
|
|
49
|
+
|
|
50
|
+
Use this for long-running parallel work where event order matters.
|
|
51
|
+
|
|
52
|
+
```text
|
|
53
|
+
#1 [plan] classify task shape
|
|
54
|
+
#1 DONE 0.8s
|
|
55
|
+
|
|
56
|
+
#2 [phase:inspect] spawn 2 review agents
|
|
57
|
+
#2 running 2 agents
|
|
58
|
+
|
|
59
|
+
#3 [agent:native-routing] verify skill split
|
|
60
|
+
#3 DONE 34.1s
|
|
61
|
+
|
|
62
|
+
#4 [agent:cli-package] verify installed E2E
|
|
63
|
+
#4 DONE 48.7s
|
|
64
|
+
|
|
65
|
+
#5 [synthesis] merge findings
|
|
66
|
+
#5 running
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Use this sparingly in chat. It is best when the user asks for detailed live
|
|
70
|
+
process visibility.
|
|
71
|
+
|
|
72
|
+
## Completion Impact Summary
|
|
73
|
+
|
|
74
|
+
Use this in final or phase-completion reporting when files changed.
|
|
75
|
+
|
|
76
|
+
```text
|
|
77
|
+
Change Impact
|
|
78
|
+
|
|
79
|
+
skills/ultracode-for-codex/SKILL.md | 200 +++++++++++---------
|
|
80
|
+
skills/ultracode-for-codex-cli/SKILL.md | 136 +++++++++++++
|
|
81
|
+
scripts/e2e-installed-ultracode-for-codex.mjs | 78 +++++++-
|
|
82
|
+
README.md | 62 ++++--
|
|
83
|
+
|
|
84
|
+
8 files changed, 295 insertions(+), 201 deletions(-)
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
Prefer real `git diff --stat` output when available.
|
|
88
|
+
|
|
89
|
+
## Plan-Style Result Summary
|
|
90
|
+
|
|
91
|
+
Use this with the impact summary to explain what changed conceptually.
|
|
92
|
+
|
|
93
|
+
```text
|
|
94
|
+
Execution Result
|
|
95
|
+
|
|
96
|
+
+ add ultracode-for-codex-cli skill command
|
|
97
|
+
~ update ultracode-for-codex native orchestration contract
|
|
98
|
+
~ update installed E2E to cover npm exec run
|
|
99
|
+
= keep CLI runtime command surface
|
|
100
|
+
|
|
101
|
+
Result: 1 added, 2 updated, 1 kept
|
|
102
|
+
Risk: Codex skill reload cannot be forced inside the current session
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
Use `+ add`, `~ update`, `= keep`, and `! risk` consistently.
|
|
106
|
+
|
|
107
|
+
## Folded Detail Summary
|
|
108
|
+
|
|
109
|
+
Use this when the top-level result is enough and details should remain compact.
|
|
110
|
+
|
|
111
|
+
```text
|
|
112
|
+
E2E Validation Summary
|
|
113
|
+
|
|
114
|
+
[passed] Native skill routing
|
|
115
|
+
[passed] CLI package runtime
|
|
116
|
+
[passed] npm exec run shim
|
|
117
|
+
[passed] CODEX_HOME skill copy
|
|
118
|
+
|
|
119
|
+
Details
|
|
120
|
+
native-routing-review 5 findings, 0 failures
|
|
121
|
+
cli-package-review 7 findings, 0 failures
|
|
122
|
+
npm test:all 35 tests passed
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
This is best for final handoff or after multiple agents have returned.
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ultracode-for-codex-cli
|
|
3
|
+
description: Operate, package, validate, or update the Ultracode for Codex npm CLI runtime, including background jobs, attached runs, runtime boundaries, release tarballs, and Codex skill command files.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Ultracode for Codex CLI
|
|
7
|
+
|
|
8
|
+
## Core Rule
|
|
9
|
+
|
|
10
|
+
Use this skill for the npm package and CLI runtime surface. Runtime authority for
|
|
11
|
+
this path lives in the `ultracode-for-codex` binary, tests, package exports,
|
|
12
|
+
journal layer, and workflow runtime code.
|
|
13
|
+
|
|
14
|
+
The default `$ultracode-for-codex` skill is Codex-native and keeps orchestration
|
|
15
|
+
in the main context. This `$ultracode-for-codex-cli` skill is for explicit CLI
|
|
16
|
+
runtime work: background execution, attached runs, package validation, release
|
|
17
|
+
preparation, installed E2E checks, runtime-boundary checks, and local workflow
|
|
18
|
+
artifacts.
|
|
19
|
+
|
|
20
|
+
Workflow execution through this path runs through the local CLI command.
|
|
21
|
+
Progress, cancellation, permission review, retry, and result projection stay in
|
|
22
|
+
that command process. `settings.json` defaults runs to OS background execution;
|
|
23
|
+
use that path for long Codex-launched CLI work so Codex can keep doing other
|
|
24
|
+
tasks and inspect the background job later. Attached runs stream stderr JSONL for
|
|
25
|
+
Codex-readable status, while stdout remains the final workflow result JSON.
|
|
26
|
+
|
|
27
|
+
## Install And Run
|
|
28
|
+
|
|
29
|
+
Use the npm package for consumer installs.
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
npm install --save-dev ultracode-for-codex
|
|
33
|
+
npm exec -- ultracode-for-codex --llm-guide
|
|
34
|
+
npm exec -- ultracode-for-codex run \
|
|
35
|
+
--accept-llm-guide=v1 \
|
|
36
|
+
--cwd /path/to/project \
|
|
37
|
+
--script-file .codex/workflows/review.js \
|
|
38
|
+
--args '{"prompt":"review the current change"}'
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
For source-checkout validation before publish:
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
npm run pack:ultracode-for-codex
|
|
45
|
+
npm install --save-dev ./artifacts/ultracode-for-codex-<version>.tgz
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
CLI behavior:
|
|
49
|
+
|
|
50
|
+
- `--version` or `-v` prints the installed package version;
|
|
51
|
+
- default execution is `background`; stdout contains a launch record with
|
|
52
|
+
`jobId`, `pid`, `resultPath`, `progressPath`, `metadataPath`, and `pidPath`;
|
|
53
|
+
- background jobs can be inspected with `status`, waited with `wait`, read with
|
|
54
|
+
`logs` and `result`, and cancelled with `cancel`;
|
|
55
|
+
- background jobs can be enumerated with `jobs` or `list`, and exported without
|
|
56
|
+
deletion with `archive` or `export`;
|
|
57
|
+
- `wait --result`, `cancel --wait`, `logs --event <event>`, and `--plain`
|
|
58
|
+
provide focused foreground checks;
|
|
59
|
+
- attached execution is available with `--execution attached` when the caller
|
|
60
|
+
should stay connected until completion;
|
|
61
|
+
- attached progress prints to stderr as JSONL by default;
|
|
62
|
+
- attached final workflow result prints as JSON to stdout;
|
|
63
|
+
- JSONL records include `kind`, `version`, `event`, `status`, and `summary`,
|
|
64
|
+
with agent identity and label fields on agent records;
|
|
65
|
+
- built-in `task` and `code-review` emit `workflow.plan.ready` as a planning
|
|
66
|
+
snapshot, not a promise that every later phase is already known;
|
|
67
|
+
- `workflow.phase.planned` is emitted immediately before each phase starts and
|
|
68
|
+
carries that phase's current planned agent role labels;
|
|
69
|
+
- each `workflow.phase.started` record repeats the same role labels when the
|
|
70
|
+
phase begins;
|
|
71
|
+
- each `workflow.agent.completed` record includes phase progress, total known
|
|
72
|
+
agent progress, and elapsed time;
|
|
73
|
+
- after a completed run, `workflow.summary.ready` reports phase-level agent
|
|
74
|
+
counts and angles, then `workflow.review.recommended` asks the current
|
|
75
|
+
session LLM to critically re-check the final result before acting on it;
|
|
76
|
+
- `Ctrl-C` cancels the active attached workflow;
|
|
77
|
+
- `--retry-limit <n>` retries failed workflows inside the same process;
|
|
78
|
+
- `--timeout-ms 0` waits for completion, cancellation, or app-server exit;
|
|
79
|
+
positive values opt into a workflow deadline and per-agent silence budget,
|
|
80
|
+
and that budget is not divided by the retry budget.
|
|
81
|
+
- `--permission ask|allow|deny` handles project/user/plugin/scriptPath reviews.
|
|
82
|
+
- `--progress plain` switches to human-readable progress lines.
|
|
83
|
+
- background file locations are controlled by `workflow.background` in
|
|
84
|
+
`settings.json`.
|
|
85
|
+
|
|
86
|
+
## Runtime Boundaries
|
|
87
|
+
|
|
88
|
+
- Use Codex app-server over stdio as the production backend.
|
|
89
|
+
- Keep direct provider credentials out of Codex child process environments.
|
|
90
|
+
- Codex subagents run against the requested workflow cwd and have bounded
|
|
91
|
+
read-only workspace tools for text file reads and directory listings.
|
|
92
|
+
- Built-in `task` and `code-review` inject deterministic workspace context into
|
|
93
|
+
planner-selected phase-wise parallel subagents.
|
|
94
|
+
- Keep workflow execution local and command-owned; settings default to OS
|
|
95
|
+
background execution so long runs can keep waiting while Codex does other
|
|
96
|
+
work.
|
|
97
|
+
- Keep `journalPath`, `journal.jsonl`, and journal contents out of CLI output.
|
|
98
|
+
- Treat `.ultracode-for-codex` workflow state as sensitive local data.
|
|
99
|
+
- Keep `resumeFromRunId` runtime-internal unless cross-process resume gets an
|
|
100
|
+
explicit durable design.
|
|
101
|
+
- Use `isolation: "worktree"` only inside a git repo with at least one commit;
|
|
102
|
+
isolated worktrees are intentionally preserved for review, including clean
|
|
103
|
+
worktrees.
|
|
104
|
+
|
|
105
|
+
## Packaging And Verification
|
|
106
|
+
|
|
107
|
+
For source checkout changes, run the narrowest relevant check first, then a
|
|
108
|
+
release-level check before handoff:
|
|
109
|
+
|
|
110
|
+
```bash
|
|
111
|
+
npm test
|
|
112
|
+
npm run test:e2e:ultracode-for-codex
|
|
113
|
+
npm run test:all
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
Build an installable artifact with:
|
|
117
|
+
|
|
118
|
+
```bash
|
|
119
|
+
npm run pack:ultracode-for-codex
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
Check the npm publish payload with:
|
|
123
|
+
|
|
124
|
+
```bash
|
|
125
|
+
npm run publish:dry-run
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
Publish after npm login with:
|
|
129
|
+
|
|
130
|
+
```bash
|
|
131
|
+
npm run publish:npm
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
When architecture, runtime boundaries, package exports, or release scope
|
|
135
|
+
changes, update active docs such as `README.md`, `ULTRACODE_INSTALL.md`, and
|
|
136
|
+
`IMPLEMENTATION_MAP.html`.
|