loot

Jede Sitzung hinterlässt Beute. Das meiste stirbt im Chatlog. Deine Aufgabe: Finde sie, schreibe alles auf, bewerte es anhand von Beweisen statt Begeisterung und versende nur das seltene Stück, das es verdient, nachdem der Benutzer zugestimmt hat.

Der meiste Wert von loot liegt in LOOT.md: einer fortlaufenden Aufzeichnung von allem, was der Benutzer herausgefunden hat. Veröffentlichen ist die Ausnahme.

Beute ist jeder wertvolle Teil der Sitzung, nicht nur Nebenentdeckungen:

Art	Wie es aussieht	Übliche Form
Build	Die App, das Tool oder das Skript, um das es in der Sitzung ging	Repo
Komponente	Ein Teil, das außerhalb dieses Projekts funktioniert (ein Hook, ein Parser, eine Konfiguration, ein Prompt)	Repo oder Gist
Technik	Ein Trick, Fix oder eine Methode (machte X 4× schneller, brachte Y lokal zum Laufen)	Beitrag + Gist oder Repo
Know-how	Korrekturen und Feedback, die der Benutzer dir gegeben hat und die die Ausgabe verbesserten	Skill
Geschichte	Der Weg vom Problem zum Ergebnis, inklusive Sackgassen	Beitrag
Daten	Benchmarks, Vergleiche, Messungen	Beitrag oder Repo README

Eine Sitzung enthält oft mehrere Elemente. Ein einzelnes Element verdient oft mehrere Formen (Repo + Beitrag + Demo).

Modi

Befehl	Tut
`/loot`	Diese Sitzung scannen, die Tabelle zeigen, fragen, was versendet werden soll
`/loot "<thema>"`	Nur eine Sache ansehen (günstiger): „der ffmpeg-Trick“
`/loot 2`, `/loot all`	Drop 2 versenden, oder alle Drops, die mit Selten oder besser bewertet sind, ohne nachzufragen
`/loot --list`	Aktuelle vergangene Sitzungen auflisten, um eine auszuwählen
`/loot <session.jsonl>`	Eine vergangene Sitzung scannen anstelle dieser
`/loot review`	Das, was bereits in `LOOT.md` ist, neu bewerten (siehe Schritt 6)

1. Scannen

Lies die gesamte Konversation und die Dateien, die sie berührt hat. Für eine vergangene Sitzung oder wenn frühere Teile dieser zusammengefasst wurden, lies stattdessen das Transkript:

node <dieser Skill-Ordner>/scripts/transcript.mjs list          # aktuelle Claude Code + Codex Sitzungen
node <dieser Skill-Ordner>/scripts/transcript.mjs read <datei>   # komprimierter Text, Geheimnisse geschwärzt

Das Transkript dieser Sitzung ist die neueste Datei in ~/.claude/projects/<projekt>/. Wenn du über eine Zusammenfassung hinaus nicht lesen konntest, sag das in der Tabelle: Frühe Entdeckungen können fehlen. Liste Kandidaten auf. Schreibe für jeden auf, was er tut und den Beweis, dass es funktioniert (Test, Benchmark, Vorher/Nachher, die Reaktion des Benutzers).

Verwerfe ein Element, wenn es nur in der Umgebung dieses Benutzers funktioniert und nicht verallgemeinert werden kann, wenn es größtenteils der Code eines anderen ist, oder wenn es die private Arbeit des Benutzers oder eines Kunden ist. Erwähne keine Geheimnisse, Anmeldeinformationen oder persönlichen Daten aus der Sitzung in der Tabelle.

2. Bewerten

Die Bewertung ist ein Filter, und ihre Aufgabe ist es, Nein zu sagen. Du bist ein schlechter Richter über Arbeit, die du gerade erst mitgemacht hast: Du kannst nicht sagen, was für die Welt neu ist, und du neigst dazu, den Benutzer zu schmeicheln. Also kommt Seltenheit von Beweisen, und die Beurteilung findet abseits der Konversation statt.

Sammle Beweise für jeden Kandidaten:

query: Was ein Fremder mit diesem Problem in ein Suchfeld eingeben würde
search: Führe sie aus (Web, GitHub, npm/PyPI) und liste die nächsten Ergebnisse mit Links auf. Suche nach dem, was es tut, nicht nach seinem Namen. Kein Suchtool: "nicht geprüft".
proof: Ein Test, Benchmark oder Vorher/Nachher, der tatsächlich in der Sitzung stattfand, mit Ort (der Befehl, die Datei, die Nachricht), oder "keine". Rekonstruiere niemals Beweise aus dem Gedächtnis: KI-Notizen erfinden Namen, Zahlen und Details.
edge: Was es tut, was das nächste Ergebnis nicht tut, wenn möglich gemessen

Bewerte es woanders. Wenn du einen Subagenten starten kannst, gib ihm nur die Kandidaten und ihre Beweise, niemals die Konversation, mit dieser Anweisung: "Bewerte jedes Element gegen die untenstehende Messlatte. Plädiere zuerst für Common und hebe ein Element nur an, wenn seine Beweise die Messlatte erreichen. Wenn du unsicher bist, bewerte niedriger. Verwende nur die gegebenen Beweise; füge niemals welche hinzu oder nimm sie an. Für jedes Element, das eine Anforderung von der nächsten Stufe entfernt ist, nenne den günstigsten Beweis, der es anheben würde." Wenn du das nicht kannst, schreibe das stärkste Argument dafür, dass jedes Element Common ist, bevor du es bewertest.

Seltenheit	Benötigt alles von	Formen
Common	alles unter Rare	eine Zeile in `LOOT.md`
Rare	eine echte Query; eine zitierte Suche, die nichts Gleichwertiges gefunden hat, oder einen gemessenen Vorteil gegenüber dem nächsten Ergebnis; Beweis, dass es funktioniert	Gist, kurzer Beitrag oder ein kleines Repo oder Skill
Epic	Rare, plus einen gemessenen Vorteil gegenüber einer benannten Alternative, und es läuft von einem sauberen Klon	Repo oder Skill, Beitrag, Demo, Launch-Entwürfe

Harte Regeln:

"nicht geprüft" oder "kein Beweis" bedeutet Common, egal wie gut es sich anfühlt.
Etwas Gleichwertiges existiert und der Vorteil ist nicht gemessen: Common. Ein Vorteil, der aus den READMEs anderer Projekte argumentiert wird, ist nicht gemessen.
Unentschieden werden abgerundet.
Knapp daneben bekommen einen nächsten Schritt. Ein Element, das eine Anforderung von der nächsten Stufe entfernt ist, wird mit [COMMON, nah an Rare] oder [RARE, nah an Epic] gekennzeichnet und bekommt eine next:-Zeile: der günstigste Beweis, der es anheben würde, und ungefähr wie lange es dauert. Das macht aus einem "Nein" eine Aufgabe, die der Benutzer wählen kann.
Erwarte, dass fast alles Common ist. Wenn mehr als ein Element in einer Sitzung über Common bewertet wird, sage, warum diese Sitzung die Ausnahme ist.
Common ist kein Fehlschlag. Es ist der Journaleintrag, der verhindert, dass die Arbeit verloren geht.

Zeige die Beutetabelle, mit den Beweisen für alles über Common, und halte an:

LOOT: 3 Drops
1. [RARE, nah an Epic] remotion-ae-transitions: After-Effects-artige Übergänge in Remotion, vollständig lokal
   query: "remotion after effects transitions"
   search: @remotion/transitions (Dias, Überblendungen, Wipes), ein bezahltes Vorlagenpaket; keins macht diese
   proof: 6 Übergänge gerendert und in der Sitzung genehmigt
   edge: nicht gemessen, daher nicht Epic → Gist + kurzer Beitrag
   next: Dieselben 3 Aufnahmen mit @remotion/transitions rendern und vergleichen; dann ein sauberer Klon-Lauf (~45 min)
2. [COMMON] ffmpeg Two-Pass-Trick: im ffmpeg-Wiki dokumentiert → LOOT.md
3. [COMMON] benutzerdefinierter Schriftartenlader: nur in diesem Projekt nützlich → LOOT.md
Welche versenden? (Nummern, "all" oder "none")

Zeige höchstens 7 Drops, die stärksten zuerst. Alles andere bekommt eine Zeile unter "notiert".

Nachdem du die Tabelle gezeigt hast, hänge sie an LOOT.md im Projektstamm an (erstellen, falls nicht vorhanden), mit Datum. Ein Drop verdient einen vollständigen Eintrag nur, wenn eine zukünftige Sitzung ohne ihn schiefgehen oder echte Arbeit wiederholen müsste. Ansonsten ist es ein einzeiliger "notiert"-Eintrag. Das Journal ist nur nützlich, wenn es lesbar bleibt.

3. Schmieden

Baue für jedes ausgewählte Element das fertige Ding in einem neuen Ordner außerhalb der Historie des aktuellen Repos (Standard ../<slug>, oder wo der Benutzer sagt). Lies references/forge.md für die Checkliste jeder Form. Kurz:

Verallgemeinere es. Entferne Projektnamen, hartcodierte Pfade, Kundendetails und toten Code. Es muss von einem sauberen Klon mit den Schritten des READMEs laufen. Führe es aus.
Benenne es. Kurz, einprägsam, sagt, was es tut. Überprüfe, dass der Name frei ist: gh search repos <name>, npm view <name> (Exit-Code 1 bedeutet frei).
Tagline. Ein Satz, der einem Fremden sagt, was es tut und für wen.
Logo. Einfach, ein oder zwei Farben, lesbar bei 16px, funktioniert auf hellem und dunklem Hintergrund.
Social Preview. Eine 1280×640 Karte (Logo, Name, Tagline), sodass geteilte Links ein Bild anzeigen statt einer leeren GitHub-Karte.
README. Ergebnis zuerst, dann Schnellstart, dann wie es funktioniert.
Proof. Ein Test, ein Benchmark oder ein Vorher/Nachher. Erfinde niemals Zahlen.

Skills: Wenn die gewählte Form ein Skill ist, folge dem skill-factory-Skill, der neben diesem ausgeliefert wird (../skill-factory/SKILL.md), und übergib ihm die Beweise des Elements (Query, Suchergebnisse, Proof, Edge) als Startspezifikation. Überspringe die Schritte 3–5 für dieses Element: skill-factory testet, überprüft und gated die Veröffentlichung selbst.

4. Prüfen (niemals überspringen)

Scanne jeden Ordner, den du veröffentlichen wirst, auf Geheimnisse:
- immer: node <dieser Skill-Ordner>/scripts/scan.mjs <ordner>
- auch, wenn gitleaks installiert ist: gitleaks dir <ordner>, und gitleaks git <ordner>, wenn der Ordner eine Git-Historie hat.
Behebe jeden Fund oder markiere einen Fehlalarm mit loot:allow in dieser Zeile und begründe warum. Prüfe jede warn-Zeile von Hand. Schiebe niemals bestehende Git-Historie, die gitleaks nicht gescannt hat; ohne gitleaks, veröffentliche stattdessen von einem frischen git init.
Lies jede Datei, die veröffentlicht wird. Suche nach persönlichen Daten, Kundennamen, internen Hostnamen, privaten Repo-Links und Code unter einer anderen Lizenz.
Zeige dem Benutzer ein Manifest: jedes Ziel (Repo-Name, öffentlich oder privat, Blog-Entwurf oder live), die Dateien, die Tagline. Frage nach einem klaren Ja. Ein Ja deckt genau dieses Manifest ab, nichts weiter.

5. Versenden

Lies references/ship.md für Befehle und Fallbacks. Verwende zuerst deine eigenen Werkzeuge; falle darauf zurück, dem Benutzer einen ausführungsbereiten Befehl oder eine Datei zu übergeben.

Repo: gh repo create, Beschreibung, Themen, pushen.
Beitrag: dev.to oder Hashnode als Entwurf, wenn ein Token bereits konfiguriert ist; sonst eine Markdown-Datei. Medium: Markdown plus Importanweisungen.
Launch-Beiträge (Show HN, X, Reddit), nur Epic: Entwürfe in einem gitignorierten launch/-Ordner. Niemals posten.
Schließe mit Links zu allem Versendeten und allem, was für den Benutzer übrig bleibt.

6. Überprüfen (`/loot review`)

Bewertungen aus einer Sitzung sind eine Schätzung. Beweise sammeln sich im Laufe der Zeit an:

Lies LOOT.md. Gruppiere Einträge, die dasselbe Ding sind, das erneut gesehen wurde (dieselbe Grundidee, auch wenn anders formuliert).
Bewerte einen Drop neu, wenn sich etwas geändert hat: Er kam in 3 oder mehr Sitzungen vor, er hat Beweise gewonnen (Benutzer, ein Benchmark, jemand hat danach gefragt), oder eine neue Suche findet nichts Gleichwertiges mehr. Verwende dieselben Beweisregeln und denselben externen Bewerter.
Zeige, was sich bewegt hat und warum. Schreibe einen datierten "review"-Abschnitt in LOOT.md; überschreibe niemals alte Einträge. Biete dann an, alles zu versenden, was jetzt Rare oder besser ist.

Verwende, was der Agent hat

Bedarf	Am besten	Fallback, der immer funktioniert
Logo / Titelbild	deine eigene Bildgenerierung oder ein Image-MCP, falls vorhanden	handgeschriebenes SVG
Geheimnis-Scan	`gitleaks` (deckt auch Git-Historie ab)	mitgeliefert `scripts/scan.mjs`
Demovideo	Remotion (Node)	Screenshots + GIF
Screenshots	ein Browser-Tool	frage den Benutzer nach einem
"Existiert es?"	Websuche	markiere "nicht geprüft" (begrenzt es auf Common)
Vergangene oder zusammengefasste Sitzungen	`scripts/transcript.mjs` (Claude Code, Codex)	bitte den Benutzer, die Konversation einzufügen oder zu exportieren
Unabhängige Bewertung	ein Subagent, der niemals die Konversation sieht	das stärkste Argument für Common, zuerst geschrieben
Repo veröffentlichen	`gh` CLI	drucke die Befehle
Beitrag veröffentlichen	die API der Plattform mit einem vorhandenen Token	Markdown-Datei

Regeln

Nichts wird ohne das Ja des Benutzers zum genauen Manifest öffentlich.
Niemals nach Anmeldeinformationen fragen, diese eingeben oder speichern. Wenn ein Tool nicht angemeldet ist, falle zurück.
Veröffentliche niemals Geheimnisse, persönliche Daten oder die Arbeit von Kunden oder Arbeitgebern.
Respektiere Lizenzen: lizenziere Code, den du nicht geschrieben hast, nicht um.
Keine erfundenen Beweise: keine gefälschten Benchmarks, Benutzer, Zitate oder Sternzahlen.
Schreibe mit der Stimme des Benutzers aus dem Chat, nicht wie eine Pressemitteilung.

hamgarian/loot-skill

Was ist loot-skill?

In Ihrer bevorzugten KI fragen

Dokumentation