tinycorn-studio/agent-skills

Studio-Konventionen (TinyCorn Studio Standard)

Gilt für jedes Repo/Tool des Studios – von der Initialisierung bis zur Wartung.

Sprache

• Kommunikation mit dem Benutzer: Vietnamesisch.
• Code, Identifikatoren, Commit-Nachrichten, Branchnamen: Englisch.
• README, CHANGELOG, Release Notes: Vietnamesisch.

Minimale Repo-Struktur

<repo>/
├── README.md          # erforderlich
├── CHANGELOG.md       # erforderlich (Keep a Changelog)
├── LICENSE            # üblicherweise MIT
└── .gitignore         # erforderlich

README.md muss enthalten:

1. Einleitung (1–2 Sätze, was das Tool macht, für wen)
2. Systemvoraussetzungen
3. Build / Ausführung
4. Hauptfunktionen (gruppiert)
5. Tastenkürzel (falls UI vorhanden)
6. Architektur / Verzeichnisstruktur
7. Konfiguration (UserDefaults, Umgebungsvariablen, Config-Datei ...)
8. Bekannte Einschränkungen
9. Versionsverlauf (Zusammenfassung, Details im CHANGELOG)
10. Download (Link zum neuesten GitHub Release – keine Installationsdateien im Repo)

Git

• .gitignore mindestens: .build/, dist/, node_modules/, .DS_Store, automatisch beim Build generierte Ressourcenverzeichnisse.
• Nicht commiten: Installationsdateien (DMG/ZIP), Build-Ausgaben, Secrets/Token.
• Commit-Nachricht: 1 Zeile, Befehlsform, Englisch, vollständige Beschreibung des Features/Fixes. Beispiel: Add folder view to Changes tab.
• Commits pro abgeschlossenem Feature; nur commiten, wenn der Benutzer es anfordert oder das Feature bestätigt wurde.
• Branch: main immer in einem auslieferbaren Zustand; Features in separaten Branches entwickeln, bei Fertigstellung --ff-only mergen.
• Version: SemVer, an einer einzigen Stelle deklariert (z.B. VERSION in make-app.sh), nicht über mehrere Dateien verteilt.

Dokumentation

• README + CHANGELOG gleichzeitig mit dem Feature aktualisieren (nicht später).
• Jedes Release umfasst: annotierten Tag vX.Y.Z + GitHub Release mit Release Notes auf Vietnamesisch (siehe Skill release-flow).
• Vermerke zu komplexen Designentscheidungen direkt im Code oder im README-Abschnitt „Architektur".

Qualität

• Vor Abschlussmeldung: Build/Test wiederholen, mit echten Daten oder einer Sandbox verifizieren.
• UI: Vorschau vor dem Anwenden (siehe Skill ui-preview-first).
• Keine Schreib-/Commit-Tests auf echten Benutzerdaten – Sandbox-Kopie verwenden.
• Nach dem Testen Sandbox/Temp-Daten bereinigen, keine Rückstände im Repo hinterlassen.

Checkliste für neue Repos

• git init + standard .gitignore
• README gemäß obiger Struktur
• CHANGELOG mit Abschnitt [0.1.0]
• LICENSE (MIT)
• Build-Skript (make-app.sh o.ä.) + DMG/Installer
• GitHub Remote + Push auf main
• Erstes Release inklusive Installationsdatei
• Skill release-flow für alle zukünftigen Veröffentlichungen bekannt