Design Hook
Overview
Designs a Uniswap V4 hook architecture without generating code. Delegates to the hook-builder agent in design-only mode to produce a comprehensive design document covering: which callbacks are needed, hook flag requirements, state management approach, gas estimates, security considerations, and architecture decisions. Use this to plan before building, or to evaluate feasibility.
When to Use
Activate when the user asks:
- "Design a hook for..."
- "What callbacks do I need for..."
- "Hook architecture for..."
- "Plan a V4 hook"
- "Is it possible to build a hook that..."
- "What would a dynamic fee hook look like?"
- "Help me think through a hook design"
- "Which flags do I need for a TWAMM?"
Parameters
| Parameter |
Required |
Default |
Description |
| behavior |
Yes |
-- |
Hook behavior description (e.g., "limit orders", "dynamic fees", "oracle pricing") |
| constraints |
No |
-- |
Gas budget, security requirements, or specific design constraints |
| integrations |
No |
-- |
External systems the hook needs to interact with (oracles, governance, staking) |
Workflow
Extract parameters from the user's request: identify the hook behavior, constraints, and any external integrations.
Delegate to hook-builder in design-only mode: Invoke Task(subagent_type:hook-builder) with explicit instruction to produce a design document only -- no code generation, no file writes. The hook-builder will:
- Analyze the requirements and determine which V4 callbacks are needed
- Map callbacks to hook flags and validate the combination
- Design the state management approach (what storage, what data structures)
- Estimate gas overhead per callback
- Identify security considerations specific to this hook design
- Evaluate feasibility and flag any concerns
Present the design document to the user covering:
- Callbacks needed and why each is required
- Hook flags and bitmask
- State management design (storage variables, data structures, access patterns)
- Gas estimates and performance implications
- Security considerations and mitigations
- Architecture decisions with rationale
- Comparison with alternative approaches if applicable
Output Format
Present a structured design document:
V4 Hook Design: Dynamic Fee Hook
Callbacks Required:
- beforeSwap: Read volatility oracle, calculate dynamic fee
- beforeInitialize: Set initial fee parameters and oracle address
Hook Flags: BEFORE_SWAP_FLAG | BEFORE_INITIALIZE_FLAG
Bitmask: 0x2080
State Management:
- volatilityOracle: IVolatilityOracle (immutable, set in constructor)
- baseFee: uint24 (configurable by owner)
- maxFee: uint24 (cap to prevent excessive fees)
- feeMultiplier: uint24 (scales with volatility)
Gas Estimates:
beforeSwap: ~30,000 gas (oracle read + fee calculation)
beforeInitialize: ~25,000 gas (one-time setup)
Security Considerations:
- Oracle manipulation: Use TWAP, not spot price
- Fee cap: Enforce maxFee to protect traders
- Owner control: Fee parameters updatable by owner only
Architecture Decisions:
- Using beforeSwap (not afterSwap) to set fee before execution
- External oracle for volatility data rather than on-chain calculation
- Fee bounded between baseFee and maxFee for predictability
Alternative Approaches:
- On-chain volatility calculation (higher gas, no oracle dependency)
- Fixed fee tiers with governance voting (simpler, less responsive)
Important Notes
- This skill produces a design document only -- no code is generated and no files are written.
- The design document provides enough detail to proceed with
build-hook when the user is ready.
- If the hook design is infeasible (e.g., requires callbacks that V4 doesn't support), this will be clearly communicated.
- Gas estimates are approximations based on typical implementations -- actual gas depends on implementation details.
Error Handling
| Error |
User-Facing Message |
Suggested Action |
VAGUE_REQUIREMENTS |
"Need more detail about the desired hook behavior." |
Describe specific behavior (e.g., "limit orders that execute at tick boundaries") |
UNSUPPORTED_CALLBACK |
"V4 does not support the requested callback." |
Review available V4 callbacks and adjust requirements |
INFEASIBLE_DESIGN |
"This hook design is not feasible with current V4 capabilities." |
Simplify requirements or consider alternative approaches |
1---2name: design-hook3description: Design a Uniswap V4 hook architecture without code generation. Use when user wants to plan a hook, understand which callbacks to use, or review an architecture before building. Returns a design document, not code.4---5
6# Design Hook
7
8## Overview
9
10Designs a Uniswap V4 hook architecture without generating code. Delegates to the `hook-builder` agent in design-only mode to produce a comprehensive design document covering: which callbacks are needed, hook flag requirements, state management approach, gas estimates, security considerations, and architecture decisions. Use this to plan before building, or to evaluate feasibility.
11
12## When to Use
13
14Activate when the user asks:
15
16- "Design a hook for..."
17- "What callbacks do I need for..."
18- "Hook architecture for..."
19- "Plan a V4 hook"
20- "Is it possible to build a hook that..."
21- "What would a dynamic fee hook look like?"
22- "Help me think through a hook design"
23- "Which flags do I need for a TWAMM?"
24
25## Parameters
26
27| Parameter | Required | Default | Description |
28| --- | --- | --- | --- |
29| behavior | Yes | -- | Hook behavior description (e.g., "limit orders", "dynamic fees", "oracle pricing") |
30| constraints | No | -- | Gas budget, security requirements, or specific design constraints |
31| integrations | No | -- | External systems the hook needs to interact with (oracles, governance, staking) |
32
33## Workflow
34
351. **Extract parameters** from the user's request: identify the hook behavior, constraints, and any external integrations.
36
372. **Delegate to hook-builder in design-only mode**: Invoke `Task(subagent_type:hook-builder)` with explicit instruction to produce a design document only -- no code generation, no file writes. The hook-builder will:
38 - Analyze the requirements and determine which V4 callbacks are needed
39 - Map callbacks to hook flags and validate the combination
40 - Design the state management approach (what storage, what data structures)
41 - Estimate gas overhead per callback
42 - Identify security considerations specific to this hook design
43 - Evaluate feasibility and flag any concerns
44
453. **Present the design document** to the user covering:
46 - Callbacks needed and why each is required
47 - Hook flags and bitmask
48 - State management design (storage variables, data structures, access patterns)
49 - Gas estimates and performance implications
50 - Security considerations and mitigations
51 - Architecture decisions with rationale
52 - Comparison with alternative approaches if applicable
53
54## Output Format
55
56Present a structured design document:
57
58```text
59V4 Hook Design: Dynamic Fee Hook
60
61 Callbacks Required:
62 - beforeSwap: Read volatility oracle, calculate dynamic fee
63 - beforeInitialize: Set initial fee parameters and oracle address
64
65 Hook Flags: BEFORE_SWAP_FLAG | BEFORE_INITIALIZE_FLAG
66 Bitmask: 0x2080
67
68 State Management:
69 - volatilityOracle: IVolatilityOracle (immutable, set in constructor)
70 - baseFee: uint24 (configurable by owner)
71 - maxFee: uint24 (cap to prevent excessive fees)
72 - feeMultiplier: uint24 (scales with volatility)
73
74 Gas Estimates:
75 beforeSwap: ~30,000 gas (oracle read + fee calculation)
76 beforeInitialize: ~25,000 gas (one-time setup)
77
78 Security Considerations:
79 - Oracle manipulation: Use TWAP, not spot price
80 - Fee cap: Enforce maxFee to protect traders
81 - Owner control: Fee parameters updatable by owner only
82
83 Architecture Decisions:
84 - Using beforeSwap (not afterSwap) to set fee before execution
85 - External oracle for volatility data rather than on-chain calculation
86 - Fee bounded between baseFee and maxFee for predictability
87
88 Alternative Approaches:
89 - On-chain volatility calculation (higher gas, no oracle dependency)
90 - Fixed fee tiers with governance voting (simpler, less responsive)
91```
92
93## Important Notes
94
95- This skill produces a design document only -- no code is generated and no files are written.
96- The design document provides enough detail to proceed with `build-hook` when the user is ready.
97- If the hook design is infeasible (e.g., requires callbacks that V4 doesn't support), this will be clearly communicated.
98- Gas estimates are approximations based on typical implementations -- actual gas depends on implementation details.
99
100## Error Handling
101
102| Error | User-Facing Message | Suggested Action |
103| --- | --- | --- |
104| `VAGUE_REQUIREMENTS` | "Need more detail about the desired hook behavior." | Describe specific behavior (e.g., "limit orders that execute at tick boundaries") |
105| `UNSUPPORTED_CALLBACK` | "V4 does not support the requested callback." | Review available V4 callbacks and adjust requirements |
106| `INFEASIBLE_DESIGN` | "This hook design is not feasible with current V4 capabilities." | Simplify requirements or consider alternative approaches |