maltego-trx-migration-planner

Maltego TRX Migration Planner Skill

Purpose

Inspect a TRX-based transform project read-only and produce a structured migration plan that another agent (the implementer) can execute. Do NOT make code changes during planning.

Golden Rule

Produce a plan document BEFORE any broad code changes. The planner's output is a migration plan — not code.

Default Migration Contract

When the user asks for a TRX-to-SDK migration and does not provide a more specific contract, infer this default:

• Preserve externally visible transform behavior.
• Preserve transform IDs/names unless incompatible with SDK naming.
• Preserve input/output entity types and key properties.
• Preserve settings semantics, including auth, optionality, popup/global behavior, and runtime names.
• Preserve API/client behavior, including request parameters, response parsing, pagination, retries, shared/singleton clients, and no-result handling.
• Preserve user-visible messages and error behavior where the SDK has an equivalent.
• Use source behavior evidence to decide what must be kept, but rewrite transform authoring to SDK-native APIs.
• Do not preserve TRX registry/wrapper/discovery artifacts unless explicitly requested.

If the source behavior is ambiguous, record a concrete assumption in the plan and continue with the safest SDK-native migration. Do not ask the user to provide obvious defaults that can be inferred from source.

Step-by-Step: Plan a TRX Migration

1. Read-Only Project Inspection

Start with file discovery — no edits:

find . -name "*.py" | sort
ls -la
cat pyproject.toml 2>/dev/null || cat setup.py 2>/dev/null || cat requirements.txt 2>/dev/null

Identify:

• Project structure (single file vs. package)
• TRX version in use (from maltego_trx.* or from extensions.*)
• Number of transform classes
• Public transform IDs, display names, input entities, output entities, and settings from registries, decorators, CSV/config files, and transform classes
• API/client modules used by transforms, including shared clients and request construction helpers
• No-result, partial-result, exception, and user-message behavior
• If the source resembles the public MaltegoTech/maltego-trx-examples project, load references/known-trx-examples.md before planning so you can compare TRX patterns such as register_transform_function, MaltegoTransform().returnOutput(), request.Slider, sidecar CSV lookups, and entity aliases like maltego_trx.entities.IPAddress.