auto-pr-pipeline

Name: auto-pr-pipeline
Author: Svenja-dev

8installs5forks

How to install auto-pr-pipeline?

svenja-dev/claude-code-skills/auto-pr-pipeline

$npx -y skills add Svenja-dev/claude-code-skills --skill auto-pr-pipeline

Installs into the current project.

Summary

Fuehrt einen repo- und policy-bewussten Delivery-Workflow fuer bestehende Code-Aenderungen aus: Zustand erfassen, passende lokale Checks auswaehlen, selektiv committen, pushen, Draft-PR oder Ready-PR erstellen/aktualisieren, CI und Reviews verarbeiten, Auto-Merge oder Merge Queue

Files · 1

View on GitHub

SKILL.md

1	# Auto-PR-Pipeline v3.0
2
3	Arbeite nicht wie ein starres Script. Arbeite wie ein senioriger Delivery-Agent, der zuerst den Zustand, dann die Repo-Policy und erst danach die naechste Aktion bestimmt.
4
5	## Mission
6
7	Bringe vorhandene Code-Aenderungen sicher und professionell bis zu einem guten Endzustand:
8
9	- sauber validiert
10	- passend committet
11	- korrekt gepusht
12	- als Draft-PR oder Ready-PR sauber dokumentiert
13	- gegen CI, Reviews und Branch-Regeln abgearbeitet
14	- gemerged oder sauber bewaffnet fuer Auto-Merge / Merge Queue
15
16	Wenn der sicherste Endzustand nicht "sofort mergen" ist, ist ein sauber vorbereiteter Draft-PR oder ein armed Auto-Merge ein guter Abschluss.
17
18	## Kernprinzipien
19
20	1. Repo-Policy zuerst. Lies Branch-Regeln, Merge-Optionen, Review-Anforderungen, CI, CODEOWNERS, PR-Templates und vorhandene Workflows bevor du ueber Commit, Push oder Merge entscheidest.
21	2. State-driven arbeiten. Entscheide nicht anhand einer festen Phase, sondern anhand des aktuellen Repo-Zustands.
22	3. Kleine Batches bevorzugen. Wenn die Aenderung zu gross oder gemischt ist, splitte oder stoppe frueh statt unklar weiterzumergen.
23	4. Repo-native Checks bevorzugen. Rate keine Standardbefehle blind. Nutze die Checks, die dieses Repo wirklich verwendet.
24	5. Veroeffentlichte History respektieren. Bereits gepushte oder reviewte Commits werden nicht leichtfertig umgeschrieben.
25	6. Plattform-Automation nutzen. Auto-Merge, Merge Queue, Required Checks und Draft/Ready sind besser als eigenes Dauer-Babysitting.
26	7. Nur echte Hochrisiko-Probleme blockieren. Stoppe nicht wegen kleiner Reibung. Stoppe bei hohem Risiko und liefere dann Optionen.
27	8. Immer resume-faehig bleiben. Jeder neue Aufruf beginnt mit frischer Zustandserfassung. Ueberspringe Erledigtes und mache sinnvoll weiter.
28	9. Arbeit retten statt stumpf abbrechen. Wenn auf dem falschen Branch gearbeitet wurde, sichere die Arbeit in einen passenden Feature-Branch statt nur zu blockieren, sofern das risikoarm moeglich ist.
29
30	## Phase 0: Snapshot bauen
31
32	Baue zuerst einen belastbaren Snapshot. Ohne Snapshot keine Aktion.
33
34	Ermittle mindestens:
35
36	- aktueller Branch, Upstream, ahead/behind, Default-Branch
37	- liegt die Arbeit versehentlich direkt auf `main` / `master` / Release-Branch
38	- staged, unstaged, untracked, lokale Commits seit Base
39	- existiert bereits ein PR fuer den Branch, ist er Draft oder Ready, was ist die URL
40	- Review-Entscheidung, offene Threads, requested changes, neue Kommentare
41	- Status Checks, Deployments, mergeable, Auto-Merge, Merge Queue
42	- Branch-Protection / Rulesets soweit mit den vorhandenen Tools sichtbar
43	- Repo-Konventionen fuer Commits, Merge-Methode und PR-Body
44	- relevante Dateien fuer Build, Tests, CI, Workflows, CODEOWNERS und PR-Templates
45
46	Lies dafuer gezielt die Repo-Dateien und GitHub-Metadaten.
47
48	Referenzen laden: Bevor du mit Phase 0 beginnst, lies die folgenden Referenz-Dateien fuer die konkreten Entscheidungsbaeume:
49
50	- `references/repo-detection.md` - Repo-Struktur, Git-Zustand, Policy, Checks
51	- `references/commit-strategy.md` - Commit-Entscheidungslogik nach Fall A-E
52	- `references/review-and-merge.md` - Review-Prioritaet, Merge-Methode, Flaky-Handling
53	- `references/blockers-and-recovery.md` - Hard/Soft Blocker, Recovery-Budget, Ausgabeformat
54
55	Die Referenzen enthalten die det

People who liked this also viewed

6 picks

Type

auto-pr-pipeline

8installs5forks

View on GitHub

How to install auto-pr-pipeline?

svenja-dev/claude-code-skills/auto-pr-pipeline

$npx -y skills add Svenja-dev/claude-code-skills --skill auto-pr-pipeline

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Auto-PR-Pipeline v3.0
2
3	Arbeite nicht wie ein starres Script. Arbeite wie ein senioriger Delivery-Agent, der zuerst den Zustand, dann die Repo-Policy und erst danach die naechste Aktion bestimmt.
4
5	## Mission
6
7	Bringe vorhandene Code-Aenderungen sicher und professionell bis zu einem guten Endzustand:
8
9	- sauber validiert
10	- passend committet
11	- korrekt gepusht
12	- als Draft-PR oder Ready-PR sauber dokumentiert
13	- gegen CI, Reviews und Branch-Regeln abgearbeitet
14	- gemerged oder sauber bewaffnet fuer Auto-Merge / Merge Queue
15
16	Wenn der sicherste Endzustand nicht "sofort mergen" ist, ist ein sauber vorbereiteter Draft-PR oder ein armed Auto-Merge ein guter Abschluss.
17
18	## Kernprinzipien
19
20	1. Repo-Policy zuerst. Lies Branch-Regeln, Merge-Optionen, Review-Anforderungen, CI, CODEOWNERS, PR-Templates und vorhandene Workflows bevor du ueber Commit, Push oder Merge entscheidest.
21	2. State-driven arbeiten. Entscheide nicht anhand einer festen Phase, sondern anhand des aktuellen Repo-Zustands.
22	3. Kleine Batches bevorzugen. Wenn die Aenderung zu gross oder gemischt ist, splitte oder stoppe frueh statt unklar weiterzumergen.
23	4. Repo-native Checks bevorzugen. Rate keine Standardbefehle blind. Nutze die Checks, die dieses Repo wirklich verwendet.
24	5. Veroeffentlichte History respektieren. Bereits gepushte oder reviewte Commits werden nicht leichtfertig umgeschrieben.
25	6. Plattform-Automation nutzen. Auto-Merge, Merge Queue, Required Checks und Draft/Ready sind besser als eigenes Dauer-Babysitting.
26	7. Nur echte Hochrisiko-Probleme blockieren. Stoppe nicht wegen kleiner Reibung. Stoppe bei hohem Risiko und liefere dann Optionen.
27	8. Immer resume-faehig bleiben. Jeder neue Aufruf beginnt mit frischer Zustandserfassung. Ueberspringe Erledigtes und mache sinnvoll weiter.
28	9. Arbeit retten statt stumpf abbrechen. Wenn auf dem falschen Branch gearbeitet wurde, sichere die Arbeit in einen passenden Feature-Branch statt nur zu blockieren, sofern das risikoarm moeglich ist.
29
30	## Phase 0: Snapshot bauen
31
32	Baue zuerst einen belastbaren Snapshot. Ohne Snapshot keine Aktion.
33
34	Ermittle mindestens:
35
36	- aktueller Branch, Upstream, ahead/behind, Default-Branch
37	- liegt die Arbeit versehentlich direkt auf `main` / `master` / Release-Branch
38	- staged, unstaged, untracked, lokale Commits seit Base
39	- existiert bereits ein PR fuer den Branch, ist er Draft oder Ready, was ist die URL
40	- Review-Entscheidung, offene Threads, requested changes, neue Kommentare
41	- Status Checks, Deployments, mergeable, Auto-Merge, Merge Queue
42	- Branch-Protection / Rulesets soweit mit den vorhandenen Tools sichtbar
43	- Repo-Konventionen fuer Commits, Merge-Methode und PR-Body
44	- relevante Dateien fuer Build, Tests, CI, Workflows, CODEOWNERS und PR-Templates
45
46	Lies dafuer gezielt die Repo-Dateien und GitHub-Metadaten.
47
48	Referenzen laden: Bevor du mit Phase 0 beginnst, lies die folgenden Referenz-Dateien fuer die konkreten Entscheidungsbaeume:
49
50	- `references/repo-detection.md` - Repo-Struktur, Git-Zustand, Policy, Checks
51	- `references/commit-strategy.md` - Commit-Entscheidungslogik nach Fall A-E
52	- `references/review-and-merge.md` - Review-Prioritaet, Merge-Methode, Flaky-Handling
53	- `references/blockers-and-recovery.md` - Hard/Soft Blocker, Recovery-Budget, Ausgabeformat
54
55	Die Referenzen enthalten die det

People who liked this also viewed

6 picks

Type