PINKIIILQWQ/oh-my-gh-writing

Was macht oh-my-gh-writing?

GitHub-Schreibfähigkeit für KI-Agenten. Leite die Anfrage weiter, lade die passende Vorlage, halte die Evidenzgrenzen klar ein und erstelle nahezu einreichungsreife GitHub-Entwürfe.

Auslösegrenze

Verwende diese Fähigkeit für GitHub-bezogene Schreiberzeugnisse und lokale GitHub-Entwurfspakete. Verwende sie nicht für allgemeines Texten, UI-Texte, Code-Implementierung, Produktstrategie oder breite Dokumentationsarbeiten, es sei denn, die gewünschte Ausgabe ist ein GitHub-Artefakt oder eine GitHub-Repository-Datei.

Arbeitsablauf

1. Ermittle, ob der Benutzer ein einzelnes Artefakt oder ein Multi-Artefakt-Workflow-Paket wünscht.
2. Wenn der Benutzer explizit ein einzelnes Artefakt nennt, leite zu diesem Artefakt weiter, auch wenn das Thema breit gefasst ist.
3. Wenn der Benutzer nach einem breiten Workflow, Start, Einrichtung, Release-Paket oder einem durchgängigen Materialsatz fragt, leite zum passenden zusammengesetzten Workflow-Paket weiter.
4. Wenn der Benutzer bittet, zu prüfen, zu kontrollieren, die Bereitschaft zu überprüfen oder zu empfehlen, welche Dateien benötigt werden, behandle dies als Nur-Prüfung: Gib nur eine Lückenanalyse und Empfehlungen für die nächsten Dateien aus. Erstelle keine Zieldateien, erstelle kein .github-writing/ und schreibe keine .github/ oder Root-Repository-Dateien, es sei denn, der Benutzer bittet explizit darum, Dateien zu entwerfen, zu erstellen, zu schreiben, anzuwenden oder zu aktualisieren.
5. Für README-Anfragen verwende die Drei-Fragen-Aufforderung in references/readme.md.
6. Befolge bei zusammengesetzten Workflow-Paketen die Entscheidungsregel des Pakets. Stelle die Frage zur Paketauswahl nur dann, wenn die Paketform nicht sicher abgeleitet werden kann; verwende andernfalls die empfohlene Standardeinstellung und dokumentiere sie in package-manifest.md.
7. Öffne und lies explizit die passenden references/*.md, bevor du eine für den Benutzer sichtbare Ausgabe erstellst. Leite den Inhalt von Referenzen nicht aus dem Gedächtnis ab oder rate ihn.
8. Lese nur die von einem zusammengesetzten Paket ausgewählten Einzel-Artefakt-Referenzen. Lade nicht jede Referenz vorab.
9. Lese references/weapons.md, wenn Abzeichen, Warnungen, Mermaid, einklappbare Blöcke, Emoji oder komplexe Tabellen benötigt werden.
10. Lese references/badge-catalog.md nur, wenn der Benutzer nach detailliertem Abzeichen-Design oder genauen shields.io-URL-Mustern fragt.
11. Lese references/emoji-guide.md, wenn Emoji angefordert wird oder das Ziel-Repository bereits Emoji verwendet.
12. Lese references/shared-principles.md, wenn die Anfrage faktenreich, risikoreich, szenarienübergreifend ist oder wenn Klarstellungen zu den Ausgabequalitätsregeln benötigt werden.
13. Verwende vor der Finalisierung references/output-validation.md als stillen Überarbeitungs-Checkliste. Wenn der Entwurf eine Prüfung nicht besteht, überarbeite ihn vor der Auslieferung. Halte die Validierung bei kleinen, sauberen Artefakten still; füge kurze Hinweise zur Nachbearbeitung nur dann hinzu, wenn das Artefakt komplex, risikoreich oder offensichtlich blockiert ist.

Wenn das Lesen lokaler Dateien nicht verfügbar ist, bitte den Benutzer, den relevanten Inhalt aus references/*.md bereitzustellen, oder gib an, dass Referenzen nicht verfügbar sind, und erstelle nur einen konservativen Entwurf basierend auf den sichtbaren Weiterleitungsregeln und gemeinsamen Prinzipien. Gib nicht vor, Dateien gelesen zu haben, auf die du nicht zugreifen kannst.

Progressive Offenlegung: Lade nur die für die aktuelle Aufgabe benötigten Dateien. Wenn mehrere Referenzen wirklich benötigt werden und die Plattform Batch-Lesevorgänge unterstützt, lese sie in einem Batch anstatt in seriellen Tool-Aufrufen.

Sprachtreue: Passe dich der vom Benutzer gewünschten Sprache oder der primären Sprache des Ziel-Repositories an. Die Sprache der Anweisungen dieser Fähigkeit darf nicht in das endgültige GitHub-Artefakt durchsickern.

Szenario-Weiterleitung

Siehe INDEX.md für die vollständige Liste der 18 Einzel-Artefakt-Standards und 7 zusammengesetzten Workflow-Pakete.

Verwende diese Weiterleitungsregeln der obersten Ebene:

Signal	Weiterleitung zu
Der Benutzer fragt nach einem expliziten Artefakt, z. B. „Schreibe Release-Notes“ oder „Erstelle eine PR-Vorlage“	Die passende Einzel-Artefakt-Referenz
Der Benutzer fragt nach einem Release-Paket, Versionsaktualisierungsmaterialien, Vorbereitung eines großen Releases oder einem Software-Update-Bundle	references/version-release.md
Der Benutzer möchte ein Repository zum ersten Mal veröffentlichen oder als Open Source bereitstellen	references/project-launch.md
Der Benutzer möchte ein Projekt für externe Mitwirkende vorbereiten	references/contribution-setup.md
Der Benutzer möchte einen Fehler vom Bericht oder Triage über einen Fix-PR bearbeiten	references/bug-fix-workflow.md
Der Benutzer möchte eine Idee in Diskussion, Design, Issue und Implementierungsmaterialien umwandeln	references/proposal-to-implementation.md
Der Benutzer möchte ein Kommunikationspaket für einen Breaking Change	references/breaking-change-package.md
Der Benutzer möchte eine breite Dokumentationsaktualisierung oder eine Dokumentationsüberholung	references/docs-overhaul.md

Wenn die Eingabe Sprache von Issue, PR und Diskussion mischt:

Signal	Weiterleitung zu
Zukünftige Funktionsanfrage ohne implementierten Diff	Feature Request
Verbesserung des bestehenden Verhaltens	Enhancement
Community-Input mit unentschiedener Lösung	Discussion
Branch, Diff oder PR implementiert eine neue Fähigkeit	Feature PR
Branch, Diff oder PR behebt einen Fehler oder Regression	Bug Fix PR
Änderung reorganisiert Code ohne Verhaltensänderung	Refactor PR
Nur Dokumentation geändert	Documentation PR
Benutzer bittet um Code-Review, PR-Review oder Diff-Review	Code Review

Wenn der Benutzer bittet, einen PR, eine Postmortem-Analyse oder eine Diskussion in ein anderes Artefakt umzuwandeln, leite nach dem angeforderten Artefakt weiter, nicht nach dem Quellmaterial.

Standardeinstellungen für zusammengesetzte Workflows

Zusammengesetzte Workflow-Pakete sind Orchestratoren, keine Vorlagen. Sie wählen aus, welche vorhandenen Einzel-Artefakt-Standards geladen werden sollen.

• Nur-Prüfungs-Eingabeaufforderungen erzeugen Empfehlungen, keine Paketdateien.
• Stelle eine Frage zur Paketauswahl nur dann, wenn die Entscheidungsregel des Pakets nicht sicher einen Standard wählen kann.
• Wenn ein Standard ohne Nachfrage gewählt wird, dokumentiere die ausgewählte Option und die Annahmen in package-manifest.md.
• Füge optionale Ergänzungen in derselben Nachricht hinzu.
• Standard-Ausgabeort sind lokale Entwurfsdateien unter .github-writing/<pack-name>/<version-or-date>/.
• Wenn keine Version oder kein Datum bekannt ist, verwende .github-writing/<pack-name>/TBD/.
• Füge in jedes zusammengesetzte Paket eine package-manifest.md ein, die die generierten Dateien, Annahmen, TODO- / TBD-Felder, sicher zu schreibende Dateien und Dateien, die eine Bestätigung des Maintainers erfordern, auflistet.
• Wenn das Schreiben von Dateien nicht verfügbar ist, zeige das Paket als Multi-Datei-Chat-Ausgabe an, indem du ## Datei: ...-Überschriften und umschlossene Blöcke verwendest. Gib nicht an, dass Dateien geschrieben wurden.
• Veröffentliche nichts, erstelle keine GitHub-Releases, pushe keine Tags, öffne keine PRs und ändere nichts am Remote-Status, es sei denn, der Benutzer bittet explizit darum.

Referenzindex

Lade INDEX.md für die vollständige Navigation. Übliche Referenzgruppen:

Gruppe	Referenzen
Issues	bug-report.md, feature-request.md, enhancement.md, discussion.md
Pull Requests	feature-pr.md, bug-fix-pr.md, refactor-pr.md, documentation-pr.md
Review und Commit	code-review.md, standard-commit.md
Docs	readme.md, contributing.md, changelog.md
Release und Design	release-notes.md, migration-guide.md, rfc.md
Vorlagen	issue-form-yaml.md, pr-template.md
Zusammengesetzte Pakete	version-release.md, project-launch.md, contribution-setup.md, bug-fix-workflow.md, proposal-to-implementation.md, breaking-change-package.md, docs-overhaul.md
Anhänge	shared-principles.md, weapons.md, badge-catalog.md, emoji-guide.md, output-validation.md, source-catalog.md

Fehlende Informationen

Stelle eine kurze Rückfrage nur dann, wenn eine erforderliche Wahl nicht sicher abgeleitet werden kann, z. B. Zielpaketname, Release-Version, Absicht eines Breaking Changes, Ausgabepaketform oder eine Bereichswahl, die die Artefaktstruktur ändert. Verwende andernfalls TBD oder TODO, nenne Annahmen kurz und entferne optionale Abschnitte, wenn keine Belege vorliegen.

Repository-Pflege

• Halte SKILL.md als schlanken Laufzeit-Router.
• Platziere szenariospezifische und zusammengesetzte Paketregeln in der passenden references/*.md.
• Halte INDEX.md nur zur Navigation.
• Halte die Laufzeitanweisungen standardmäßig auf Englisch.
• Aktualisiere README-bezogene Lektionen in references/readme.md, wenn README-Fehler entdeckt werden.
• Halte lokale Forschungs- und Validierungsausgaben außerhalb des verfolgten Laufzeitinhalts.