/permissioned-pools-configurator

name: permissioned-pools-configurator
description: Interactively collect and validate the parameters for a Uniswap v4 Permissioned Pool setup - chain, underlying token, allowlist checker, adapter owner, verification deposit, the four wrapper registrations, hook, and pool pricing - and emit the JSON config the deployer skill consumes. Use when the user says "configure a permissioned pool", "permissioned pool config", "adapter parameters", "permissioned pool setup parameters", "PermissionsAdapter configuration", or asks to set up parameters for a permissioned pool before deploying. Covers contract mechanics only - does not constitute legal, financial, investment, tax, or compliance advice, and is not a compliance review.
allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion
model: opus
license: MIT
metadata:
  author: uniswap
  version: '0.1.0'

Permissioned Pools Configurator

Interactive bulk-form configurator for a Uniswap v4 Permissioned Pool. Collects every parameter the setup journey needs, validates each one, and displays a single JSON configuration object that the `permissioned-pools-deployer` skill consumes to run the on-chain sequence. For the contract mechanics behind any of these parameters, see [`permissioned-pools-issuer`](../permissioned-pools-issuer/SKILL.md).

> **Runtime Compatibility:** This skill uses `AskUserQuestion` to collect parameters in > batches. If `AskUserQuestion` is not available in your runtime, collect the same > parameters through natural language conversation instead, in the same batch groupings > and with the same validation after each group.

Scope and Disclaimer

**This is a configuration tool, not deployment guidance and not a compliance review.**

• ✅ It collects and validates the inputs a permissioned-pool setup needs and produces a

JSON document. It does not call any contract, does not broadcast anything, and holds no signing keys.

• ✅ **Treat this as contract mechanics only.** This skill does not constitute legal, financial, investment, or tax advice, and it is **not** a compliance review of your token, your allowlist, your KYC or AML program, or your configuration. It covers what each parameter means and what breaks if it is wrong.
• ✅ It never invents a contract address. Addresses you supply are recorded as given;

addresses you do not yet have — whether because they still need to be looked up against the deploy guide's table or because the issuer has not decided on them yet — are stored as the literal string `"RESOLVE"`, never guessed or recalled from memory.

• ✅ Review the emitted configuration yourself, and re-resolve every address it marks for

resolution, before handing it to a deployment flow.

• ✅ **Read the repo's usage guidelines.** The repo root `DISCLAIMER.md` governs every skill in

this repository: they are provided as is without warranty, they do not constitute legal, financial, investment, or tax advice, and it sets out use limits plus an AI-disclosure duty that applies when you use a skill to generate financial information and present it directly to individuals or consumers. Point the user to it.

State this framing inline (quoted or in your own words) and continue with the configuration flow in the same response — this is reference and data-collection content, not an action-oriented deployment step, so no acknowledgment gate is needed here. The deployer skill gates on acknowledgment before anything gas-spending.

What This Config Is (and Isn't)

The output is a **pre-deployment plan**, not a record of what already exists on-chain.

• The **`PermissionsAdapter` address does not appear in this config.** It does not exist

until the deployer's Step 2 (`createPermissionsAdapter`) creates it. If the issuer already has a deployed adapter for this token, that is a re-run/import scenario this skill does not currently handle — collect its address as a note and confirm with the deployer skill's preflight checks instead of adding it here. **This declines only the adapter address itself — it does not block the rest of the request.** Continue validating and including every other field the user supplied (or marked `"RESOLVE"`) in the emitted configuration exactly as the flow below describes.

• The **underlying permissioned token is the only token address this config records.**

See the two-addresses distinction in `permissioned-pools-issuer` — the pool currency the deployer builds later is the adapter, derived at deploy time, not configured here.

• Wrapper and hook addresses are **chain-specific and change over time.** This skill asks

whether you already have them resolved for your target chain; if not, it marks them for resolution rather than filling in a value.

Configuration Flow

Collect parameters in four batches of at most four questions each. After each batch, validate every answer against [`config-schema.md`](./references/config-schema.md) before moving on, and show a running summary of what has been collected and what remains. Field-by-field meaning, how to choose each value, and what breaks if it is wrong are all in [`parameter-reference.md`](./references/parameter-reference.md).

Front-loaded or skip-ahead answers

A user may answer several batches' worth of questions in one free-form message, or ask to skip the remaining questions and finish immediately. Do not withhold the whole configuration while asking whether to proceed. Instead: validate everything the user did supply against `config-schema.md`, apply the literal string `"RESOLVE"` (or `null` for `allowlistChecker.address` when the checker is `to-be-deployed`) to every address-type field left open, and produce that partial configuration in the same response. Fields with no `"RESOLVE"` sentinel — the verification deposit amount, pool currency, fee tier, tick spacing, starting price, and seeding — have no safe default; flag each one explicitly as still needing an answer rather than guessing at it, and ask only