feat: comprehensive icp-cli skill improvements for dfx migration

[marc0olo]

Summary

Significantly expands the icp-cli skill to cover real-world dfx-to-icp migration scenarios that were discovered during an actual migration. The original skill covered basic config and commands but missed critical patterns around frontend integration, canister discovery, and binding generation.

New Common Pitfalls (10-12)

• #10: No .env file / output_env_file — icp-cli injects canister IDs via env vars, frontends read the ic_env cookie
• #11: No dfx generate — use @icp-sdk/bindgen Vite plugin with a .did file on disk
• #12: Candid file behavior with recipes — candid specified = must exist, omitted = auto-generated in build cache. Includes commands to generate .did files manually for both Rust (candid-extractor) and Motoko (moc --idl)

New Configuration Sections

• Canister Environment Variables — how frontends (ic_env cookie + @icp-sdk/core) and backends (Rust env_var_value, Motoko Runtime.envVar with import) discover each other
• Binding Generation — @icp-sdk/bindgen Vite plugin setup for single and multi-canister projects, actor creation pattern, non-Vite CLI fallback
• Dev Server Configuration — complete Vite dev server pattern using icp network status --json for api_url + root_key, multi-canister cookie setup, ICP_ENVIRONMENT for multi-environment support

New Migration Sections

• Local network port change — dfx 4943 → icp-cli 8000, recommends dynamic api_url from icp network status
• Remove .env file and output_env_file — dfx-specific env vars to clean up
• Frontend package migration — required upgrade from @dfinity/* to @icp-sdk/* (bindgen depends on core), step-by-step instructions
• Post-Migration Verification — replaces "Verify It Works" with actionable verification steps an agent can grep/check

Updated Existing Sections

• Configuration mapping — added output_env_file and dfx generate rows
• Replaced "Verify It Works" throwaway project with project-specific verification checklist

Context

These gaps were discovered during a real migration of marc0olo/promptathon-showcase from dfx to icp-cli, then validated against the example migration PRs (#1303, #1308, #1309, #1311) in dfinity/examples and the official icp-cli documentation.

References

• https://dfinity.github.io/icp-cli/0.2/concepts/canister-discovery/
• https://dfinity.github.io/icp-cli/0.2/concepts/binding-generation/
• https://github.com/dfinity/icp-cli/tree/main/examples/icp-frontend-environment-variables
• https://github.com/dfinity/icp-cli-recipes/blob/main/recipes/rust/recipe.hbs
• https://github.com/dfinity/icp-cli-recipes/blob/main/recipes/motoko/recipe.hbs
• feat: migrate hosting examples to icp-cli + remove svelte-starter examples#1303
• feat: add icp-cli support for rust/hello_world examples#1309
• feat: add icp-cli support for motoko/hello_world examples#1308
• feat: add icp-cli support to flying_ninja (Rust + Motoko) examples#1311
• docs: update Motoko env var example to motoko-core Runtime.envVar icp-cli#408

[raymondk]

Maybe we play it safe and don't ask for this to be deleted?

[marc0olo]

I think it should be fine. The agent using the skill should create and commit the new mapping file. And typically the canister id could be recovered through the git history. If a dev explicitly asks to keep dfx working, I expect the Agent to respect this decision and keep the files required for dfx.