| name | dependency-and-decompilation-analysis |
| description | Rules for discovering, decompiling, and classifying missing dependencies during flow analysis. Covers DLL decompilation with ilspycmd, source-vs-decompiled precedence, missing dependency classification, and what blocks migration. |
Skill: Dependency and Decompilation Analysis
Purpose: Authoritative rules for discovering, decompiling, and classifying missing dependencies during flow analysis. Follow exactly.
1. DLL Discovery
Call migration_listArtifacts with category="custom-code" to find all .dll, .jar, .cs, .vb files.
1.1 Mandatory Coverage Guardrails [NO FALSE NEGATIVES]
- Build the dependency candidate list from artifact inventory and source references, not from a root-folder file loop.
- Do NOT assume "all root
.dll files were decompiled" means dependency analysis is complete.
- Treat any assembly/namespace referenced by flow-used code as a dependency candidate until explicitly resolved.
- If a referenced assembly cannot be located in scanned source artifacts, mark it missing (fail-closed).
Anti-pattern to avoid:
- Running
Get-ChildItem -Filter *.dll only at workspace root and concluding dependency closure from that result.
2. Decompilation Procedure
2.1 When to Decompile
Do NOT blindly decompile every .dll in the source folder. Instead, decompile on demand when a DLL reference is encountered during analysis:
- An orchestration references a .NET helper class in a DLL
- A map uses a scripting functoid that calls into a DLL
