pjt222/transmute
i18n/de/skills/transmute/SKILL.md
Eine einzelne Funktion, ein Modul oder eine Datenstruktur von einer Form in eine andere transformieren und dabei das wesentliche Verhalten beibehalten. Leichtgewichtiger als der volle Athanor-Zyklus, geeignet fuer gezielte Konvertierungen bei denen die Ein- und Ausgabeformen gut verstanden sind. Anwenden beim Konvertieren einer Funktion zwischen Sprachen, Verschieben eines Moduls zwischen Paradigmen, Migrieren eines API-Konsumenten auf eine neue Version, Konvertieren von Datenformaten oder Ersetzen einer Abhaengigkeit — wenn der Transformationsumfang eine einzelne Funktion, Klasse oder ein Modul ist statt eines ganzen Systems.
$ install --global
skillsauthnpx skillsauth add pjt222/agent-almanac transmuteInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 15, 2026, 9:26 AM4.1s1 file scanned
SKILL.md
- name:
- transmute
- locale:
- de
- source_locale:
- en
- source_commit:
- 6f65f316
- translator:
- claude
- translation_date:
- 2026-03-17
- description:
- >
- license:
- MIT
- allowed-tools:
- Read Write Edit Bash Grep Glob
- author:
- Philipp Thoss
- version:
- 1.0
- domain:
- alchemy
- complexity:
- intermediate
- language:
- multi
- tags:
- alchemy, transmutation, conversion, refactoring, transformation, targeted
Transmutieren
Ein bestimmtes Stueck Code oder Daten von einer Form in eine andere transformieren — Sprachuebersetzung, Paradigmenwechsel, Formatkonvertierung oder API-Migration — und dabei das wesentliche Verhalten und die Semantik beibehalten.
Wann verwenden
- Konvertieren einer Funktion von einer Sprache in eine andere (Python nach R, JavaScript nach TypeScript)
- Verschieben eines Moduls von einem Paradigma (klassenbasiert zu funktional, Callbacks zu async/await)
- Migrieren eines API-Konsumenten von v1 zu v2 eines externen Dienstes
- Konvertieren von Daten zwischen Formaten (CSV nach Parquet, REST nach GraphQL-Schema)
- Ersetzen einer Abhaengigkeit durch eine gleichwertige (moment.js durch date-fns, jQuery durch natives JS)
- Wenn der Transformationsumfang eine einzelne Funktion, Klasse oder ein Modul ist (nicht ein ganzes System)
Eingaben
- Erforderlich: Quellmaterial (Dateipfad, Funktionsname oder Datenbeispiel)
- Erforderlich: Zielform (Sprache, Paradigma, Format oder API-Version)
- Optional: Verhaltensvertrag (Tests, Typsignaturen oder erwartete Ein-/Ausgabepaare)
- Optional: Einschraenkungen (muss Rueckwaertskompatibilitaet wahren, Performancebudget)
Vorgehensweise
Schritt 1: Das Quellmaterial analysieren
Genau verstehen was die Quelle tut bevor eine Transformation versucht wird.
- Die Quelle vollstaendig lesen — jeden Zweig, Grenzfall und Fehlerpfad
- Den Verhaltensvertrag identifizieren:
- Welche Eingaben akzeptiert sie? (Typen, Bereiche, Grenzfaelle)
- Welche Ausgaben erzeugt sie? (Rueckgabewerte, Seiteneffekte, Fehlersignale)
- Welche Invarianten haelt sie aufrecht? (Reihenfolge, Eindeutigkeit, referenzielle Integritaet)
- Abhaengigkeiten katalogisieren: was importiert, ruft auf oder setzt die Quelle voraus?
- Falls Tests existieren, sie lesen um das erwartete Verhalten zu verstehen
- Falls keine Tests existieren, vor dem Transmutieren Verhaltenscharakterisierungstests schreiben
Erwartet: Ein vollstaendiges Verstaendnis dessen was die Quelle tut (nicht wie sie es tut). Der Verhaltensvertrag ist explizit und testbar.
Bei Fehler: Wenn die Quelle zu komplex fuer eine einzelne Transmutation ist, erwaegen sie in kleinere Teile zu zerlegen oder zum vollstaendigen athanor-Verfahren zu eskalieren. Bei mehrdeutigem Verhalten um Klaerung bitten statt zu raten.
Schritt 2: Quelle auf Zielform abbilden
Die Transformationsabbildung entwerfen.
- Fuer jedes Element in der Quelle das Ziel-Aequivalent identifizieren:
- Sprachkonstrukte: Schleifen -> map/filter, Klassen -> Closures usw.
- API-Aufrufe: alter Endpunkt -> neuer Endpunkt, Aenderungen der Request-/Response-Struktur
- Datentypen: DataFrame-Spalten -> Schema-Felder, verschachteltes JSON -> flache Tabellen
- Elemente ohne direktes Aequivalent identifizieren:
- Quellfunktionalitaet die im Ziel fehlt (z.B. Pattern Matching in einer Sprache ohne diese Funktion)
- Zielidiome die in der Quelle nicht existieren (z.B. R-Vektorisierung vs. Python-Schleifen)
- Fuer jede Luecke eine Anpassungsstrategie waehlen:
- Emulieren: das Verhalten mit zielseitigen Konstrukten nachbilden
- Vereinfachen: wenn das Quellkonstrukt ein Workaround war, die native Loesung des Ziels nutzen
- Dokumentieren: wenn sich das Verhalten leicht aendert, den Unterschied explizit festhalten
- Die Transformationsabbildung schreiben: Quellelement -> Zielelement, fuer jedes Stueck
Erwartet: Eine vollstaendige Abbildung in der jedes Quellelement ein Ziel hat. Luecken sind identifiziert und Anpassungsstrategien gewaehlt.
Bei Fehler: Wenn zu viele Elemente kein direktes Aequivalent haben, ist die Transformation moeglicherweise ungeeignet (z.B. Transmutieren eines stark objektorientierten Designs in eine Sprache ohne Klassen). Die Zielform ueberdenken oder zu athanor eskalieren.
Schritt 3: Die Transformation ausfuehren
Die Zielform gemaess der Abbildung schreiben.
- Die Zieldatei(en) mit passender Struktur und Boilerplate erstellen
- Jedes Element gemaess der Abbildung aus Schritt 2 transmutieren:
- Den Verhaltensvertrag beibehalten — gleiche Eingaben erzeugen gleiche Ausgaben
- Zielseitige Idiome verwenden statt woertlicher Uebersetzungen
- Fehlerbehandlung beibehalten oder verbessern
- Abhaengigkeiten behandeln:
- Quellabhaengigkeiten durch Ziel-Aequivalente ersetzen
- Wenn eine Abhaengigkeit kein Aequivalent hat, einen minimalen Adapter implementieren
- Inline-Kommentare nur dort hinzufuegen wo die Transformation nicht offensichtlich war
Erwartet: Eine vollstaendige Zielimplementierung die der Transformationsabbildung folgt. Der Code liest sich als waere er nativ in der Zielform geschrieben, nicht mechanisch uebersetzt.
Bei Fehler: Wenn ein bestimmtes Element sich der Transformation widersetzt, es isolieren. Alles andere zuerst transformieren, dann das widerspenstige Element mit fokussierter Aufmerksamkeit angehen. Wenn es wirklich nicht transmutiert werden kann, dokumentieren warum und einen Workaround bereitstellen.
Schritt 4: Verhaltensaequivalenz verifizieren
Bestaetigen dass die transmutierte Form das Verhalten des Originals bewahrt.
- Die Verhaltensvertragstests gegen die Zielimplementierung ausfuehren
- Fuer jeden Testfall verifizieren:
- Gleiche Eingaben -> gleiche Ausgaben (innerhalb akzeptabler Toleranz fuer numerische Konvertierungen)
- Gleiche Fehlerbedingungen -> aequivalente Fehlersignale
- Seiteneffekte (falls vorhanden) sind bewahrt oder als geaendert dokumentiert
- Grenzfaelle explizit pruefen:
- Null/NA/undefined-Behandlung
- Leere Sammlungen
- Grenzwerte (maximaler Integer, leerer String, Arrays der Laenge Null)
- Wenn die Zielform Faehigkeiten hinzufuegt (z.B. Typsicherheit), diese ebenfalls verifizieren
Erwartet: Alle Verhaltensvertragstests bestehen. Grenzfaelle werden aequivalent behandelt. Alle Verhaltensunterschiede sind dokumentiert und beabsichtigt.
Bei Fehler: Wenn Tests fehlschlagen, die Differenz zwischen Quell- und Zielverhalten finden. Das Ziel an den Quellvertrag anpassen. Wenn die Abweichung beabsichtigt ist (z.B. Beheben eines Fehlers im Original), sie explizit dokumentieren.
Validierung
- [ ] Quellmaterial vollstaendig analysiert mit explizitem Verhaltensvertrag
- [ ] Transformationsabbildung deckt jedes Quellelement ab
- [ ] Luecken identifiziert mit dokumentierten Anpassungsstrategien
- [ ] Zielimplementierung verwendet native Idiome (keine woertliche Uebersetzung)
- [ ] Alle Verhaltensvertragstests bestehen gegen das Ziel
- [ ] Grenzfaelle verifiziert (null, leer, Grenzwerte)
- [ ] Abhaengigkeiten mit Ziel-Aequivalenten aufgeloest
- [ ] Alle Verhaltensunterschiede dokumentiert und beabsichtigt
Haeufige Stolperfallen
- Woertliche Uebersetzung: Python-in-R oder Java-in-JavaScript schreiben statt Zielidiome zu verwenden. Das Ergebnis sollte nativ aussehen
- Verhaltenstests ueberspringen: Transmutieren ohne Tests bedeutet man kann die Aequivalenz nicht verifizieren. Zuerst Charakterisierungstests schreiben
- Grenzfaelle ignorieren: Der Standardpfad transmutiert leicht; in den Grenzfaellen verstecken sich die Fehler
- Adapter ueberdesignen: Wenn eine Abhaengigkeit einen 200-Zeilen-Adapter braucht, ist der Transmutationsumfang zu gross
- Kommentare woertlich uebernehmen: Kommentare sollten den Zielcode erklaeren, nicht die Quelle widerspiegeln. Sie neu schreiben
Verwandte Skills
athanor— Vollstaendige vierstufige Transformation fuer Systeme die zu gross fuer eine einzelne Transmutation sindchrysopoeia— Optimierung transmutierten Codes fuer maximale Wertgewinnungreview-software-architecture— Architekturpruefung nach der Transmutation fuer groessere Konvertierungenserialize-data-formats— Spezialisierte Datenformat-Konvertierungsverfahren
Related Skills
pjt222/unleash-the-agents
testing
VerifiedTrustedCommunity
Launch all available agents in parallel waves for open-ended hypothesis generation on problems where the correct domain is unknown. Use when facing a cross-domain problem with no clear starting point, when single-agent approaches have stalled, or when diverse perspectives are more valuable than deep expertise. Produces a ranked hypothesis set with convergence analysis and adversarial refinement.
9SKILL.mdUpdated Apr 15, 2026
pjt222/test-cli-application
tools
VerifiedTrustedCommunity
Write integration tests for a Node.js CLI application using the built-in node:test module. Covers the exec helper pattern, output assertions, filesystem state verification, cleanup hooks, JSON output parsing, error case testing, and state restoration after destructive tests. Use when adding tests to an existing CLI, testing a new command, verifying adapter behavior across frameworks, or setting up CI for a CLI tool.
9SKILL.mdUpdated Apr 15, 2026
pjt222/screen-trademark
development
VerifiedTrustedCommunity
Screen a proposed trademark for conflicts and distinctiveness before filing. Covers trademark database searches (TMview, WIPO Global Brand Database, USPTO TESS), distinctiveness analysis using the Abercrombie spectrum, likelihood of confusion assessment using DuPont factors and EUIPO relative grounds, common law rights evaluation, and goods/services overlap analysis. Produces a conflict report with a risk matrix. Use before adopting a new brand name, logo, or slogan — distinct from patent prior art search, which uses different databases, legal frameworks, and analysis methods.
9SKILL.mdUpdated Apr 15, 2026
pjt222/scaffold-cli-command
tools
VerifiedTrustedCommunity
Scaffold a new CLI command using Commander.js with options, action handler, three output modes (human-readable, quiet, JSON), and optional ceremony variant. Covers command naming, option design, shared context patterns, error handling, and integration testing. Use when adding a command to an existing Commander.js CLI, designing a new CLI tool from scratch, or standardizing command structure across a multi-command CLI.
9SKILL.mdUpdated Apr 15, 2026