transmute
À propos
Transmute est une compétence de transformation ciblée pour convertir une fonction, un module ou une structure de données unique en une autre forme tout en préservant son comportement fondamental. C'est une alternative plus légère à un cycle de refactorisation complet, idéale pour des conversions bien comprises comme la traduction d'une fonction entre langages ou la migration d'un consommateur d'API. Utilisez-la pour des tâches ciblées où la portée est une unité discrète, et non un système entier.
Installation rapide
Claude Code
Recommandénpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/transmuteCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
Transmute
Transform specific code/data → another form (lang translation, paradigm shift, format conversion, API migration) preserving essential behavior + semantics.
Use When
- Convert fn between langs (Python → R, JS → TS)
- Shift module between paradigms (class-based → functional, callbacks → async/await)
- Migrate API consumer v1 → v2
- Convert data formats (CSV → Parquet, REST → GraphQL schema)
- Replace dep w/ equiv (moment.js → date-fns, jQuery → vanilla JS)
- Scope = single fn, class, module (NOT full system)
In
- Required: Source (file path, fn name, data sample)
- Required: Target form (lang, paradigm, format, API ver)
- Optional: Behavioral contract (tests, type signatures, expected I/O pairs)
- Optional: Constraints (backward compat, perf budget)
Do
Step 1: Analyze Source
Understand exactly what src does before transforming.
- Read src completely — every branch, edge case, err path
- ID behavioral contract:
- What ins accepts? (types, ranges, edge cases)
- What outs produces? (return values, side effects, err signals)
- What invariants maintains? (ordering, uniqueness, ref integrity)
- Catalog deps: what src imports, calls, relies on?
- Tests exist → read for expected behavior
- No tests → write behavioral characterization tests before transmuting
Got: Complete understanding of what src does (not how). Behavioral contract explicit + testable.
If err: Src too complex for single transmute → break into smaller pieces | escalate to full athanor proc. Behavior ambiguous → ask clarification vs guess.
Step 2: Map Source → Target
Design transformation mapping.
- Per src element, ID target equivalent:
- Lang constructs: loops → map/filter, classes → closures
- API calls: old endpoint → new, req/res shape changes
- Data types: dataframe cols → schema fields, nested JSON → flat tables
- ID elements w/ no direct equiv:
- Src features missing in target (pattern matching in lang w/o it)
- Target idioms not in src (R vectorization vs Python loops)
- Per gap, choose adaptation strategy:
- Emulate: reproduce behavior w/ target-native constructs
- Simplify: src construct was workaround → use target's native solution
- Document: behavior changes slightly → note explicit
- Write transformation map: src → target per piece
Got: Complete mapping where every src element has target dest. Gaps ID'd + adaptation chosen.
If err: Too many no direct equivs → transformation may be inappropriate (highly OO design → lang w/o classes). Reconsider target | escalate athanor.
Step 3: Execute
Write target form following map.
- Create target file(s) w/ structure + boilerplate
- Transmute each element per Step 2 map:
- Preserve behavioral contract — same ins → same outs
- Use target-native idioms not literal translations
- Maintain | improve err handling
- Handle deps:
- Replace src deps w/ target equivs
- No equiv → impl minimal adapter
- Inline comments ONLY where transformation non-obvious
Got: Complete target impl following map. Reads like written natively in target, not mechanically translated.
If err: Specific element resists → isolate. Transform everything else first, tackle resistant w/ focused attention. Truly can't be transmuted → doc why + workaround.
Step 4: Verify Behavioral Equivalence
Confirm transmuted preserves original's behavior.
- Run behavioral contract tests vs target impl
- Per test:
- Same ins → same outs (within tolerance for numeric conversions)
- Same err conditions → equiv err signals
- Side effects (if any) preserved | doc'd as changed
- Check edge cases explicit:
- Null/NA/undefined handling
- Empty collections
- Boundary values (max int, empty string, zero-length arrays)
- Target adds capabilities (type safety) → verify those too
Got: All behavioral contract tests pass. Edge cases handled equivalent. Behavioral diffs doc'd + intentional.
If err: Tests fail → diff src vs target behavior, find divergence. Fix target → match src contract. Divergence intentional (fixing src bug) → doc explicit.
Check
- Src fully analyzed w/ explicit behavioral contract
- Transformation map covers every src element
- Gaps ID'd w/ adaptation strategies doc'd
- Target uses native idioms (not literal translation)
- All behavioral contract tests pass vs target
- Edge cases verified (null, empty, boundary)
- Deps resolved w/ target equivs
- Behavioral diffs doc'd + intentional
Traps
- Literal translation: Python-in-R | Java-in-JS vs using target idioms. Result should look native.
- Skip behavioral tests: Transmute w/o tests → can't verify equivalence. Write characterization tests first.
- Ignore edge cases: Happy path transmutes easy; edge cases hide bugs.
- Over-engineer adapter: Dep needs 200-line adapter → scope too large.
- Transmute comments verbatim: Comments explain target code, not echo src. Rewrite.
→
athanor— Full 4-stage transformation for systems too large for single transmutechrysopoeia— Optimizing transmuted code for max value extractionreview-software-architecture— Post-transmutation arch review for larger conversionsserialize-data-formats— Specialized data format conversion procedures
Dépôt GitHub
Compétences associées
executing-plans
DesignUtilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.
requesting-code-review
DesignCette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.
connect-mcp-server
DesignCette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.
web-cli-teleport
DesignCette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.
