joeseesun/qiaomu-github-publisher

Qiaomu GitHub Publisher

Verwandle ein funktionierendes Projekt in ein GitHub-Repository, das Menschen verstehen, ausprobieren, mit einem Stern versehen, installieren und vertrauen können.

Copyright (c) 向阳乔木

• X: https://x.com/vista8
• GitHub: https://github.com/joeseesun/
• Profilquelle: ~/.agents/skills/qiaomu-profile

Kernworkflow

1. Überprüfe das Repository vor dem Schreiben:
   • README.md, package.json / Projektmetadaten, Screenshots, Beispiele, Dokumentation, Lizenz, Bereitstellungsskripte, Testskripte.
   • GitHub- und Community-Oberflächen: About-Beschreibung, Homepage, Themen, Social Preview, Lizenz, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, Issue-Vorlagen, PR-Vorlage, Releases/Changelog, falls vorhanden.
   • GitHub-Remote-Status über gh repo view --json name,description,homepageUrl,repositoryTopics,url,defaultBranchRef,isPrivate,licenseInfo.
2. Lege die öffentliche Positionierung fest:
   • Einzeiliger Haken auf Chinesisch und Englisch, wobei die chinesische Version zuerst kommt.
   • Zielgruppe und warum sie es jetzt ausprobieren sollten.
   • Klare Grenze zwischen Produktwert, technischer Architektur und privatem/lokalem Setup.
   • Beabsichtigte Veröffentlichungshaltung: reines Showcase, benutzerinstallierbares Tool, Projekt mit externen Mitwirkenden, Bibliothek/Paket oder bereitgestelltes Produkt.
3. Schreibe README.md als Produktseite um oder patche sie:
   • README.md ist die GitHub-Eingangstür. Für Qiaomu-eigene Repositories muss sie standardmäßig chinesisch zuerst und zweisprachig sein.
   • Setze Chinesisch zuerst, dann Englisch. Tue dies, es sei denn, der Benutzer fordert explizit nur Englisch an oder das Repository hat eine dokumentierte Nicht-Qiaomu-Upstream-Anforderung.
   • Eine separate README.zh-CN.md ist erlaubt, erfüllt diese Anforderung jedoch nicht allein; die standardmäßige README.md muss zuerst Chinesisch zeigen.
   • Englisch kann ein vollständiger unterer Abschnitt sein, der durch # English verankert ist, eine verlinkte README.en.md oder ein kompakter gespiegelter Abschnitt, aber Installations-/Testanweisungen, Verifizierung, Grenzen und Lizenz-/Zugangserwartungen müssen für englische Leser verständlich sein.
   • Baue eine scan-freundliche Zusammensetzung: Sprachwechsel, echte Hero-Medien, kurze Story-Haken, Nachweisstreifen, kompakte Badges, „Was/Warum“, Feature-Matrix, schnellster Schnellstart, erweiterbares manuelles Setup, Nutzung, Produkttour, Kompatibilitäts-/Ökosystemkataloge, Workflow/Architektur, Verifizierung, Einschränkungen und Vertrauenslinks.
   • Verwende echte Screenshots oder Ausgabebeispiele, wenn verfügbar; erfinde keine Screenshots.
4. Setze GitHub About:
   • Verwende standardmäßig eine kompakte zweisprachige Beschreibung für Qiaomu-eigene öffentliche Repositories, zuerst Chinesisch und dann Englisch.
   • Füge eine Homepage-URL hinzu, wenn es eine Live-Demo gibt.
   • Füge fokussierte Themen hinzu; vermeide Thema-Spam.
   • Für die öffentliche Veröffentlichungspflege erstelle oder fordere ein Social-Preview-Bild an. Wenn es nicht automatisiert werden kann, notiere den manuellen GitHub-Einstellungsschritt als Folgemaßnahme, anstatt vorzugeben, dass er gesetzt wurde.
5. Verbessere Vertrauensoberflächen entsprechend der Veröffentlichungshaltung:
   • Überprüfe immer den Lizenzstatus für Open-Source-Repositories.
   • Für Projekte mit externen Mitwirkenden füge CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, Issue-Vorlagen und eine PR-Vorlage hinzu oder aktualisiere sie, wenn sie fehlen oder veraltet sind.
   • Erkläre bei reinen Showcase-Repositories, ob Beitrags-/Community-Dateien absichtlich weggelassen wurden.
6. Überprüfe, was das README verspricht:
   • Führe bei Bedarf bereitgestellte Lint-/Build-/Testbefehle aus.
   • Überprüfe bei Skills die Auffindbarkeit/Installierbarkeit über npx skills add.
   • Überprüfe bei Websites nach der Bereitstellung die Live-URL/API/den Gesundheitsstatus, falls zutreffend.
7. Veröffentliche über einen sauberen GitHub-Workflow:
   • Verwende einen Feature-Branch und einen PR.
   • Pushe niemals direkt auf main.
   • Wenn die Verifizierung bestanden ist und der Benutzer nicht explizit um Zurückhaltung gebeten hat, merge den PR in main.
   • Gib in der endgültigen Antwort die PR-URL und den Merge-Commit an.

Quellgestütztes Präsentationsmodell

Diese Fähigkeit basiert auf den eigenen Präsentationsoberflächen von GitHub:

• README: GitHub sagt, dass ein Repository-README erklären sollte, was das Projekt tut, warum es nützlich ist, wie Benutzer loslegen, wo sie Hilfe bekommen und wer es pflegt. GitHub zeigt Besuchern automatisch ein erkanntes README an.
• Themen: GitHub-Themen helfen Menschen, Repositories nach Zweck, Fachgebiet, Community, Sprache oder anderen wichtigen Eigenschaften zu entdecken.
• Lizenz: Die Lizenzanleitung von GitHub besagt, dass ein öffentliches Repository eine Open-Source-Lizenz benötigt, bevor andere es klar frei nutzen, ändern und verbreiten können.
• Community-Profil: Die Checkliste für öffentliche Repositories von GitHub sucht nach README, Lizenz, Verhaltenskodex, Mitwirkungsleitfaden, Sicherheitsrichtlinie und Issue-/PR-Vorlagen.
• Sicherheitsrichtlinie: SECURITY.md sagt den Leuten, wie sie Schwachstellen melden können.
• Issue- und PR-Vorlagen: Vorlagen standardisieren die Informationen, die Mitwirkende beim Öffnen von Issues oder Pull Requests bereitstellen.
• Social Preview: GitHub ermöglicht Repository-Betreuern, ein Social-Preview-Bild aus den Repository-Einstellungen festzulegen; verwende einfarbige Hintergründe, wenn Transparenz unvorhersehbar dargestellt werden kann.

Verwende zuerst die offizielle Dokumentation, wenn diese Anleitung mit einer Blog-Checkliste in Konflikt steht.

Referenzfall zum Lernen, nicht zum blinden Kopieren: santifer/career-ops präsentiert sein README als kompakte Startseite. Es beginnt mit Sprachzugang, einem echten Heldenbild, einer dreizeiligen Ursprungsgeschichte, verdienten externen Nachweisen, einer Demo, quantifizierten Ergebnissen, fokussierten Badges, und geht dann zu dem über, was es ist, Funktionen, Schnellstart, Nutzung, Workflow, Struktur, Stack, Haftungsausschluss und Kontakt. Verwende diese Reihenfolgelogik neu, wenn sie zu einem Qiaomu-Repository passt, aber erfinde niemals Presse, Community, Downloads, Sterne, Benutzererfolge oder Nutzungsbehauptungen.

Referenzfall für komplexe Produkte: nexu-io/open-design behandelt sein README als Produktkarte für ein großes Ökosystem. Es verwendet Release/CTA-Hinweise, einen starken Produkttour-Abschnitt, gruppierte Demo-Galerien, Plattformkompatibilitätstabellen, mehrgleisigen Schnellstart, Agent-/MCP-Nutzung, Fähigkeits-/Designsystem-/Plugin-Kataloge, Architektur- und Sicherheitshinweise, Roadmap, Community-/Mitwirkendentabellen, Betreuer, Repository-Aktivität und Abstammung/Herkunft. Verwende dies als modulare Checkliste für Qiaomu-Repositories mit vielen Oberflächen, aber kopiere niemals Skalennummern, Support-Matrizen, kostenpflichtige Serviceansprüche, Community-Behauptungen, Sicherheitsgarantien oder Drittanbieter-Abstammung, es sei denn, sie sind im aktuellen Repository verifiziert.

README-Standard

Sprach-Gate

Für Qiaomu-eigene öffentliche Repositories muss README.md vor der Veröffentlichung chinesisch-zuerst zweisprachig sein:

• Erster Viewport: Projektname, chinesisches Wertversprechen, englisches Wertversprechen, Badges/Links und ein sichtbarer Sprachwechsel wie **中文** | [English](#english).
• Hauptteil: Zuerst chinesische Abschnitte, geschrieben als standardmäßige Leseerfahrung.
• Englischer Zugang: Biete einen substantiellen englischen Abschnitt oder ein verlinktes englisches README. Mindestens müssen englische Leser verstehen, was es tut, wie man es ausprobiert/installiert, was verifiziert ist und die Hauptgrenzen/Voraussetzungen.
• Übersetzungsdateien wie README.zh-CN.md und README.en.md können existieren, aber das standardmäßige GitHub-README.md muss dennoch zuerst mit Chinesisch öffnen, es sei denn, der Benutzer hat ausdrücklich eine andere Zielgruppe genehmigt.
• Wenn README.md nur auf Englisch, zuerst auf Englisch oder sich auf eine separate chinesische Datei für die chinesische Erfahrung verlässt, stoppe und behebe dies, bevor der Release-PR geöffnet/gemeret wird.

Erster-Viewport-Gate

Der obere Teil von README.md sollte einen 60-Sekunden-Fremdentest bestehen:

• Was ist das, in einem konkreten Satz?
• Für wen ist es und welchen Schmerz beseitigt es?
• Was kann ich sofort klicken, installieren oder ausprobieren?
• Welchen Beweis kann ich sehen: Screenshot, Demo, Beispielausgabe, CI-Badge oder verifizierten Befehl?
• Was sollte ich vertrauen: Lizenz, Betreuer, Sicherheits-/Datenschutzgrenze und zuletzt verifizierter Status?

Vermeide Badge-Wände, abstrakte Slogans und architektur-zuerst-Öffnungen. Architektur gehört, nachdem der Benutzer den Produktwert verstanden hat.

Öffentliches README muss fünf Fragen schnell beantworten:

• Welchen Schmerz löst dies?
• Was bekomme ich nach der Installation/Ausführung?
• Kann ich einen Beweis in einem Screenshot, einer Demo oder einer Beispielausgabe sehen?
• Wie kann ich es in weniger als fünf Minuten ausprobieren?
• Was sind die Grenzen, Kosten oder Voraussetzungen?

Kompositions-Gate

Verwende ein README-Layout, das sowohl als Produktseite als auch als technisches Dokument funktioniert:

• Beginne mit Ergebnis und Beweis vor Interna: Projektname, Sprachwechsel, echte Produktmedien, ein oder zwei konkrete Wertzeilen, primäre Aktionslinks und eine vertrauenswürdige Beweiszeile.
• Mache Beweise spezifisch und überprüfbar: Live-Demo, Installationsbefehl, Paket-/Release-Badge, CI-Ergebnis, Screenshot, Beispielausgabe, Benchmark, Fallstudie, Benutzerergebnis, Presserwähnung oder Sterndiagramm. Wenn es nicht verifiziert oder verdient wurde, lasse es weg.
• Verwende eine Funktionstabelle, wenn es 4+ Fähigkeiten gibt. Jede Zeile sollte eine benannte Fähigkeit dem benutzersichtbaren Ergebnis zuordnen, nicht nur Module auflisten.
• Setze den schnellsten erfolgreichen Pfad vor das manuelle Setup. Verwende zuerst einen Befehl oder den kürzesten bewährten Pfad und verstecke dann längeres manuelles Setup in <details>, wenn es die Seite überladen würde.
• Füge nach dem Schnellstart Nutzungsbefehle, Workflow/So-funktioniert-es, Projektstruktur und Technologie-Stack hinzu. Diese Abschnitte sollten einem ernsthaften Benutzer helfen, das System zu inspizieren, ohne den ersten Test zu verzögern.
• Setze Datenschutz, Dateneigentum, Kosten, Drittanbieterbedingungen, „kein gehosteter Dienst“ und „tut X nicht“-Grenzen in einen sichtbaren Abschnitt zu Einschränkungen/Haftungsausschluss, wenn relevant.
• Halte visuelle Assets zielgerichtet. Ein Heldenbild, Demo-GIF, Logos, Badges und Diagramme sollten das Produkt oder den Status beweisen; sie sollten nicht zur Dekoration oder geliehenen Autorität werden.

Komplexes Produktkatalog-Gate

Verwende dies, wenn das Repository mehr als eine einzelne App/Bibliothek ist: Multi-Plattform-Apps, Agenten-Ökosysteme, Plugin-/Vorlagenkataloge, Designsysteme, Medienpipelines, MCP-Server, selbst gehostete Stacks oder Projekte mit substantiellen Community-/Mitwirkungsoberflächen.

• Füge eine Produkttour vor tiefen Interna hinzu. Gruppiere Screenshots/Demos nach Benutzeroberfläche oder Artefakttyp und gib jedem Element eine einzeilige Ergebnisbeschreibung: Einstiegs-App, Studio/Editor, Dashboard, Plugin-Marktplatz, generierte Ausgabe, API, CLI, MCP, mobile/Desktop-Ansicht usw.
• Füge eine Kompatibilitätsmatrix hinzu, wenn das Produkt plattform-, agenten-, anbieter-, betriebssystem-, bereitstellungsmodus- oder paketmanagerübergreifend läuft. Spalten sollten konkret sein: Ziel, Status, Installationsbefehl, Verifizierungsbefehl und bekannte Grenzen.
• Füge Ökosystemkataloge für Fähigkeiten, Plugins, Vorlagen, Designsysteme, Anbieter, Beispiele oder Integrationen hinzu. Verwende Zahlen nur, wenn sie aus dem Repository generiert oder frisch verifiziert wurden; sage andernfalls „viele“ oder verlinke zum Verzeichnis. Gute Spalten: Element, Kategorie/Modus, Zielgruppe, Ausgabe, Quellpfad.
• Biete Schnellstarts nach Persona/Pfad an: Desktop- oder gehostete App, CLI/Agent-nur, Docker/selbst gehostet, aus der Quelle für Entwickler. Setze den empfohlenen Pfad zuerst und gib jedem Pfad eine Erfolgsprüfung.
• Zeige Architektur und Sicherheit zusammen, wenn das Repository einen Daemon, MCP-Server, Proxy, lokale Datenbank, Anmeldeinformationen, generierte Artefakte oder Netzwerkgrenze hat. Bevorzuge ein kompaktes Diagramm/eine Tabelle, verlinke zum autoritativen tieferen Dokument und vermeide die Duplizierung von driftanfälligen Speicher- oder Secret-Behandlungsdetails.
• Füge Abschnitte zu Roadmap, Community, Mitwirkung, Betreuer und Herkunft ein, wenn das Repository externe Arbeit einlädt oder Drittanbieter-Assets bündelt. Herkunft sollte Upstream-Projekte, Lizenzgrenzen und das, was angepasst oder gebündelt wurde, benennen.
• Halte die Katalogdichte unter Kontrolle: Verwende Tabellen zum Scannen, <details> für lange Inventare und tiefe Dokumente für erschöpfende Listen. Das README sollte einen Neuling orientieren, nicht das gesamte Handbuch werden.

Empfohlene Struktur:

# Projektname

**中文** | [English](#english)

![Produktscreenshot oder Held](docs/assets/product-screenshot.png)

> Chinesisches Wertversprechen
> Englisches Wertversprechen

[Live-Demo] [Installieren] [Dokumente] [Lizenz] [CI]

**Verifiziert:** `npm test` / `npx skills add ...` / Live-Gesundheitscheck / Beispielausgabe

## 这是什么
## 为什么值得用
## 核心能力

| Fähigkeit | Was der Benutzer erhält |
|---|---|
| ... | ... |

## 样例输出
## 快速开始

### Schnellster Pfad

```bash
...

...

使用方式

产品巡游 / Demo

平台兼容 / 生态目录

工作流 / 原理

架构与安全模型

项目结构

部署 / API / Skill

路线图 / 社区 / 贡献

来源谱系 / License 边界

实测验证

限制、隐私与边界

Troubleshooting

关于向阳乔木

---

Englischer Abschnitt

### Beweis und Medien

- Bevorzuge einen echten Screenshot, ein Demo-GIF, ein Terminal-Transkript, eine API-Antwort, ein generiertes Artefakt oder eine gehostete Demo in der Nähe des oberen Teils.
- Jeder Screenshot oder jedes Beispiel muss mit einem aktuellen verifizierten Zustand übereinstimmen. Verwende keine Mock-Bilder, es sei denn, sie sind klar als Design-Mockups gekennzeichnet.
- Quantifizierte Behauptungen sollten aktuell und quellenbasiert sein: Beispiele umfassen Anzahl verarbeiteter Elemente, generierte Artefakte, installierte Versionen, Kompatibilitätsziele, Katalogzahlen, Benchmark-Ergebnisse oder veröffentlichte Fallstudien. Wenn das Repository eine Zahl nicht aus Code, generierten Metadaten, Tests, Release-Artefakten oder Dokumenten beweisen kann, verwende stattdessen einen verifizierten Befehl/Ausgabe.
- Füge für CLI/Tools ein kurzes erfolgreiches Befehls-Transkript und ein Fehler-/Fehlerbehebungsbeispiel ein.
- Füge für Websites/Apps eine Live-URL, ein Bereitstellungsziel, einen Gesundheits-/API-Check und einen Desktop-/Mobil-Screenshot ein, wenn machbar.
- Halte das README bequem unterhalb des 500-KiB-Render-Trimlimits von GitHub. Wenn die Dokumente groß werden, teile tieferes Material in `docs/` auf und verlinke es.

## GitHub-Oberflächenstandard

### GitHub-About-Standard

Verwende standardmäßig eine kompakte zweisprachige Form für Qiaomu-eigene öffentliche Repositories:

```text
Kurze chinesische Beschreibung | Kurze englische Beschreibung.

Halte es konkret. Gute Beispiele:

• 把 App Store 评价变成产品研究证据，发现痛点、机会和版本风险 | Turn App Store reviews into product research evidence: pain points, opportunities, and version risks.
• 把任意资料整理成 NotebookLM 可用知识包 | Turn messy sources into NotebookLM-ready knowledge packs.

Themen sollten eng und nützlich sein:

• Domäne: app-store, app-reviews, notebooklm, geo
• Stack: nextjs, agent-skill, deepseek
• Zielgruppe/Workflow: product-management, ai-workflow

Vermeide generische Themen wie tool, website, ai, es sei denn, sie erhöhen die Auffindbarkeit.

Homepage, Badges und Social Preview

• Setze die Homepage auf die Live-Demo, Dokumentation, Installationsseite oder Produkt-Homepage. Wenn keine existiert, lasse sie leer, anstatt auf eine nicht zusammenhängende Seite zu verweisen.
• Verwende eine kleine Badge-Reihe: CI/Build, Lizenz, Paket...

…

[verkürzt für die Übersetzung]