openclaw-code-agent 3.1.0 β 3.2.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/README.md +69 -10
- package/dist/index.js +191 -106
- package/openclaw.plugin.json +1 -1
- package/package.json +28 -10
- package/skills/code-agent-orchestration/SKILL.md +114 -144
package/openclaw.plugin.json
CHANGED
package/package.json
CHANGED
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "openclaw-code-agent",
|
|
3
|
-
"version": "3.
|
|
3
|
+
"version": "3.2.0",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"main": "dist/index.js",
|
|
6
6
|
"scripts": {
|
|
7
|
-
"build": "esbuild index.ts --bundle --platform=node --target=
|
|
7
|
+
"build": "esbuild index.ts --bundle --platform=node --target=node22 --format=esm --outfile=dist/index.js --minify --external:openclaw --external:openclaw/plugin-sdk --external:openclaw/plugin-sdk/* --external:@anthropic-ai/claude-agent-sdk",
|
|
8
8
|
"test": "node scripts/run-tests.mjs",
|
|
9
9
|
"test:serial": "node scripts/run-tests.mjs",
|
|
10
10
|
"test:file": "node scripts/run-tests.mjs",
|
|
@@ -13,13 +13,22 @@
|
|
|
13
13
|
"smoke:codex-worktrees": "node scripts/run-tests.mjs tests/codex-harness.test.ts tests/session-bootstrap.test.ts tests/session-restore-service.test.ts",
|
|
14
14
|
"smoke:codex-live": "OPENCLAW_RUN_LIVE_CODEX_SMOKE=1 node scripts/run-tests.mjs tests/live-codex-app-server-smoke.test.ts",
|
|
15
15
|
"smoke:codex-release": "OPENCLAW_RUN_LIVE_CODEX_RELEASE_SMOKE=1 node scripts/run-tests.mjs tests/live-codex-app-server-smoke.test.ts",
|
|
16
|
-
"typecheck": "tsc --noEmit",
|
|
16
|
+
"typecheck": "tsc -p tsconfig.typecheck.json --noEmit",
|
|
17
|
+
"validate:release-metadata": "node scripts/validate-release-metadata.mjs",
|
|
17
18
|
"verify": "pnpm typecheck && pnpm build && pnpm test"
|
|
18
19
|
},
|
|
19
20
|
"openclaw": {
|
|
20
21
|
"extensions": [
|
|
21
22
|
"./dist/index.js"
|
|
22
|
-
]
|
|
23
|
+
],
|
|
24
|
+
"compat": {
|
|
25
|
+
"pluginApi": ">=2026.4.9",
|
|
26
|
+
"minGatewayVersion": "2026.4.9"
|
|
27
|
+
},
|
|
28
|
+
"build": {
|
|
29
|
+
"openclawVersion": "2026.4.9",
|
|
30
|
+
"pluginSdkVersion": "2026.4.9"
|
|
31
|
+
}
|
|
23
32
|
},
|
|
24
33
|
"files": [
|
|
25
34
|
"dist/",
|
|
@@ -30,13 +39,14 @@
|
|
|
30
39
|
"LICENSE"
|
|
31
40
|
],
|
|
32
41
|
"dependencies": {
|
|
33
|
-
"@anthropic-ai/claude-agent-sdk": "^0.2.
|
|
42
|
+
"@anthropic-ai/claude-agent-sdk": "^0.2.101"
|
|
34
43
|
},
|
|
35
44
|
"devDependencies": {
|
|
36
|
-
"@sinclair/typebox": "^0.34.
|
|
37
|
-
"@types/node": "^25.5.
|
|
38
|
-
"esbuild": "^0.
|
|
45
|
+
"@sinclair/typebox": "^0.34.49",
|
|
46
|
+
"@types/node": "^25.5.2",
|
|
47
|
+
"esbuild": "^0.28.0",
|
|
39
48
|
"nanoid": "^5.1.7",
|
|
49
|
+
"openclaw": "2026.4.10",
|
|
40
50
|
"tsx": "^4.21.0",
|
|
41
51
|
"typescript": "^6.0.2"
|
|
42
52
|
},
|
|
@@ -71,7 +81,10 @@
|
|
|
71
81
|
},
|
|
72
82
|
"description": "An OpenClaw plugin that orchestrates coding agent sessions as managed background processes. Launch, monitor, and control coding agents (Claude Code, Codex, and more) directly from your AI gateway.",
|
|
73
83
|
"peerDependencies": {
|
|
74
|
-
"openclaw": ">=2026.
|
|
84
|
+
"openclaw": ">=2026.4.9"
|
|
85
|
+
},
|
|
86
|
+
"overrides": {
|
|
87
|
+
"basic-ftp": "5.2.2"
|
|
75
88
|
},
|
|
76
89
|
"pnpm": {
|
|
77
90
|
"onlyBuiltDependencies": [
|
|
@@ -81,6 +94,11 @@
|
|
|
81
94
|
"sharp",
|
|
82
95
|
"@img/sharp-linux-x64",
|
|
83
96
|
"@img/sharp-linux-arm64"
|
|
84
|
-
]
|
|
97
|
+
],
|
|
98
|
+
"overrides": {
|
|
99
|
+
"basic-ftp": "5.2.2",
|
|
100
|
+
"brace-expansion@>=4.0.0 <5.0.5": ">=5.0.5",
|
|
101
|
+
"path-to-regexp@>=8.0.0 <8.4.0": ">=8.4.0"
|
|
102
|
+
}
|
|
85
103
|
}
|
|
86
104
|
}
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: Code Agent Orchestration
|
|
3
|
-
description: Skill for orchestrating coding agent sessions from OpenClaw. Covers launching, monitoring,
|
|
3
|
+
description: Skill for orchestrating coding agent sessions from OpenClaw. Covers launching, monitoring, plan approval, lifecycle management, and worktree decisions.
|
|
4
4
|
metadata:
|
|
5
5
|
openclaw:
|
|
6
6
|
homepage: https://github.com/goldmar/openclaw-code-agent
|
|
@@ -17,16 +17,16 @@ metadata:
|
|
|
17
17
|
|
|
18
18
|
Use `openclaw-code-agent` to run Claude Code or Codex sessions as background coding jobs from chat.
|
|
19
19
|
|
|
20
|
-
##
|
|
20
|
+
## Launch
|
|
21
21
|
|
|
22
22
|
- Do not pass `channel` manually. Routing comes from `agentChannels`, the current chat context, and `fallbackChannel`.
|
|
23
|
-
- Sessions are multi-turn.
|
|
23
|
+
- Sessions are multi-turn. Continue existing work with `agent_respond` or `agent_launch(..., resume_session_id=...)`; do not start a fresh session for the same task.
|
|
24
24
|
- Always set a short kebab-case `name` when you care about later follow-up.
|
|
25
|
-
- Set `workdir` to the target repo
|
|
26
|
-
-
|
|
27
|
-
- Use `permission_mode: "
|
|
28
|
-
-
|
|
29
|
-
- In `plan` mode, the plan
|
|
25
|
+
- Set `workdir` to the target repo.
|
|
26
|
+
- Use `permission_mode: "plan"` when the user wants a real review gate before implementation.
|
|
27
|
+
- Use `permission_mode: "bypassPermissions"` only for autonomous execution.
|
|
28
|
+
- `defaultWorktreeStrategy` now defaults to `off`. Opt into a worktree strategy explicitly when you want branch isolation.
|
|
29
|
+
- In `plan` mode, the plan belongs in normal session output. Do not ask the coding agent to write plan docs or transcript artifacts unless the user explicitly asked for a file.
|
|
30
30
|
|
|
31
31
|
Example:
|
|
32
32
|
|
|
@@ -38,76 +38,67 @@ agent_launch(
|
|
|
38
38
|
)
|
|
39
39
|
```
|
|
40
40
|
|
|
41
|
-
Resume
|
|
41
|
+
## Resume, Don't Respawn
|
|
42
42
|
|
|
43
|
-
|
|
44
|
-
agent_launch(
|
|
45
|
-
prompt: "Continue where you left off",
|
|
46
|
-
resume_session_id: "fix-auth"
|
|
47
|
-
)
|
|
48
|
-
|
|
49
|
-
agent_launch(
|
|
50
|
-
prompt: "Try a different approach",
|
|
51
|
-
resume_session_id: "fix-auth",
|
|
52
|
-
fork_session: true,
|
|
53
|
-
name: "fix-auth-alt"
|
|
54
|
-
)
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
## 2. Anti-Cascade Rule
|
|
58
|
-
|
|
59
|
-
When you are woken because a session is waiting or completed, do not launch a new coding session in response. Only use the existing session with:
|
|
60
|
-
|
|
61
|
-
- `agent_output`
|
|
62
|
-
- `agent_respond`
|
|
63
|
-
- `agent_merge`
|
|
64
|
-
- `agent_pr`
|
|
65
|
-
- `agent_worktree_status`
|
|
43
|
+
When a session already exists for the task, keep using it.
|
|
66
44
|
|
|
67
|
-
|
|
45
|
+
- Waiting for plan approval: `agent_respond(session, message, approve=true)` or `agent_request_plan_approval(...)` if delegated approval must escalate to the user
|
|
46
|
+
- Waiting for a question answer: `agent_respond(session, message)`
|
|
47
|
+
- Killed/stopped by restart: `agent_respond(session, message)`
|
|
48
|
+
- Completed but needs follow-up: `agent_launch(resume_session_id=session_id, prompt="...")`
|
|
49
|
+
- Fresh `agent_launch` is only for genuinely independent work
|
|
68
50
|
|
|
69
|
-
|
|
51
|
+
Do not launch a new coding session from a wake event for the same task.
|
|
70
52
|
|
|
71
|
-
|
|
72
|
-
|-----------|---------------|
|
|
73
|
-
| Session waiting for plan approval | `agent_respond(session, message, approve=true)` |
|
|
74
|
-
| Session waiting for a question answer | `agent_respond(session, message)` |
|
|
75
|
-
| Session killed/stopped by restart | `agent_respond(session, message)` β killed sessions auto-resume on next `agent_respond` |
|
|
76
|
-
| Session completed, user wants to extend/revise | `agent_launch(resume_session_id=session_id)` |
|
|
77
|
-
| Worktree has uncommitted work after a crash | `agent_respond` on the stopped session first; only if truly unrecoverable, relaunch with the worktree still in place |
|
|
78
|
-
|
|
79
|
-
**Never use `agent_launch` to start a fresh session when `agent_respond` would work.** Spawning fresh loses conversation history, may duplicate worktrees, and confuses the user.
|
|
80
|
-
|
|
81
|
-
Only spawn a genuinely new session for work that is **completely independent** of any existing session.
|
|
82
|
-
|
|
83
|
-
## 3. Monitoring
|
|
53
|
+
## State and Monitoring
|
|
84
54
|
|
|
85
55
|
Use:
|
|
86
56
|
|
|
87
57
|
```text
|
|
88
58
|
agent_sessions()
|
|
89
|
-
agent_sessions(status: "running")
|
|
90
59
|
agent_output(session: "fix-auth", lines: 100)
|
|
91
60
|
agent_output(session: "fix-auth", full: true)
|
|
92
61
|
```
|
|
93
62
|
|
|
94
|
-
|
|
95
|
-
|
|
63
|
+
For worktree follow-through, inspect:
|
|
64
|
+
|
|
65
|
+
```text
|
|
66
|
+
agent_worktree_status()
|
|
67
|
+
agent_worktree_status(session: "fix-auth")
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
Treat that tool's lifecycle, derived state, cleanup disposition, and retained reasons as authoritative. Do not infer cleanup safety from a transcript summary or from branch names alone.
|
|
71
|
+
|
|
72
|
+
Treat these wake fields as authoritative state when present:
|
|
96
73
|
|
|
97
74
|
- `requestedPermissionMode`
|
|
98
|
-
- `effectivePermissionMode` /
|
|
75
|
+
- `effectivePermissionMode` / `currentPermissionMode`
|
|
99
76
|
- `approvalExecutionState`
|
|
100
77
|
|
|
101
|
-
|
|
78
|
+
Use those deterministic fields instead of inferring behavior from transcript fragments.
|
|
79
|
+
|
|
80
|
+
Approval/execution meanings:
|
|
81
|
+
|
|
82
|
+
- `approved_then_implemented`: normal approved execution
|
|
83
|
+
- `implemented_without_required_approval`: actual approval bypass
|
|
84
|
+
- `awaiting_approval`: still stopped at the approval gate
|
|
85
|
+
- `not_plan_gated`: no plan gate applied
|
|
102
86
|
|
|
103
|
-
Completion
|
|
87
|
+
Completion ownership:
|
|
104
88
|
|
|
105
|
-
-
|
|
106
|
-
-
|
|
107
|
-
-
|
|
108
|
-
-
|
|
89
|
+
- The plugin sends the canonical completion notification.
|
|
90
|
+
- The plugin owns the canonical completion status line; the orchestrator owns any additional plain-text follow-up.
|
|
91
|
+
- After a coding-agent session completes, the orchestrator should usually add at least a short human-useful summary of what changed, what was done, or the concrete outcome.
|
|
92
|
+
- That expectation applies to ordinary terminal/manual completions, manual no-change completions, and delegated worktree completions alike.
|
|
93
|
+
- Treat the plugin's canonical `β
` as the status signal and your follow-up as the factual outcome summary that should usually come right after it.
|
|
94
|
+
- That summary can be brief; one sentence is often enough.
|
|
95
|
+
- Extra synthesis, risk framing, and next-step guidance are optional. Add them when useful; do not force them every time.
|
|
96
|
+
- Do not generate your own heuristic completion summary from transcript tail lines. Base any summary on reliable result data such as `agent_output(..., full=true)`, diff context, or deterministic tool state.
|
|
97
|
+
- Skip the summary only in narrow cases:
|
|
98
|
+
- no user-facing follow-up will be sent at all because the orchestrator is silently continuing an internal multi-phase pipeline
|
|
99
|
+
- the completion produced no meaningful outcome to report, or the reliable result data is still too incomplete to support even a short factual summary
|
|
109
100
|
|
|
110
|
-
##
|
|
101
|
+
## Respond Rules
|
|
111
102
|
|
|
112
103
|
Auto-respond immediately only for:
|
|
113
104
|
|
|
@@ -121,120 +112,99 @@ Forward everything else to the user:
|
|
|
121
112
|
- scope changes
|
|
122
113
|
- credentials or production questions
|
|
123
114
|
- ambiguous requirements
|
|
124
|
-
- anything you are not certain you should answer autonomously
|
|
125
115
|
|
|
126
|
-
When forwarding, quote the session's exact question. Do not add
|
|
116
|
+
When forwarding, quote the session's exact question. Do not add commentary.
|
|
127
117
|
|
|
128
|
-
|
|
118
|
+
## Plan Approval
|
|
129
119
|
|
|
130
|
-
|
|
131
|
-
agent_respond(session: "fix-auth", message: "Yes, proceed.")
|
|
132
|
-
|
|
133
|
-
agent_respond(
|
|
134
|
-
session: "fix-auth",
|
|
135
|
-
message: "Stop. Do not touch the database schema.",
|
|
136
|
-
interrupt: true
|
|
137
|
-
)
|
|
138
|
-
```
|
|
139
|
-
|
|
140
|
-
## 5. Plan Approval
|
|
120
|
+
Use `permission_mode: "plan"` whenever the user wants a real planning checkpoint.
|
|
141
121
|
|
|
142
|
-
|
|
122
|
+
### `planApproval: "ask"`
|
|
143
123
|
|
|
144
|
-
-
|
|
145
|
-
-
|
|
146
|
-
- If the user
|
|
147
|
-
-
|
|
148
|
-
-
|
|
124
|
+
- Approval belongs to the user.
|
|
125
|
+
- The plugin sends the canonical Approve / Revise / Reject prompt directly to the user.
|
|
126
|
+
- If the user requests changes, wait for the revised plan from that same session; the revised submission becomes the latest actionable review version automatically.
|
|
127
|
+
- Wait for the user's answer, then forward it with `agent_respond(...)`.
|
|
128
|
+
- Do not send a duplicate approval recap or second approval prompt.
|
|
149
129
|
|
|
150
|
-
|
|
130
|
+
### `planApproval: "delegate"`
|
|
151
131
|
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
132
|
+
- Approval belongs to the orchestrator first.
|
|
133
|
+
- This is wake-first: the plugin wakes the orchestrator without user buttons.
|
|
134
|
+
- Before deciding, read the full plan with `agent_output(session, full=true)`; do not rely on the truncated preview.
|
|
135
|
+
- Approve directly with `agent_respond(..., approve=true)` only when the latest actionable plan version is clearly in-bounds and low risk.
|
|
136
|
+
- When approving directly, pass a structured rationale with `approval_rationale`, for example: `agent_respond(session='...', message='Approved. Go ahead.', approve=true, approval_rationale='Scope matches the request and the changes are low risk.')`
|
|
137
|
+
- After approving directly, send the user a short plain-text follow-up explaining what was approved and why. The plugin's `π Plan approved` line is only a fallback signal, not the full explanation.
|
|
138
|
+
- If a prior version had `changes_requested`, that stale state should not block approval of the latest revised plan version.
|
|
139
|
+
- If escalation is needed, call `agent_request_plan_approval(session='...', summary='...')` exactly once so the plugin sends the single canonical user approval prompt.
|
|
140
|
+
- That escalation summary must concisely explain why you are escalating, plus risk/scope notes the user needs to decide.
|
|
141
|
+
- After that canonical prompt exists, wait for the user's decision; do not send a second plain-text approval summary.
|
|
160
142
|
|
|
161
|
-
|
|
143
|
+
### `planApproval: "approve"`
|
|
162
144
|
|
|
163
|
-
-
|
|
164
|
-
- Do not send approval and revision feedback in the same call.
|
|
165
|
-
- In `planApproval: "ask"`, the user is expected to approve or revise. Wait for that input.
|
|
166
|
-
- Telegram users may get inline `Approve`, `Reject`, and `Revise` buttons for plan review.
|
|
145
|
+
- Auto-approve only after verification per the session policy.
|
|
167
146
|
|
|
168
|
-
##
|
|
169
|
-
|
|
170
|
-
### `ask`
|
|
147
|
+
## Worktree Decisions
|
|
171
148
|
|
|
172
|
-
|
|
173
|
-
- **β
Merge** β merge branch locally
|
|
174
|
-
- **π¬ Open PR** β create a GitHub PR
|
|
175
|
-
- **βοΈ Decide later** β snooze reminders for 24h
|
|
176
|
-
- **ποΈ Dismiss (deletes branch)** β permanently delete branch and worktree (irreversible)
|
|
149
|
+
Treat worktrees as temporary task sandboxes, not as generic branch inventory.
|
|
177
150
|
|
|
178
|
-
|
|
151
|
+
Lifecycle meanings:
|
|
179
152
|
|
|
180
|
-
|
|
153
|
+
- `pending_decision`: still waiting for merge / PR / dismiss follow-through
|
|
154
|
+
- `pr_open`: PR exists; preserve the sandbox
|
|
155
|
+
- `merged`: normal ancestry merge landed
|
|
156
|
+
- `released`: content already landed on the base branch even though SHAs differ after rebase, squash, or cherry-pick
|
|
157
|
+
- `dismissed`: sandbox intentionally discarded
|
|
158
|
+
- `no_change`: no committed delta
|
|
181
159
|
|
|
182
|
-
|
|
160
|
+
If `agent_worktree_status` reports `released`, treat that sandbox as already landed. Do not narrate it as βstill unmergedβ just because the branch appears ahead.
|
|
183
161
|
|
|
184
|
-
|
|
185
|
-
- **NEVER call `agent_pr()` autonomously** β always escalate PR decisions to the user
|
|
186
|
-
- escalate to the user if scope or risk is unclear, or if a PR is the safer choice
|
|
187
|
-
- if the wake already says the plugin sent the canonical completion message, only add user-facing follow-up when you need synthesis, risk framing, or concrete next steps beyond that message
|
|
162
|
+
### `off`
|
|
188
163
|
|
|
189
|
-
|
|
164
|
+
- No worktree. The session runs in the main checkout.
|
|
190
165
|
|
|
191
|
-
|
|
166
|
+
### `ask`
|
|
192
167
|
|
|
193
|
-
|
|
168
|
+
- The plugin owns the user-facing completion/decision message and button UI.
|
|
169
|
+
- Do not call `agent_merge` or `agent_pr` unless the user explicitly asks after that.
|
|
170
|
+
- A completed ask-session worktree may later resolve as `released` if its content already landed on base through another path. Confirm that with `agent_worktree_status(...)` before deciding what follow-up is still needed.
|
|
194
171
|
|
|
195
|
-
|
|
196
|
-
- never clear a pending worktree decision by inventing your own workaround; use `agent_worktree_cleanup(session: "...", dismiss_session: true)` to permanently dismiss
|
|
197
|
-
- never call `agent_pr()` autonomously in `delegate` flows β always escalate to the user for PR decisions
|
|
172
|
+
### `delegate`
|
|
198
173
|
|
|
199
|
-
|
|
174
|
+
- The plugin wakes the orchestrator with diff context and no automatic user buttons.
|
|
175
|
+
- Read the diff context and decide whether a local merge is clearly safe.
|
|
176
|
+
- `agent_merge` is acceptable for low-risk, clearly scoped changes that match the task.
|
|
177
|
+
- Never call `agent_pr()` autonomously in delegate flows. Escalate PR decisions to the user.
|
|
178
|
+
- If the wake already says the plugin sent the canonical completion notification, do not repeat that status line, but you should still usually add a short summary of the completed outcome.
|
|
200
179
|
|
|
201
|
-
|
|
202
|
-
- Do NOT commit planning documents, investigation notes, or analysis artifacts to the branch
|
|
203
|
-
- Only commit actual code, configuration, tests, and documentation changes that were explicitly requested as part of the task
|
|
180
|
+
### `manual`
|
|
204
181
|
|
|
205
|
-
|
|
182
|
+
- Wait for an explicit user request before calling `agent_merge` or `agent_pr`.
|
|
206
183
|
|
|
207
|
-
|
|
208
|
-
- Do not create a new session if the old worktree branch still has unmerged changes β resume instead
|
|
209
|
-
- If the user wants a fresh start, use `fork_session: true` to branch from the previous session state
|
|
184
|
+
### Cleanup
|
|
210
185
|
|
|
211
|
-
|
|
186
|
+
- Use `agent_worktree_cleanup(mode: "preview_safe")` to review what **Clean all safe** would remove.
|
|
187
|
+
- Use `agent_worktree_cleanup(mode: "clean_safe")` only when the user asked to clean up safe sandboxes.
|
|
188
|
+
- Use `agent_worktree_cleanup(mode: "preview_all")` when you need both safe candidates and retained reasons.
|
|
189
|
+
- Respect retained reasons from `agent_worktree_status` / `agent_worktree_cleanup`; they are the lifecycle model, not advisory prose.
|
|
212
190
|
|
|
213
|
-
|
|
214
|
-
- The only common non-resumable path is `startup-timeout`.
|
|
215
|
-
- Terminal runtime sessions are evicted after `sessionGcAgeMinutes` (default 1440 minutes), but persisted metadata remains resumable.
|
|
216
|
-
- `agent_stats` is the quick operator view for aggregate cost and duration.
|
|
191
|
+
### Never
|
|
217
192
|
|
|
218
|
-
|
|
193
|
+
- Never use raw `git merge` or raw PR commands in place of plugin tools.
|
|
194
|
+
- Never invent your own workaround for a pending worktree decision; use `agent_worktree_cleanup(session: "...", dismiss_session: true)` to dismiss permanently.
|
|
195
|
+
- Never use `agent_worktree_cleanup` to force-delete unresolved worktrees. The supported bulk action is "clean all safe": omit `session` and let the plugin remove only lifecycle-safe worktrees while preserving anything active, pending, dirty, or PR-open.
|
|
196
|
+
- Never merge or PR an `ask` worktree behind the user's back.
|
|
219
197
|
|
|
220
|
-
|
|
198
|
+
## File Artifact Policy
|
|
221
199
|
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
/agent_output fix-auth
|
|
226
|
-
/agent_respond fix-auth Add tests too
|
|
227
|
-
/agent_kill fix-auth
|
|
228
|
-
/agent_resume --fork fix-auth Try a different approach
|
|
229
|
-
/agent_stats
|
|
230
|
-
```
|
|
200
|
+
- Do not ask the coding agent to write planning documents, investigation notes, or analysis artifacts as files unless the user explicitly requested a file.
|
|
201
|
+
- Do not commit planning documents, investigation notes, or transcript-summary artifacts to the branch.
|
|
202
|
+
- Commit only actual code, configuration, tests, and explicitly requested documentation.
|
|
231
203
|
|
|
232
|
-
##
|
|
204
|
+
## Anti-Patterns
|
|
233
205
|
|
|
234
|
-
- Do not pass
|
|
235
|
-
- Do not pass `channel` manually unless you are debugging routing
|
|
206
|
+
- Do not pass `multi_turn` or `multi_turn_disabled`; all sessions are multi-turn.
|
|
207
|
+
- Do not pass `channel` manually unless you are debugging routing.
|
|
236
208
|
- Do not auto-answer design or scope questions.
|
|
237
|
-
- Do not
|
|
238
|
-
- Do not
|
|
239
|
-
|
|
240
|
-
See `README.md` for the product overview and `docs/REFERENCE.md` for the canonical operator reference.
|
|
209
|
+
- Do not infer approval/completion ownership from old transcript snippets when deterministic fields are present.
|
|
210
|
+
- Do not post duplicate completion or approval recaps when the plugin already sent the canonical message.
|