> ## Documentation Index
> Fetch the complete documentation index at: https://www.zkcompression.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Prompts

> Ready-to-use AI prompts for Light Protocol. Copy a prompt, paste into your AI coding agent, and let it implement the recipe in your project.

{/* toolkits */}

## Token Distribution

<Accordion title="Token distribution">
  Copy the prompt below or view the [guide](/compressed-tokens/token-distribution).

  <Prompt description="Distribute compressed tokens via airdrop" actions={["copy", "cursor"]}>
    {`---
        description: Distribute compressed tokens via airdrop
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Distribute compressed tokens via airdrop

        Context:
        - Guide: https://zkcompression.com/compressed-tokens/token-distribution
        - Skills and resources index: https://zkcompression.com/skill.md
        - Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/airdrop
        - Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js, @solana/spl-token
        - Example repo: https://github.com/Lightprotocol/example-token-distribution
        - Webapp alternative: https://airship.helius.dev/ (Airship by Helius Labs, up to 200k recipients)

        Key APIs: LightTokenProgram.compress(), getTokenPoolInfos(), selectTokenPoolInfo(), getStateTreeInfos(), selectStateTreeInfo(), buildAndSignTx(), sendAndConfirmTx()

        ### 1. Index project
        - Grep \`LightTokenProgram|compress|getTokenPoolInfos|selectTokenPoolInfo|getStateTreeInfos|@lightprotocol|airdrop|distribution\` across src/
        - Glob \`**/*.ts\` for project structure
        - Identify: existing airdrop/distribution logic, token minting setup, recipient list format
        - Check package.json for existing @lightprotocol/* or @solana/spl-token dependencies
        - Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review all three tabs (Localnet Guide, Simple Airdrop, Batched)
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: what scale? (<10k recipients = simple airdrop, 10k+ = batched)
        - AskUserQuestion: localnet testing first, or production deploy?
        - AskUserQuestion: do you have an existing SPL mint, or need to create one?
        - AskUserQuestion: do you need decompression/claim functionality, or just direct distribution?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan
        - For simple airdrop: create mint → mint SPL tokens → LightTokenProgram.compress() with recipients array
        - For batched: create instruction batches → manage blockhash refresh → sign and send with retry logic
        - Address lookup table needed for production (mainnet: 9NYFyEqPkyXUhkerbGHXUXkvb4qpzeEdHuGpgbgpH1NJ)
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - Add deps if missing: Bash \`npm install @lightprotocol/compressed-token @lightprotocol/stateless.js @solana/spl-token\`
        - Set up RPC: \`createRpc(RPC_ENDPOINT)\` with a ZK Compression endpoint (Helius, Triton)
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Bash \`tsc --noEmit\`
        - Bash run existing test suite or execute localnet test airdrop
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Distribute compressed tokens via airdrop
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Distribute compressed tokens via airdrop

  Context:
  - Guide: https://zkcompression.com/compressed-tokens/token-distribution
  - Skills and resources index: https://zkcompression.com/skill.md
  - Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/airdrop
  - Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js, @solana/spl-token
  - Example repo: https://github.com/Lightprotocol/example-token-distribution
  - Webapp alternative: https://airship.helius.dev/ (Airship by Helius Labs, up to 200k recipients)

  Key APIs: LightTokenProgram.compress(), getTokenPoolInfos(), selectTokenPoolInfo(), getStateTreeInfos(), selectStateTreeInfo(), buildAndSignTx(), sendAndConfirmTx()

  ### 1. Index project
  - Grep `LightTokenProgram|compress|getTokenPoolInfos|selectTokenPoolInfo|getStateTreeInfos|@lightprotocol|airdrop|distribution` across src/
  - Glob `**/*.ts` for project structure
  - Identify: existing airdrop/distribution logic, token minting setup, recipient list format
  - Check package.json for existing @lightprotocol/* or @solana/spl-token dependencies
  - Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review all three tabs (Localnet Guide, Simple Airdrop, Batched)
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: what scale? (<10k recipients = simple airdrop, 10k+ = batched)
  - AskUserQuestion: localnet testing first, or production deploy?
  - AskUserQuestion: do you have an existing SPL mint, or need to create one?
  - AskUserQuestion: do you need decompression/claim functionality, or just direct distribution?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan
  - For simple airdrop: create mint → mint SPL tokens → LightTokenProgram.compress() with recipients array
  - For batched: create instruction batches → manage blockhash refresh → sign and send with retry logic
  - Address lookup table needed for production (mainnet: 9NYFyEqPkyXUhkerbGHXUXkvb4qpzeEdHuGpgbgpH1NJ)
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - Add deps if missing: Bash `npm install @lightprotocol/compressed-token @lightprotocol/stateless.js @solana/spl-token`
  - Set up RPC: `createRpc(RPC_ENDPOINT)` with a ZK Compression endpoint (Helius, Triton)
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Bash `tsc --noEmit`
  - Bash run existing test suite or execute localnet test airdrop
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

## Compressed PDA

<Accordion title="Nullifier PDAs">
  Copy the prompt below or view the [guide](/compressed-pdas/nullifier-pda).

  <Prompt description="Create rent-free nullifier PDAs to prevent duplicate actions" actions={["copy", "cursor"]}>
    {`---
        description: Create rent-free nullifier PDAs to prevent duplicate actions
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Create rent-free nullifier PDAs to prevent duplicate actions

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/nullifier-pda
        - Skills and resources index: https://zkcompression.com/skill.md
        - Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/zk-nullifier
        - Rust crates: light-nullifier-program, light-client
        - TS packages: @lightprotocol/nullifier-program, @lightprotocol/stateless.js
        - Example: https://github.com/Lightprotocol/examples-light-token/blob/main/rust-client/actions/create_nullifier.rs
        - Program source: https://github.com/Lightprotocol/nullifier-program/

        Key APIs:
        - Rust: create_nullifier_ix(), fetch_proof(), build_instruction(), derive_nullifier_address()
        - TS: createNullifierIx(), fetchProof(), buildInstruction(), deriveNullifierAddress()

        ### 1. Index project
        - Grep \`nullifier|create_nullifier|createNullifierIx|deriveNullifierAddress|NFLx5WGPrTHHvdRNsidcrNcLxRruMC92E4yv7zhZBoT\` across src/
        - Glob \`**/*.rs\` and \`**/*.ts\` for project structure
        - Identify: existing transaction building, duplicate prevention logic, payment flow
        - Check Cargo.toml or package.json for existing light-* dependencies
        - Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both Rust and TS code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: Rust or TypeScript?
        - AskUserQuestion: what is the goal? (prevent duplicate payments, idempotent instruction execution, other use case)
        - AskUserQuestion: do you need the helper (create_nullifier_ix) or manual proof fetching (fetch_proof + build_instruction)?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's pattern: create unique 32-byte ID → build nullifier instruction → prepend to transaction
        - If checking existence is needed, add derive_nullifier_address + get_compressed_account check
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - For Rust: Bash \`cargo add light-nullifier-program@0.1 light-client@0.23\`
        - For TypeScript: Bash \`npm install @lightprotocol/nullifier-program @lightprotocol/stateless.js@^0.23.0\`
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Rust: Bash \`cargo check\` + \`cargo test\` if tests exist
        - TypeScript: Bash \`tsc --noEmit\` + run existing test suite if present
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Create rent-free nullifier PDAs to prevent duplicate actions
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Create rent-free nullifier PDAs to prevent duplicate actions

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/nullifier-pda
  - Skills and resources index: https://zkcompression.com/skill.md
  - Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/zk-nullifier
  - Rust crates: light-nullifier-program, light-client
  - TS packages: @lightprotocol/nullifier-program, @lightprotocol/stateless.js
  - Example: https://github.com/Lightprotocol/examples-light-token/blob/main/rust-client/actions/create_nullifier.rs
  - Program source: https://github.com/Lightprotocol/nullifier-program/

  Key APIs:
  - Rust: create_nullifier_ix(), fetch_proof(), build_instruction(), derive_nullifier_address()
  - TS: createNullifierIx(), fetchProof(), buildInstruction(), deriveNullifierAddress()

  ### 1. Index project
  - Grep `nullifier|create_nullifier|createNullifierIx|deriveNullifierAddress|NFLx5WGPrTHHvdRNsidcrNcLxRruMC92E4yv7zhZBoT` across src/
  - Glob `**/*.rs` and `**/*.ts` for project structure
  - Identify: existing transaction building, duplicate prevention logic, payment flow
  - Check Cargo.toml or package.json for existing light-* dependencies
  - Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both Rust and TS code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: Rust or TypeScript?
  - AskUserQuestion: what is the goal? (prevent duplicate payments, idempotent instruction execution, other use case)
  - AskUserQuestion: do you need the helper (create_nullifier_ix) or manual proof fetching (fetch_proof + build_instruction)?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's pattern: create unique 32-byte ID → build nullifier instruction → prepend to transaction
  - If checking existence is needed, add derive_nullifier_address + get_compressed_account check
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - For Rust: Bash `cargo add light-nullifier-program@0.1 light-client@0.23`
  - For TypeScript: Bash `npm install @lightprotocol/nullifier-program @lightprotocol/stateless.js@^0.23.0`
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Rust: Bash `cargo check` + `cargo test` if tests exist
  - TypeScript: Bash `tsc --noEmit` + run existing test suite if present
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="Client guide (TypeScript & Rust)">
  Copy the prompt below or view the [guide](/compressed-pdas/guides/client-guide).

  <Prompt description="Write client code to interact with compressed PDA programs" actions={["copy", "cursor"]}>
    {`---
        description: Write client code to interact with compressed PDA programs
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Write client code to interact with compressed PDA programs

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/guides/client-guide
        - Skills and resources index: https://zkcompression.com/skill.md
        - TS packages: @lightprotocol/stateless.js, @lightprotocol/compressed-token, @solana/web3.js
        - Rust crates: light-client, light-sdk
        - TS example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create/tests
        - Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create/programs/create/tests
        - All operations: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor

        Key APIs:
        - TS: createRpc(), deriveAddressSeedV2(), deriveAddressV2(), getValidityProofV0(), PackedAccounts, SystemAccountMetaConfig, getStateTreeInfos(), selectStateTreeInfo()
        - Rust: LightClientConfig, LightClient, derive_address(), get_validity_proof(), PackedAccounts, SystemAccountMetaConfig, get_random_state_tree_info()

        ### 1. Index project
        - Grep \`@lightprotocol|stateless\.js|createRpc|deriveAddress|getValidityProof|PackedAccounts|light_client|light_sdk|derive_address|get_validity_proof\` across src/
        - Glob \`**/*.ts\` and \`**/*.rs\` for project structure
        - Identify: RPC setup, existing compressed account operations, program ID references
        - Check package.json or Cargo.toml for existing light-* dependencies
        - Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both TypeScript and Rust code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: TypeScript or Rust?
        - AskUserQuestion: what is the goal? (new client from scratch, add client calls to existing project, migrate from regular accounts)
        - AskUserQuestion: which operations? (create only, full CRUD, specific subset like create + update)
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's step order: Setup → Address derivation → Validity proof → PackedAccounts → Instruction data → Build instruction → Send transaction
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - For TypeScript: Bash \`npm install @lightprotocol/stateless.js @lightprotocol/compressed-token @solana/web3.js\`
        - For Rust: Bash \`cargo add light-client@0.23 light-sdk@0.23\`
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - TypeScript: Bash \`tsc --noEmit\` + run existing test suite if present
        - Rust: Bash \`cargo check\` + \`cargo test\` if tests exist
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Write client code to interact with compressed PDA programs
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Write client code to interact with compressed PDA programs

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/guides/client-guide
  - Skills and resources index: https://zkcompression.com/skill.md
  - TS packages: @lightprotocol/stateless.js, @lightprotocol/compressed-token, @solana/web3.js
  - Rust crates: light-client, light-sdk
  - TS example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create/tests
  - Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create/programs/create/tests
  - All operations: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor

  Key APIs:
  - TS: createRpc(), deriveAddressSeedV2(), deriveAddressV2(), getValidityProofV0(), PackedAccounts, SystemAccountMetaConfig, getStateTreeInfos(), selectStateTreeInfo()
  - Rust: LightClientConfig, LightClient, derive_address(), get_validity_proof(), PackedAccounts, SystemAccountMetaConfig, get_random_state_tree_info()

  ### 1. Index project
  - Grep `@lightprotocol|stateless\.js|createRpc|deriveAddress|getValidityProof|PackedAccounts|light_client|light_sdk|derive_address|get_validity_proof` across src/
  - Glob `**/*.ts` and `**/*.rs` for project structure
  - Identify: RPC setup, existing compressed account operations, program ID references
  - Check package.json or Cargo.toml for existing light-* dependencies
  - Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both TypeScript and Rust code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: TypeScript or Rust?
  - AskUserQuestion: what is the goal? (new client from scratch, add client calls to existing project, migrate from regular accounts)
  - AskUserQuestion: which operations? (create only, full CRUD, specific subset like create + update)
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's step order: Setup → Address derivation → Validity proof → PackedAccounts → Instruction data → Build instruction → Send transaction
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - For TypeScript: Bash `npm install @lightprotocol/stateless.js @lightprotocol/compressed-token @solana/web3.js`
  - For Rust: Bash `cargo add light-client@0.23 light-sdk@0.23`
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - TypeScript: Bash `tsc --noEmit` + run existing test suite if present
  - Rust: Bash `cargo check` + `cargo test` if tests exist
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="Create compressed accounts">
  Copy the prompt below or view the [guide](/compressed-pdas/guides/how-to-create-compressed-accounts).

  <Prompt description="Build a program that creates compressed accounts with addresses" actions={["copy", "cursor"]}>
    {`---
        description: Build a program that creates compressed accounts with addresses
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Build a program that creates compressed accounts with addresses

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-create-compressed-accounts
        - Skills and resources index: https://zkcompression.com/skill.md
        - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
        - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create
        - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/create

        Key SDK API: LightAccount::new_init(), derive_address()

        ### 1. Index project
        - Grep \`declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|seeds|init|payer|space\` across src/
        - Glob \`**/*.rs\` and \`**/Cargo.toml\` for project structure
        - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
        - Read Cargo.toml — note existing dependencies and Solana SDK version
        - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both Anchor and Native Rust code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: what is the goal? (new program from scratch, add account creation to existing program, migrate from regular accounts)
        - AskUserQuestion: Anchor or Native Rust framework?
        - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Derive Address → Address Tree Check → Initialize Account → Light System Program CPI
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - Add deps: Bash \`cargo add light-sdk@0.23\` (add \`anchor_lang@0.31\` for Anchor or \`solana-program@2.2\` + \`borsh@0.10\` for Native Rust)
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Bash \`cargo build-sbf\` or \`anchor build\`
        - Bash \`cargo test-sbf\` or \`anchor test\` if tests exist
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Build a program that creates compressed accounts with addresses
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Build a program that creates compressed accounts with addresses

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-create-compressed-accounts
  - Skills and resources index: https://zkcompression.com/skill.md
  - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
  - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create
  - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/create

  Key SDK API: LightAccount::new_init(), derive_address()

  ### 1. Index project
  - Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|seeds|init|payer|space` across src/
  - Glob `**/*.rs` and `**/Cargo.toml` for project structure
  - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
  - Read Cargo.toml — note existing dependencies and Solana SDK version
  - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both Anchor and Native Rust code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: what is the goal? (new program from scratch, add account creation to existing program, migrate from regular accounts)
  - AskUserQuestion: Anchor or Native Rust framework?
  - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Derive Address → Address Tree Check → Initialize Account → Light System Program CPI
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Bash `cargo build-sbf` or `anchor build`
  - Bash `cargo test-sbf` or `anchor test` if tests exist
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="Update compressed accounts">
  Copy the prompt below or view the [guide](/compressed-pdas/guides/how-to-update-compressed-accounts).

  <Prompt description="Build a program that updates compressed accounts" actions={["copy", "cursor"]}>
    {`---
        description: Build a program that updates compressed accounts
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Build a program that updates compressed accounts

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-update-compressed-accounts
        - Skills and resources index: https://zkcompression.com/skill.md
        - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
        - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/update
        - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/update

        Key SDK API: LightAccount::new_mut()

        ### 1. Index project
        - Grep \`declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|mut|update|modify\` across src/
        - Glob \`**/*.rs\` and \`**/Cargo.toml\` for project structure
        - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
        - Read Cargo.toml — note existing dependencies and Solana SDK version
        - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both Anchor and Native Rust code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: what is the goal? (new program from scratch, add account update to existing program, migrate from regular accounts)
        - AskUserQuestion: Anchor or Native Rust framework?
        - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Update Compressed Account → Light System Program CPI
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - Add deps: Bash \`cargo add light-sdk@0.23\` (add \`anchor_lang@0.31\` for Anchor or \`solana-program@2.2\` + \`borsh@0.10\` for Native Rust)
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Bash \`cargo build-sbf\` or \`anchor build\`
        - Bash \`cargo test-sbf\` or \`anchor test\` if tests exist
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Build a program that updates compressed accounts
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Build a program that updates compressed accounts

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-update-compressed-accounts
  - Skills and resources index: https://zkcompression.com/skill.md
  - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
  - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/update
  - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/update

  Key SDK API: LightAccount::new_mut()

  ### 1. Index project
  - Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|mut|update|modify` across src/
  - Glob `**/*.rs` and `**/Cargo.toml` for project structure
  - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
  - Read Cargo.toml — note existing dependencies and Solana SDK version
  - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both Anchor and Native Rust code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: what is the goal? (new program from scratch, add account update to existing program, migrate from regular accounts)
  - AskUserQuestion: Anchor or Native Rust framework?
  - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Update Compressed Account → Light System Program CPI
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Bash `cargo build-sbf` or `anchor build`
  - Bash `cargo test-sbf` or `anchor test` if tests exist
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="Close compressed accounts">
  Copy the prompt below or view the [guide](/compressed-pdas/guides/how-to-close-compressed-accounts).

  <Prompt description="Build a program that closes compressed accounts" actions={["copy", "cursor"]}>
    {`---
        description: Build a program that closes compressed accounts
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Build a program that closes compressed accounts

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-close-compressed-accounts
        - Skills and resources index: https://zkcompression.com/skill.md
        - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
        - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/close
        - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/close

        Key SDK API: LightAccount::new_close()

        ### 1. Index project
        - Grep \`declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|close|delete|remove\` across src/
        - Glob \`**/*.rs\` and \`**/Cargo.toml\` for project structure
        - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
        - Read Cargo.toml — note existing dependencies and Solana SDK version
        - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both Anchor and Native Rust code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: what is the goal? (new program from scratch, add account close to existing program, migrate from regular accounts)
        - AskUserQuestion: Anchor or Native Rust framework?
        - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Close Compressed Account → Light System Program CPI
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - Add deps: Bash \`cargo add light-sdk@0.23\` (add \`anchor_lang@0.31\` for Anchor or \`solana-program@2.2\` + \`borsh@0.10\` for Native Rust)
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Bash \`cargo build-sbf\` or \`anchor build\`
        - Bash \`cargo test-sbf\` or \`anchor test\` if tests exist
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Build a program that closes compressed accounts
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Build a program that closes compressed accounts

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-close-compressed-accounts
  - Skills and resources index: https://zkcompression.com/skill.md
  - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
  - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/close
  - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/close

  Key SDK API: LightAccount::new_close()

  ### 1. Index project
  - Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|close|delete|remove` across src/
  - Glob `**/*.rs` and `**/Cargo.toml` for project structure
  - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
  - Read Cargo.toml — note existing dependencies and Solana SDK version
  - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both Anchor and Native Rust code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: what is the goal? (new program from scratch, add account close to existing program, migrate from regular accounts)
  - AskUserQuestion: Anchor or Native Rust framework?
  - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Close Compressed Account → Light System Program CPI
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Bash `cargo build-sbf` or `anchor build`
  - Bash `cargo test-sbf` or `anchor test` if tests exist
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="Reinitialize compressed accounts">
  Copy the prompt below or view the [guide](/compressed-pdas/guides/how-to-reinitialize-compressed-accounts).

  <Prompt description="Build a program that reinitializes closed compressed accounts" actions={["copy", "cursor"]}>
    {`---
        description: Build a program that reinitializes closed compressed accounts
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Build a program that reinitializes closed compressed accounts

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-reinitialize-compressed-accounts
        - Skills and resources index: https://zkcompression.com/skill.md
        - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
        - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/reinit
        - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/reinit

        Key SDK API: LightAccount::new_empty()

        ### 1. Index project
        - Grep \`declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|reinit|empty|reset\` across src/
        - Glob \`**/*.rs\` and \`**/Cargo.toml\` for project structure
        - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
        - Read Cargo.toml — note existing dependencies and Solana SDK version
        - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both Anchor and Native Rust code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: what is the goal? (new program from scratch, add account reinitialization to existing program, migrate from regular accounts)
        - AskUserQuestion: Anchor or Native Rust framework?
        - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Reinitialize Closed Account → Light System Program CPI
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - Add deps: Bash \`cargo add light-sdk@0.23\` (add \`anchor_lang@0.31\` for Anchor or \`solana-program@2.2\` + \`borsh@0.10\` for Native Rust)
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Bash \`cargo build-sbf\` or \`anchor build\`
        - Bash \`cargo test-sbf\` or \`anchor test\` if tests exist
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Build a program that reinitializes closed compressed accounts
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Build a program that reinitializes closed compressed accounts

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-reinitialize-compressed-accounts
  - Skills and resources index: https://zkcompression.com/skill.md
  - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
  - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/reinit
  - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/reinit

  Key SDK API: LightAccount::new_empty()

  ### 1. Index project
  - Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|reinit|empty|reset` across src/
  - Glob `**/*.rs` and `**/Cargo.toml` for project structure
  - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
  - Read Cargo.toml — note existing dependencies and Solana SDK version
  - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both Anchor and Native Rust code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: what is the goal? (new program from scratch, add account reinitialization to existing program, migrate from regular accounts)
  - AskUserQuestion: Anchor or Native Rust framework?
  - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Reinitialize Closed Account → Light System Program CPI
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Bash `cargo build-sbf` or `anchor build`
  - Bash `cargo test-sbf` or `anchor test` if tests exist
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="Burn compressed accounts">
  Copy the prompt below or view the [guide](/compressed-pdas/guides/how-to-burn-compressed-accounts).

  <Prompt description="Build a program that permanently burns compressed accounts" actions={["copy", "cursor"]}>
    {`---
        description: Build a program that permanently burns compressed accounts
        allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
        ---

        ## Build a program that permanently burns compressed accounts

        Context:
        - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-burn-compressed-accounts
        - Skills and resources index: https://zkcompression.com/skill.md
        - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
        - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/burn
        - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/burn

        Key SDK API: LightAccount::new_burn()

        ### 1. Index project
        - Grep \`declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|burn|destroy|permanent\` across src/
        - Glob \`**/*.rs\` and \`**/Cargo.toml\` for project structure
        - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
        - Read Cargo.toml — note existing dependencies and Solana SDK version
        - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

        ### 2. Read references
        - WebFetch the guide above — review both Anchor and Native Rust code samples
        - WebFetch skill.md — check for a dedicated skill and resources matching this task
        - TaskCreate one todo per phase below to track progress

        ### 3. Clarify intention
        - AskUserQuestion: what is the goal? (new program from scratch, add account burn to existing program, migrate from regular accounts)
        - AskUserQuestion: Anchor or Native Rust framework?
        - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
        - Summarize findings and wait for user confirmation before implementing

        ### 4. Create plan
        - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
        - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Burn Compressed Account → Light System Program CPI
        - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
        - Present the plan to the user for approval before proceeding

        ### 5. Implement
        - Add deps: Bash \`cargo add light-sdk@0.23\` (add \`anchor_lang@0.31\` for Anchor or \`solana-program@2.2\` + \`borsh@0.10\` for Native Rust)
        - Follow the guide and the approved plan
        - Write/Edit to create or modify files
        - TaskUpdate to mark each step done

        ### 6. Verify
        - Bash \`cargo build-sbf\` or \`anchor build\`
        - Bash \`cargo test-sbf\` or \`anchor test\` if tests exist
        - TaskUpdate to mark complete

        ### Tools
        - mcp__zkcompression__SearchLightProtocol("<query>") for API details
        - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
        - Task subagent with Grep/Read/WebFetch for parallel lookups
        - TaskList to check remaining work`}
  </Prompt>

  ```text theme={null}
  ---
  description: Build a program that permanently burns compressed accounts
  allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
  ---

  ## Build a program that permanently burns compressed accounts

  Context:
  - Guide: https://zkcompression.com/compressed-pdas/guides/how-to-burn-compressed-accounts
  - Skills and resources index: https://zkcompression.com/skill.md
  - Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
  - Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/burn
  - Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/burn

  Key SDK API: LightAccount::new_burn()

  ### 1. Index project
  - Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|burn|destroy|permanent` across src/
  - Glob `**/*.rs` and `**/Cargo.toml` for project structure
  - Identify: program ID, existing instructions, account structs, framework (Anchor or native)
  - Read Cargo.toml — note existing dependencies and Solana SDK version
  - Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

  ### 2. Read references
  - WebFetch the guide above — review both Anchor and Native Rust code samples
  - WebFetch skill.md — check for a dedicated skill and resources matching this task
  - TaskCreate one todo per phase below to track progress

  ### 3. Clarify intention
  - AskUserQuestion: what is the goal? (new program from scratch, add account burn to existing program, migrate from regular accounts)
  - AskUserQuestion: Anchor or Native Rust framework?
  - AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
  - Summarize findings and wait for user confirmation before implementing

  ### 4. Create plan
  - Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
  - Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Burn Compressed Account → Light System Program CPI
  - If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
  - Present the plan to the user for approval before proceeding

  ### 5. Implement
  - Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
  - Follow the guide and the approved plan
  - Write/Edit to create or modify files
  - TaskUpdate to mark each step done

  ### 6. Verify
  - Bash `cargo build-sbf` or `anchor build`
  - Bash `cargo test-sbf` or `anchor test` if tests exist
  - TaskUpdate to mark complete

  ### Tools
  - mcp__zkcompression__SearchLightProtocol("<query>") for API details
  - mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
  - Task subagent with Grep/Read/WebFetch for parallel lookups
  - TaskList to check remaining work
  ```
</Accordion>

<Accordion title="v1 to v2 Merkle tree migration">
  Copy the prompt below or view the [guide](/resources/migration-v1-to-v2).

  <Prompt description="Migrate Light Protocol program from v1 to v2 Merkle trees" actions={["copy", "cursor"]}>
    {`---
        argument-hint: <path_to_program>
        description: Migrate Light Protocol program from v1 to v2 Merkle trees
        allowed-tools: [Bash, Read, Glob, Grep, Task, WebFetch]
        ---

        Migrate this Light Protocol program from v1 to v2 Merkle trees.

        ## Goal

        Produce a **fully working migration** that builds and tests pass.

        ## Available commands

        Via Bash tool:
        - **cargo build-sbf**, **cargo test-sbf**, **cargo fmt**, **cargo clippy**
        - **anchor build**, **anchor test**
        - **grep**, **sed**

        ## Documentation

        - Migration Guide: https://zkcompression.com/references/migration-v1-to-v2
        - Reference PR: https://github.com/Lightprotocol/program-examples/commit/54f0e7f15c2972a078f776cfb40b238d83c7e486

        ## Reference repos

        program-examples/counter/anchor/
        ├── programs/counter/src/lib.rs    # v2 patterns: derive_address, CpiAccounts
        ├── Cargo.toml                      # v2 feature flags
        └── tests/counter.ts                # v2 client patterns

        ## Workflow

        ### Phase 1: Index program

        Find all v1 patterns:

          grep -r "::v1::" src/ tests/
          grep -r "ADDRESS_TREE_V1" src/
          grep -r "into_new_address_params_packed" src/
          grep -r "get_address_tree_v1" tests/

        ### Phase 2: Update dependencies

        Update Cargo.toml. V2 is the default - no feature flag needed:

          # On-chain program
          [dependencies]
          light-sdk = { version = "0.17.1", features = ["anchor"] }
          light-hasher = "5.0.0"

          # Off-chain client
          [dependencies]
          light-client = "0.17.2"

        Note: V2 is now the default in all crates. Only specify \`features = ["v2"]\` if you disabled default features.

        ### Phase 3: Rust SDK replacements

        | v1 Pattern | v2 Replacement |
        |------------|----------------|
        | address::v1::derive_address | address::v2::derive_address |
        | cpi::v1::CpiAccounts | cpi::v2::CpiAccounts |
        | cpi::v1::LightSystemProgramCpi | cpi::v2::LightSystemProgramCpi |
        | constants::ADDRESS_TREE_V1 | constants::ADDRESS_TREE_V2 |
        | .into_new_address_params_packed(seed) | .into_new_address_params_assigned_packed(seed, Some(0)) |
        | .add_system_accounts(config) | .add_system_accounts_v2(config) |

        ### Phase 4: TypeScript SDK replacements

        | v1 Pattern | v2 Replacement |
        |------------|----------------|
        | deriveAddress( | deriveAddressV2( |
        | deriveAddressSeed( | deriveAddressSeedV2( |
        | defaultTestStateTreeAccounts().addressTree | batchAddressTree |
        | .newWithSystemAccounts( | .newWithSystemAccountsV2( |
        | get_address_tree_v1() | get_address_tree_v2() |
        | get_random_state_tree_info_v1() | get_random_state_tree_info() |

        ### Phase 5: Build and test loop

        **Required commands (no shortcuts):**

        For Anchor programs: **anchor build && anchor test**

        For Native programs: **cargo build-sbf && cargo test-sbf**

        **NO shortcuts allowed:**

        - Do NOT use **cargo build** (must use **cargo build-sbf**)
        - Do NOT use **cargo test** (must use **cargo test-sbf**)
        - Tests MUST run against real BPF bytecode

        **On failure:** Spawn debugger agent with error context.

        **Loop rules:**

        1. Each debugger gets fresh context + previous debug reports
        2. Each attempt tries something DIFFERENT
        3. **NEVER GIVE UP** - keep spawning until fixed

        Do NOT proceed until all tests pass.

        ## DeepWiki fallback

        If no matching pattern in reference repos:

          mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "How to migrate {pattern} from v1 to v2?")`}
  </Prompt>

  ```text theme={null}
  ---
  argument-hint: <path_to_program>
  description: Migrate Light Protocol program from v1 to v2 Merkle trees
  allowed-tools: [Bash, Read, Glob, Grep, Task, WebFetch]
  ---

  Migrate this Light Protocol program from v1 to v2 Merkle trees.

  ## Goal

  Produce a **fully working migration** that builds and tests pass.

  ## Available commands

  Via Bash tool:
  - **cargo build-sbf**, **cargo test-sbf**, **cargo fmt**, **cargo clippy**
  - **anchor build**, **anchor test**
  - **grep**, **sed**

  ## Documentation

  - Migration Guide: https://zkcompression.com/references/migration-v1-to-v2
  - Reference PR: https://github.com/Lightprotocol/program-examples/commit/54f0e7f15c2972a078f776cfb40b238d83c7e486

  ## Reference repos

  program-examples/counter/anchor/
  ├── programs/counter/src/lib.rs    # v2 patterns: derive_address, CpiAccounts
  ├── Cargo.toml                      # v2 feature flags
  └── tests/counter.ts                # v2 client patterns

  ## Workflow

  ### Phase 1: Index program

  Find all v1 patterns:

      grep -r "::v1::" src/ tests/
      grep -r "ADDRESS_TREE_V1" src/
      grep -r "into_new_address_params_packed" src/
      grep -r "get_address_tree_v1" tests/

  ### Phase 2: Update dependencies

  Update Cargo.toml. V2 is the default - no feature flag needed:

      # On-chain program
      [dependencies]
      light-sdk = { version = "0.17.1", features = ["anchor"] }
      light-hasher = "5.0.0"

      # Off-chain client
      [dependencies]
      light-client = "0.17.2"

  Note: V2 is now the default in all crates. Only specify `features = ["v2"]` if you disabled default features.

  ### Phase 3: Rust SDK replacements

  | v1 Pattern | v2 Replacement |
  |------------|----------------|
  | address::v1::derive_address | address::v2::derive_address |
  | cpi::v1::CpiAccounts | cpi::v2::CpiAccounts |
  | cpi::v1::LightSystemProgramCpi | cpi::v2::LightSystemProgramCpi |
  | constants::ADDRESS_TREE_V1 | constants::ADDRESS_TREE_V2 |
  | .into_new_address_params_packed(seed) | .into_new_address_params_assigned_packed(seed, Some(0)) |
  | .add_system_accounts(config) | .add_system_accounts_v2(config) |

  ### Phase 4: TypeScript SDK replacements

  | v1 Pattern | v2 Replacement |
  |------------|----------------|
  | deriveAddress( | deriveAddressV2( |
  | deriveAddressSeed( | deriveAddressSeedV2( |
  | defaultTestStateTreeAccounts().addressTree | batchAddressTree |
  | .newWithSystemAccounts( | .newWithSystemAccountsV2( |
  | get_address_tree_v1() | get_address_tree_v2() |
  | get_random_state_tree_info_v1() | get_random_state_tree_info() |

  ### Phase 5: Build and test loop

  **Required commands (no shortcuts):**

  For Anchor programs: **anchor build && anchor test**

  For Native programs: **cargo build-sbf && cargo test-sbf**

  **NO shortcuts allowed:**

  - Do NOT use **cargo build** (must use **cargo build-sbf**)
  - Do NOT use **cargo test** (must use **cargo test-sbf**)
  - Tests MUST run against real BPF bytecode

  **On failure:** Spawn debugger agent with error context.

  **Loop rules:**

  1. Each debugger gets fresh context + previous debug reports
  2. Each attempt tries something DIFFERENT
  3. **NEVER GIVE UP** - keep spawning until fixed

  Do NOT proceed until all tests pass.

  ## DeepWiki fallback

  If no matching pattern in reference repos:

      mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "How to migrate {pattern} from v1 to v2?")
  ```
</Accordion>