ki-copilot/06-teams-enterprise-ci.md

Kapitel 6

Teams, Enterprise und CI – wenn aus „mein Agent“ „unser System“ wird

Kern in einem Satz: Im Team zählen wiederholbare Standards, nicht überstimmbare Policies und enge Automationen – nicht der cleverste Einzel-Prompt.

---

6.1 Team-Standards etablieren

Onboarding-Tag 1, 14:30: Neue Kollegin clont das Repo, startet copilot – und kämpft zwei Stunden mit anderen Test-Commands, anderen Allowlists und einem MCP-Server, den nur du lokal hast. Slack-Thread: „Bei mir läuft Copilot anders.“ Das ist kein Modell-Problem. Es fehlen committed Artefakte.

Solo optimiert auf persönlichen Flow. Teams optimieren auf Vorhersagbarkeit: Jeder Laptop, jeder PR, jeder Onboarding-Tag soll denselben Agenten-Rahmen sehen.

Was gehört mindestens ins Git?

Die Tabelle ist die Checkliste für „Clone → gleiche Leitplanken“ – nicht die vollständige Enterprise-Policy.

Artefakt	Zweck	Warum im Git
.github/copilot-instructions.md	gemeinsame Fakten (Build, Test, Immer/Nie)	reviewbar, versioniert
.github/instructions/**/*.instructions.md	path-scoped Normen	modular wachsbar
.github/copilot/settings.json	geteilte Settings (wo sinnvoll)	gleiche Leitplanken
.github/hooks/*.json	erzwungene Lifecycle-Skripte	Guardrails für alle
.github/skills/**/SKILL.md	Team-Workflows on-demand	Rituale ohne Kontext-Romane
.github/agents/*.md	Repo-Custom-Agents	Spezial-Rollen im Projekt
kurzer Abschnitt in README	Onboarding „AI / Copilot CLI setup“	Menschen finden den Einstieg

Diese Woche: Team-Instructions + enge Deny-/Allow-Konvention committen. Skills, Hooks und Agents folgen, sobald der Nutzen klar ist.

Ein genialer Prompt stirbt mit dem Chat. Eine Zeile in .github/copilot-instructions.md und ein Verify-Skill leben in jedem Checkout.

Onboarding-Reibung ist das Messgerät: Wenn ein neuer Dev „zwei Tage braucht, bis Copilot bei mir so läuft wie bei euch“, fehlen committed Artefakte. Zielbild: Clone → Install → Trust → Session mit denselben Test-Commands und Deny-Regeln wie der Rest des Teams. Alles, was nur in Slack-Threads lebt, ist kein Standard.

Review-Pflicht – auch (und gerade) bei Agent-Diffs

Agenten multiplizieren Tempo. Review skaliert nicht automatisch mit.

Regel	Warum
Menschlicher Review vor Merge	Ownership bleibt bei dir
Kleine PRs bevorzugen	Review-Qualität > Agent-Tempo
Diff lesen, nicht nur grünen CI-Haken	Der Agent kann „korrekt“ und trotzdem falsch sein
Kein Auto-Merge durch den Agenten	Accountability bleibt menschlich

Vorlage für die Team-Baseline: vorlagen/copilot-instructions.team.md → Zielpfad .github/copilot-instructions.md.

Conventions für Plan und Delegate

Ohne gemeinsame Sprache driftet der Alltag: der eine YOLO-t Features, die andere delegiert alles in die Cloud.

Situation	Team-Convention (Startpunkt)
Multi-file / unklare Architektur	Plan Mode (Shift+Tab / /plan) → Plan freigeben → Code
Enge, bekannte Fixes	Direkt arbeiten; Diff lesen
Tangentiale Arbeit (Docs, Neben-Repo, asynchron)	/delegate → Cloud Agent → PR reviewen
Kernfeature mit interaktivem Debug	lokal in der CLI-Session
Nach Agent-Änderungen	/diff, Tests/Lint aus den Instructions, menschlicher Merge

Haltet die Convention kurz in den Instructions oder im Team-README – nicht als 20-Seiten-Playbook, das niemand liest.

Skill-Bibliothek (Beispiele)

.github/skills/
  verify/SKILL.md
  review-pr/SKILL.md
  add-migration/SKILL.md

Verify-Vorlage im Buch: vorlagen/skills/verify/SKILL.md.

Review und Implement mischen Bias. Getrennte Rollen (oder Sessions) halten Findings ehrlich – z. B. Implement in einer Session, Review mit /review oder dem Security-Reviewer-Agent in einer anderen.

Onboarding-Checkliste für neue Dev-Laptops

1. Copilot CLI installieren (siehe Install-Doku / Kapitel 01)
2. copilot login mit Org-Konto (bzw. freigegebenem Zugang)
3. Repo clonen, Trusted directory bewusst wählen
4. MCP nur für freigegebene Server authentifizieren
5. copilot init nicht blind committen – Team-Instructions sind Source of Truth

copilot init optimiert auf dieses Checkout und erfindet gern Commands. Die Team-Datei ist das Ergebnis von Reviews – nicht der erste Generator-Output eines Neulings.

---

6.2 Org- und Enterprise-Custom-Agents

Kern: Org-Agents sind gemeinsame Spezial-Personas – versioniert im Org-Repo, nicht als privates ~/.copilot/agents-Glück.

Custom Agents kannst du auf mehreren Ebenen definieren (Stand Docs Mitte/Ende 2026):

Ebene	Ort (typisch)	Scope
User	~/.copilot/agents/	alle deine Projekte
Repository	.github/agents/	dieses Repo
Organisation	/agents/ im Org-Repo .github oder .github-private	alle Mitglieder der Org
Enterprise	/agents/ im von der Enterprise designierten .github-private (Org als Source)	Repos der Enterprise

Org-Setup (Konzept): Org-Level-Agents liegen im Verzeichnis /agents der Org-Repositories .github oder .github-private. Beide Varianten machen die Agents für Mitglieder verfügbar – auch wenn sie keinen direkten Zugriff auf das Config-Repo selbst haben. Details und Setup-Schritte: Preparing custom agents in your organization.

Namenskonflikte (laut CLI-Doku): System-/Built-in schlägt Repo; Repo schlägt Org. Bei Unsicherheit aktuelle Docs und /agent in der Session prüfen.

Praxis:

• Security-Reviewer, Docs-Writer, Migration-Helper als wenige Org-Agents
• Repo-Agents nur, wenn das Projekt wirklich eigene Workflows hat
• Agents reviewen wie Code: Prompt, Tool-Subset, Beschreibung

Repo-Vorlage: vorlagen/agents/security-reviewer.agent.md.

Feature-Status kann Preview sein – bei Abweichungen gelten die aktuellen GitHub-Docs, nicht dieses Buch.

---

6.3 MDM, Managed Settings und Bypass sperren

Managed Settings sind das Compliance-Modell: Org-Regeln dürfen nicht pro Entwickler-Pref aushebelbar sein.

Settings-Hierarchie (später überschreibt früher – grob, Stand Docs):

1. Built-in Defaults
2. MDM / managed settings
3. User: ~/.copilot/settings.json
4. Repo: .github/copilot/settings.json
5. Local: .github/copilot/settings.local.json (gitignore)
6. Environment Variables
7. Command-line Flags

Ausführlich: Kapitel 4 und copilot help config.

permissions.disableBypassPermissionsMode

Der kritische Governance-Hebel für YOLO:

// enterprise-managed / MDM / managed settings (Pfad je Auslieferung)
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Wirkung (laut Docs): Wenn der Wert "disable" ist, werden Allow-all-/Bypass-Flags unterdrückt – u. a. --allow-all-tools, --allow-all-paths, --allow-all-urls, --allow-all, --yolo. Ein MDM-Wert "disable" gewinnt gegenüber User-Overrides.

Enterprise-managed Settings greifen u. a. über die konfigurierte Source-Org und deren .github-private (bzw. den dokumentierten managed-settings-Pfad). Rollout: Pilot-Laptops → prüfen → breit ausrollen. UI-Pfade und exakte Delivery-Formen driften – Admin-Doku und Enterprise-AI-Controls sind Source of Truth.

Achtung: Ohne Bypass-Sperre kann ein Entwickler mit --yolo dieselbe Session-Macht haben wie mit Root-Shell-Gewohnheit. Deny und Managed ersetzen keine Kultur – sie setzen die harte Decke.

Für Team-Leads ohne MDM: Zuerst Repo-Instructions + Review-Pflicht + enge CI-Allowlist. Managed-Policy kommt, sobald „jeder Laptop ist eine Schneeflocke“ Compliance bricht.

Weitere Hebel in Repo/User-Settings (nur Keys setzen, die copilot help config und die Doku kennen):

{
  "deniedUrls": ["*.evil.example"],
  "allowedUrls": ["*.github.com", "docs.github.com"],
  "companyAnnouncements": [
    "Plan Mode bei multi-file. Diff lesen. Kein YOLO ohne Team-OK."
  ]
}

Hinweise und Flag-Muster: vorlagen/settings.permissions-hints.md.

---

6.4 Programmatic Mode und CI/CD

Der verlockende PR-Bot: Jeder Diff bekommt automatisch einen Kommentar. Drei Sprints später: Review-Lärm, Credit-Rechnung, und niemand traut den Findings – weil der Bot auch bei Typos „Critical“ schreibt und mit zu breiten Rechten läuft. CI ist mächtig. Ohne Grenzen wird daraus teure, laute und manchmal gefährliche Automation.

Welches CI-Muster passt?

Muster	Beschreibung	Risiko
PR-Review-Assist	Diff analysieren, Kommentar/Artifact	Lärm, False Positives
Issue-Triage	Labels/Repros vorschlagen	falsche Labels
Generative Tasks	Tests/Docs in Branch	ungeprüfte Diffs
Gate (vorsichtig)	enger Prompt + Menschen-Review	nie blind mergen

Start klein: Ein enger Review-Prompt, least-privilege Token, kein Auto-Merge.

Achtung: Kein Auto-Merge durch den Agenten. Ownership und Accountability bleiben menschlich – CI-Agenten sind Assistenten, keine Release-Manager.

Programmatic: copilot -p

{width=90%}

copilot -p "Erkläre die letzten Testfehler. Keine Dateiänderungen." \
  -s \
  --allow-tool='shell(pytest)' \
  --allow-tool='shell(git status)' \
  --allow-tool='shell(git log)' \
  --deny-tool='write' \
  --deny-tool='shell(rm)' \
  --deny-tool='shell(git push)' \
  --no-ask-user

Live-Beispiel (Review-Prompt, Deny write — Ausgabe gerendert, kein Auto-Merge):

{width=90%}

Flag / Muster	Rolle
-p / --prompt	ein Prompt, dann Exit (programmatic)
-s / silent	weniger Session-Metadaten in der Ausgabe
--allow-tool=…	enge Allowlist
--deny-tool=…	harte Sperre (deny schlägt allow)
--no-ask-user	keine Rückfragen (CI-tauglich)
--model …	reproduzierbares Modell in Pipelines
--allow-all / --yolo	nur in isolierten Sandboxes, nicht als CI-Default

Pipe ist möglich (echo "…" \| copilot), wird aber ignoriert, wenn gleichzeitig -p gesetzt ist. Details: Run programmatically und copilot help permissions.

Rezepte (eng, kopierbar)

Branch-Review ohne Write (Findings als Log/Artifact, kein Commit):

copilot -p '/review the changes on this branch compared to main. Focus on bugs and security. Do not modify files.' \
  -s --no-ask-user \
  --model YOUR-STABLE-MODEL \
  --allow-tool='shell(git:*)' \
  --deny-tool='write' \
  --deny-tool='shell(rm)' \
  --deny-tool='shell(git push)' \
  --max-ai-credits 80

Docs generieren (Write eng, kein Push):

copilot -p 'Generate module docstrings for exported functions under todo/. No new dependencies. Run pytest -q after edits.' \
  -s --no-ask-user \
  --allow-tool='write' \
  --allow-tool='shell(pytest)' \
  --deny-tool='shell(rm)' \
  --deny-tool='shell(git push)'

Tipps aus der Programmatic-Doku (komprimiert): Prompt präzise und quoted; --no-ask-user setzen; Modell explizit (--model) für Reproduzierbarkeit; Allow/Deny pro Task, nicht „alles erlauben und hoffen“. Session-Cap: --max-ai-credits (Preview, Kap. 3 / 7).

Auth für CI (Stand Mitte/Ende 2026)

Punkt	Vorgabe (Doku)
Empfohlenes Token	Fine-grained PAT mit Permission Copilot Requests
Resource owner	Personal account des Token-Owners – nicht die Org als Owner für diese Permission
Env-Precedence	COPILOT_GITHUB_TOKEN > GH_TOKEN > GITHUB_TOKEN
Classic PAT (ghp_)	laut Doku nicht unterstützt
Auch ok	OAuth-Tokens der Copilot-CLI-App bzw. gh-App (interaktiv / vorhandene Auth)

# Beispiel lokal / Runner – Token nie committen
export COPILOT_GITHUB_TOKEN=github_pat_YOUR_TOKEN
copilot -p "Summarize recent failures. Do not modify files." -s \
  --allow-tool='shell(git log)' \
  --deny-tool='write'

Secret im Repo: z. B. COPILOT_GITHUB_TOKEN als Repository- oder Org-Secret. Rotation und least privilege (nur nötige Repos) gehören zur Team-Hygiene.

GitHub Actions – Gerüst

Kopiervorlage: beispiele/configs/github-actions-copilot.yml.

Kernidee des Gerüsts:

# Auszug – vollständige Datei unter beispiele/configs/
env:
  COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
run: |
  copilot -p "${{ inputs.prompt }}" \
    --allow-tool='shell(pytest)' \
    --allow-tool='shell(git log)' \
    --deny-tool='write' \
    --deny-tool='shell(rm)' \
    --deny-tool='shell(git push)'

Praxisregeln CI:

1. Least-privilege permissions: im Workflow (oft nur contents: read)
2. Enge --allow-tool / harte --deny-tool – deny vor allow denken
3. Prompt: read-only Review vs. write strikt trennen
4. Ausgabe als PR-Comment, Artifact oder Log – nie ungeprüfter Merge
5. Trigger begrenzen (workflow_dispatch, Label, paths:) – nicht bei jedem Tippfehler Max-Credits
6. Install- und Token-Details gegen aktuelle Install-/Auth-Doku prüfen

Team-System in einem Bild: Managed Settings steuern den Laptop-Agenten; CI liefert Assistenz und Artefakte; Merge und Release bleiben menschlich.

{width=90%}

---

6.5 Cloud Agent, Branch Protection, menschlicher Merge

/delegate schickt Arbeit an den Copilot Cloud Agent (PR auf GitHub, asynchron). Das ist stark für tangentiale Tasks – und gefährlich, wenn Branch Protection und Review fehlen.

Nutze Cloud Agent	Arbeite lokal
Docs, kleine Nebenmodule	interaktives Debuggen
asynchrone, abgrenzbare Tasks	Kernfeature mit vielen Rückfragen
andere Repos / Warteschlangen	Explore mit enger Steuerung

Mindest-Schutz (Team-Policy):

1. Branch Protection auf main / Release-Branches
2. Required reviews (mind. 1 Mensch, besser CODEOWNERS)
3. Required status checks
4. Kein Auto-Merge als Empfehlung – auch nicht „nur wenn CI grün“
5. Cloud-PR wie jeden anderen PR behandeln: Diff lesen, Tests, Intent prüfen

Achtung: Cloud-Agent + schwache Branch Rules = ungeprüfte Änderungen im Default-Branch. Die Bremse ist Protection + Mensch, nicht „der Agent meint es gut“.

Lokale Session und Cloud-Session kannst du mit Resume/Continue und den Session-Tools verbinden (Kapitel 07) – das ersetzt keinen Review.

---

6.6 Kosten, Credits, Session-Limits

Finance fragt nach der Rechnung. Bevor du nur „billigeres Modell“ verordnest: Die teuersten Sessions sind oft Kontext-Schleudern – lange Instructions, viele MCP-Server, Kitchen-Sink-Chats.

Hebel	Effekt
Kurze, konkrete Instructions	weniger Dauerlast pro Turn
Path-scoped Instructions	Relevanz statt Roman
Skills on-demand statt immer alles im Prompt	weniger Ballast
Fokussierte Sessions (/clear / /new)	bessere Qualität, oft weniger Credits
/model passend zur Task	Alltagsarbeit ≠ Architektur-Refactor; Extended/Reasoning sparsam
/limits / --max-ai-credits	Soft-Cap pro Session (Preview)
Enge Tasks und Verify-Schleifen	weniger Tool-Loops
MCP-Anzahl begrenzen	Tool-Schemas kosten Kontext
Session-Limit für AI Credits	Cap pro Session (siehe aktuelle How-to-Doku)

In der Session:

/usage
/context
/limits set max-ai-credits 80

/usage zeigt u. a. Credits der Session, Dauer, Code-Änderungen und Token-Breakdown pro Modell (Stand Docs). Session-Caps: /limits set max-ai-credits N interaktiv bzw. --max-ai-credits=N programmatisch (Preview; Soft-Limit). How-to Setting an AI credit session limit – UI-Details können driften.

CI-Budgets: Jobs hart deckeln (nur Label, nur Draft-PRs, nur workflow_dispatch). Fleet und starke Modelle multiplizieren Kosten – bewusst einsetzen (Kapitel 5).

---

6.7 Compliance-Orientierung: Audit, Datenschutz, AI Act

Kern: Deny, Managed Settings und Diff-Review sind notwendig – aber nicht hinreichend. Ohne Ownership-Story, Datenfluss-Klarheit und menschliche Kontrolle bleibt „Enterprise“ eine Config-Sammlung.

Dieser Abschnitt ist Orientierung – kein Rechtsgutachten, keine Freigabe (Stand Mitte/Ende 2026).

Wer	Was
Harness-Team	Instructions, Settings, Deny, Hooks, CI least privilege, Evidence
Security/IT	Managed/MDM, Bypass-Policy, MCP-Allowlist, Key-Rotation, Incident
Legal/DPO	Use-Case, DSGVO/AVV, AI-Act-Einordnung, interne AI-Policy

Wann du Legal und Security holst

Hol Legal/DPO u. a. bei: personenbezogenen oder besonderen Daten im Repo/Session-Kontext; Prompt-Content-Logging; Cloud-Region/AVV; Personal- oder Leistungsentscheidungen mit AI.

Hol Security/IT u. a. bei: org-weiten Managed Policies; CI mit breiten Cloud-Rechten; prod-nahen Runnern; MCP-Freigaben.

Evidence-Paket (halbe Seite reicht oft):

1. Use-Case in einem Satz (z. B. Coding-Assistent im Dev-Alltag – keine Personalbewertung)
2. Datenfluss-Skizze (GitHub Copilot / Provider, MCP, CI)
3. Policy-Artefakte (Instructions, Settings, relevante Managed-Keys)
4. Ownership: wer mergt, wer darf YOLO/Bypass

Audit – drei Schichten, nicht „ein Log“

Schicht	Typisch sichtbar	Ersetzt nicht
GitHub Org/Enterprise Audit	Logins, Admin-Events, Policy-Spuren	feinen Tool-Loop auf dem Laptop
Session-/CLI-Spuren	Logs unter ~/.copilot/logs/, Session-State, CI-Artifacts	zentrale Retention-Policy
Team-Spuren	Hooks, PR-Comments, Reviews, Git-History	org-weite Governance

Im Incident willst du rekonstruieren wer, wann, welches Tool, allow/deny, welcher CI-Job – nicht monatelang Volltext-Prompts mit Kundendaten.

Datenschutz (kurz)

Was im Kontext liegt, kann zum Modell-Provider, zu MCP-Servern und in CI-Logs wandern. Steuerhebel: Scope eng, Secrets denyen, MCP reviewen, CI least privilege, Content-Logging nur mit klarem Zweck.

EU AI Act (Orientierung)

Der AI Act ist kein Schalter in settings.json. Coding-Assistenten im normalen Entwicklungsalltag sind oft nicht die High-Risk-Story aus Annex III – sobald dieselbe Pipeline Mitarbeiter bewertet oder regulierte Entscheidungen trifft, ändert sich das Bild. Klassifizierung: Legal/DPO. Harness-Beitrag: menschliche Aufsicht (Diff, kein Auto-Merge), Transparenz, dokumentierte Policies.

Haftung und Ownership

Der Agent multipliziert Tempo – nicht die Verantwortung. Merge, Release und Prod-Zugriff bleiben menschlich.

---

Häufige Fehler (Team / CI)

Symptom	Typische Ursache	Fix
„Lokal eng, CI weit“	andere Auth/Policy in der Pipeline	Workflow lesen; Allow/Deny und Token-Scope explizit
Token in Job-Logs / untrusted Step	PAT job-weit oder in Debug-Output	Secret nur am Prozess / Action-Input; Logs redigieren
Settings/Instructions greifen bei Kollege nicht	Local überschreibt; anderes COPILOT_HOME; nicht committed	Repo-Layer im Git; Local gitignored und dokumentiert
YOLO geht trotz Team-Policy	Bypass nicht gesperrt; MDM greift nicht	permissions.disableBypassPermissionsMode; Org-Policy prüfen
Auto-Merge durch Agent	zu weite CI-Rechte + freier Prompt	Write-Job trennen; Merge bleibt Mensch; Branch Protection
Cloud-YOLO trotz Laptop-Deny	Deny reist nicht mit	Environment-Ownership und Cloud-Rechte getrennt reviewen
„Bei mir läuft Copilot anders“	Slack-Normen, keine committed Artefakte	Team-Instructions + Onboarding-Checkliste (6.1)

---

Jetzt selbst machen: Team-Baseline (ca. 20 Min)

In einem Demo-Repo (oder beispiele/todo-cli/ als Sandbox):

1. .github/copilot-instructions.md aus vorlagen/copilot-instructions.team.md anpassen (echte Test-/Lint-Commands).
2. Optional path-scoped Datei aus vorlagen/path-instructions.example.md.
3. .gitignore: .github/copilot/settings.local.json und lokale Secrets.
4. Session starten: Trust, /instructions prüfen, enge Test-Aufgabe.
5. Optional: Workflow aus beispiele/configs/github-actions-copilot.yml nach .github/workflows/ kopieren – Secret erst auf einem Test-Repo, Token-Typ gegen Install-Doku prüfen.
6. Optional (~5 Min): Evidence-Notiz – Use-Case, wer mergt, YOLO erlaubt?, Prompt-Content in Logs ja/nein.

---

Was du jetzt kannst

• Team-Standards als committed Instructions, Settings, Skills und Agents denken
• Org-/Enterprise-Agents und Managed Settings als Policy-Schicht einordnen
• permissions.disableBypassPermissionsMode als YOLO-Bremse verstehen
• Programmatic copilot -p mit Allow/Deny und CI-Auth (fine-grained PAT, Env-Precedence) aufsetzen
• Cloud Agent mit Branch Protection und menschlichem Merge koppeln
• Kosten- und Compliance-Hebel nüchtern benennen – ohne Rechtsberatung vorzutäuschen

Nächste Schritte

• Kapitel 07: Kontext, Sessions, Symptom→Fix, Doku-Drift, Grenzen & Trade-offs

• Kapitel 08: Flags, Pfade, Glossar, Vorlagen-Index · stabile Kerne: Anhang A

• Vorlagen unter vorlagen/ und CI-Gerüst unter beispiele/configs/ ins echte Repo übernehmen

• Programmatic/CI als Rezept: beispiele/rezepte/04-programmatic-ci.md

• Primärdoku: GitHub Copilot CLI