[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GWEB8DKMMJQJTQGHRWHHTX":3,"skill-same:01M6GWEB8DKMMJQJTQGHRWHHTX":85},{"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":19,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6GWEB8DKMMJQJTQGHRWHHTX","dexe-create-proposal",null,"Create any DeXe governance proposal with the one-call `dexe_proposal_create`\ncomposite — it runs approve→deposit→createProposalAndVote and uploads correct\nIPFS metadata for you. Covers every wired proposalType + params recipe and the\nmetadata\u002FABI\u002Fblacklist failure modes. Use when the user says \"create a proposal\",\n\"transfer treasury\", \"add an expert\", \"change voting settings\", \"start a token sale\".","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\u002Fmcp-servers\u002Fedward-arinin-web-dev-dexe-create-proposal\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Fedward-arinin-web-dev-dexe-create-proposal\u002FSKILL.md",[],[20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"create","dexe create proposal","create proposal","proposal","when","change","modes","for","treasury","you","with","add","recipe","ipfs","token","deposit","call","expert","uploads","use","voting","correct","start","2026-11-10 10:12:30",false,"---\nname: dexe-create-proposal\ndescription: |\n  Create any DeXe governance proposal with the one-call `dexe_proposal_create`\n  composite — it runs approve→deposit→createProposalAndVote and uploads correct\n  IPFS metadata for you. Covers every wired proposalType + params recipe and the\n  metadata\u002FABI\u002Fblacklist failure modes. Use when the user says \"create a proposal\",\n  \"transfer treasury\", \"add an expert\", \"change voting settings\", \"start a token sale\".\n---\n\n# dexe-create-proposal\n\n`dexe_proposal_create` builds a governance proposal in **one call**: it checks\ntoken balance, approves the **UserKeeper** (not GovPool), deposits, uploads IPFS\nmetadata with the correct `{proposalName, proposalDescription, category, isMeta,\nchanges}` shape, and calls `createProposalAndVote`. With a signer (WalletConnect,\nkeystore, or an unattended hot key) it broadcasts; otherwise it returns ordered\n`TxPayload`s.\n\nIf you don't already know the target `govPool`\u002Fchain, call **`dexe_context`** —\nit returns the active chain and the DAOs\u002Fproposals from prior sessions\n(`dexe_write_context` returns the signer).\nWhen the user already told you the DAO and what to do, go straight to\n`dexe_proposal_create`.\n\n**Do not hand-sequence** approve\u002Fdeposit\u002Fcreate, and do not hand-build the IPFS\nmetadata — the composite does both correctly. **Do not guess ABIs\u002Fselectors**;\nthe wired builders encode canonical calldata. For a truly custom call use the\n`custom_abi` type; `dexe_proposal_catalog` (or the playbook — MCP resource\n`dexe:\u002F\u002Fplaybook`, `docs\u002FPLAYBOOK.md`) lists every type and its params.\n\n**Amounts:** a digits-only string is raw wei; a string with a decimal point\n(`\"1000.0\"`) is human units, scaled by the token's **real on-chain decimals**\n(never assumed 18). Both forms work in every `params` amount and `voteAmount`.\n\n## Pick a proposalType\n\nPass `proposalType` + the type's inputs in `params`:\n\n| proposalType | params |\n|---|---|\n| `token_transfer` | `{ token, recipient, amount, isNative? }` |\n| `withdraw_treasury` | `{ receiver, token?, amount?, nftAddress?, nftIds? }` (emits external `token.transfer`) |\n| `change_voting_settings` | `{ govSettings, settings:[…], settingsIds? }` (empty ids ⇒ addSettings) |\n| `add_expert` | `{ expertNftContract, scope:\"local\"\\|\"global\", nominatedUser, uri? }` |\n| `remove_expert` | `{ expertNftContract, scope, nominatedUser }` |\n| `token_distribution` | `{ distributionProposal, proposalId, token, amount, isNative? }` |\n| `token_sale` | `{ tokenSaleProposal, tiers:[…], latestTierId? }` |\n| `custom_abi` | `{ target, signature, method, args?, value? }` |\n| `modify_dao_profile` | top-level `newDaoName\u002FnewDaoDescription\u002FnewWebsiteUrl\u002FnewSocialLinks`; avatar via `newAvatarPath` (local image path — the server uploads + validates it; do NOT read the file yourself) or `newAvatarCID` |\n| `custom` | top-level `actionsOnFor:[{executor,value,data}]` (+ optional `category`) |\n\n**All 33 catalog types are wired** — `proposalType` is a strict enum; an\nunknown string is rejected at validation with the list of valid types. Beyond\nthe table above: treasury\u002Ftokens (`apply_to_dao`, `token_sale_recover`,\n`token_sale_whitelist`), governance config (`new_proposal_type`,\n`enable_staking`, `change_math_model`, `manage_validators` \u002F\n`validators_allocation`), experts\u002Fdelegation (`delegate_to_expert` \u002F\n`revoke_from_expert`, plus catalog-style aliases like\n`delegate_tokens_to_expert` and `add_local_expert` \u002F `add_global_expert`),\ntoken controls (`blacklist`, `reward_multiplier`), and staking\n(`create_staking_tier`).\n\nInternal validator types (`change_validator_balances`,\n`change_validator_settings`, `monthly_withdraw`, `offchain_internal_proposal`)\n**auto-route to `GovValidators.createInternalProposal`** — validators only, no\ndeposit or UserKeeper approve. Off-chain types are on the DeXe backend, not\non-chain: build with `dexe_proposal_build_offchain_*`, then **`dexe_auth_login`**\n(one call — signs the nonce internally when a signer is set; never write code\nthat extracts the private key to sign), then POST with the Bearer token. Only\n**single-option and multi-option** off-chain voting exist in the DeXe product —\n**`offchain_for_against` is NOT creatable** (the app has no for\u002Fagainst creation\npath); for a binary vote use `offchain_single_option` with `[\"For\",\"Against\"]`.\nDiscover every type + params with `dexe_proposal_catalog`.\n\n## Example: transfer treasury tokens\n\n```jsonc\ndexe_proposal_create({\n  govPool: \"0x…\",\n  chainId: 97,\n  proposalType: \"token_transfer\",\n  title: \"Pay contributor grant\",\n  description: \"Q3 grant to @alice.\",\n  params: { token: \"0xGovToken\", recipient: \"0xAlice\", amount: \"1000.0\" }  \u002F\u002F human units\n})\n```\n\n## Example: update the DAO avatar (ONE call — no upload step, no file reading)\n\n```jsonc\ndexe_proposal_create({\n  govPool: \"0x…\",\n  proposalType: \"modify_dao_profile\",\n  title: \"New DAO avatar\",\n  newAvatarPath: \"C:\u002FUsers\u002Fme\u002FPictures\u002Flogo.png\"   \u002F\u002F server reads, validates, pins\n})\n```\n\nThe server reads the image from disk, rejects non-raster bytes (SVG never\nrenders on app.dexe.io), pins it, rebuilds the metadata, and creates the\nproposal. Do not call `dexe_ipfs_upload_avatar` first and do not read the\nimage file into the conversation.\n\n## Failure modes this guards against\n\n1. **Sequence** — the composite runs approve→deposit→create; never do it by hand.\n2. **Metadata shape** — auto-built + preflight-validated (`{proposalName,\n   proposalDescription, category, isMeta:false, changes:{proposedChanges,\n   currentChanges}}`). Wrong shape breaks the frontend indexer\u002Fdiff.\n3. **ABI\u002Fselector guessing** — wired builders use canonical signatures; tuple\n   field order is easy to get wrong by hand.\n4. **votingPower vs tokenBalance** — deposited power is\n   `tokenBalance(user,0).balance − ownedBalance`, not `votingPower()` (which is 0\n   without a deposit). The composite computes it.\n6. **Approve target** — the composite approves the **UserKeeper** (which does\n   `transferFrom`), never GovPool.\n8. **withdraw_treasury** emits an external `token.transfer`, never\n   `GovPool.withdraw` (\"Gov: invalid internal data\").\n10. **Blacklisted recipient** — token transfers to a blacklisted address are\n    refused up front (they'd stick the proposal in `SucceededFor` forever).\n11. **Quorum-danger gate (`confirmRisky`)** — a `change_voting_settings` \u002F\n    `new_proposal_type` build that lowers quorum below the safe floor (into\n    treasury-drain territory) is refused **before any transaction** with\n    `mode: \"blocked-risky\"` + `governanceAdvisories`. If the lowering is\n    intentional, re-run the SAME call with `confirmRisky: true`. CAUTION-level\n    advisories (no-timelock, unreachable validator quorum) attach to the result\n    without blocking.\n\n## Cross-DAO delegation (partner DAO votes with delegated power)\n\nA holder can delegate deposited power to another DAO's GovPool, and that DAO\nthen votes in the first DAO with the delegated (micropool) power:\n\n1. `dexe_vote_build_delegate({ govPool: A, delegatee: \u003CDAO_B govPool>, amount })`\n   → broadcast. (First make every proposal you voted on in A **terminal**, or\n   this reverts `GovUK: overdelegation` — see [[dexe-vote-execute]].)\n2. In DAO B, create a `custom` proposal whose action calls A's vote:\n   `actionsOnFor: [{ executor: A, data: \u003CA.multicall([vote(pid, true, 0, [])])> }]`\n   (build the inner calldata with `dexe_vote_build_vote({ govPool: A, proposalId, amount: \"0\" })`).\n3. Pass + execute the DAO-B proposal → on execute, B calls `A.vote()` and its\n   micropool power is counted (verify with\n   `dexe_vote_get_votes(A, pid, voter: B, voteType: \"MicropoolVote\")`).\n   Works when A has `delegatedVotingAllowed=false` (micropool voting).\n\n## No signer? Preview first\n\nPass `dryRun: true` to get the ordered `TxPayload`s without broadcasting (also\nthe default behavior when no signer is configured). Then broadcast via\n`dexe_tx_send` or a connected wallet.\n\nNext step after it passes: [[dexe-vote-execute]].\n\n## Canonical recipe (generated from src\u002Fknowledge\u002F — edit there, then `npm run gen:knowledge`)\n\n\u003C!-- BEGIN GENERATED: flow-recipe -->\n### Create a governance proposal (any type) (`create_proposal`)\n\nCreate ANY of the 33 catalog proposal types with one dexe_proposal_create call — it handles approve → deposit → create + IPFS metadata.\n\n**Ask the user:**\n- `govPool` — Which DAO (govPool address)? If we just created one this session, confirm reusing it.\n- `proposalType` — What should the proposal DO? (map the user's intent to a proposalType via dexe_proposal_catalog — e.g. token_transfer, change_voting_settings, add_expert)\n- `title` — Proposal title (public)?\n- `description` (optional) — Short proposal description for voters? (optional but recommended)\n\n**Steps:**\n1. `dexe_proposal_catalog` — Only when unsure which proposalType matches the intent: list all 33 types with their target + effect. The per-type params shapes are in dexe_proposal_create's description and docs\u002FPLAYBOOK.md. _(skip when: the proposalType is already obvious from the user's request)_\n2. `dexe_proposal_create` — Approve → deposit → createProposalAndVote in one call, with correct IPFS metadata.\n\n**Pitfalls (danger first):**\n- ? When depositing gov tokens, ERC20.approve must target the DAO's UserKeeper, NEVER the GovPool. Approving the GovPool burns gas and the deposit reverts. The composites (dexe_proposal_create, dexe_proposal_vote_and_execute) sequence this correctly — do not hand-build the approve.\n- ? CHAIN-ASYMMETRIC (verified 2026-07-23): on fresh TESTNET (97) pools, EXECUTING a proposal whose action is GovSettings.addSettings reverts 'disallowed tx pattern' — deterministically, re-running never helps. This hits change_voting_settings WITHOUT settingsIds, new_proposal_type, and enable_staking. On current MAINNET (56) fresh pools addSettings EXECUTES fine (proven 2026-07-22) — testnet runs an older protocol deployment. On 97: EDIT existing settings instead (pass settingsIds) — editSettings is always allowed — and do NOT use testnet to validate addSettings-based flows.\n- ⚠ Tokens you voted with stay LOCKED per-proposal even after the proposal executes, and votingPower() reads 0 while locked (it shows available, not deposited, power). Between proposals run dexe_vote_build_withdraw to unlock, or the next create\u002Fvote fails with 'No voting power available'.\n- ⚠ Fresh (SphereX-guarded, deployed ≥ 2026-07) pools reject multicall([deposit, createProposalAndVote]) with 'SphereX error: disallowed tx pattern'. Deposit and create must be SEPARATE transactions — the composites already send them separately; never re-bundle them.\n- ⚠ settingsIds semantics: 0 = DEFAULT settings, 1 = INTERNAL settings (2 validators, 3 distribution, 4 tokenSale on fresh deploys). When editing, leave executorDescription blank to preserve the on-chain value — it holds the settings-JSON IPFS ref the frontend reads; overwriting it blanks the DAO's settings UI.\n- ⚠ A token transfer to a blacklisted recipient passes the vote and then REVERTS at execute — the proposal is stuck in SucceededFor forever (there is no cancel). Before proposing transfers of an ERC20Gov token, verify the recipient isn't blacklisted.\n- ℹ Creating a proposal requires approve(UserKeeper) → deposit(GovPool) → createProposal, in that order. dexe_proposal_create runs the whole sequence; on partial failure it returns the landed-steps ledger — fix the cause and re-run the SAME call. approve, deposit, createProposalAndVote and the vote are re-derived from chain state and skipped; GovPool.execute and the validator round are NOT, and a receipt-wait TIMEOUT means the transaction was already broadcast — check dexe_tx_status before re-running.\n- ℹ The FIRST proposal on a freshly deployed DAO can revert 'low creating power' — the just-landed deposit isn't credited at snapshot time. This is transient: re-run the SAME dexe_proposal_create call; the ledger resume skips the landed deposit and the create succeeds.\n- ℹ Amount strings: digits-only = RAW smallest units (wei); a decimal point (\"12.5\") = human units scaled by the token's REAL on-chain decimals (never assumed 18). Durations and delays are SECONDS (86400 = 1 day). Composite quorum\u002Fpercent params are plain percent numbers (51).\n\n_For the machine-readable plan (interview questions with risk notes, step templates with `flowContext` chaining), call the `dexe_guide` tool with `flow:\"create_proposal\"`._\n\u003C!-- END GENERATED: flow-recipe -->\n","# dexe-create-proposal\n\n`dexe_proposal_create` builds a governance proposal in **one call**: it checks\ntoken balance, approves the **UserKeeper** (not GovPool), deposits, uploads IPFS\nmetadata with the correct `{proposalName, proposalDescription, category, isMeta,\nchanges}` shape, and calls `createProposalAndVote`. With a signer (WalletConnect,\nkeystore, or an unattended hot key) it broadcasts; otherwise it returns ordered\n`TxPayload`s.\n\nIf you don't already know the target `govPool`\u002Fchain, call **`dexe_context`** —\nit returns the active chain and the DAOs\u002Fproposals from prior sessions\n(`dexe_write_context` returns the signer).\nWhen the user already told you the DAO and what to do, go straight to\n`dexe_proposal_create`.\n\n**Do not hand-sequence** approve\u002Fdeposit\u002Fcreate, and do not hand-build the IPFS\nmetadata — the composite does both correctly. **Do not guess ABIs\u002Fselectors**;\nthe wired builders encode canonical calldata. For a truly custom call use the\n`custom_abi` type; `dexe_proposal_catalog` (or the playbook — MCP resource\n`dexe:\u002F\u002Fplaybook`, `docs\u002FPLAYBOOK.md`) lists every type and its params.\n\n**Amounts:** a digits-only string is raw wei; a string with a decimal point\n(`\"1000.0\"`) is human units, scaled by the token's **real on-chain decimals**\n(never assumed 18). Both forms work in every `params` amount and `voteAmount`.\n\n## Pick a proposalType\n\nPass `proposalType` + the type's inputs in `params`:\n\n| proposalType | params |\n|---|---|\n| `token_transfer` | `{ token, recipient, amount, isNative? }` |\n| `withdraw_treasury` | `{ receiver, token?, amount?, nftAddress?, nftIds? }` (emits external `token.transfer`) |\n| `change_voting_settings` | `{ govSettings, settings:[…], settingsIds? }` (empty ids ⇒ addSettings) |\n| `add_expert` | `{ expertNftContract, scope:\"local\"\\|\"global\", nominatedUser, uri? }` |\n| `remove_expert` | `{ expertNftContract, scope, nominatedUser }` |\n| `token_distribution` | `{ distributionProposal, proposalId, token, amount, isNative? }` |\n| `token_sale` | `{ tokenSaleProposal, tiers:[…], latestTierId? }` |\n| `custom_abi` | `{ target, signature, method, args?, value? }` |\n| `modify_dao_profile` | top-level `newDaoName\u002FnewDaoDescription\u002FnewWebsiteUrl\u002FnewSocialLinks`; avatar via `newAvatarPath` (local image path — the server uploads + validates it; do NOT read the file yourself) or `newAvatarCID` |\n| `custom` | top-level `actionsOnFor:[{executor,value,data}]` (+ optional `category`) |\n\n**All 33 catalog types are wired** — `proposalType` is a strict enum; an\nunknown string is rejected at validation with the list of valid types. Beyond\nthe table above: treasury\u002Ftokens (`apply_to_dao`, `token_sale_recover`,\n`token_sale_whitelist`), governance config (`new_proposal_type`,\n`enable_staking`, `change_math_model`, `manage_validators` \u002F\n`validators_allocation`), experts\u002Fdelegation (`delegate_to_expert` \u002F\n`revoke_from_expert`, plus catalog-style aliases like\n`delegate_tokens_to_expert` and `add_local_expert` \u002F `add_global_expert`),\ntoken controls (`blacklist`, `reward_multiplier`), and staking\n(`create_staking_tier`).\n\nInternal validator types (`change_validator_balances`,\n`change_validator_settings`, `monthly_withdraw`, `offchain_internal_proposal`)\n**auto-route to `GovValidators.createInternalProposal`** — validators only, no\ndeposit or UserKeeper approve. Off-chain types are on the DeXe backend, not\non-chain: build with `dexe_proposal_build_offchain_*`, then **`dexe_auth_login`**\n(one call — signs the nonce internally when a signer is set; never write code\nthat extracts the private key to sign), then POST with the Bearer token. Only\n**single-option and multi-option** off-chain voting exist in the DeXe product —\n**`offchain_for_against` is NOT creatable** (the app has no for\u002Fagainst creation\npath); for a binary vote use `offchain_single_option` with `[\"For\",\"Against\"]`.\nDiscover every type + params with `dexe_proposal_catalog`.\n\n## Example: transfer treasury tokens\n\n```jsonc\ndexe_proposal_create({\n  govPool: \"0x…\",\n  chainId: 97,\n  proposalType: \"token_transfer\",\n  title: \"Pay contributor grant\",\n  description: \"Q3 grant to @alice.\",\n  params: { token: \"0xGovToken\", recipient: \"0xAlice\", amount: \"1000.0\" }  \u002F\u002F human units\n})\n```\n\n## Example: update the DAO avatar (ONE call — no upload step, no file reading)\n\n```jsonc\ndexe_proposal_create({\n  govPool: \"0x…\",\n  proposalType: \"modify_dao_profile\",\n  title: \"New DAO avatar\",\n  newAvatarPath: \"C:\u002FUsers\u002Fme\u002FPictures\u002Flogo.png\"   \u002F\u002F server reads, validates, pins\n})\n```\n\nThe server reads the image from disk, rejects non-raster bytes (SVG never\nrenders on app.dexe.io), pins it, rebuilds the metadata, and creates the\nproposal. Do not call `dexe_ipfs_upload_avatar` first and do not read the\nimage file into the conversation.\n\n## Failure modes this guards against\n\n1. **Sequence** — the composite runs approve→deposit→create; never do it by hand.\n2. **Metadata shape** — auto-built + preflight-validated (`{proposalName,\n   proposalDescription, category, isMeta:false, changes:{proposedChanges,\n   currentChanges}}`). Wrong shape breaks the frontend indexer\u002Fdiff.\n3. **ABI\u002Fselector guessing** — wired builders use canonical signatures; tuple\n   field order is easy to get wrong by hand.\n4. **votingPower vs tokenBalance** — deposited power is\n   `tokenBalance(user,0).balance − ownedBalance`, not `votingPower()` (which is 0\n   without a deposit). The composite computes it.\n6. **Approve target** — the composite approves the **UserKeeper** (which does\n   `transferFrom`), never GovPool.\n8. **withdraw_treasury** emits an external `token.transfer`, never\n   `GovPool.withdraw` (\"Gov: invalid internal data\").\n10. **Blacklisted recipient** — token transfers to a blacklisted address are\n    refused up front (they'd stick the proposal in `SucceededFor` forever).\n11. **Quorum-danger gate (`confirmRisky`)** — a `change_voting_settings` \u002F\n    `new_proposal_type` build that lowers quorum below the safe floor (into\n    treasury-drain territory) is refused **before any transaction** with\n    `mode: \"blocked-risky\"` + `governanceAdvisories`. If the lowering is\n    intentional, re-run the SAME call with `confirmRisky: true`. CAUTION-level\n    advisories (no-timelock, unreachable validator quorum) attach to the result\n    without blocking.\n\n## Cross-DAO delegation (partner DAO votes with delegated power)\n\nA holder can delegate deposited power to another DAO's GovPool, and that DAO\nthen votes in the first DAO with the delegated (micropool) power:\n\n1. `dexe_vote_build_delegate({ govPool: A, delegatee: \u003CDAO_B govPool>, amount })`\n   → broadcast. (First make every proposal you voted on in A **terminal**, or\n   this reverts `GovUK: overdelegation` — see [[dexe-vote-execute]].)\n2. In DAO B, create a `custom` proposal whose action calls A's vote:\n   `actionsOnFor: [{ executor: A, data: \u003CA.multicall([vote(pid, true, 0, [])])> }]`\n   (build the inner calldata with `dexe_vote_build_vote({ govPool: A, proposalId, amount: \"0\" })`).\n3. Pass + execute the DAO-B proposal → on execute, B calls `A.vote()` and its\n   micropool power is counted (verify with\n   `dexe_vote_get_votes(A, pid, voter: B, voteType: \"MicropoolVote\")`).\n   Works when A has `delegatedVotingAllowed=false` (micropool voting).\n\n## No signer? Preview first\n\nPass `dryRun: true` to get the ordered `TxPayload`s without broadcasting (also\nthe default behavior when no signer is configured). Then broadcast via\n`dexe_tx_send` or a connected wallet.\n\nNext step after it passes: [[dexe-vote-execute]].\n\n## Canonical recipe (generated from src\u002Fknowledge\u002F — edit there, then `npm run gen:knowledge`)\n\n\u003C!-- BEGIN GENERATED: flow-recipe -->\n### Create a governance proposal (any type) (`create_proposal`)\n\nCreate ANY of the 33 catalog proposal types with one dexe_proposal_create call — it handles approve → deposit → create + IPFS metadata.\n\n**Ask the user:**\n- `govPool` — Which DAO (govPool address)? If we just created one this session, confirm reusing it.\n- `proposalType` — What should the proposal DO? (map the user's intent to a proposalType via dexe_proposal_catalog — e.g. token_transfer, change_voting_settings, add_expert)\n- `title` — Proposal title (public)?\n- `description` (optional) — Short proposal description for voters? (optional but recommended)\n\n**Steps:**\n1. `dexe_proposal_catalog` — Only when unsure which proposalType matches the intent: list all 33 types with their target + effect. The per-type params shapes are in dexe_proposal_create's description and docs\u002FPLAYBOOK.md. _(skip when: the proposalType is already obvious from the user's request)_\n2. `dexe_proposal_create` — Approve → deposit → createProposalAndVote in one call, with correct IPFS metadata.\n\n**Pitfalls (danger first):**\n- ? When depositing gov tokens, ERC20.approve must target the DAO's UserKeeper, NEVER the GovPool. Approving the GovPool burns gas and the deposit reverts. The composites (dexe_proposal_create, dexe_proposal_vote_and_execute) sequence this correctly — do not hand-build the approve.\n- ? CHAIN-ASYMMETRIC (verified 2026-07-23): on fresh TESTNET (97) pools, EXECUTING a proposal whose action is GovSettings.addSettings reverts 'disallowed tx pattern' — deterministically, re-running never helps. This hits change_voting_settings WITHOUT settingsIds, new_proposal_type, and enable_staking. On current MAINNET (56) fresh pools addSettings EXECUTES fine (proven 2026-07-22) — testnet runs an older protocol deployment. On 97: EDIT existing settings instead (pass settingsIds) — editSettings is always allowed — and do NOT use testnet to validate addSettings-based flows.\n- ⚠ Tokens you voted with stay LOCKED per-proposal even after the proposal executes, and votingPower() reads 0 while locked (it shows available, not deposited, power). Between proposals run dexe_vote_build_withdraw to unlock, or the next create\u002Fvote fails with 'No voting power available'.\n- ⚠ Fresh (SphereX-guarded, deployed ≥ 2026-07) pools reject multicall([deposit, createProposalAndVote]) with 'SphereX error: disallowed tx pattern'. Deposit and create must be SEPARATE transactions — the composites already send them separately; never re-bundle them.\n- ⚠ settingsIds semantics: 0 = DEFAULT settings, 1 = INTERNAL settings (2 validators, 3 distribution, 4 tokenSale on fresh deploys). When editing, leave executorDescription blank to preserve the on-chain value — it holds the settings-JSON IPFS ref the frontend reads; overwriting it blanks the DAO's settings UI.\n- ⚠ A token transfer to a blacklisted recipient passes the vote and then REVERTS at execute — the proposal is stuck in SucceededFor forever (there is no cancel). Before proposing transfers of an ERC20Gov token, verify the recipient isn't blacklisted.\n- ℹ Creating a proposal requires approve(UserKeeper) → deposit(GovPool) → createProposal, in that order. dexe_proposal_create runs the whole sequence; on partial failure it returns the landed-steps ledger — fix the cause and re-run the SAME call. approve, deposit, createProposalAndVote and the vote are re-derived from chain state and skipped; GovPool.execute and the validator round are NOT, and a receipt-wait TIMEOUT means the transaction was already broadcast — check dexe_tx_status before re-running.\n- ℹ The FIRST proposal on a freshly deployed DAO can revert 'low creating power' — the just-landed deposit isn't credited at snapshot time. This is transient: re-run the SAME dexe_proposal_create call; the ledger resume skips the landed deposit and the create succeeds.\n- ℹ Amount strings: digits-only = RAW smallest units (wei); a decimal point (\"12.5\") = human units scaled by the token's REAL on-chain decimals (never assumed 18). Durations and delays are SECONDS (86400 = 1 day). Composite quorum\u002Fpercent params are plain percent numbers (51).\n\n_For the machine-readable plan (interview questions with risk notes, step templates with `flowContext` chaining), call the `dexe_guide` tool with `flow:\"create_proposal\"`._\n\u003C!-- END GENERATED: flow-recipe -->\n",{"name":5,"description":7},"main","3df1d0d67b30ff15236561f8c0f9f06d33f42dfd","skills\u002Fmcp-servers\u002Fedward-arinin-web-dev-dexe-create-proposal",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-12 02:28:42",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill dexe-create-proposal",{"tool":63,"command":64},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill dexe-create-proposal",{"tool":66,"command":67},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill dexe-create-proposal","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Fedward-arinin-web-dev-dexe-create-proposal\u002FSKILL.md",true,[71,75,81],{"path":72,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":16},"LICENSE","许可证",1070,{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"SOURCE.md","REFERENCE","参考文档",393,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Fedward-arinin-web-dev-dexe-create-proposal\u002FSOURCE.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"TRUST.auto.yaml",2174,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Fedward-arinin-web-dev-dexe-create-proposal\u002FTRUST.auto.yaml",[86,113,135,153,166,176],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":90,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":43},"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",[],[94,95,32,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112],"performance","recipe performance","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":117,"licenseFileUrl":118,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":43},"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",[],[122,123,124,125,126,127,128,129,130,131,27,132,133,134],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","api keys","maintenance","protobuf",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":117,"licenseFileUrl":139,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":43},"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",[],[143,123,144,145,146,147,148,132,27,131,149,150,151,127,152,126,125],"mexc spot rest","REST","admin","signing","Wallet","requests","actions","secure","data","orders",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":117,"licenseFileUrl":157,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":43},"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",[],[161,162,124,163,164,133,27,165,130,129,127,126],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":167,"name":168,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":169,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":43},"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",[],[173,174,175],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":180,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":43},"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",[],[184,185,186,187,188,189,190,39,191,192,193],"tests","cover","verify tests cover changed lines","verify","coverage","pr","exercise","patch","code","share"]