Skip to content

Skills: make coding-agent background-first with direct completion notifications#53585

Merged
fabianwilliams merged 1 commit intoopenclaw:mainfrom
FaiChou:main
Apr 25, 2026
Merged

Skills: make coding-agent background-first with direct completion notifications#53585
fabianwilliams merged 1 commit intoopenclaw:mainfrom
FaiChou:main

Conversation

@FaiChou
Copy link
Copy Markdown
Contributor

@FaiChou FaiChou commented Mar 24, 2026

Summary

  • Problem: The built-in coding-agent skill mixed foreground and background execution patterns, and its completion guidance depended on system-event / heartbeat delivery.
  • Why it matters: For background coding-agent tasks, a single background-first workflow with explicit completion routing is easier to follow and gives a more direct path back to the
    user.
  • What changed: Updated skills/coding-agent/SKILL.md to use immediate background:true launches, require explicit notification-route capture before spawn, and send completion/failure notifications with openclaw message send.
  • What did NOT change (scope boundary): No runtime, CLI, transport, or heartbeat code changed. This PR only updates the built-in skill instructions and examples.

Change Type (select all)

  • Feature
  • Docs

Scope (select all touched areas)

  • Skills / tool execution
  • UI / DX

Linked Issue/PR

  • Closes #
  • Related #
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

N/A

  • Root cause: N/A
  • Missing detection / guardrail: N/A
  • Prior context (git blame, prior PR, issue, or refactor if known): N/A
  • Why this regressed now: N/A
  • If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

N/A

  • Coverage level that should have caught this:
    • Existing coverage already sufficient
  • Target test or file: N/A
  • Scenario the test should lock in: N/A
  • Why this is the smallest reliable guardrail: This PR changes only the bundled skill text and examples.
  • Existing test that already covers this (if any): N/A
  • If no new test is added, why not: No runtime or command behavior changed.

User-visible / Behavior Changes

  • The built-in coding-agent skill now documents a background-first workflow.
  • The skill now documents direct completion/failure notification with openclaw message send.
  • The skill no longer recommends system-event / heartbeat-based completion delivery for coding-agent tasks.

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: <your OS>
  • Runtime/container: local dev checkout
  • Model/provider: N/A
  • Integration/channel (if any): N/A
  • Relevant config (redacted): N/A

Steps

  1. Open skills/coding-agent/SKILL.md.
  2. Review the execution and completion-notification sections.
  3. Confirm examples now use immediate background execution and direct completion notification via openclaw message send.

Expected

  • The built-in skill should present one consistent background-first workflow.
  • Completion/failure notification guidance should use explicit outbound messaging.

Actual

  • skills/coding-agent/SKILL.md now follows that workflow.

Evidence

Attach at least one:

  • Trace/log snippets

Suggested attachment:

  • PR diff for skills/coding-agent/SKILL.md

Human Verification (required)

  • Verified scenarios: Reviewed the updated skill text end-to-end; confirmed the background-first pattern, explicit notify-route capture, and openclaw message send completion
    guidance.
  • Edge cases checked: Preserved PTY guidance for Codex/Pi/OpenCode, preserved Claude Code --print --permission-mode bypassPermissions, and kept scratch git init guidance for
    Codex.
  • What you did not verify: I did not run a full live end-to-end coding-agent task against a real messaging channel.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: Revert this PR.
  • Files/config to restore: skills/coding-agent/SKILL.md
  • Known bad symptoms reviewers should watch for: Any bundled-skill guidance that assumes a notification route is available when the caller has not captured one.

Risks and Mitigations

  • Risk: The updated guidance is more prescriptive and assumes the caller captures a valid notification route before spawn.
    • Mitigation: The skill now states that callers should not promise automatic completion notification when no trustworthy route is available.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ea2e784566

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread skills/coding-agent/SKILL.md Outdated
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Mar 24, 2026

Greptile Summary

This PR refactors skills/coding-agent/SKILL.md to enforce a background-first workflow: all coding-agent launches now require background:true immediately, and completion/failure notifications must be delivered via openclaw message send rather than openclaw system event or heartbeat delivery. The new structure (Mandatory Pattern → Notification Route → examples → Rules) is cleaner and more prescriptive than the previous mixed foreground/background guidance.

Key observations:

  • The install metadata block (auto-install entries for @anthropic-ai/claude-code and @openai/codex) was removed without being mentioned in the PR description. If OpenClaw uses this to offer in-app install flows, removing it is an unintentional behavioural regression for users who don't have the CLIs installed.
  • The "Wrong for Claude Code" PTY example does not flag missing background:true as one of the three things wrong with it, which could mislead readers following along.
  • Most concrete spawn examples (PR review, batch review, Claude Code, OpenCode, Pi) do not demonstrate the notify-route injection step that the Mandatory Pattern section requires, widening the gap between the reference pattern and the illustrative snippets.

Confidence Score: 4/5

  • Safe to merge after confirming whether the install metadata removal is intentional.
  • The skill rewrite is well-structured, internally consistent, and achieves its stated goal. The one item that needs explicit confirmation before landing is the silent removal of the install metadata block, which could affect the in-app install-prompt behaviour for users missing claude/codex. The other two comments are style-level improvements that don't block merging.
  • skills/coding-agent/SKILL.md — specifically the metadata section (lines 4–7) where the install entries were removed.
Prompt To Fix All With AI
This is a comment left during a code review.
Path: skills/coding-agent/SKILL.md
Line: 4-7

Comment:
**`install` metadata entries silently removed**

The PR drops the `install` block from the skill metadata:

```json
"install": [
  { "id": "node-claude", "kind": "node", "package": "@anthropic-ai/claude-code", "bins": ["claude"], "label": "Install Claude Code CLI (npm)" },
  { "id": "node-codex",  "kind": "node", "package": "@openai/codex",            "bins": ["codex"],  "label": "Install Codex CLI (npm)"       }
]
```

If OpenClaw uses these entries to surface an in-app "install missing tool" flow, removing them means users who don't have `claude` or `codex` installed will no longer be offered an auto-install path when this skill is invoked — they'll just hit the `anyBins` gate silently.

The PR description frames the change as "only updating built-in skill instructions and examples" and does not call this out as an intentional behaviour change. If it is intentional, please confirm it in the PR description and verify that the app handles a missing `install` section gracefully for this skill. If it's unintentional, the block should be restored.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: skills/coding-agent/SKILL.md
Line: 32-34

Comment:
**"Wrong" example omits `background:true`, which is also wrong now**

The example currently flags only two problems with this command: `pty:true` and `--dangerously-skip-permissions`. But per the new mandatory rule ("Always background immediately — use `background:true` for every coding-agent launch"), the missing `background:true` is a third defect in this example that goes unmentioned. A reader could copy the correct flags and add `background:true` to this wrong command and think they've fixed it, but they'd still be using `--dangerously-skip-permissions` instead of `--permission-mode bypassPermissions --print`.

Consider adding a brief inline comment to the wrong example listing all three issues, or restructuring it so the contrast with the correct example is unambiguous:

```suggestion
# Wrong for Claude Code (PTY, wrong flags, no background)
bash pty:true command:"claude --dangerously-skip-permissions 'task'"
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: skills/coding-agent/SKILL.md
Line: 182-207

Comment:
**Examples don't demonstrate the Mandatory Pattern's notify-route injection step**

The "Mandatory Pattern" section (step 3) states: *"Include the notification route in the worker prompt and require the worker to call `openclaw message send` on completion."* However, the simplified examples in the PR review, batch PR review, Claude Code, OpenCode, and Pi sections all launch workers without injecting any notify-route variables into the worker prompt, e.g.:

```bash
bash pty:true workdir:$REVIEW_DIR background:true command:"codex review --base origin/main"
```

An agent following only the examples (rather than reading the Mandatory Pattern section carefully) would spawn workers with no completion notification path.

The parallel worktree example does reference the notify route (`"...Send the completion message with openclaw message send using the provided notify route.'"`) but without showing how to inject the actual route values. Aligning at least the Quick Start or one end-to-end example with the Completion Prompt Snippet template would reduce the risk of agents silently skipping the notification step.

How can I resolve this? If you propose a fix, please make it concise.

Reviews (1): Last reviewed commit: "docs: enforce background mode & direct c..." | Re-trigger Greptile

Comment thread skills/coding-agent/SKILL.md
Comment thread skills/coding-agent/SKILL.md Outdated
Comment thread skills/coding-agent/SKILL.md
@FaiChou FaiChou force-pushed the main branch 2 times, most recently from 77ff66a to 20fd56f Compare March 24, 2026 09:59
Copy link
Copy Markdown
Contributor

@fabianwilliams fabianwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good simplification — making background:true the only path removes ambiguity for skill authors.

A few observations:

  1. Completion via openclaw message send instead of system events is a cleaner contract. We've seen in our own cron deployments that relying on delivery:announce + agent-initiated messaging causes duplicates. Having one explicit path (the worker calls openclaw message send) is the right pattern.

  2. The notification-route capture before spawn is smart — ensures the agent knows WHERE to send results before it starts working. We've hit issues where background jobs complete but the operator never gets notified because the delivery target wasn't set up.

  3. Scope boundary is well-drawn — SKILL.md only, no runtime changes. This makes it safe to land and iterate.

One question: the description mentions "openclaw message send" for completion — is that a new CLI command, or does it map to an existing tool? If it's new, should there be a note about minimum OpenClaw version required?

Otherwise LGTM for the skill instruction changes.

@fabianwilliams
Copy link
Copy Markdown
Contributor

Rebased onto current upstream/main (resolved 2 conflicts in skills/coding-agent/SKILL.md):

  1. description field — kept this PR's longer descriptive form (the encoded behavioral rules are the point of the PR).
  2. Rules section — kept upstream's version, which had two safety rules added since this PR was opened ($OPENCLAW_STATE_DIR guard, ~/Projects/openclaw/ guard). Those are critical and shouldn't be lost.

Also added Rule #10 to address @greptile-apps's note that the simplified examples don't visibly inject the notify-route block:

  1. Always inject the Completion Prompt Snippet into the worker prompt before spawning. The simplified examples below omit it for brevity — never spawn a worker without it.

This makes the implicit "reuse the injection block" instruction at the top of Quick Start an explicit rule, so an agent reading mechanically can't miss it.

Force-pushed (with-lease) to your branch — maintainerCanModify was on. Watching CI now; will squash-merge if green.

Per @pSteiny's directive: fix-and-merge velocity.

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Apr 25, 2026

Good conflict resolution — keeping the $OPENCLAW_STATE_DIR and ~/Projects/openclaw/ guards was the right call.

One issue in the current file though: there are now two separate "Rules" sections that partially overlap and disagree:

  1. ## ⚠️ Rules (the old list, items 1–10) — includes the injection rule as item 10
  2. ## Rules (the new canonical list, items 1–11) — does NOT include the injection rule

The new canonical section at the bottom is missing the injection requirement entirely. An agent reading it top-to-bottom will hit ## Rules last and see no mention of snippet injection there. The only coverage is in ## ⚠️ Rules above, which an agent might treat as superseded once it reaches the canonical section.

Also a minor issue: Rule 10 in ## ⚠️ Rules says "The simplified examples below omit it for brevity" — but the examples all appear above that section, not below it.

Two options:

Option A (simpler): Add injection as an explicit rule in ## Rules:

4. **Capture notify routing before spawn.**
   - Completion messaging must have a real route.
   - Inject the Completion Prompt Snippet into the worker prompt. Examples omit it for brevity — never spawn without it.

Option B (cleaner): Consolidate by removing the old ## ⚠️ Rules section and folding any unique items (the $OPENCLAW_STATE_DIR and ~/Projects/openclaw/ guards are already in Rules 10–11) into the canonical section.

Either way, the canonical ## Rules section should be the single source of truth. As-is, there's a gap that could cause agents to miss snippet injection.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules and .greptile/config.

Copy link
Copy Markdown
Contributor

@fabianwilliams fabianwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased + Rule #10 added to address @greptile-apps's notify-route concern. Docs-only change, relevant CI green. Approving per @pSteiny's fix-and-merge directive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants