ki-copilot/03-alltag-und-workflows.md

Kapitel 3

Alltag und Workflows – Explore, Plan, Code, Verify, Commit

Kern in einem Satz: Produktive Sessions folgen einem Zyklus – erst verstehen, dann planen, dann ändern, dann verifizieren und committen – statt „ein Prompt, alles auf einmal“.

---

3.1 Der Zyklus

Ein Prompt, der teurer wird als fünf kurze: „Bau atomare Writes in store.py, Tests, README, und öffne einen PR.“ Der Agent startet breit, rät Architektur, flickt Tests, verbrennt Kontext – und du reviewst einen Diff, den niemand mehr in Phasen zerlegen kann.

Der Zyklus ist keine Bürokratie. Er ist die Fehlerbremse gegen genau diesen Impuls.

Phase	Ziel	Typische Mittel
Explore	Landkarte	Read-only-Prompts, @datei, „ändere nichts“
Plan	Vorgehen freigeben	Plan Mode (Shift+Tab / /plan), Plan reviewen
Code	Umsetzen	enger Scope, Tests mitdenken
Verify	Realität prüfen	Test-Command aus Instructions, /diff
Commit	nachvollziehbar speichern	Message, die ein Mensch in sechs Monaten versteht

Faustregel: Mehr als eine Datei oder unklare Architektur → erst Plan freigeben, dann Code. Agenten akkumulieren Fehler in langen Ketten: Eine falsche Annahme in Minute 2 wird in Minute 20 zum Refactor an der falschen Stelle.

{width=90%}

Scope eng halten ist hier der Alltagshebel: pro Prompt Dateien, Done-Kriterium und Stop-Regel nennen – nicht „mach das Feature irgendwie fertig“.

Kurzform zum Mitnehmen (ohne Slash-Pflicht): Anhang A.5.

---

3.2 Explore – ohne Nebenwirkungen

Jetzt selbst machen (todo-cli):

cd beispiele/todo-cli
copilot

Karten das Repo: Einstiegspunkt, Persistenz, Tests.
Nenne die drei riskantesten Stellen für Datenverlust.
Ändere keine Dateien.

Ohne „ändere nichts“ startet Explore oft mit Aufräumen – und vermischt Lernen mit Side-Effects.

Gute Explore-Fragen:

• „Wo wird der Store geladen und gespeichert?“
• „Welche Tests decken save ab – und welche fehlen?“
• „Erkläre @todo/store.py in einfachen Worten.“

Schlechte:

• „Optimier alles“ – kein Ziel, maximaler Diff
• „Räum mal auf“ – subjektiv, endlos, review-feindlich

Gutes Explore: viele Reads, wenig oder keine Writes, am Ende eine Landkarte, die du gegenprüfen kannst.

---

3.3 Plan Mode – bevor Dateien fallen

Plan Mode lenkt den Agenten auf Analysieren und Strukturieren, statt sofort zu editieren.

Umschalten:

• Shift+Tab – wechselt zwischen Standard, Plan und Autopilot (Statusleiste beachten)
• oder Slash: /plan …

/plan Atomare Writes in store.py inkl. Testfällen.
Kein Code am Projekt, bis ich den Plan freigebe.

Laut Doku (Best Practices / Command Reference, Stand Mitte/Ende 2026):

• Copilot analysiert, stellt oft Rückfragen, erzeugt einen strukturierten Plan (Checkboxen)
• Plan liegt typisch als plan.md im Session-Ordner
• Freigabe, dann Implementierung
• Plan Mode blockt in der Regel Projekt-Edits; der Plan selbst darf im privaten Plan-Workspace liegen
• Shell/MCP mit unklarem Effekt sind kein luftdichtes Lockdown – denke „Änderungen brauchen Review“, nicht „absolut read-only“

Plan im Editor ansehen/editieren (wo angeboten, z. B. Ctrl+Y – Labels können driften): lies den Plan wie einen Mini-RFC.

Guter Plan enthält:

1. Betroffene Dateien
2. Schritte in Reihenfolge
3. Verify-Command (der echte aus den Instructions)
4. Nicht-Ziele

Skeleton zum Handoff: vorlagen/PLAN.md.skeleton.md.

So ungefähr sieht die Freigabe im Terminal aus (Labels können driften):

{width=90%}

Wann Plan	Wann überspringen
multi-file, Refactor, neues Feature	Einzeiler, Tippfehler, eine Log-Zeile
unklare Architektur	Diff in einem Satz beschreibbar
Daten-/Security-Risiko	reines Docs-Update mit klarem Scope

Nach der Freigabe oft: Plan annehmen und umsetzen – ggf. direkt in Autopilot (UI-Option „Accept plan and build on autopilot“, Formulierung driftet).

---

3.4 Autopilot – wann ja, wann nein

Autopilot = lokal, in dieser Session: der Agent arbeitet in mehreren Schritten weiter, bis die Aufgabe als erledigt gilt (oder Limit/Abbruch). Das ist nicht dasselbe wie /fleet (parallele Subagents) und nicht dasselbe wie /delegate (Cloud Agent / PR auf GitHub).

{width=90%}

Start:

• interaktiv: Shift+Tab bis „autopilot“
• Startflag: --autopilot (ggf. mit -p "…")
• Limit: --max-autopilot-continues N

# Programmatisch mit Limit – zuerst enge Allowlist, kein YOLO
copilot --autopilot --max-autopilot-continues 10 \
  --allow-tool='shell(pytest)' \
  --allow-tool='write' \
  --deny-tool='shell(rm)' \
  --deny-tool='shell(git push)' \
  -p "Setze den freigegebenen Plan um: atomare Writes + Tests. Stoppe bei roten Tests nach 2 Fix-Versuchen."

Wenn freigabepflichtige Tools den Lauf abbrechen und die Umgebung isoliert ist (Sandbox, kein Prod-Zugang): erst dann --yolo / --allow-all erwägen – nach Deny-Baseline und nie als Default-Alias.

Autopilot ja	Autopilot nein
klarer Plan, wohldefinierte Schritte	offene Exploration
Tests schreiben, CI-Fixes, Batch	Feature ohne Akzeptanzkriterien
du willst fortlaufend zusehen können	du brauchst jede Entscheidung mitzusteuern

Permissions: Autopilot läuft reibungsloser mit ausreichenden Freigaben; ohne sie werden freigabepflichtige Tools oft automatisch verweigert und der Lauf bricht ab. Genau deshalb gilt: Deny/enge Allowlist und Sandbox denken, bevor YOLO – und YOLO nur, wenn CWD, Trust und Risiko passen.

Credits: jeder autonome Schritt verbraucht AI Credits ohne dein Zwischen-OK. /usage im Blick behalten.

Optional sticky: Setting stayInAutopilot (Default oft an) – nach Task-Ende im Mode bleiben oder zurück in interaktiv. Details: Autopilot-Konzeptdoku.

---

3.5 Kontext steuern: @, #, !, Anhänge

Syntax	Wirkung
@pfad/zur/datei	Dateiinhalt in den Prompt-Kontext
#123 / Issue/PR	GitHub-Issue oder PR referenzieren (eingebaute GitHub-Anbindung)
!befehl	Shell ohne Modell – direkt lokal
Bilder/PDF	per @datei, Drag&Drop oder Clipboard – wenn das Modell Vision unterstützt

Beispiele:

Erkläre @todo/store.py – keine Änderungen.

Implementiere die Akzeptanzkriterien aus #42.
Nur Dateien unter todo/ und tests/.

!git status
!pytest -q

! ist nützlich, wenn du den Output selbst sehen und dann dem Agenten die Essenz geben willst – ohne Tool-Runde. Für GitHub-Arbeit im Chat: Issue/PR mit # einbinden statt den Text zu kopieren.

Unterstützte Anhangstypen (Doku): u. a. JPEG, PNG, GIF, WEBP, PDF, HEIC/HEIF – „implementiere dieses Mockup: @mockup.png“.

Browse in der TUI: In interaktiven Sessions gibt es oft Tabs bzw. Views, um Issues, PRs und Gists zu durchstöbern, ohne das Terminal zu verlassen (How-to Browsing issues, pull requests, and gists). Praktisch für Überblick; für gezielte Arbeit am Ticket bleibt #123 im Prompt die engere Variante.

Während der Agent denkt – Steering:

Steering ist der Alltagshebel, wenn der Agent abbiegt: Du schickst Folge-Nachrichten während der Arbeit, und der Agent nimmt sie in den laufenden Task auf – du musst nicht alles abbrechen und neu starten.

Mittel	Wirkung
Steering-Nachricht	Kurs korrigieren („nur todo/, kein README-Rewrite“)
Queue (Ctrl+Enter / Ctrl+Q – Labels driftfähig)	Nachricht einreihen, während der Agent busy ist
Stop (Esc)	laufenden Turn abbrechen
Deny + Inline-Feedback	Tool ablehnen und sagen, was stattdessen (Kap. 1)

Beispiel-Steering, während der Agent noch an Tests bastelt:

Stop – kein Refactor von cli.py. Nur store.py und tests/.

Details und exakte Shortcuts: Command Reference; Labels können je Version leicht abweichen.

---

3.6 Code – enge Aufträge

Setze den freigegebenen Plan um.
Nur todo/store.py und tests/test_store.py.
Nach jeder logischen Einheit: pytest -q.
Stoppe und berichte, wenn ein Test rot bleibt und du >2 Fix-Versuche brauchst.

Stop-Regel bremst Loops: Derselbe Fix mit Variationen frisst Runden; nach zwei Fehlversuchen ist menschliche Kurskorrektur billiger.

Feature-Beispiel: todo rm

Feature: `todo rm <id>` löscht einen Eintrag.
- argparse-Subcommand
- Exit 1 wenn ID fehlt
- Tests
- README eine Zeile
Kein Refactor außerhalb dieses Scopes.

Jede Bullet ist ein Check im Review. „Mach rm“ ohne Exit-Codes endet in halbgaren CLIs.

---

Lokal-first: der Agent ohne PR

Kern: Eine Session ist fertig, wenn Explore–Plan–Code–Verify greifen – auch ohne Remote, Issue oder Pull Request. GitHub-Flow ist Erweiterung, nicht Eintrittsschwelle.

Du brauchst kein Issue und keinen PR, damit der Agent nützlich ist. Typische Sessions:

Session-Typ	Typischer Abschluss	Remote nötig?
Feature/Fix nur lokal	grüne Tests, optional Commit	nein
Greenfield / PoC im CWD	lauffähiger Skelett-Stand, README	nein
Debug-Schleife	Repro + Fix + Verify	nein
Docs / Refactor ohne Merge-Druck	Diff gelesen, Tests grün	nein
Issue → Branch → PR	/pr create, menschlicher Merge	ja (GitHub)

Dieselben Hebel, weniger Oberfläche: Scope eng, Plan bei multi-file, Diff lesen, Deny vor YOLO. Weg fallen #issue, /pr, /delegate – und oft Push-Risiken. Bleiben: Permissions, Instructions, Verify-Command.

Implementiere atomare Writes in store.py wie im freigegebenen Plan.
Nur store.py und tests. pytest -q nach dem Fix.
Kein Commit, kein Push – ich prüfe den Diff selbst.

Sitzt der lokale Strang, lohnt der GitHub-Alltag (nächste Abschnitte): Commit-Message, /review, /pr, optional Cloud. In der Mikrogeschichte 3.12 bleibt der Kern bis Verify lokal; Remote kommt erst mit Commit und /pr.

---

3.7 Verify und /diff – der Schritt, den viele überspringen

Mindest-Verify:

pytest -q
# oder der Command aus .github/copilot-instructions.md

In der Session:

Fasse Diff und Testergebnis zusammen. Nenne Restrisiken in 3 Bullets.

/diff: interaktiver Diff der Änderungen (Working Tree; bei sauberem Tree oft Branch-Diff – experimentell je Version). Shortcuts in der Diff-Ansicht: Navigation, Kommentare, Whitespace-Toggle – siehe ? / Command Reference.

Diff lesen vor Commit ist derselbe Hebel wie in Kapitel 1 und 2 – anderer Moment. Nach 20 Minuten Agent-Arbeit willst du „fertig“ sein. Genau dann rutschen Secrets, Debug-Prints und Scope-Creep durch.

git status
git diff

Verify ist die Realitätsschicht: Der Agent berichtet oft Optimismus; Tests und Diffs korrigieren das. Im Prompt den konkreten Command nennen – „teste bitte“ ist zu vage und öffnet Command-Halluzination (Kapitel 2).

Agentic Review: /review

Nach grünen Tests und vor Commit/PR lohnt oft eine zweite Meinung im Terminal – ohne dass du dafür GitHub.com öffnest:

/review
/review Fokus: Bugs und Sicherheitslücken in store.py und tests/. Style-Nörgeln auslassen.

/review startet den built-in Code-Review-Agent (Subagent mit eigenem Kontext). Er analysiert Änderungen, fragt ggf. nach Shell-Tools (Diff lesen) und liefert high-signal Findings. Das ist kein Ersatz für /diff und menschlichen Merge – es ist ein zusätzlicher Filter vor dem Push.

Wann /review	Wann nicht
multi-file Feature, Auth/Persistenz, vor PR	Tippfehler-Einzeiler
du willst Bias der Implement-Session brechen	du hast den Diff noch nicht gelesen
Security-Fokus (oder Custom Security-Agent, Kap. 5)	du brauchst Code-Änderungen – dann normaler Prompt

Programmatisch (CI/Skript, eng begrenzt):

copilot -p '/review the changes on this branch compared to main. Focus on bugs and security.' \
  -s --allow-tool='shell(git:*)' --deny-tool='write' --no-ask-user

Wenn der Agent daneben gelegen hat: Rollback mit /undo bzw. /rewind oder Esc zweimal – Vertiefung Kapitel 7.

---

3.8 Commit und GitHub-Alltag

Erstelle einen Commit mit klarer Message (Conventional Commits, wenn im Repo üblich).
Stage nur relevante Dateien. Kein push, bis ich es sage.

Schlechte Message: update · Bessere: fix(store): atomic save via temp file and replace

GitHub-Tag über die CLI: Issue mit #42 → Plan → Code → Verify → /diff → optional /review → Commit → /pr → menschlicher Merge.

/pr – Lifecycle ohne Terminal-Wechsel

Statt nur Freitext „erstell einen PR“ bietet die CLI den Slash-Command /pr (Repo muss auf GitHub liegen; Subcommands beziehen sich auf den aktuellen Branch):

Befehl	Zweck	Kann committen/pushen?
/pr / /pr view	Status des PRs zum Branch	nein
/pr view web	PR im Browser öffnen	nein
/pr create	PR anlegen (oder updaten)	ja (push)
/pr fix feedback	Review-Kommentare umsetzen	ja
/pr fix conflicts	Base syncen, Konflikte lösen	ja
/pr fix ci	rote Checks diagnostizieren und fixen	ja
/pr fix / /pr fix all	feedback → conflicts → ci	ja
/pr auto	ggf. create, dann Fix-Schleife bis grün	ja

/pr create
/pr create Prefix im Titel: 'todo-cli: '
/pr fix ci focus on test failures

/pr create pusht fehlende Commits und nutzt PR-Templates, wenn vorhanden. Merge-Strategie bei Konflikten: Setting mergeStrategy (rebase | merge) in User- oder Repo-settings.json – sonst fragt die CLI.

Achtung: /pr fix … und besonders /pr auto dürfen committen und pushen (nach Permission-Prompts, sofern nicht vorab erlaubt). Das ist Autopilot für den PR-Strang – Deny für destruktive Shell behalten, Diff lesen, Branch Protection und menschlicher Merge bleiben Pflicht. /pr auto ist kein Freifahrtschein für ungeprüfte Production-Merges.

Freitext-PR bleibt möglich, wenn du mehr Kontrolle im Prompt willst:

Erstelle einen PR gegen main.
Titel und Body aus den Commits und #42.
Checkliste im Body: Tests, Diff-Risiken, Nicht-Ziele. Kein Merge.

Commit ist lokal und reversibel; Push teilt; PR startet CI – die Stufen getrennt halten.

---

3.9 Modelle und Credits

/model

Situation	Tendenz
Architektur, hartes Debugging, nuancierter Refactor	stärkeres / teureres Modell
Routine-CRUD, klare Tests	günstigeres / schnelleres Modell
Unsicher / Rate-Limits	Auto (wo angeboten)

Namen und Defaults driften mit dem Angebot. Mid-Session wechseln ist erlaubt: Plan stark, Bulk günstig – oder Review mit zweitem Modell.

Erweiterte Modell-Fähigkeiten (wo das gewählte Modell sie anbietet, Stand Docs):

• Extended Context (z. B. bis ca. 1 Mio. Tokens) – große Codebases, lange Docs; spürbar teurer
• Reasoning-Level – tiefere „Denk“-Phase vor der Antwort; ebenfalls credit-intensiver

Default: normales Fenster und normales Reasoning. Extended/hoch nur, wenn die Task es wirklich braucht – nicht als Alltags-Default.

Credits und Limits:

Mittel	Zweck
/usage	Credits, Dauer, Token-Breakdown der Session
/limits set max-ai-credits N	Soft-Cap pro Session (Preview; Doku: oft > 30 sinnvoll)
/limits unset	Cap entfernen
--max-ai-credits=N	dasselbe programmatisch

/limits set max-ai-credits 50

copilot -p "…" --max-ai-credits 40 --allow-tool='shell(pytest)' --deny-tool='write'

Soft-Limit: die laufende Antwort darf noch fertig werden, danach stoppt der Agent und fragt interaktiv nach Reset – programmatisch endet der Lauf. Details und Drift: How-to Setting an AI credit session limit.

---

3.10 /delegate vs. lokal

	Lokal (Session / Autopilot)	/delegate (Cloud Agent)
Wo	dein Rechner, aktuelle CWD	remote auf GitHub, Branch + Draft-PR
Wann	Debug, Exploration, enge Iteration	asynchrone / tangentiale Tasks
Du	steuerst live, /diff, Steering	arbeitest weiter; Review am PR
Eher	Kern-Feature, interaktives Debug	Docs, paralleles Modul, Laptop darf zu

{width=90%}

/delegate Ergänze API-Integrationstests und fixe rote Edge Cases.

Oder Prefix & (wo unterstützt). Typisch: Checkpoint-Commit, Cloud Agent öffnet Draft-PR, Link zu PR und Agent-Session.

Autopilot ≠ Delegate: einer bleibt lokal multi-step, der andere schiebt Arbeit in die Cloud – nacheinander sinnvoll, nicht synonym.

---

3.11 /fleet – nur der Hinweis

/fleet … erlaubt parallele Subagent-Ausführung. Kostet Credits, erhöht Review-Komplexität. Detail: Kapitel 5. Hier reicht: Fleet ist Parallelität – kein Ersatz für Plan und Diff-Disziplin.

---

3.12 Mikrogeschichte: von Issue zu PR (todo-cli)

Die Geschichte startet mit GitHub (#17), weil der End-to-End-Strang so greifbar ist. Bis einschließlich Verify (pytest grün, /diff) ist das derselbe lokale Agent-Zyklus wie unter „Lokal-first“ – erst ab Commit/PR kommt die Remote-Schicht dazu.

Annotation: > = du, Rest = Agent sinngemäß.

> Lies #17 (Feature: todo rm <id>). Fasse Akzeptanzkriterien in 5 Bullets.
  Ändere nichts.

Agent: [Bullets: Subcommand, Exit 1, Store-Methode, Tests, README]

> /plan Setze #17 um. Nur todo/, tests/, README. Verify: pytest -q.

Agent: [Plan mit Dateien, Schritten, Nicht-Zielen]

> Plan ist ok. Scope eng halten. Umsetzen bis pytest -q grün.

Agent: [Edits, pytest -q → green]

> /diff

[Du liest den Diff – kein Scope-Creep, keine Secrets]

> /review Fokus Bugs und Datenverlust. Kein Style-Nörgeln.

> Commit mit klarer Message. Kein push, bis ich „push“ sage.

> /pr create

Wenn der Diff sauber ist: push (über /pr create oder bewusst selbst) und Draft-PR. Follow-up asynchron z. B. /delegate … oder /pr fix ci bei roten Checks.

Weich vs. hart im Alltag: Instructions sagen „pytest -q“ und „kein Force-Push“; Deny-Flags bremsen git push/rm im Flow. Zyklus = Custom Instructions für Qualität, Policy für Sicherheit.

Session-Hygiene kurz: Themenwechsel → /new; Kontext voll → /context / /compact (Kap. 7); fortsetzen → copilot --continue oder /resume; Fehlschlag rückgängig → /undo (Kap. 7).

---

Checkliste Alltag

• Explore mit „keine Änderungen“, wenn du nur lernen willst
• Plan Mode bei multi-file; Plan reviewen (Dateien, Nicht-Ziele, Verify)
• Code mit Scope + Stop-Regel; Tests mit Command aus den Instructions
• /diff oder git diff vor Commit
• Session darf lokal enden (grün + Diff) – Remote/PR ist optional, nicht Pflicht
• Optional /review vor PR (Bugs/Security)
• PR über /pr create bzw. bewussten Freitext – Merge menschlich
• Autopilot nur bei klarem Plan und bewusstem Permission-Profil
• /pr auto / /pr fix nur mit Deny-Baseline und Diff-Disziplin
• /delegate für asynchrones Nebenbei, nicht als Review-Ersatz
• /usage und ggf. /limits bei langen Sessions

Symptom	Gegenmittel
Riesen-Diff ohne Struktur	Plan Mode + engere Prompts
Agent „optimiert“ Nebenmodule	Nicht-Ziele im Plan; Steering
Autopilot-Schrott	kein Autopilot ohne Plan; Limit setzen; /undo
Credits weg	/usage; /limits; Fleet/Autopilot dosieren
PR-Fix-Schleife eskaliert	/pr fix abbrechen; Diff lesen; Scope enger

Jetzt selbst machen

cd beispiele/todo-cli
copilot

1. Explore store.py (read-only).
2. /plan für atomare Writes oder todo rm.
3. Plan freigeben, umsetzen, pytest -q.
4. /diff lesen – hier darfst du lokal stoppen (Session fertig).
5. Optional: /review, Commit-Message, bewusst /pr create oder push erst auf Kommando.

---

Was du jetzt kannst

• Den Zyklus Explore → Plan → Code → Verify → Commit bewusst steuern
• Lokal-first arbeiten: Session ohne Remote/PR als vollwertig behandeln
• Plan Mode bedienen und Pläne vor der Freigabe prüfen
• Autopilot von /delegate und /fleet unterscheiden und situationsgerecht wählen
• Kontext mit @, #, ! und Anhängen gezielt füttern
• Während der Arbeit steuern (Steering, Queue, Esc, Deny-Feedback)
• /review und /pr im GitHub-Alltag einsetzen – inkl. Risiken von fix/auto
• Modelle, Extended Context/Reasoning und Credits (/usage, /limits) handhaben
• Einen Feature-Strang von Issue bis PR über die CLI fahren

Nächste Schritte

• Kapitel 4: Settings-Hierarchie, Trusted Dirs, Sandbox, multi-repo
• Kapitel 5: MCP, Skills, Hooks, Custom Agents, Plugins, Fleet im Detail
• Kapitel 7: Rollback, Remote Control, Chronicle/Session-Daten
• Vorlage vorlagen/PLAN.md.skeleton.md für Handoffs nutzen
• Session-Rezepte Plan und Diff/Review: beispiele/rezepte/02-plan-mode.md, beispiele/rezepte/03-diff-und-review.md

Primärquellen: Using Copilot CLI, Best practices, Autopilot, Delegate tasks, Agentic code review, Manage pull requests (/pr), Command Reference.