semantic-equivalence-checker

Semantic Equivalence Checker

How this skill is reached

Nothing in the plugin references this skill. It is not in the manifest, it has no slash command, and the migration skill's <skill-match> block does not list it, so it will never be suggested and nothing routes into it on its own.

It is reached by being named together with where it lives, for example "using the semantic-equivalence-checker sub-skill under migration/SKILL.md, check ...". Naming the checker without saying where it sits is not enough: an agent asked only to "use the semantic checker" does not find this directory, and will compare the XML and the models unaided instead, which produces something shaped like a verdict with no deterministic pass behind it.

On Entry

Tell the user:

Semantic equivalence check — I'll compare an Informatica workflow XML against its converted dbt model and tell you whether the conversion preserves the business logic. I won't change any files. I need the XML, the dbt models folder, and which workflow to check.

<SKILL_DIR> below is the absolute path to the directory containing this file. Loaded the normal way, from the migration skill's <skill-match> block, that is the semantic-equivalence-checker directory sitting beside the migration skill's own SKILL.md, so resolve it from wherever you read this file.

If you do not have an absolute path for it, say so and stop. Every command here runs as uv run --project <SKILL_DIR>, and a relative path gives --project nothing to resolve. Do not fall back to comparing the files by hand: see the check at the end of Step 3.

Run every shell command through uv run --project <SKILL_DIR>, which resolves the checker's dependencies from its pyproject.toml. Do not activate a virtualenv or invoke python directly — the package is only importable under that project.

Chain the commands of a single step into one bash call. Each separate call costs the user another permission prompt.

Architecture: one workflow, many models