icp-cli.json

{
  "skill": "icp-cli",
  "description": "Evaluation cases for the icp-cli skill. Tests whether agents produce correct icp-cli commands and configuration instead of legacy dfx equivalents, avoid documented pitfalls, and know when to consult reference files.",
  "output_evals": [
    {
      "name": "New project setup",
      "prompt": "I want to build a dapp on ICP with a Rust backend and a React frontend. How do I set this up?",
      "expected_behaviors": [
        "Uses icp (not dfx) commands throughout",
        "Configuration file is icp.yaml, NOT dfx.json",
        "Canisters are a YAML array of objects (- name: ...), NOT a keyed map",
        "Rust canister uses a recipe with a version pin (e.g., @dfinity/rust@v3.3.0)",
        "Frontend/asset canister uses a recipe with a version pin",
        "Asset canister recipe includes explicit build commands (e.g., npm install, npm run build)",
        "Shows how to start the local network (icp network start -d)"
      ]
    },
    {
      "name": "Deploy to mainnet",
      "prompt": "My canisters work locally, how do I get them on mainnet?",
      "expected_behaviors": [
        "Uses 'icp deploy -e ic', NOT 'dfx deploy --network ic' or '--network ic'",
        "Mentions cycles are needed",
        "Mentions canister IDs are stored in .icp/data/ and should be committed to git",
        "Does NOT use --network ic flag for deployment",
        "Recommends checking ICP or cycles balance on mainnet before deploying (icp token balance -n ic or icp cycles balance -n ic)"
      ]
    },
    {
      "name": "Migrate from dfx",
      "prompt": "I have an older IC project that still uses dfx and dfx.json. It has a Motoko backend and a frontend asset canister. I also have canisters running on mainnet already. Show me the icp.yaml and the full migration steps.",
      "expected_behaviors": [
        "Shows icp.yaml with recipe-based canister configuration",
        "Motoko canister uses @dfinity/motoko recipe with a version pin",
        "Does NOT map dfx.json's \"main\" to recipe.configuration.main in icp.yaml -- under the @dfinity/motoko@v5+ recipe main belongs in mops.toml as [canisters.<name>].main",
        "Frontend canister uses a version-pinned recipe -- @dfinity/static-site (recommended) or @dfinity/asset-canister (legacy) is acceptable",
        "Mentions identity migration (export from dfx, import into icp) or references dfx-migration.md",
        "Mentions canister ID migration via .icp/data/mappings/ic.ids.json or references dfx-migration.md",
        "Uses correct icp identity commands ('icp identity default' not 'icp identity use') or references dfx-migration.md for the command mapping"
      ]
    },
    {
      "name": "Recipe version pinning",
      "prompt": "Here's my icp.yaml, does it look right?\n\ncanisters:\n  - name: backend\n    recipe:\n      type: \"@dfinity/rust\"\n      configuration:\n        package: backend",
      "expected_behaviors": [
        "Identifies that the recipe is missing a version pin",
        "Recommends pinning to a specific version (e.g., @dfinity/rust@v3.3.0)",
        "Explains that icp-cli rejects unpinned recipe references"
      ]
    },
    {
      "name": "Multi-canister environment variables",
      "prompt": "I have a frontend and two backend canisters (auth and api). How does the frontend know the canister IDs of both backends?",
      "expected_behaviors": [
        "Explains that icp-cli injects canister IDs as PUBLIC_CANISTER_ID:<name> environment variables",
        "Mentions the ic_env cookie set by the asset canister",
        "Shows safeGetCanisterEnv from @icp-sdk/core to read canister IDs",
        "Does NOT suggest using .env files or process.env.CANISTER_ID_* patterns",
        "Does NOT suggest hardcoding canister IDs"
      ]
    },
    {
      "name": "Frontend TypeScript bindings",
      "prompt": "How do I generate TypeScript bindings for my backend canister so I can call it from my React frontend?",
      "expected_behaviors": [
        "Does NOT suggest 'dfx generate' — it does not exist in icp-cli",
        "Recommends @icp-sdk/bindgen with a version constraint (>= 0.4.0) or references references/binding-generation.md which contains the version",
        "Mentions @icp-sdk/core with an explicit major pin (^6) — does NOT leave core unpinned",
        "Shows npm install commands for both packages (@icp-sdk/core and @icp-sdk/bindgen)",
        "Mentions that the .did file must exist on disk before the frontend builds",
        "Shows a Vite plugin setup using icpBindgen from @icp-sdk/bindgen, or references references/binding-generation.md for the full setup"
      ]
    },
    {
      "name": "Local network behavior",
      "prompt": "I ran icp deploy but it says the local network isn't running. I thought it was already started from my other project.",
      "expected_behaviors": [
        "Explains that local networks are project-local, unlike dfx which runs one shared global network",
        "Instructs to run 'icp network start -d' in the current project directory",
        "Does NOT suggest 'dfx start' or 'dfx start --background'"
      ]
    },
    {
      "name": "Custom build steps",
      "prompt": "I need a custom build process for my canister — it uses a special build tool, not standard cargo. How do I configure this in icp.yaml?",
      "expected_behaviors": [
        "Shows build.steps with type: script and commands array",
        "Mentions copying the WASM to $ICP_WASM_OUTPUT_PATH",
        "Mentions embedding candid metadata with ic-wasm if a .did file is needed",
        "Does NOT invent non-existent YAML fields like 'wasm', 'candid', or 'metadata' at canister level"
      ]
    },
    {
      "name": "Adversarial: env file pattern",
      "prompt": "How do I set up output_env_file in my icp.yaml so my frontend can read the canister IDs from .env?",
      "expected_behaviors": [
        "Explains that icp-cli does NOT support output_env_file",
        "Does NOT generate an icp.yaml with output_env_file",
        "Redirects to the ic_env cookie pattern with safeGetCanisterEnv",
        "Does NOT suggest reading canister IDs from process.env"
      ]
    },
    {
      "name": "Adversarial: dfx commands",
      "prompt": "I need to deploy to mainnet. Let me run dfx deploy --network ic, right?",
      "expected_behaviors": [
        "Corrects the user — dfx is legacy, use icp instead",
        "Provides the correct command: icp deploy -e ic",
        "Uses -e (environment) not --network for deployment",
        "Does NOT validate or endorse the dfx command"
      ]
    },
    {
      "name": "Candid file generation with recipes",
      "prompt": "I have a Rust backend canister using the @dfinity/rust recipe. My React frontend needs TypeScript bindings via @icp-sdk/bindgen, which requires a .did file. But I don't see a .did file anywhere in my project. Where does it come from?",
      "expected_behaviors": [
        "Explains that when candid is omitted from the recipe config, the recipe auto-generates the .did file in the build cache (not at a predictable project path)",
        "Explains that when candid is specified, the file must already exist on disk",
        "Recommends generating the .did file once, committing it, and specifying candid in the recipe config",
        "Shows how to generate the .did file (candid-extractor for Rust)",
        "Does NOT suggest using dfx generate"
      ]
    },
    {
      "name": "Adversarial: missing [canisters] section in mops.toml for Motoko v5",
      "prompt": "I set up a new Motoko canister with the @dfinity/motoko@v5.0.0 recipe. My icp.yaml has the canister named 'backend'. I have a mops.toml with [toolchain] but no [canisters] section. When I run icp build I get: 'No Motoko canisters found in mops.toml configuration'. What's wrong? Just the fix, no deploy steps.",
      "expected_behaviors": [
        "Identifies that mops.toml is missing the [canisters.backend] section required by the v5 recipe",
        "Shows adding [canisters.backend] with a main field pointing to the .mo entry point",
        "Explains that the key (backend) must exactly match the canister name in icp.yaml",
        "Does NOT suggest adding main or candid inside recipe.configuration in icp.yaml"
      ]
    },
    {
      "name": "Staging and production environments",
      "prompt": "I want to deploy my project to both a staging and production environment on mainnet, with different settings for each. How?",
      "expected_behaviors": [
        "Shows custom environment configuration in icp.yaml with multiple environments targeting the ic network",
        "Uses -e flag to select the environment (e.g., icp deploy -e staging)",
        "Does NOT suggest using separate dfx.json configs or --network flags",
        "Shows that environments can have different canister settings"
      ]
    },
    {
      "name": "Motoko project setup",
      "prompt": "I want to create a new ICP project with a Motoko backend canister. Walk me through the setup.",
      "expected_behaviors": [
        "Uses icp (not dfx) commands throughout",
        "Configuration file is icp.yaml, NOT dfx.json",
        "Motoko canister uses @dfinity/motoko@v5.0.0 recipe with NO recipe.configuration block in icp.yaml",
        "Mentions installing ic-mops (npm i -g ic-mops)",
        "Shows a mops.toml with a [toolchain] section specifying a concrete moc version (not a placeholder like <version>)",
        "Shows a [canisters.backend] section in mops.toml with the main field pointing to the .mo entry point",
        "Does NOT put main or candid inside recipe.configuration in icp.yaml"
      ]
    },
    {
      "name": "Full-stack Motoko config artifacts (icp.yaml, mops.toml, bindings)",
      "prompt": "For a hello-world ICP dapp with a Motoko backend (canister 'backend') and a React frontend that calls it via @icp-sdk/bindgen, show ONLY these artifacts, each in one fenced block with at most a one-line note — no React component code, no prose walkthrough, no deploy steps: (1) icp.yaml with both the Motoko backend and the frontend asset canister, (2) mops.toml, (3) the single command that produces the committed .did file, (4) the @icp-sdk/bindgen Vite plugin config block.",
      "expected_behaviors": [
        "icp.yaml has Motoko backend with @dfinity/motoko@v5.0.0 (no recipe.configuration block) and a version-pinned asset canister for the frontend",
        "mops.toml has a [toolchain] section (concrete moc version) and a [canisters.backend] section with a main field",
        "Uses 'mops generate candid backend' (or 'mops generate candid') as the command that produces the committed .did file — NOT the older 'mops build' + 'cp .mops/.build/backend.did' two-step",
        "Uses @icp-sdk/bindgen (>= 0.4.0) Vite plugin with a didFile path pointing to the committed .did file",
        "Uses @icp-sdk/core pinned to ^6 if a version is referenced",
        "Does NOT use dfx commands, dfx.json, .env files, or process.env for canister IDs"
      ]
    },
    {
      "name": "Adversarial: mixing fields across config styles",
      "prompt": "Here's my icp.yaml for a Rust backend. Is this correct?\n\ncanisters:\n  - name: backend\n    candid: backend/backend.did\n    init_arg_file: ./args.candid\n    recipe:\n      type: \"@dfinity/rust@v3.2.0\"\n      configuration:\n        package: backend",
      "expected_behaviors": [
        "Identifies that candid is not a valid canister-level field when using a recipe — it belongs inside recipe.configuration",
        "Identifies that init_arg_file is not a valid field at all — the correct form is init_args with a path property (e.g., init_args: { path: ./args.candid, format: candid })",
        "Shows the corrected icp.yaml with candid moved inside recipe.configuration and init_arg_file replaced with init_args",
        "Does NOT validate or endorse the original config as correct"
      ]
    },
    {
      "name": "Adversarial: porting @dfinity/agent actor setup to bindgen",
      "prompt": "I'm migrating my frontend from dfx to icp-cli. What's wrong with this actor setup? Just the fixes and a corrected snippet, no Vite or deploy setup:\n\nimport { HttpAgent } from '@icp-sdk/core';\nimport { createActor } from './bindings/backend';\nconst agent = new HttpAgent({ identity, host });\nconst backend = createActor(canisterId, { agent });",
      "expected_behaviors": [
        "Sets rootKey from safeGetCanisterEnv() (IC_ROOT_KEY from the ic_env cookie), noting the agent otherwise defaults to the mainnet root key",
        "Replaces the deprecated `new HttpAgent(...)` constructor — with `{ agentOptions }` or `HttpAgent.create()` from '@icp-sdk/core/agent'",
        "Removes the hardcoded host (the agent's default host resolution picks the right endpoint)",
        "Keeps `identity` in the corrected setup (in `agentOptions` or in `HttpAgent.create`), so calls stay authenticated",
        "Does NOT claim that passing { agent } to createActor is ignored or silently results in an anonymous identity"
      ]
    },
    {
      "name": "Candid opt T representation in bindgen",
      "prompt": "My backend has a Motoko function `getNickname : () -> (opt text) query`. In my React frontend I'm checking `if (result.length > 0) { name = result[0]; }` but it crashes with 'Cannot read properties of null'. What's wrong?",
      "expected_behaviors": [
        "Identifies that @icp-sdk/bindgen's wrapper converts opt T to T | null, not [] | [T]",
        "Shows the correct check: result !== null instead of result.length > 0",
        "The corrected code uses result directly as the value (name = result), NOT result[0] — the wrapper unwraps the array",
        "Does NOT suggest the issue is a backend error or missing canister deployment"
      ]
    },
    {
      "name": "Dev server configuration",
      "prompt": "I have a React frontend and a backend canister deployed locally. How do I set up the Vite dev server to talk to my local canisters?",
      "expected_behaviors": [
        "Shows or references the getDevServerConfig() pattern from references/dev-server.md",
        "States prerequisites: local network must be running (icp network start -d) and backend must be deployed (icp deploy backend) before vite dev works",
        "Wraps getDevServerConfig() in a mode guard so it only runs during vite dev (command === 'serve'), not during vite build",
        "Uses icp network status and icp canister status commands (not dfx or hardcoded ports)",
        "Reads canister IDs with `icp canister status <name> --id-only` (or its short form `-i`), not by parsing full status output",
        "Mentions the ic_env cookie for passing canister IDs and root key to the frontend",
        "Does NOT suggest using .env files or process.env for canister IDs"
      ]
    },
    {
      "name": "Port conflict on local network start",
      "prompt": "I'm trying to start my local network with 'icp network start -d' but it fails because port 8000 is already in use. How do I fix this?",
      "expected_behaviors": [
        "Distinguishes between two scenarios: another icp-cli project holding the port vs. a non-icp service",
        "For another icp-cli project: provides 'icp network stop --project-root-override /path/to/other-project'",
        "For a non-icp service: recommends configuring gateway.port in icp.yaml to use an alternate port",
        "Mentions 'icp network status --json' to read the actual gateway URL dynamically instead of hardcoding localhost:8000",
        "Does NOT suggest killing processes manually or using dfx commands"
      ]
    },
    {
      "name": "Parallel local networks across git worktrees",
      "prompt": "I'm running two agents on the same icp-cli project in separate git worktrees, and both need a local network running at the same time. Starting the second fails with a port conflict on 8000. How do I run both at once? Just the icp.yaml config and the command to find each network's port — no deploy steps.",
      "expected_behaviors": [
        "Sets gateway.port to 0 in the managed local network config so the OS assigns a free ephemeral port per worktree",
        "Explains that local networks are project-local, so each worktree runs its own independent network",
        "Uses 'icp network status --json' (reading gateway_url or api_url) to look up each network's actual assigned port",
        "Does NOT invent a non-existent command such as 'icp network config'",
        "Does NOT hardcode localhost:8000 or tell the user to stop one of the networks"
      ]
    },
    {
      "name": "Scripted project creation in CI",
      "prompt": "What is the correct icp new command to scaffold a Rust project non-interactively in CI? Just the command, no deploy steps.",
      "expected_behaviors": [
        "Uses --silent flag with icp new to suppress the interactive prompt",
        "Passes --subfolder and --define flags to icp new (e.g., --subfolder rust --define project_name=...)",
        "Uses icp (not dfx) for project scaffolding"
      ]
    },
    {
      "name": "Adversarial: deploying to mainnet with the anonymous identity",
      "prompt": "My project works great locally. Can I just run 'icp deploy -e ic' to deploy to mainnet?",
      "expected_behaviors": [
        "Warns that the anonymous identity (default locally) should not be used on mainnet — it is shared and uncontrolled",
        "Uses `icp identity list` (singular) to list identities — NOT `icp identities list`, which is not a valid subcommand",
        "Recommends checking and switching to a named identity using icp commands (e.g. icp identity default, icp identity new, icp identity default <name>) — NOT dfx identity use",
        "Recommends checking mainnet balance before deploying using icp commands: icp token balance -n ic or icp cycles balance -n ic (NOT dfx ledger balance)",
        "Mentions that a new identity will need to be funded with ICP or cycles before it can deploy",
        "Presents identity switch and balance check as required prerequisites before running icp deploy -e ic, not optional suggestions"
      ]
    },
    {
      "name": "Funding a new identity with a card (finds buy-cycles)",
      "prompt": "I made a new icp identity for mainnet. I have no ICP and no exchange account, only a credit card. How do I get cycles onto it so that icp deploy -e ic works? Name the command and which skill to load for it; no full deploy walkthrough.",
      "expected_behaviors": [
        "Names `icp cycles buy` (with `-n ic`) as the way to buy cycles with a card for the identity itself",
        "Points to the `buy-cycles` skill for the purchase flow",
        "Does not route the user through dfx, an exchange, a wallet, or `icp cycles mint` (which needs ICP the user does not have)"
      ]
    },
    {
      "name": "Candid generation for Motoko binding (mops generate candid)",
      "prompt": "I have a Motoko backend canister named 'backend' built with the @dfinity/motoko@v5.0.0 recipe. My React frontend needs TypeScript bindings via @icp-sdk/bindgen, which needs a .did file committed at a stable path. What's the simplest way to produce and keep that .did file up to date? Just the command and workflow, no deploy steps.",
      "expected_behaviors": [
        "Recommends 'mops generate candid backend' (or 'mops generate candid') to produce the .did file",
        "Notes it extracts the Candid interface from Motoko source WITHOUT compiling WASM",
        "Explains it overwrites the [canisters.backend].candid path if set, otherwise writes <name>.did next to main and records the path in mops.toml",
        "States it must be re-run after each interface change and the .did and mops.toml committed together",
        "Does NOT present the older 'mops build backend' + 'cp .mops/.build/backend.did' two-step as the primary approach",
        "Does NOT suggest dfx generate"
      ]
    },
    {
      "name": "Adversarial: Rust recipe package parameter (minimal vs workspace)",
      "prompt": "Using the @dfinity/rust@v3.3.0 recipe, show me two icp.yaml snippets, no prose: (1) the MINIMAL config for one Rust canister named 'backend' whose Cargo.toml [package] name is also 'backend'; (2) the same canister named 'backend' but where the Cargo.toml [package] name is instead 'my_app_backend'.",
      "expected_behaviors": [
        "The first (matching-name) snippet OMITS the package parameter entirely — it does not include a redundant 'package: backend'",
        "The second (differing-name) snippet sets 'package: my_app_backend' inside recipe.configuration",
        "Conveys that package defaults to the canister name (so it is optional when they match) and is only needed when the Cargo package name differs",
        "Does NOT claim the package parameter is required in the matching-name case"
      ]
    },
    {
      "name": "Adversarial: bundling a project into an .icp package",
      "prompt": "Using icp-cli, what command packages my project into a self-contained .icp bundle I can deploy on a machine without the Rust toolchain, and how do I deploy from it? Give the commands and any important caveats — no project setup steps.",
      "expected_behaviors": [
        "Uses `icp project bundle --output <path>` as the bundling command",
        "Notes the command is experimental and hidden from `icp --help` output but works",
        "Deploys by extracting the archive (tar -xzf) and running `icp deploy` from the extracted directory",
        "Does NOT invent commands like `icp bundle`, `icp package`, or `dfx` equivalents"
      ]
    },
    {
      "name": "Adversarial: prebuilt recipe config key",
      "prompt": "I have a pre-compiled canister.wasm.gz and want to deploy it with icp-cli using the prebuilt recipe. Show me just the icp.yaml canister entry, no deploy steps.",
      "expected_behaviors": [
        "Points the pre-built WASM at the `path` configuration key (e.g. path: canister.wasm.gz)",
        "Does NOT use a `wasm` key inside recipe.configuration — that key does not exist and fails with a cryptic strict-mode template error naming `path`",
        "Uses a version-pinned `@dfinity/prebuilt` recipe type string (e.g. @dfinity/prebuilt@v2.1.0), not the non-functional v1.0.0"
      ]
    },
    {
      "name": "Adversarial: agentOptions host on a custom domain",
      "prompt": "My icp-cli frontend uses @icp-sdk/bindgen bindings and safeGetCanisterEnv(). Show the agentOptions object I should pass to createActor so the same build works on the local network AND in production, including when the site is served from a custom domain. Just the agentOptions object plus a one-sentence explanation.",
      "expected_behaviors": [
        "Omits host from agentOptions (or explicitly says to leave it unset), relying on the agent's default host resolution",
        "Sets rootKey from the ic_env cookie (canisterEnv?.IC_ROOT_KEY via safeGetCanisterEnv)",
        "Explains that with host unset, a page on a custom domain sends its calls to https://icp-api.io",
        "Gives the reason: a custom domain serves only the HTTP gateway, not /api/v2",
        "Does NOT set host to window.location.origin (conditionally or unconditionally)"
      ]
    },
    {
      "name": "Parallel agents sharing global CLI state (ICP_HOME)",
      "prompt": "I'm running several coding agents against the same icp-cli repo in separate git worktrees and they keep blocking each other on icp commands and stepping on each other's identity. How do I isolate them? Just the environment setup and identity commands, no deploy walkthrough.",
      "expected_behaviors": [
        "Sets ICP_HOME to a per-worktree/per-agent directory to isolate global CLI state",
        "Sets the managed local network gateway.port to 0 so each worktree gets a free port",
        "Warns that the OS keyring is shared across ICP_HOME values, so identity names collide between agents",
        "Recommends 'icp identity new <name> --storage plaintext' for the per-agent identity",
        "Does NOT claim that ICP_HOME alone isolates keyring-stored identities",
        "Mentions that a fresh ICP_HOME re-downloads the package cache (recipes, network launcher)"
      ]
    },
    {
      "name": "Adversarial: agent host and root key in a Node test against the local network",
      "prompt": "My Node test script (vitest) calls my backend canister on the icp-cli local network through the createActor function generated by @icp-sdk/bindgen. Show just the agentOptions object I pass to createActor, how I get its values, and one sentence on why each is needed. No test framework setup.",
      "expected_behaviors": [
        "Sets host explicitly to the api_url from `icp network status --json`, explaining that outside a browser the default host is https://icp-api.io (mainnet)",
        "Sets rootKey from root_key in the same `icp network status --json` output, decoded from hex to bytes",
        "Does NOT use safeGetCanisterEnv() or the ic_env cookie, which only exist in a browser"
      ]
    },
    {
      "name": "Adversarial: mainnet deploy fails with Insufficient cycles (finds buy-cycles)",
      "prompt": "I ran `icp deploy -e ic` to deploy to mainnet and it failed with: `Insufficient cycles. Requested: 500000000000 cycles, available balance: 0 cycles.` I don't hold any ICP. What is wrong and how do I fix it? Name the commands and which skill to load; no full deploy walkthrough.",
      "expected_behaviors": [
        "Explains that the deploying identity's cycles-ledger balance on mainnet is empty and checks it with `icp cycles balance -n ic`",
        "Names `icp cycles buy` (with `-n ic`) as the fix for buying cycles with a card when the user has no ICP, and points to the `buy-cycles` skill for the purchase flow",
        "Does NOT recommend dfx (dfx wallet, dfx cycles, dfx ledger), a cycles wallet canister, the NNS dapp, or a cycles faucet, and does NOT present `icp cycles mint` as the fix (it needs ICP the user does not have)"
      ]
    },
    {
      "name": "Pre-deploy cycles estimate with a short balance",
      "prompt": "My icp.yaml has three canisters (backend, frontend, worker), none created on mainnet yet (.icp/data/mappings/ic.ids.json does not exist). `icp cycles balance -n ic` for my deploy identity prints 2.5T cycles. Should I run `icp deploy -e ic` now? Give the arithmetic and what to do, briefly; no icp.yaml, no code.",
      "expected_behaviors": [
        "Estimates before deploying: 3 creations x the 2T default `--cycles` (plus the 100M cycles-ledger fee each), about 6T, and states the gap against 2.5T (roughly 3.5T, or up to about 4.5T with a margin)",
        "Says no: does NOT tell the user to run `icp deploy -e ic` as is and see whether it fails",
        "Offers both ways to close the gap and leaves the choice to the user: `icp cycles mint --cycles <gap> -n ic` if `icp token balance -n ic` shows enough ICP, or `icp cycles buy --cycles <gap> -n ic` with a card (the buy-cycles skill)",
        "Does NOT suggest dfx, a cycles wallet canister, the NNS dapp, or a cycles faucet"
      ]
    }
  ],
  "trigger_evals": {
    "description": "Queries to test whether the skill activates correctly. 'should_trigger' queries should cause the skill to load; 'should_not_trigger' queries should NOT activate this skill.",
    "should_trigger": [
      "Set up a new Internet Computer project with Rust",
      "How do I deploy my canister to the local network?",
      "What's the icp.yaml config for a Motoko canister?",
      "I'm getting an error with dfx deploy, can you help?",
      "How do I start the local replica?",
      "Migrate my dfx.json project to the new CLI",
      "How do I create a new identity for mainnet deployment?",
      "What recipes are available for icp-cli?",
      "My icp deploy is failing with a build error",
      "How do I check my canister status on mainnet?",
      "How do I set up output_env_file for my canister IDs?",
      "Generate TypeScript declarations for my canister",
      "Configure Vite dev server for local IC development",
      "Build a hello-world dapp with Motoko and React",
      "Bundle my Internet Computer project into a .icp package I can share",
      "How do I package my canister project so it deploys without a build toolchain?"
    ],
    "should_not_trigger": [
      "Add access control to my Motoko canister",
      "How does stable memory work in Rust canisters?",
      "Implement ICRC-1 token transfer in my canister",
      "Write a unit test for my Motoko actor",
      "Set up inter-canister calls between two canisters",
      "How do I use certified variables?",
      "Explain the IC consensus mechanism",
      "Add Internet Identity login to my frontend",
      "How do I handle canister upgrades safely?",
      "What's the best way to store large data on-chain?"
    ]
  }
}