App Scorecard

Was macht App Scorecard?

Wenn eine LOCAL.md-Datei neben dieser SKILL.md liegt, lies sie zuerst – sie enthält die spezifischen Angaben dieses Workspace (Pfade, Tools, Beispiele) und überschreibt die untenstehenden generischen Vorgaben.

Eine Rubrik, jede App, jedes Mal. Der entscheidende Punkt ist die Vergleichbarkeit: dieselben Dimensionen, dieselben 0–5-Anker, dieselben Tore, sodass eine im März bewertete App im Juni erneut bewertet werden kann und das Delta eine Bedeutung hat, und zwei Apps miteinander verglichen werden können, ohne die Kriterien neu zu diskutieren.

Abgeleitet aus dem Forschungsbericht „What Makes an App Exceptional“ (references/framework-source.md) und gezielter Forschung zur Schließung seiner Lücken (references/research-notes.md). Ausgearbeitetes Beispiel einer vollständigen 23-Dimensionen-Auswertung (anonymisiert): assets/example-audit.html.

Prinzipien (einmal lesen, sie bestimmen alles)

1. Tore vor Bewertungen. Sicherheit, Datenschutz, Legalität, Barrierefreiheit und – für jede App, die Fakten behauptet – inhaltliche Korrektheit sind nicht kompensierbar. Eine 5 im Design gleicht keine 0 im Datenschutz aus. Liste offene Tore zuerst auf; niemals mitteln.
2. Evidenz ist wichtiger als Meinung. Jede Bewertung trägt einen Evidenzgrad (E0 Behauptung → E4 belastbar) und jede Feststellung ist mit Beobachtet / Abgeleitet / Hypothese / Unbekannt gekennzeichnet.
3. Nie Verhalten aus Code ableiten. Bindung, Engagement, Marktfit, Zufriedenheit, Umsatz sind unbekannt, sofern keine Telemetriedaten, Kohortendaten oder eine Umfrage vorliegen. Code und Screenshots können sie nicht belegen. Sage „unbekannt“, nicht „wahrscheinlich“.
4. Die Phase bestimmt die Rubrik. Pre-PMF-Apps werden danach beurteilt, ob sie lernen, nicht ob sie SLAs haben. Siehe references/stages.md.
5. Takt vor Benchmarks. Keine universelle D7-Bindung. Ein wöchentlich genutzter Job, der „in zwei Wochen ein paar Mal“ verwendet wird, ist in Ordnung. Nenne zuerst den natürlichen Takt.
6. Jede schwache Dimension bekommt einen kleinsten Fix. Eine Bewertungstabelle ohne Korrekturen ist eine Beschwerde. Eine Zeile, umkehrbar, in Stunden oder Tagen bemessen.

Arbeitsablauf

0 · Einrahmen (5 Minuten, nicht überspringen)

Lege fest, jeweils in einer Zeile: Zielbenutzer · primäre Aufgabe · natürlicher Takt · erstes Wertereignis · Geschäftsmodell · Hauptalternativen (inkl. „nichts tun“). Wenn das Repository AGENTS.md / README.md enthält, übernimm dies von dort und zitiere es. Falls nicht vorhanden, leite es ab, nenne die Annahme und fahre fort.

Wähle dann die Phase (references/stages.md):

Phase	Signal	Rubrik
Pre-PMF	< ~100 aktive Nutzer, keine Kohortendaten oder Sean Ellis „sehr enttäuscht“ < 40 %	9 Dimensionen + Tore
Wachstum	Kohorten existieren, > 100 Aktive oder zahlende Kunden	volle 23 + Tore
Idee / Spezifikation	Noch kein Code	Nur hypothesenqualitative Rubrik (stages.md §3)

1 · Evidenz sammeln (nach Möglichkeit parallel)

Immer (Code + Deployment):

• Routen / Bildschirme, API-Oberfläche, Authentifizierung und Autorisierung (serverseitig?)
• Tests: führe sie aus. Lint: führe ihn aus. CI: lies die Workflows. Deployment: lies das Skript.
• Telemetrie: Was wird tatsächlich gesendet? (Ein Analytics-Import, der auf eine Plattform abzielt, auf der die App nicht gehostet wird, zählt als nichts.)
• Store / DB: Was wird pro Benutzer geschrieben, gibt es eine Löschfunktion, gibt es ein Backup.
• Datenschutz / AGB / Löschwege. Ratenlimits und Kontingente bei kostenpflichtigen APIs.
• Barrierefreiheit: Greps nach aria-, alt=, focus-visible, prefers-reduced-motion, Labels.
• i18n-Abdeckung: Auslagerte vs. hartcodierte Strings, Locales, Plural-/Datumsregeln.
• Fehler-/Leer-/Lade-/Offline-Zustände; route-level error.tsx / not-found.tsx.
• Leistung: Schwere Daten serverseitig oder clientseitig, Caching, p95 falls protokolliert.
• Für KI-/Referenz-Apps: Zuschreibungs- und Zitierlogik, Grounding Guard, Halluzinationskontrollen, Korpusherkunft.

Wenn verfügbar (Verhalten): Beta-Formular, Analysen, Kohortentabellen, Support-Tickets, Sean-Ellis-Umfrageergebnisse, beobachtete Sitzungen. Diese heben Dimensionen von „unbekannt“ auf einen echten Score. Ohne sie belasse sie unbekannt.

Verteile schreibgeschützte Explore-Agenten für die Breite (max. 3 gleichzeitig); lies selbst den Einstiegspunkt, die Navigation, den Kernablauf, die Authentifizierung und den Store.

2 · Die Tore prüfen

Aus references/rubric.md §Gates. Jedes Tor ist offen / geschlossen / n. z. mit der beobachteten Evidenz. Offene Tore erscheinen bei jeder Ausgabe ganz oben. Häufige: keine Datenschutzerklärung oder kein Löschweg bei Erhebung personenbezogener Daten; Zahlungen ohne AGB; fehlende serverseitige Authentifizierung; keine prefers-reduced-motion bei Animationen für ein älteres Publikum; falsch zugeordnete oder nicht zitierte Inhalte in einer Referenz-App.

3 · Jede Dimension bewerten

Für jede Dimension der gewählten Rubrik (references/rubric.md):

• Bewertung 0–5 anhand der Anker in der Rubrik (nicht nach Bauchgefühl).
• Evidenzgrad E0–E4 und Kennzeichnung Beobachtet / Abgeleitet / Unbekannt.
• Checkliste der Dimension abhaken: vorhanden / teilweise / fehlend / nicht ermittelbar.
• Einzeilige Feststellung, gestützt auf datei:zeile, eine Route, eine Konfiguration oder ein Zitat.
• Einzeiliger kleinster Fix, wenn Bewertung ≤ 3.

Für UI / UX-Design verwende die Sub-Rubrik für visuelles Design in rubric.md §UX Design (Typografie, Hierarchie, Farbe, Abstände, Konsistenz, Text). Wenn der Benutzer hier mehr Tiefe wünscht, rufe nach der Bewertungstabelle ui-usability-audit auf und verweise auf deren Noten.

4 · Beurteilen

• Offene Tore (erneut, zuerst).
• Top 3 Gründe zu gewinnen · Top 3 Gründe zu scheitern · Top 3 Unbekannte.
• Der einzelne nächste Hebel mit der größten Wirkung: Experiment oder Korrektur.
• Urteil: Go / Bedingtes Go / Iterieren / No-Go, mit Konfidenz. Faustregel: Ein offenes Tor ⇒ höchstens Iterieren; alle Tore geschlossen + Wertereignis instrumentiert ⇒ Bedingtes Go; vier Wochen Bindungsdaten im natürlichen Takt ⇒ Go ist möglich.

5 · Liefern – die visuelle Bewertungstabelle ist das Ergebnis

Die Chat-Nachricht ist eine Zusammenfassung. Der veröffentlichte HTML-Scorecard-Artifakt ist die Ausgabe. Beende einen Durchlauf niemals ohne einen; falls das Artifact-Tool nicht verfügbar ist (Codex, ein Unteragent), schreibe das HTML in docs/scorecards/<Datum>-scorecard.html im App-Repository und sende/öffne stattdessen die Datei.

1. Erstelle den Artifakt aus assets/scorecard-template.html. Lade zuerst die artifact-design-Fähigkeit, behalte dann die Struktur der Vorlage genau in dieser Reihenfolge bei, damit die Bewertungstabelle jeder App gleich gelesen wird:
   1. Kopfzeile — <App> Scorecard, Phase + Evidenzquellen + Datum (Augenbraue), ein Satz These, Urteils-Chip (go / Standard Amber / nogo-Klasse), Konfidenz und der Einrahmungsstreifen (Benutzer · Aufgabe · Takt · Wertereignis · Alternativen).
   2. Auf einen Blick – Raster — eine Kachel pro Dimension, Bewertungsband farbig kodiert (teal ≥ 3, amber 2, rot ≤ 1, grau unbekannt), gate-Umrandung bei jeder Dimension mit einem offenen Tor und ein ▲/▼-Delta zum vorherigen Durchlauf, falls vorhanden.
   3. Tore — jedes Tor als Karte: offen (rot) oder geschlossen (grün), mit der beobachteten Evidenz und Datei-/Routennamen in code.
   4. Pro-Dimension-Karten, gruppiert (Strategie & Ökonomie · Erfahrung & Vertrauen · Engineering & Skalierung, oder die Tier-A-Liste): Bewertung, Evidenzabzeichen, 2–4 Sätze Feststellung, Checkliste mit vorhanden/teilweise/fehlend/nicht ermittelbar und die Zeile mit dem kleinsten Fix für alles ≤ 3.
   5. Abschließendes Urteil — drei Spalten (Gründe zu gewinnen · Gründe zu scheitern · kritische Unbekannte) und das dunkle Panel „Nächster Schritt mit größtem Hebel“.
   6. Methodenfußnote — was gelesen, ausgeführt, verweigert wurde; Link zum vorherigen Durchlauf. Gestaltungsregeln: nur echte Inhalte, kein Lorem; jede Farbe aus dem Tokenset, damit der Dunkelmodus hält; kein Emoji, keine dekorativen Diagramme; Ziffern in tabellarischer Monospace. Betrachte die gerenderte Seite einmal, korrigiere, was sie zeigt, veröffentliche.
2. Veröffentliche mit Artifact. Titel <App Name> Scorecard, Favicon 🔬 nur bei der ersten Veröffentlichung. Bei einer erneuten Ausführung übergib die url des vorherigen Artifakts, sodass die Historie unter einem Link bleibt (finde sie in docs/SCORECARD.md).
3. Chat: zuerst den Link, dann den Einrahmungsblock, offene Tore, eine kompakte Tabelle (Dimension · Bewertung · Evidenz · Feststellung), Urteil. Knapp. Verdopple nicht den Prosa-Text des Artifakts.
4. Persistieren einer Zeile in der docs/SCORECARD.md des App-Repositorys (erstellen, falls nicht vorhanden): Datum · Phase · offene Tore · Bewertungen pro Dimension · Urteil · Artifact-URL. Nur committen, wenn der Benutzer darum bittet.

Regeln

• Vollständig lesen, dann bewerten. Die Rubrik verkürzt das Urteil, niemals das Lesen.
• Zitieren, nicht paraphrasieren, wenn ein Tester oder eine Datei die Aussage enthält.
• Weigere dich, etwas zu bewerten, das nicht bekannt sein kann. „Unbekannt“ ist eine gültige, ehrliche Zelle.
• Erfinde keine Benchmarks. Die einzigen numerischen Schwellenwerte, die du nennen darfst, sind die in references/research-notes.md (SUS 68/80, Ellis 40 %, CWV 2,5 s / 200 ms / 0,1, Nielsen-Schweregrad 0–4, WCAG 2.2 AA, ASVS L1). Alles andere ist ein Vergleich mit dem eigenen vorherigen Durchlauf der App.
• Gleiche Rubrik für alle Apps. Füge keine Dimensionen pro App hinzu oder entferne sie. Markiere n. z., wenn eine Dimension wirklich nicht zutrifft (z. B. Monetarisierung bei einem internen Tool) – n. z. wird aufgezeichnet, nicht übersprungen.
• Nur Dev/Staging, wenn du die Live-App bedienen musst. Niemals Produktion.
• Nur lesender Zugriff. Die Bewertungstabelle empfiehlt; sie bearbeitet die App nicht.
• Kein Artifakt, kein Durchlauf. Eine Bewertungstabelle, die nur im Chat-Scrollback lebt, ist im nächsten Quartal nicht vergleichbar. Veröffentliche immer (oder schreibe die HTML-Datei).

Kombiniert mit

• ui-usability-audit – Tiefe in der UX-Design-Dimension, visuelles Vorher/Nachher.
• qa-sweep – funktionaler PASS/FAIL, der die Zuverlässigkeit und die Kern-UX speist.
• dev-to-prod-promotion-review – das Urteil der Bewertungstabelle ist eine Eingabe für das Release-Tor.
• panel-brainstorm – wenn für die „kleinsten Fixes“ Alternativen generiert werden müssen.