Cursor Agent per CLI – der Agent wird zum Job

Datum: 2026-01-15

Chat ist Werkstatt – CLI ist Fabrik

In der IDE fühlt sich KI-Arbeit natürlich an: Frage stellen, Diff annehmen, weiter. Für Teams, Nachtjobs und CI reicht das nicht. Was im Chat passiert, ist schwer zu automatisieren: kein stabiler Exit-Code, kein Cron, kein Watchdog, keine reproduzierbaren Logs auf der Festplatte.

Cursor Agent per CLI (`cursor agent`) schließt diese Lücke: derselbe Agent-Kern wie im Editor, aber als Shell-Job mit klarem Anfang und Ende.

Das Problem

Wer nur tippt, hat einen Assistenten. Wer Jobs definiert, hat eine Fabrik.

Das Pattern

`cursor agent` läuft headless in der Shell – mit Prompt, Projektkontext und definiertem Ende. Du erhältst:

Merksatz: Chat = explorativ. CLI = produktiv.

So sieht es bei uns aus

Unsere `start-vendor-*`-Scripts kapseln den CLI-Agent-Aufruf:

Der Entwickler startet ein Script – nicht einen 500-Zeilen-Prompt. Intern: Orchestrator → Steps → `cursor agent` mit Subagent-Prompt aus `cursor-rules/agents/`.

Architektur: Script → Orchestrator → Agent

start-vendor-*.php
    ↓
CLIOrchestrator (Steps 001…00N)
    ↓
Step-Services (Logs, Validierung, Agent-Aufruf)
    ↓
cursor agent (headless)
    ↓
Subagent + Skills + Rules

Jedes `start-vendor-*.php` hat ein Briefing unter `briefing/CLIOrchestrator/…` – Briefing-First gilt auch für CLI.

Exit-Code und Logs

001. Exit 0 – Workflow/Loop konvergent oder erfolgreich abgeschlossen.

002. Exit ≠ 0 – Fehler, Abbruch, offene Failures (je nach Script dokumentiert).

003. Logs unter `logs-start-vendor-*` – ein Ordner pro Lauf, nachvollziehbar im Team.

Ohne Exit-Code ist Automatisierung Glücksspiel. Ohne Logs ist Post-Mortem unmöglich.

Andere CLIs – gleiches Prinzip

Nicht nur Cursor: Claude Code, Aider, OpenCode und vergleichbare Tools folgen demselben Muster:

- stdin/stdout

- Exit-Code

- Logfile

- Anbindung an Shell-Pipelines

Agentic Engineering ist tool-agnostisch an der Grenze zur Shell – die Projekt-Steuerung (Rules, Skills, Subagents) bleibt im Repo.

Anti-Patterns

001. Alles im Chat – Nacht-Qualität hängt von Motivation ab.

002. CLI ohne Orchestrator – Ein Riesen-Prompt in `cursor agent` ohne Steps → nicht wartbar.

003. Keine Logs – „Hat letzte Nacht was gemacht?“ → unbekannt.

004. Exit-Code ignorieren – CI grün obwohl Agent FAILED meldete.

005. Secrets im Prompt – API-Keys in Shell-History; nutze `config.env` und Rules.

Workflow-Beispiel

# Einmaliger Subagent bis konvergent
php start-vendor-subagent-ralph-loop.php subagent-check-translations

# Kompletter Development-Workflow
php start-vendor-development-workflow.php

Lokal interaktiv starten, in Produktion per Cron mit gleichen Befehlen – dieselbe Fabrik.

Häufige Fragen

Brauche ich dafür Cursor Pro?

Details zum Lizenzmodell auf der Cursor-Website; für Automatisierung brauchst du einen Weg, `cursor agent` non-interactive zu betreiben.

Ersetzt CLI den IDE-Chat?

Nein – Exploration bleibt im Chat. Wiederholbare Qualität läuft über CLI.

Wie verbinde ich das mit Ralph-Loop?

`start-vendor-subagent-ralph-loop.php` ist genau diese Kombination: CLI + Subagent + Marker.

Verwandte Beiträge

Takeaway

Was im Prompt passiert, ist schwer steuerbar – was in der Shell läuft, schon. Cursor Agent per CLI macht aus der KI einen Job: reproduzierbar, loggbar, CI-fähig. Wer Agentic Engineering ernst meint, verlagert Wiederholbares aus dem Chat in `start-vendor-*.php`.