Verwendung

Ein Coding-Auftrag besteht aus einer Repo-URL und einer Aufgabenbeschreibung. Der coding-agent erkennt den Provider automatisch, legt einen Draft-PR an und startet die Implementierung.

Auftrag starten


node coding-agent/start.mjs \
  --repo <repo-url> \
  --title "Kurztitel" \
  --description "Vollständige Beschreibung" \
  [--assignee username] \
  [--reviewer username-oder-email] \
  [--thinking off|low|medium|high]

Parameter	Pflicht	Beschreibung
`--repo`	ja	Vollständige Repo-URL (GitHub oder Azure DevOps); GitHub-Kurzform `owner/repo` wird akzeptiert
`--title`	ja	Kurztitel des Tasks (PR-Titel)
`--description`	ja	Vollständige Aufgabenbeschreibung (PR-Body)
`--assignee`	nein	Zuweisung (nur GitHub)
`--reviewer`	nein	Reviewer (Username bzw. E-Mail)
`--thinking`	nein	Denk-Intensität: `off`, `low`, `medium`, `high` (Default: `medium`)

Ausgabe: { sessionId, prUrl }

start.mjs ist ein Komfort-Wrapper (Test-CLI): Es baut aus den Parametern den Task-Payload und ruft darunter openclaw agent auf. Der Agent selbst lässt sich auf mehreren Wegen ansprechen — siehe unten.

Alternativen: dem Agenten eine Nachricht senden

Der coding-agent ist ein normaler OpenClaw-Agent (agentId: coding-agent). Er erwartet als Nachricht einen Task-Payload im JSON-Format:


{
  "schemaVersion": "0.1",
  "task": {
    "title": "Kurztitel des Tasks",
    "description": "Vollständige Aufgabenbeschreibung"
  },
  "repoUrl": "https://github.com/owner/repo",
  "assignee": "username",
  "reviewer": "username-oder-email"
}

assignee (nur GitHub) und reviewer sind optional. Diesen Payload kann man auf verschiedene Weise an den Agenten schicken:

1. Test-CLI `start.mjs`

Der einfachste Weg zum Ausprobieren — siehe Auftrag starten oben. Baut den Payload aus den ---Parametern und erzeugt automatisch einen frischen Session-Key.

2. OpenClaw-CLI direkt

Genau das ruft start.mjs intern auf:


openclaw agent \
  --agent coding-agent \
  --message '{"schemaVersion":"0.1","task":{"title":"...","description":"..."},"repoUrl":"https://github.com/owner/repo"}' \
  --session-key "agent:coding-agent:$(uuidgen)" \
  --thinking medium \
  --json

Ohne --session-key setzt OpenClaw die letzte Session fort. Für einen neuen Auftrag immer einen frischen Session-Key im Format agent:coding-agent:<uuid> vergeben — sonst landet der Task in einer bestehenden Konversation.

3. Aus einem LowCode-Flow

In ProcessCube® LowCode adressiert man mit dem openclaw-message-send-Node die Agent ID coding-agent und legt den Task-Payload auf msg.payload. Den kompletten Aufbau — inkl. Gateway-Verbindung aus dem Container — zeigt der Blog-Beitrag OpenClaw-Agenten aus ProcessCube® LowCode ansprechen.

Provider-Erkennung

Der Provider wird automatisch an der Repo-URL erkannt:

Provider	Erkennung	CLI
GitHub	`https://github.com/owner/repo` (oder Kurzform `owner/repo`)	`gh`
Azure DevOps	`https://dev.azure.com/org/project/_git/repo`	`az`

Ablauf

Draft-PR wird erstellt

Der coding-agent legt einen Draft-PR an und setzt Assignee und Reviewer.

Sofortige Antwort

Der Agent antwortet umgehend mit sessionId und prUrl — noch bevor die Implementierung beginnt.

Implementierung

Der coding-agent-worker implementiert den Task im Worktree. Er setzt den PR auf Draft, während er arbeitet, und auf Ready, wenn er fertig ist.

Review-Schleife

Der coding-agent-pr-watcher pollt den PR und leitet neue Review-Kommentare an den Worker weiter — solange der PR offen ist.

Weil der Agent früh antwortet (nach dem Anlegen des Draft-PRs), eignet sich der Aufruf gut für reaktive Integrationen — etwa aus einem LowCode-Flow oder einem BPMN-Prozess. Den Fortschritt verfolgt man danach direkt am PR.