[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GREP8Y6T8VYMA3JSV4G8ZR":3,"skill-same:01M6GREP8Y6T8VYMA3JSV4G8ZR":92},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":16,"sourceHtmlUrl":17,"categories":18,"keywords":24,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6GREP8Y6T8VYMA3JSV4G8ZR","v4-hook-generator",null,"Generate Uniswap v4 hook contracts via OpenZeppelin MCP. Use when building custom swap logic, async swaps, hook-owned liquidity, custom curves, dynamic fees, MEV protection, limit orders, or oracle hooks.","jiayaoqijia\u002Fcryptoskill","jiayaoqijia","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1453879?v=4","01M6GMYTX7Q7S504VC6E756ENR","YQ","01M6GMYV1QKJ1CC75MTTGT9PR0",81,"MIT","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Funiswap-official-v4-hook-generator\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Funiswap-official-v4-hook-generator\u002FSKILL.md",[19],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"v4 hook generator","generator","hook","hook generator","swaps","when","openzeppelin mcp","limit","opus","liquidity","uniswap","MCP","fees","orders","contracts","async","hooks","use","read","Bash","generate","oracle","2026-11-10 10:12:30",false,"---\nname: v4-hook-generator\ndescription: 'Generate Uniswap v4 hook contracts via OpenZeppelin MCP. Use when building custom swap logic, async swaps, hook-owned liquidity, custom curves, dynamic fees, MEV protection, limit orders, or oracle hooks.'\nallowed-tools: Read, Glob, Grep, WebFetch, Bash\nmodel: opus\nlicense: MIT\nmetadata:\n  author: uniswap\n  version: '1.0.0'\n---\n\n# v4 Hook Generator\n\nGenerate Uniswap v4 hook contracts via the OpenZeppelin Contracts Wizard MCP tool. This skill\nguides you through selecting the right hook type, configuring permissions and utilities, assembling\nthe canonical MCP JSON, and invoking the MCP tool to produce ready-to-compile Solidity code.\n\n> **Security companion**: Generated hook code touches fund-handling contracts. Always apply the\n> `v4-security-foundations` skill immediately after generation to audit permissions, delta\n> accounting, and access control before deploying to any network.\n\n## When to Use This Skill\n\nUse this skill when you need to:\n\n- Scaffold a new Uniswap v4 hook contract from scratch\n- Select the right base hook type for a specific use case (fees, MEV protection, oracles, etc.)\n- Configure hook permissions, utility libraries, shares, and access control\n- Produce the canonical MCP tool call JSON to invoke the OpenZeppelin Contracts Wizard\n- Understand trade-offs between hook configuration options before committing to an implementation\n\n**Prerequisite \u002F companion skill**: `v4-security-foundations` — run it before writing custom logic\nand again before deployment. Hook misconfiguration can drain user funds.\n\n## Hook Type Decision Table\n\nChoose the base hook type that matches your primary goal. If your hook has multiple goals, choose\nthe type that covers the most critical concern and layer additional logic on top.\n\n| Goal                 | Use Hook                   |\n| -------------------- | -------------------------- |\n| Custom swap logic    | `BaseHook`                 |\n| Async\u002Fdelayed swaps  | `BaseAsyncSwap`            |\n| Hook-owned liquidity | `BaseCustomAccounting`     |\n| Custom curve         | `BaseCustomCurve`          |\n| Dynamic LP fees      | `BaseDynamicFee`           |\n| Dynamic swap fees    | `BaseOverrideFee`          |\n| Post-swap fees       | `BaseDynamicAfterFee`      |\n| Fixed hook fees      | `BaseHookFee`              |\n| MEV protection       | `AntiSandwichHook`         |\n| JIT protection       | `LiquidityPenaltyHook`     |\n| Limit orders         | `LimitOrderHook`           |\n| Yield on idle        | `ReHypothecationHook`      |\n| Oracle               | `BaseOracleHook`           |\n| V3-compatible oracle | `OracleHookWithV3Adapters` |\n\n**Selection tips**:\n\n- `BaseHook` is the general-purpose starting point — choose a specialized type only when the\n  built-in logic provides concrete value.\n- `BaseCustomCurve` replaces the entire AMM math; only use it if you are implementing a novel\n  pricing algorithm.\n- `AntiSandwichHook` and `LiquidityPenaltyHook` both address MEV but target different actors\n  (traders vs. JIT LPs). Clarify which attack vector you are mitigating.\n- `OracleHookWithV3Adapters` is appropriate when downstream integrations expect a Uniswap v3\n  `IUniswapV3Pool`-compatible oracle interface.\n\n## Minimal Decision Checklist\n\nBefore calling the MCP tool, confirm all six decisions:\n\n1. **Hook type** — chosen from the decision table above\n2. **Permissions to enable** — only the callbacks your logic actually uses (`beforeSwap`, `afterSwap`, etc.)\n3. **Utility libraries** — `currencySettler`, `safeCast`, `transientStorage` as needed\n4. **Shares** — `false`, `ERC20`, `ERC6909`, or `ERC1155`\n5. **Access control** — `ownable`, `roles`, or `managed`\n6. **Hook inputs** — `blockNumberOffset`, `maxAbsTickDelta` (only for hook types that use them)\n\n## Permission Configuration\n\nAll 14 permission flags with guidance on when to enable each. Start with all flags `false` and\nenable only what your hook logic requires. Every enabled permission increases the hook's attack\nsurface and requires a specific bit to be set in the hook's deployed address (see address encoding\nnote below).\n\n| Permission Flag                   | Enable When                                                                                                     | Risk     |\n| --------------------------------- | --------------------------------------------------------------------------------------------------------------- | -------- |\n| `beforeInitialize`                | You need to validate or restrict pool creation params                                                           | LOW      |\n| `afterInitialize`                 | You need to set up state after a pool is created                                                                | LOW      |\n| `beforeAddLiquidity`              | You need to gate or transform LP deposits                                                                       | MEDIUM   |\n| `afterAddLiquidity`               | You track LP positions or distribute rewards                                                                    | LOW      |\n| `beforeRemoveLiquidity`           | You need lock-up periods or fee-on-exit logic                                                                   | HIGH     |\n| `afterRemoveLiquidity`            | You track position removals for accounting                                                                      | LOW      |\n| `beforeSwap`                      | You modify swap behavior, apply dynamic fees, or block                                                          | HIGH     |\n| `afterSwap`                       | You observe final swap state for oracles or accounting                                                          | MEDIUM   |\n| `beforeDonate`                    | You restrict who may donate to the pool                                                                         | LOW      |\n| `afterDonate`                     | You track donation events                                                                                       | LOW      |\n| `beforeSwapReturnDelta`           | You implement custom AMM curves or JIT liquidity (CRITICAL: NoOp attack vector — see `v4-security-foundations`) | CRITICAL |\n| `afterSwapReturnDelta`            | You extract a hook fee from swap output                                                                         | HIGH     |\n| `afterAddLiquidityReturnDelta`    | You adjust LP token amounts on deposit                                                                          | HIGH     |\n| `afterRemoveLiquidityReturnDelta` | You adjust withdrawal amounts                                                                                   | HIGH     |\n\n**Address encoding note**: Permissions are encoded as bits in the hook contract's deployed address.\nThe address must have the correct bits set at deployment time or the PoolManager will revert. Use\n`HookMiner` (from `v4-periphery`) to mine a salt that produces an address with the correct bit\npattern. Never change permissions after deployment — the address is immutable.\n\n## Utility Library Selection\n\nThree optional utility libraries can be included in the generated hook. Include only what your\nhook logic uses.\n\n| Library            | Include When                                                                                                                                                |\n| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `currencySettler`  | Your hook moves tokens between itself and the PoolManager (e.g., custom accounting, fee collection)                                                         |\n| `safeCast`         | Your hook performs arithmetic that could overflow when casting between integer types                                                                        |\n| `transientStorage` | Your hook needs to pass data between callbacks within a single transaction without persisting to storage (requires EVM Cancun or later, Solidity >= 0.8.24) |\n\n**Guidance**:\n\n- `currencySettler` is almost always needed when `beforeSwapReturnDelta`,\n  `afterSwapReturnDelta`, `afterAddLiquidityReturnDelta`, or `afterRemoveLiquidityReturnDelta`\n  are enabled — it provides `settle` and `take` helpers that implement the correct\n  `sync → transfer → settle` sequence.\n- `transientStorage` is a gas-efficient alternative to storage slots for intra-transaction state.\n  Use it to pass a flag or value from `beforeSwap` to `afterSwap` without paying 20k gas for a\n  cold SSTORE.\n- `safeCast` is advisable whenever you compute amounts derived from `int256`\u002F`uint256` conversions,\n  especially for fee calculations.\n\n## Shares Configuration\n\nThe `shares` option controls whether the generated hook issues a token representing user shares\n(e.g., LP positions in hook-owned liquidity pools).\n\n| Option    | Description                                                                                  | Use When                                                 |\n| --------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------- |\n| `false`   | No share token — hook does not track ownership of deposited assets                           | Simple hooks that do not hold user funds                 |\n| `ERC20`   | Fungible share token — one token represents proportional ownership of all hook-held assets   | Hook-managed liquidity pools with interchangeable shares |\n| `ERC6909` | Multi-token (minimal) — one contract manages many token IDs with lower overhead than ERC1155 | Hook manages multiple distinct asset classes efficiently |\n| `ERC1155` | Multi-token (standard) — full ERC1155 with metadata URI support                              | Hook needs broad wallet and marketplace compatibility    |\n\n**Trade-offs**:\n\n- `false`: smallest bytecode, no share accounting overhead; appropriate for fee hooks and oracles.\n- `ERC20`: simplest fungible share; good DeFi composability (e.g., used as collateral).\n- `ERC6909`: gas-efficient multi-token with a minimal interface; preferred for new protocol designs.\n- `ERC1155`: widest ecosystem support (wallets, explorers, NFT marketplaces); higher gas cost per\n  transfer than ERC6909.\n\n## Access Control Options\n\nThe `access` option shapes the constructor and administrative interface of the generated hook.\n\n| Option    | Constructor Shape                                 | Use When                                                                     |\n| --------- | ------------------------------------------------- | ---------------------------------------------------------------------------- |\n| `ownable` | `constructor(IPoolManager, address initialOwner)` | Single owner controls all admin functions                                    |\n| `roles`   | `constructor(IPoolManager, address admin)`        | Multiple roles with granular permissions (OpenZeppelin AccessControl)        |\n| `managed` | `constructor(IPoolManager, address authority)`    | External authority contract governs permissions (OpenZeppelin AccessManaged) |\n\n**Guidance**:\n\n- `ownable` is the simplest — one address can perform all privileged operations. Suitable for\n  early-stage hooks and personal tools.\n- `roles` adds `ADMIN_ROLE`, `PAUSER_ROLE`, etc. via OpenZeppelin `AccessControl`. Use when\n  different team members need different privileges (e.g., a keeper bot that can update fees but\n  cannot upgrade the contract).\n- `managed` delegates all permission checks to a separate `AccessManager` contract. Use when\n  you need a unified governance layer across multiple contracts or want timelocked admin actions.\n\n> **Note**: Changing the `access` option changes the constructor signature. Update deployment\n> scripts and initialization logic accordingly. When using `ownable`, ensure the `initialOwner`\n> is not the zero address — OpenZeppelin's `Ownable` reverts on zero address since v5.\n\n## Hook Inputs Reference\n\nSome hook types accept numeric configuration inputs that tune behavior. These are passed as the\n`inputs` object in the MCP tool call.\n\n| Input               | Type      | Used By                                    | Description                                                            |\n| ------------------- | --------- | ------------------------------------------ | ---------------------------------------------------------------------- |\n| `blockNumberOffset` | `uint256` | `AntiSandwichHook`, `LiquidityPenaltyHook` | Number of blocks before sandwich\u002FJIT detection window opens            |\n| `maxAbsTickDelta`   | `int24`   | `AntiSandwichHook`                         | Maximum tick movement allowed per block before MEV protection triggers |\n\nFor hook types that do not use these inputs, omit the `inputs` field or pass an empty object `{}`.\nPassing unsupported inputs to the MCP tool will not cause an error but the values will be ignored.\n\n## MCP Tool Call (Canonical)\n\nThe OpenZeppelin Contracts Wizard exposes a `generate_hook` MCP tool. The following is the\ncanonical JSON schema — populate each field according to your decisions from the sections above,\nthen pass this object as the tool's argument.\n\n```json\n{\n  \"hook\": \"BaseHook\",\n  \"name\": \"MyHook\",\n  \"pausable\": false,\n  \"currencySettler\": true,\n  \"safeCast\": true,\n  \"transientStorage\": false,\n  \"shares\": { \"options\": false },\n  \"permissions\": {\n    \"beforeInitialize\": false,\n    \"afterInitialize\": false,\n    \"beforeAddLiquidity\": false,\n    \"beforeRemoveLiquidity\": false,\n    \"afterAddLiquidity\": false,\n    \"afterRemoveLiquidity\": false,\n    \"beforeSwap\": true,\n    \"afterSwap\": false,\n    \"beforeDonate\": false,\n    \"afterDonate\": false,\n    \"beforeSwapReturnDelta\": false,\n    \"afterSwapReturnDelta\": false,\n    \"afterAddLiquidityReturnDelta\": false,\n    \"afterRemoveLiquidityReturnDelta\": false\n  },\n  \"inputs\": {\n    \"blockNumberOffset\": 1,\n    \"maxAbsTickDelta\": 100\n  },\n  \"access\": \"ownable\",\n  \"info\": { \"license\": \"MIT\" }\n}\n```\n\n**Field notes**:\n\n- `hook`: string — one of the 14 hook types from the decision table\n- `name`: string — the Solidity contract name (PascalCase, no spaces)\n- `pausable`: boolean — wraps the hook in OpenZeppelin `Pausable`; adds `pause()`\u002F`unpause()` admin functions\n- `shares.options`: `false` | `\"ERC20\"` | `\"ERC6909\"` | `\"ERC1155\"`\n- `access`: `\"ownable\"` | `\"roles\"` | `\"managed\"`\n- `info.license`: SPDX license identifier — use `\"MIT\"` for open-source hooks\n- `inputs`: omit or pass `{}` for hook types that do not use `blockNumberOffset`\u002F`maxAbsTickDelta`\n\n## Workflow: Gather → Configure → Generate → Secure\n\nFollow these steps in order every time you use this skill.\n\n### Step 1: Gather Requirements\n\nAsk the user (or infer from context):\n\n1. What is the hook's primary goal? (Map to the decision table.)\n2. Which lifecycle events does the hook need to intercept? (Map to permissions.)\n3. Does the hook hold or move user funds? (Determines `currencySettler` and `shares`.)\n4. Who administers the hook? (Single owner, role-based team, or external governance?)\n5. Does the hook need to pass state between callbacks within a single transaction?\n6. Is this for a chain with EVM Cancun support? (Required for `transientStorage`.)\n\n### Step 2: Select Hook Type\n\nUsing the decision table, identify the single best hook type. If the user's goal maps to multiple\ntypes, explain the trade-offs and ask them to confirm. Document the chosen type and the reasoning.\n\n### Step 3: Configure All Six Decisions\n\nWork through the minimal decision checklist:\n\n1. Set `hook` to the chosen type.\n2. Set each permission flag — default `false`, enable only what the logic requires.\n3. Set `currencySettler`, `safeCast`, `transientStorage` based on utility library guidance.\n4. Set `shares.options` based on shares guidance.\n5. Set `access` based on access control guidance.\n6. Set `inputs` only if the hook type uses `blockNumberOffset` or `maxAbsTickDelta`.\n\n### Step 4: Assemble and Call the MCP Tool\n\nConstruct the JSON object from Step 3 and call the OpenZeppelin Contracts Wizard MCP tool with it.\nThe tool returns Solidity source code — it does **not** write files automatically.\n\nAfter receiving the generated code:\n\n1. Display the code to the user.\n2. Explain the key generated sections (constructor, `getHookPermissions`, enabled callbacks).\n3. Note any manual steps required (HookMiner for address mining, deployment script updates for\n   constructor args if `access` is `roles` or `managed`).\n\n### Step 5: Apply Security Foundations\n\n**Always remind the user** — and invoke `v4-security-foundations` — before the code is deployed:\n\n- Verify all enabled callbacks check `msg.sender == address(poolManager)`.\n- Review any enabled `*ReturnDelta` permissions for NoOp attack exposure.\n- Confirm delta accounting sums to zero for every execution path.\n- Run the full pre-deployment audit checklist from `v4-security-foundations`.\n\n## Important Notes\n\n- **Access control changes constructor shape**: Choosing `ownable` adds an `initialOwner` parameter;\n  `roles` adds an `admin` parameter; `managed` adds an `authority` parameter. Update deployment\n  scripts and factory contracts accordingly.\n- **Permissions encode in the hook address**: Each enabled permission flag corresponds to a specific\n  bit in the lower bytes of the hook's deployed address. The PoolManager validates these bits on\n  every callback. Use `HookMiner` from `v4-periphery` to mine a deployment salt that produces a\n  matching address.\n- **MCP returns code only — it does not write files**: The generated Solidity is returned as a\n  string. You must write it to disk yourself (e.g., `packages\u002Fcontracts\u002Fsrc\u002Fhooks\u002FMyHook.sol`).\n\n## Related Skills\n\n- `v4-security-foundations` — **Run this after generation.** Security audit for Uniswap v4 hooks:\n  permission risk matrix, NoOp attack patterns, delta accounting, access control verification,\n  and the full pre-deployment audit checklist. Generated hook code should never be deployed without\n  completing this review.\n- `viem-integration` — Deploy generated hook contracts and interact with them using viem\u002Fwagmi\n- `v4-sdk-integration` — Interact with deployed hooks via the Uniswap v4 SDK\n","# v4 Hook Generator\n\nGenerate Uniswap v4 hook contracts via the OpenZeppelin Contracts Wizard MCP tool. This skill\nguides you through selecting the right hook type, configuring permissions and utilities, assembling\nthe canonical MCP JSON, and invoking the MCP tool to produce ready-to-compile Solidity code.\n\n> **Security companion**: Generated hook code touches fund-handling contracts. Always apply the\n> `v4-security-foundations` skill immediately after generation to audit permissions, delta\n> accounting, and access control before deploying to any network.\n\n## When to Use This Skill\n\nUse this skill when you need to:\n\n- Scaffold a new Uniswap v4 hook contract from scratch\n- Select the right base hook type for a specific use case (fees, MEV protection, oracles, etc.)\n- Configure hook permissions, utility libraries, shares, and access control\n- Produce the canonical MCP tool call JSON to invoke the OpenZeppelin Contracts Wizard\n- Understand trade-offs between hook configuration options before committing to an implementation\n\n**Prerequisite \u002F companion skill**: `v4-security-foundations` — run it before writing custom logic\nand again before deployment. Hook misconfiguration can drain user funds.\n\n## Hook Type Decision Table\n\nChoose the base hook type that matches your primary goal. If your hook has multiple goals, choose\nthe type that covers the most critical concern and layer additional logic on top.\n\n| Goal                 | Use Hook                   |\n| -------------------- | -------------------------- |\n| Custom swap logic    | `BaseHook`                 |\n| Async\u002Fdelayed swaps  | `BaseAsyncSwap`            |\n| Hook-owned liquidity | `BaseCustomAccounting`     |\n| Custom curve         | `BaseCustomCurve`          |\n| Dynamic LP fees      | `BaseDynamicFee`           |\n| Dynamic swap fees    | `BaseOverrideFee`          |\n| Post-swap fees       | `BaseDynamicAfterFee`      |\n| Fixed hook fees      | `BaseHookFee`              |\n| MEV protection       | `AntiSandwichHook`         |\n| JIT protection       | `LiquidityPenaltyHook`     |\n| Limit orders         | `LimitOrderHook`           |\n| Yield on idle        | `ReHypothecationHook`      |\n| Oracle               | `BaseOracleHook`           |\n| V3-compatible oracle | `OracleHookWithV3Adapters` |\n\n**Selection tips**:\n\n- `BaseHook` is the general-purpose starting point — choose a specialized type only when the\n  built-in logic provides concrete value.\n- `BaseCustomCurve` replaces the entire AMM math; only use it if you are implementing a novel\n  pricing algorithm.\n- `AntiSandwichHook` and `LiquidityPenaltyHook` both address MEV but target different actors\n  (traders vs. JIT LPs). Clarify which attack vector you are mitigating.\n- `OracleHookWithV3Adapters` is appropriate when downstream integrations expect a Uniswap v3\n  `IUniswapV3Pool`-compatible oracle interface.\n\n## Minimal Decision Checklist\n\nBefore calling the MCP tool, confirm all six decisions:\n\n1. **Hook type** — chosen from the decision table above\n2. **Permissions to enable** — only the callbacks your logic actually uses (`beforeSwap`, `afterSwap`, etc.)\n3. **Utility libraries** — `currencySettler`, `safeCast`, `transientStorage` as needed\n4. **Shares** — `false`, `ERC20`, `ERC6909`, or `ERC1155`\n5. **Access control** — `ownable`, `roles`, or `managed`\n6. **Hook inputs** — `blockNumberOffset`, `maxAbsTickDelta` (only for hook types that use them)\n\n## Permission Configuration\n\nAll 14 permission flags with guidance on when to enable each. Start with all flags `false` and\nenable only what your hook logic requires. Every enabled permission increases the hook's attack\nsurface and requires a specific bit to be set in the hook's deployed address (see address encoding\nnote below).\n\n| Permission Flag                   | Enable When                                                                                                     | Risk     |\n| --------------------------------- | --------------------------------------------------------------------------------------------------------------- | -------- |\n| `beforeInitialize`                | You need to validate or restrict pool creation params                                                           | LOW      |\n| `afterInitialize`                 | You need to set up state after a pool is created                                                                | LOW      |\n| `beforeAddLiquidity`              | You need to gate or transform LP deposits                                                                       | MEDIUM   |\n| `afterAddLiquidity`               | You track LP positions or distribute rewards                                                                    | LOW      |\n| `beforeRemoveLiquidity`           | You need lock-up periods or fee-on-exit logic                                                                   | HIGH     |\n| `afterRemoveLiquidity`            | You track position removals for accounting                                                                      | LOW      |\n| `beforeSwap`                      | You modify swap behavior, apply dynamic fees, or block                                                          | HIGH     |\n| `afterSwap`                       | You observe final swap state for oracles or accounting                                                          | MEDIUM   |\n| `beforeDonate`                    | You restrict who may donate to the pool                                                                         | LOW      |\n| `afterDonate`                     | You track donation events                                                                                       | LOW      |\n| `beforeSwapReturnDelta`           | You implement custom AMM curves or JIT liquidity (CRITICAL: NoOp attack vector — see `v4-security-foundations`) | CRITICAL |\n| `afterSwapReturnDelta`            | You extract a hook fee from swap output                                                                         | HIGH     |\n| `afterAddLiquidityReturnDelta`    | You adjust LP token amounts on deposit                                                                          | HIGH     |\n| `afterRemoveLiquidityReturnDelta` | You adjust withdrawal amounts                                                                                   | HIGH     |\n\n**Address encoding note**: Permissions are encoded as bits in the hook contract's deployed address.\nThe address must have the correct bits set at deployment time or the PoolManager will revert. Use\n`HookMiner` (from `v4-periphery`) to mine a salt that produces an address with the correct bit\npattern. Never change permissions after deployment — the address is immutable.\n\n## Utility Library Selection\n\nThree optional utility libraries can be included in the generated hook. Include only what your\nhook logic uses.\n\n| Library            | Include When                                                                                                                                                |\n| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `currencySettler`  | Your hook moves tokens between itself and the PoolManager (e.g., custom accounting, fee collection)                                                         |\n| `safeCast`         | Your hook performs arithmetic that could overflow when casting between integer types                                                                        |\n| `transientStorage` | Your hook needs to pass data between callbacks within a single transaction without persisting to storage (requires EVM Cancun or later, Solidity >= 0.8.24) |\n\n**Guidance**:\n\n- `currencySettler` is almost always needed when `beforeSwapReturnDelta`,\n  `afterSwapReturnDelta`, `afterAddLiquidityReturnDelta`, or `afterRemoveLiquidityReturnDelta`\n  are enabled — it provides `settle` and `take` helpers that implement the correct\n  `sync → transfer → settle` sequence.\n- `transientStorage` is a gas-efficient alternative to storage slots for intra-transaction state.\n  Use it to pass a flag or value from `beforeSwap` to `afterSwap` without paying 20k gas for a\n  cold SSTORE.\n- `safeCast` is advisable whenever you compute amounts derived from `int256`\u002F`uint256` conversions,\n  especially for fee calculations.\n\n## Shares Configuration\n\nThe `shares` option controls whether the generated hook issues a token representing user shares\n(e.g., LP positions in hook-owned liquidity pools).\n\n| Option    | Description                                                                                  | Use When                                                 |\n| --------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------- |\n| `false`   | No share token — hook does not track ownership of deposited assets                           | Simple hooks that do not hold user funds                 |\n| `ERC20`   | Fungible share token — one token represents proportional ownership of all hook-held assets   | Hook-managed liquidity pools with interchangeable shares |\n| `ERC6909` | Multi-token (minimal) — one contract manages many token IDs with lower overhead than ERC1155 | Hook manages multiple distinct asset classes efficiently |\n| `ERC1155` | Multi-token (standard) — full ERC1155 with metadata URI support                              | Hook needs broad wallet and marketplace compatibility    |\n\n**Trade-offs**:\n\n- `false`: smallest bytecode, no share accounting overhead; appropriate for fee hooks and oracles.\n- `ERC20`: simplest fungible share; good DeFi composability (e.g., used as collateral).\n- `ERC6909`: gas-efficient multi-token with a minimal interface; preferred for new protocol designs.\n- `ERC1155`: widest ecosystem support (wallets, explorers, NFT marketplaces); higher gas cost per\n  transfer than ERC6909.\n\n## Access Control Options\n\nThe `access` option shapes the constructor and administrative interface of the generated hook.\n\n| Option    | Constructor Shape                                 | Use When                                                                     |\n| --------- | ------------------------------------------------- | ---------------------------------------------------------------------------- |\n| `ownable` | `constructor(IPoolManager, address initialOwner)` | Single owner controls all admin functions                                    |\n| `roles`   | `constructor(IPoolManager, address admin)`        | Multiple roles with granular permissions (OpenZeppelin AccessControl)        |\n| `managed` | `constructor(IPoolManager, address authority)`    | External authority contract governs permissions (OpenZeppelin AccessManaged) |\n\n**Guidance**:\n\n- `ownable` is the simplest — one address can perform all privileged operations. Suitable for\n  early-stage hooks and personal tools.\n- `roles` adds `ADMIN_ROLE`, `PAUSER_ROLE`, etc. via OpenZeppelin `AccessControl`. Use when\n  different team members need different privileges (e.g., a keeper bot that can update fees but\n  cannot upgrade the contract).\n- `managed` delegates all permission checks to a separate `AccessManager` contract. Use when\n  you need a unified governance layer across multiple contracts or want timelocked admin actions.\n\n> **Note**: Changing the `access` option changes the constructor signature. Update deployment\n> scripts and initialization logic accordingly. When using `ownable`, ensure the `initialOwner`\n> is not the zero address — OpenZeppelin's `Ownable` reverts on zero address since v5.\n\n## Hook Inputs Reference\n\nSome hook types accept numeric configuration inputs that tune behavior. These are passed as the\n`inputs` object in the MCP tool call.\n\n| Input               | Type      | Used By                                    | Description                                                            |\n| ------------------- | --------- | ------------------------------------------ | ---------------------------------------------------------------------- |\n| `blockNumberOffset` | `uint256` | `AntiSandwichHook`, `LiquidityPenaltyHook` | Number of blocks before sandwich\u002FJIT detection window opens            |\n| `maxAbsTickDelta`   | `int24`   | `AntiSandwichHook`                         | Maximum tick movement allowed per block before MEV protection triggers |\n\nFor hook types that do not use these inputs, omit the `inputs` field or pass an empty object `{}`.\nPassing unsupported inputs to the MCP tool will not cause an error but the values will be ignored.\n\n## MCP Tool Call (Canonical)\n\nThe OpenZeppelin Contracts Wizard exposes a `generate_hook` MCP tool. The following is the\ncanonical JSON schema — populate each field according to your decisions from the sections above,\nthen pass this object as the tool's argument.\n\n```json\n{\n  \"hook\": \"BaseHook\",\n  \"name\": \"MyHook\",\n  \"pausable\": false,\n  \"currencySettler\": true,\n  \"safeCast\": true,\n  \"transientStorage\": false,\n  \"shares\": { \"options\": false },\n  \"permissions\": {\n    \"beforeInitialize\": false,\n    \"afterInitialize\": false,\n    \"beforeAddLiquidity\": false,\n    \"beforeRemoveLiquidity\": false,\n    \"afterAddLiquidity\": false,\n    \"afterRemoveLiquidity\": false,\n    \"beforeSwap\": true,\n    \"afterSwap\": false,\n    \"beforeDonate\": false,\n    \"afterDonate\": false,\n    \"beforeSwapReturnDelta\": false,\n    \"afterSwapReturnDelta\": false,\n    \"afterAddLiquidityReturnDelta\": false,\n    \"afterRemoveLiquidityReturnDelta\": false\n  },\n  \"inputs\": {\n    \"blockNumberOffset\": 1,\n    \"maxAbsTickDelta\": 100\n  },\n  \"access\": \"ownable\",\n  \"info\": { \"license\": \"MIT\" }\n}\n```\n\n**Field notes**:\n\n- `hook`: string — one of the 14 hook types from the decision table\n- `name`: string — the Solidity contract name (PascalCase, no spaces)\n- `pausable`: boolean — wraps the hook in OpenZeppelin `Pausable`; adds `pause()`\u002F`unpause()` admin functions\n- `shares.options`: `false` | `\"ERC20\"` | `\"ERC6909\"` | `\"ERC1155\"`\n- `access`: `\"ownable\"` | `\"roles\"` | `\"managed\"`\n- `info.license`: SPDX license identifier — use `\"MIT\"` for open-source hooks\n- `inputs`: omit or pass `{}` for hook types that do not use `blockNumberOffset`\u002F`maxAbsTickDelta`\n\n## Workflow: Gather → Configure → Generate → Secure\n\nFollow these steps in order every time you use this skill.\n\n### Step 1: Gather Requirements\n\nAsk the user (or infer from context):\n\n1. What is the hook's primary goal? (Map to the decision table.)\n2. Which lifecycle events does the hook need to intercept? (Map to permissions.)\n3. Does the hook hold or move user funds? (Determines `currencySettler` and `shares`.)\n4. Who administers the hook? (Single owner, role-based team, or external governance?)\n5. Does the hook need to pass state between callbacks within a single transaction?\n6. Is this for a chain with EVM Cancun support? (Required for `transientStorage`.)\n\n### Step 2: Select Hook Type\n\nUsing the decision table, identify the single best hook type. If the user's goal maps to multiple\ntypes, explain the trade-offs and ask them to confirm. Document the chosen type and the reasoning.\n\n### Step 3: Configure All Six Decisions\n\nWork through the minimal decision checklist:\n\n1. Set `hook` to the chosen type.\n2. Set each permission flag — default `false`, enable only what the logic requires.\n3. Set `currencySettler`, `safeCast`, `transientStorage` based on utility library guidance.\n4. Set `shares.options` based on shares guidance.\n5. Set `access` based on access control guidance.\n6. Set `inputs` only if the hook type uses `blockNumberOffset` or `maxAbsTickDelta`.\n\n### Step 4: Assemble and Call the MCP Tool\n\nConstruct the JSON object from Step 3 and call the OpenZeppelin Contracts Wizard MCP tool with it.\nThe tool returns Solidity source code — it does **not** write files automatically.\n\nAfter receiving the generated code:\n\n1. Display the code to the user.\n2. Explain the key generated sections (constructor, `getHookPermissions`, enabled callbacks).\n3. Note any manual steps required (HookMiner for address mining, deployment script updates for\n   constructor args if `access` is `roles` or `managed`).\n\n### Step 5: Apply Security Foundations\n\n**Always remind the user** — and invoke `v4-security-foundations` — before the code is deployed:\n\n- Verify all enabled callbacks check `msg.sender == address(poolManager)`.\n- Review any enabled `*ReturnDelta` permissions for NoOp attack exposure.\n- Confirm delta accounting sums to zero for every execution path.\n- Run the full pre-deployment audit checklist from `v4-security-foundations`.\n\n## Important Notes\n\n- **Access control changes constructor shape**: Choosing `ownable` adds an `initialOwner` parameter;\n  `roles` adds an `admin` parameter; `managed` adds an `authority` parameter. Update deployment\n  scripts and factory contracts accordingly.\n- **Permissions encode in the hook address**: Each enabled permission flag corresponds to a specific\n  bit in the lower bytes of the hook's deployed address. The PoolManager validates these bits on\n  every callback. Use `HookMiner` from `v4-periphery` to mine a deployment salt that produces a\n  matching address.\n- **MCP returns code only — it does not write files**: The generated Solidity is returned as a\n  string. You must write it to disk yourself (e.g., `packages\u002Fcontracts\u002Fsrc\u002Fhooks\u002FMyHook.sol`).\n\n## Related Skills\n\n- `v4-security-foundations` — **Run this after generation.** Security audit for Uniswap v4 hooks:\n  permission risk matrix, NoOp attack patterns, delta accounting, access control verification,\n  and the full pre-deployment audit checklist. Generated hook code should never be deployed without\n  completing this review.\n- `viem-integration` — Deploy generated hook contracts and interact with them using viem\u002Fwagmi\n- `v4-sdk-integration` — Interact with deployed hooks via the Uniswap v4 SDK\n",{"name":5,"model":33,"license":15,"metadata":52,"description":7,"allowed-tools":54},{"author":35,"version":53},"1.0.0","Read, Glob, Grep, WebFetch, Bash","main","3df1d0d67b30ff15236561f8c0f9f06d33f42dfd","skills\u002Fdefi\u002Funiswap-official-v4-hook-generator",17,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia","https:\u002F\u002Feth2030.com","Hardcore infra. Building @alt-research and applied cryptography.","2026-11-15 02:28:10",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill v4-hook-generator",{"tool":70,"command":71},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill v4-hook-generator",{"tool":73,"command":74},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill v4-hook-generator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Funiswap-official-v4-hook-generator\u002FSKILL.md",true,[78,82,88],{"path":79,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":16},"LICENSE","许可证",1069,{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"SOURCE.md","REFERENCE","参考文档",370,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Funiswap-official-v4-hook-generator\u002FSOURCE.md",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"TRUST.auto.yaml",2184,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fdefi\u002Funiswap-official-v4-hook-generator\u002FTRUST.auto.yaml",[93,121,144,161,174,184],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":97,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":47},"01M712C436EQYE43342Q4E7GG1","recipe-performance","Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold\u002Fwarm\u002Fbackground-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout\u002Fpaint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FSKILL.md",[],[101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120],"performance","recipe performance","recipe","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":125,"licenseFileUrl":126,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":47},"01M70XT2F8A5CQZ81JBP98KSW3","mexc-spot-websocket","MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FSKILL.md",[],[130,131,132,133,134,135,136,137,138,139,140,141,142,143],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","for","api keys","maintenance","protobuf",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":125,"licenseFileUrl":148,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":47},"01M70XT0MBXN3WZY1BKN0CPNKR","mexc-spot-rest","MEXC Spot REST workflows for public data, signed account requests, orders, wallet\u002Fadmin actions, and secure signing without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FSKILL.md",[],[152,131,153,154,155,156,157,141,140,139,158,159,160,135,38,134,133],"mexc spot rest","REST","admin","signing","Wallet","requests","actions","secure","data",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":125,"licenseFileUrl":165,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":47},"01M70XSYSVZ2N0N91XCAR2CAK0","mexc-futures-websocket","MEXC Futures WebSocket workflows for public streams, private account\u002Forder\u002Fposition streams, ping\u002Fpong, subscriptions, and depth maintenance.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FSKILL.md",[],[169,170,132,171,172,142,140,173,138,137,135,134],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":175,"name":176,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":177,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":47},"01M6H0ZWHVE5W04WG2DKQE2SQC","0xklen-version-and-refresh-sanctions-lists","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FSKILL.md",[],[181,182,183],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":188,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":47},"01M6H0Z28Q3R8J0S799GJQWXM3","verify-tests-cover-changed-lines","Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FSKILL.md",[],[192,193,194,195,196,197,198,42,199,200,201],"tests","cover","verify tests cover changed lines","verify","coverage","pr","exercise","patch","code","share"]