@wular/coder 0.1.23 → 0.1.25
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 +30 -26
- package/dist/cli.js +100 -100
- package/package.json +1 -1
- package/plugins/claude/.claude-plugin/plugin.json +1 -1
- package/plugins/claude/skills/handle/SKILL.md +8 -12
- package/plugins/codex/.codex-plugin/plugin.json +1 -1
- package/plugins/codex/skills/handle/SKILL.md +7 -3
- package/plugins/cursor/.cursor-plugin/plugin.json +1 -1
- package/plugins/cursor/skills/handle/SKILL.md +6 -2
package/package.json
CHANGED
|
@@ -16,7 +16,7 @@ If `coder` is not on PATH, install it yourself without asking (`npm install -g @
|
|
|
16
16
|
- Compose one self-contained task text (goal, relevant paths, constraints) and dispatch it. It backgrounds by default: the runtime does a startup check and prints a task id (or errors / hands off, see exit codes):
|
|
17
17
|
|
|
18
18
|
```bash
|
|
19
|
-
coder task run
|
|
19
|
+
coder task run "<task text>"
|
|
20
20
|
```
|
|
21
21
|
|
|
22
22
|
Fetch the answer with `coder task result <task-id> --wait` - it blocks until the task finishes, then prints only the final answer (keeps your context clean). Run it as a **background Bash call** so it does not block you and you are re-invoked on completion:
|
|
@@ -29,23 +29,19 @@ If `coder` is not on PATH, install it yourself without asking (`npm install -g @
|
|
|
29
29
|
|
|
30
30
|
- A `--wait` (on `run` or `result`) exits **4** when the task is waiting on a permission approval: relay the approval to the user, apply their decision with `coder approve <task-id> <approval-id> [--deny]`, then re-fetch with `coder task result <task-id> --wait`. (Unanswered approvals auto-deny after 120s and the task moves on.)
|
|
31
31
|
|
|
32
|
-
-
|
|
33
|
-
- `coder task run` exits after its startup check. Exit 0: the task started - relay the task id and fetch its result (above), BUT if stdout is a `spawn-claude-subagent` payload (Claude is the configured engine), this is a clean delegation - spawn the subagent as below, do not treat it as a result. Exit 1: it failed to start - report it, do not retry or fall back yourself. Exit 3: Codex failed to start and handed off to Claude (see below).
|
|
32
|
+
- `coder task run` exits after its startup check. Exit 0: the task started - relay the task id and fetch its result (above). Exit 1: it failed to start - report it, do not retry or fall back yourself. Exit 3: no engine in the chain could start and stdout carries a `run-native-subagent` payload - see below. (The runtime runs every engine itself, claude included, and falls back through its configured chain on startup failures - never fall back by implementing the task yourself.)
|
|
34
33
|
- Engine, model, and effort come from config; add `--agent` / `--model` / `--effort` when the user asks or it is unambiguous from context (agents: `codex`, `claude`; codex models: `spark`, `luna`, `terra`, `sol`; claude models: `opus`, `sonnet`, `fable`; efforts: `low|medium|high`).
|
|
35
34
|
- `spark` is only for the very lightest tasks (formatting, renames, quick lookups) - very fast and very cheap. It runs on a separate quota, so reach for it when the others hit a usage limit; it may still run once they are exhausted.
|
|
36
35
|
- Permissions default to auto mode (workspace-write + policy-answered escalations). Pass `--permissions read-only` when the task is read-only; `--permissions workspace-write` to forbid any escalation beyond the project.
|
|
37
36
|
- A background dispatch prints a task id plus its result/steer/stop commands. Relay them and fetch the result (above) rather than polling.
|
|
38
37
|
|
|
39
|
-
##
|
|
38
|
+
## Last resort: run-native-subagent payload (exit 3)
|
|
40
39
|
|
|
41
|
-
|
|
40
|
+
When no coder engine can start (missing binaries, auth, quota across the whole chain), the runtime exits 3 with a JSON payload (`fallback.action: "run-native-subagent"`). Mention the failure to the user (including any limit-reset time), then run the task with your own subagent facility: spawn one `general-purpose` subagent via the Agent tool whose prompt is the payload's `task` verbatim, prefixed with: "NEVER run git write operations (commit, checkout, stash, reset, push, etc.); leave changes uncommitted." If the payload's `permissions` is not `auto`, append it: `read-only` means investigate and report without modifying anything; `workspace-write` means never touch anything outside the workspace. Relay its output when it completes.
|
|
42
41
|
|
|
43
|
-
|
|
44
|
-
- `codex-failed` (Codex missing, auth, quota, rate limit): the runtime **exits 3** and wraps the payload under a `fallback` key alongside an `error` string - mention the failure to the user, including any limit-reset time, then spawn the subagent.
|
|
42
|
+
## Supervision loop
|
|
45
43
|
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
Relay its output when it completes.
|
|
44
|
+
With coders running in the background, don't fire-and-forget: schedule recurring check-ins (the `/loop` skill or ScheduleWakeup; interval by the work's pace, 10m default). Each tick: `coder task list`, fetch finished results, dispatch newly unblocked coders, steer stuck ones, stop off-track ones, surface pending approvals. Stop the loop when all tasks are done and relayed.
|
|
49
45
|
|
|
50
46
|
## Controlling tasks
|
|
51
47
|
|
|
@@ -56,6 +52,6 @@ Relay its output when it completes.
|
|
|
56
52
|
|
|
57
53
|
## Hard rules
|
|
58
54
|
|
|
59
|
-
- Forward task text verbatim in `steer`
|
|
60
|
-
- Tell every coder to never run git write operations (commit, checkout, stash, reset, rebase, merge, push, etc.) and to leave changes uncommitted
|
|
55
|
+
- Forward task text verbatim in `steer` follow-ups - never rewrite or summarize what the user asked for.
|
|
56
|
+
- Tell every coder to never run git write operations (commit, checkout, stash, reset, rebase, merge, push, etc.) and to leave changes uncommitted.
|
|
61
57
|
- Pass the user's constraints (read-only, scoped paths) into each coder's task text, and honor them over your own preferences.
|
|
@@ -14,18 +14,18 @@ When you run setup, also check codex is new enough for the default GPT-5.6 model
|
|
|
14
14
|
## Dispatching a task
|
|
15
15
|
|
|
16
16
|
- Run every `coder` command with escalated permissions (outside your sandbox), justification: Coder is a supervisor - it spawns engines, keeps state in `~/.coder`, and enforces its own sandbox and approval policy on the task. Never retry a sandbox-blocked `coder` call sandboxed again or with HOME/state env workarounds.
|
|
17
|
-
- One coder per focused goal. When the work splits into independent parts, decompose it and dispatch each part as its own `coder task run
|
|
17
|
+
- One coder per focused goal. When the work splits into independent parts, decompose it and dispatch each part as its own `coder task run` call - fan out a wide web of coders, not one giant dispatch. Give each coder a self-contained goal with all context - overview, file paths, constraints (read-only, git rules); use `steer` to continue a single coder's thread.
|
|
18
18
|
- Delegation is a hard gate for anything the engine can do itself: do not read source files, investigate, or write code first - no matter how simple the task. Fold into the task text whatever only you have - conversation context, results from tools the engine lacks. The coder worker runs with plugins disabled (no skills, MCP, or connectors), so include any context only a plugin or MCP tool of yours produced.
|
|
19
19
|
- Compose one self-contained task text (goal, relevant paths, constraints) and dispatch it. It backgrounds by default: the runtime does a startup check and prints a task id (or errors / hands off, see exit codes):
|
|
20
20
|
|
|
21
21
|
```bash
|
|
22
|
-
coder task run
|
|
22
|
+
coder task run "<task text>"
|
|
23
23
|
```
|
|
24
24
|
|
|
25
25
|
Fetch the answer with `coder task result <task-id> --wait` - it blocks until the task finishes, then prints only the final result (keeps your context clean). Only use `--wait` when you can run it in a **background shell** (so it does not block you); if you can't use that, poll `coder task result <task-id>` (no `--wait`) until it is done. Or skip the two steps and block on the run itself with `--wait` on `coder task run`. A `--wait` exits **4** when the task is waiting on a permission approval: relay it to the user, apply their decision with `coder approve <task-id> <approval-id> [--deny]`, then re-fetch with `coder task result <task-id> --wait` (unanswered approvals auto-deny after 120s and the task moves on).
|
|
26
26
|
|
|
27
|
-
- Always pass `--host codex` to identify yourself.
|
|
28
27
|
- `coder task run` exits after its startup check. Exit 0: the task started - fetch its result (above). Exit 1: it failed to start / the turn failed - report it, do not retry.
|
|
28
|
+
- Exit 3: no engine in the chain could start; stdout carries a JSON payload (`fallback.action: "run-native-subagent"`). Mention the failure to the user (including any limit-reset time), then run the task with your own subagent facility: spawn one subagent whose prompt is the payload's `task` verbatim, prefixed with: "NEVER run git write operations (commit, checkout, stash, reset, push, etc.); leave changes uncommitted." If the payload's `permissions` is not `auto`, append it: `read-only` means investigate and report without modifying anything; `workspace-write` means never touch anything outside the workspace. Relay its output when it completes.
|
|
29
29
|
- When the first engine can't start (auth, quota, rate limit), the runtime automatically falls back to the next engine in the chain, runs the same task on it via CLI, and still exits 0 - so just fetch the result. If the failure mentions a usage-limit reset time, relay that to the user.
|
|
30
30
|
|
|
31
31
|
- Engine, model, and effort come from config; add `--agent` / `--model` / `--effort` when the user asks or it is unambiguous from context (agents: `codex`, `claude`; codex models: `spark`, `luna`, `terra`, `sol`; claude models: `opus`, `sonnet`, `fable`; efforts: `low|medium|high`).
|
|
@@ -33,6 +33,10 @@ When you run setup, also check codex is new enough for the default GPT-5.6 model
|
|
|
33
33
|
- Permissions default to auto mode. Pass `--permissions read-only` when the task is read-only; `--permissions workspace-write` to forbid any escalation beyond the project.
|
|
34
34
|
- A background dispatch prints a task id plus its result/steer/stop commands. Relay them and fetch the result (above) rather than polling.
|
|
35
35
|
|
|
36
|
+
## Supervision loop
|
|
37
|
+
|
|
38
|
+
With coders running in the background, don't fire-and-forget: run a recurring monitoring loop in this task (interval by the work's pace, 10m default). Each tick: `coder task list`, fetch finished results, dispatch newly unblocked coders, steer stuck ones, stop off-track ones, surface pending approvals. Stop the loop when all tasks are done and relayed.
|
|
39
|
+
|
|
36
40
|
## Controlling tasks
|
|
37
41
|
|
|
38
42
|
- Continue prior work ("keep going", "apply the top fix"): `coder task steer <task-id> "<follow-up>"`.
|
|
@@ -19,19 +19,23 @@ When you run setup, also check codex is new enough for the default GPT-5.6 model
|
|
|
19
19
|
- Compose one self-contained task text (goal, relevant paths, constraints) and dispatch it. It backgrounds by default: the runtime does a startup check and prints a task id (or errors, see exit codes):
|
|
20
20
|
|
|
21
21
|
```bash
|
|
22
|
-
coder task run
|
|
22
|
+
coder task run "<task text>"
|
|
23
23
|
```
|
|
24
24
|
|
|
25
25
|
Fetch the answer with `coder task result <task-id> --wait` - it blocks until the task finishes, then prints only the final result (keeps your context clean). Run it in a **background terminal** so it does not block you; if you can't, poll `coder task result <task-id>` (no `--wait`) until it is done. Or skip the two steps and block on the run itself with `--wait` on `coder task run`. A `--wait` exits **4** when the task is waiting on a permission approval: relay it to the user, apply their decision with `coder task approve <task-id> <approval-id> [--deny]`, then re-fetch with `coder task result <task-id> --wait` (unanswered approvals auto-deny after 120s and the task moves on).
|
|
26
26
|
|
|
27
|
-
- Always pass `--host cursor` to identify yourself.
|
|
28
27
|
- `coder task run` exits after its startup check. Exit 0: the task started - fetch its result (above). Exit 1: it failed to start / the turn failed - report it, do not retry.
|
|
28
|
+
- Exit 3: no engine in the chain could start; stdout carries a JSON payload (`fallback.action: "run-native-subagent"`). Mention the failure to the user (including any limit-reset time), then run the task with your own subagent facility: spawn one subagent whose prompt is the payload's `task` verbatim, prefixed with: "NEVER run git write operations (commit, checkout, stash, reset, push, etc.); leave changes uncommitted." If the payload's `permissions` is not `auto`, append it: `read-only` means investigate and report without modifying anything; `workspace-write` means never touch anything outside the workspace. Relay its output when it completes.
|
|
29
29
|
- Codex startup failures (auth, quota, rate limit) fall back to the next engine in the chain automatically - the runtime reruns the same task on the claude engine via its CLI and still exits 0, so just fetch the result. If it mentions a usage-limit reset time, relay that to the user.
|
|
30
30
|
- Engine, model, and effort come from config; add `--agent` / `--model` / `--effort` when the user asks or it is unambiguous from context (agents: `codex`, `claude`; codex models: `spark`, `luna`, `terra`, `sol`; claude models: `opus`, `sonnet`, `fable`; efforts: `low|medium|high`).
|
|
31
31
|
- `spark` is only for the very lightest tasks (formatting, renames, quick lookups) - very fast and very cheap. It runs on a separate quota, so reach for it when the others hit a usage limit; it may still run once they are exhausted.
|
|
32
32
|
- Permissions default to auto mode. Pass `--permissions read-only` when the task is read-only; `--permissions workspace-write` to forbid any escalation beyond the project.
|
|
33
33
|
- A background dispatch prints a task id plus its result/steer/stop commands. Relay them and fetch the result (above) rather than polling.
|
|
34
34
|
|
|
35
|
+
## Supervision loop
|
|
36
|
+
|
|
37
|
+
With coders running in the background, don't fire-and-forget: run a recurring monitoring loop in this session (interval by the work's pace, 10m default). Each tick: `coder task list`, fetch finished results, dispatch newly unblocked coders, steer stuck ones, stop off-track ones, surface pending approvals. Stop the loop when all tasks are done and relayed.
|
|
38
|
+
|
|
35
39
|
## Controlling tasks
|
|
36
40
|
|
|
37
41
|
- Continue prior work ("keep going", "apply the top fix"): `coder task steer <task-id> "<follow-up>"`.
|