transmute
Acerca de
Transmute es una habilidad de transformación dirigida para convertir una única función, módulo o estructura de datos a otra forma, preservando su comportamiento central. Es una alternativa más ligera a un ciclo de refactorización completo, ideal para conversiones bien comprendidas, como traducir una función entre lenguajes o migrar un consumidor de API. Úsala para tareas enfocadas donde el alcance es una unidad discreta, no un sistema completo.
Instalación rápida
Claude Code
Recomendadonpx 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/transmuteCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
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
Repositorio GitHub
Habilidades relacionadas
executing-plans
DiseñoUtilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
requesting-code-review
DiseñoEsta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
connect-mcp-server
DiseñoEsta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
web-cli-teleport
DiseñoEsta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
