[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77WD9V76YAPJS47ZN92C2RT":3,"skill-same:01M77WD9V76YAPJS47ZN92C2RT":53},{"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":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":31,"updatedAt":32,"install":33,"resources":46},"01M77WD9V76YAPJS47ZN92C2RT","builder",null,"Get permission for an app or agent to use a person's Vana data, read it, and verify the requested result. Use for consuming-app integration, including the developer's own collected data, grants, escrow, fees, saved app delivery and connector iteration. Source collection belongs to connect-data.","vana-com\u002Fvana-cli","vana-com","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F123112561?v=4","01M77WCAG7S42PDY7VTEVWXQD1","Vana","01M77WCAGV436KWGZWHNHZXGVH",2,"MIT","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002Fskills\u002Fbuilder\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: builder\ndescription: >\n  Get permission for an app or agent to use a person's Vana data, read it,\n  and verify the requested result. Use for consuming-app integration,\n  including the developer's own collected data, grants, escrow, fees,\n  saved app delivery and connector iteration. Source collection belongs\n  to connect-data.\n---\n\n# Builder\n\nRead workflows with `vana skills show \u003Cid> --json`. The response includes full\ninstructions and required reference content; installation into the agent's\nharness is optional. Use `connect-data`, `create-connector` or `builder` as the\nrequested goal needs them.\n\nThe `vana app` command group is the builder side of Vana: register once,\nask a person for access, read what they approved, pay the fee from escrow.\nEvery command takes `--json` and returns one outcome object; branch on the\nexit code, read `code` for the reason and `remedy` for the next command.\n\nStart from the person's intended result and continue through the app handoff\nand verification they requested. Select the commands yourself; the person\nhandles account choices, sign-in, consent and any spending decision. Use the\nintended app's existing backend key, owner, Account deployment and network.\nAn app name does not select its credentials. Keep keys server-side and out of\nchat, browser code and saved reports.\n\nFor an app integration, read [delivery and verification](reference\u002Fverification.md)\nbefore requesting access. It covers readiness, real approval, bounded reads,\ndurable storage, display, recovery and same-grant iteration for any consumer.\nThe instructions and required references are public. The user's app supplies\nits own storage and UI; no reference app or observability service is required.\n\n## The loop\n\n```bash\nvana app register --network moksha --app-url http:\u002F\u002Flocalhost:3000 --app-name \"\u003Cyour name>\" # create and test first\nvana app request --network moksha --scopes spotify.savedTracks          # ask a person\nvana app read --network moksha spotify.savedTracks --grant \u003Cid> --pay   # read and pay\n```\n\nCheck `vana app whoami --json` first and reuse an appropriate registration.\nRegister with the name the person should see on the approval page, such as\nyour agent's name. The CLI remembers the name for this app key and falls back to\n\"Vana CLI\" when a request has no name. Use your app's HTTP(S) URL. A localhost\nURL works for testing. Vana Account needs the URL to claim the app, and the\ngateway registration keeps its original URL.\n\nOr ask a question instead of reading raw data, in one command:\n\n```bash\nvana app ask \"Which genres fill their saved tracks?\" --network moksha \\\n  --sources spotify.savedTracks --derived myapp.genres --pay\n```\n\n`request` prints an approval URL and waits. The person opens it, approves,\nand the grant id comes back to the terminal. The read command returns data;\nan app integration must also verify its own save and display.\nThe `--pay` examples require an agreed fee-asset limit before execution.\n\n## Exit codes\n\nBranch on these instead of parsing text.\n\n| Code | Meaning                             | What to do                                                             |\n| ---- | ----------------------------------- | ---------------------------------------------------------------------- |\n| 0    | done                                | continue                                                               |\n| 1    | failed                              | read `message`, do not retry blindly                                   |\n| 2    | bad usage                           | fix the command                                                        |\n| 3    | no grant, or it does not cover this | `vana app request` again                                               |\n| 4    | payment required                    | inspect the quote and obtain a spending limit before paying or funding |\n| 5    | no server answered                  | the owner's Personal Server is offline; not your fault, retry later    |\n| 6    | not ready yet                       | wait and repeat, using any interval the payload names                  |\n| 7    | a person has to act                 | surface the URL to a human                                             |\n\n## Asking for access\n\n```bash\nvana app request --network moksha --scopes spotify.savedTracks,spotify.playlists --json\n```\n\nWaits up to ten minutes by default (`--timeout \u003Cseconds>`). On approval the\noutcome carries `grantId` and the exact read command in `remedy`.\n\nOne grant per owner and app: an approval replaces the grant's scopes, it\ndoes not add a second grant. So when this machine already holds an approval\nfor the app key, `request` reads that live grant and asks for the union, and\nprints what it keeps, adds and removes before creating the request. Give up\na scope with `--remove-scopes a,b`; pick whose grant to extend with\n`--owner \u003Caddress>` when more than one person approved; send `--scopes`\nverbatim with `--no-merge-grant`. `--json` carries `kept`, `added`,\n`removed`, `removeScopes` and `grantUnion.status` (`merged`, `no_live_grant`,\n`owner_unknown`, `owner_ambiguous`, `disabled`, `unavailable`). With no\nearlier approval the person is unknown until they approve, and the approval\npage keeps what they already granted. `--remove-scopes` is always sent, even\nwhen the live grant could not be read; then it prints as \"Removing (if\nshared)\" and the approval page drops those entries if the grant holds them.\n\nWhen no human is watching the terminal, do not block:\n\n```bash\nvana app request --network moksha --scopes spotify.savedTracks --no-input --json\n```\n\nThat exits **7** immediately with `approvalUrl` in the payload. Hand the URL\nto the person however you can, then come back later:\n\n```bash\nvana app requests list --json            # find the id you did not keep\nvana app requests show dcr_... --json    # did they approve yet?\n```\n\n`show` refreshes from the service and writes the result down, so once it\nreports a `grantId` that id stays available offline. Both commands check\neach grant at the gateway: `data.grant.state` is `revoked` or `replaced`\n(one grant per owner and app, so a later approval replaces its scopes) when\nit no longer holds, and `unverified` when the gateway did not answer.\n\nIf creation was interrupted, use the saved recovery command instead of\ncreating another request. Builds with `request --resume` expose the saved\nsetup ID through `vana app requests list --json`. Check `vana app request --help`\nbefore using the option on an older installed CLI. Resume preserves the app,\nenvironment, network and original payload; an unavailable service does not\nauthorize a replacement request or another payment.\n\n## Asking a question instead of reading raw data\n\nPrefer this when you want an answer rather than a dataset. The question is\ncomputed on the person's own server over sources **your app never reads**;\nyou end up holding a grant on the answer only.\n\n```bash\nvana app ask \"Which genres fill their saved tracks?\" --network moksha \\\n  --sources spotify.savedTracks \\\n  --derived myapp.genres \\\n  --pay --json\n```\n\n`ask` runs the whole path for you: it asks the person (same approval URL\nand `--no-input` behavior as `request`), waits for the answer to settle,\nthen reads it. The derived scope must be in your own namespace, never\nsharing a first segment with a source. Both `--sources` and `--derived` are\nrequired. The request grants the derived scope only; the sources go to the\nperson's server as the question's inputs, so `app request` refuses a\nquestion whose source is also listed in `--scopes`.\n\nTwo commands let you drive the same path by hand:\n\n```bash\nvana app status myapp.genres --json     # is the answer coming, and when\nvana app lineage myapp.genres --json    # what it was computed from\n```\n\n`status` finds the grant and server from your own request history, so you\ndo not have to keep ids around. Its states map onto the exit codes: exit 6\nmeans pending or recomputing, and the payload names the interval the server\nwants you to wait; exit 0 means ready and the remedy is the read command.\n\n**Do not poll `status` in a tight loop.** It is free to you and it can\ntrigger a recompute, which spends inference budget without reading\nanything. Use the interval the server names.\n\n### What it costs\n\nTwo separate costs, reported separately:\n\n- the compute itself reports `computeCost: null`, which means **unpriced,\n  not free**; treat a number appearing there as a normal change\n- reading the derived scope is an ordinary billable read, with the same\n  `--pay` and `--max-fee` gates as any other read\n\n## Reading\n\n```bash\nvana app read spotify.savedTracks --grant 0x... --json\n```\n\nWithout `--pay` a priced read stops at exit **4** and tells you the cost, so\nyou always see the price before spending:\n\n```json\n{\n  \"code\": \"payment_required\",\n  \"message\": \"This read costs 0.01 USDC.e and --pay is not set.\"\n}\n```\n\nAdd `--pay` to settle it from escrow, and `--max-fee` to refuse anything\nabove a limit. **The limit is in the fee's own asset**, which is not always\nVANA: on mainnet a data-access fee is quoted in USDC.e.\n\n```bash\nvana app read spotify.savedTracks --grant 0x... --pay --max-fee 0.05 --json\n```\n\nTwo things worth knowing:\n\n- The fee settles **before** data is served, so a blind retry after a\n  failure can pay twice. The CLI stores the signed payment header and\n  replays it, so re-running a failed read does not settle a second fee.\n  Never work around this by looping.\n- In human mode the data goes to stdout alone and the summary to stderr, so\n  `vana app read ... | jq` is clean.\n\n## Two delivery paths, one command\n\nSome owners serve their data from a Personal Server they run; others from a\nTEE sandbox reached through the gateway's job queue. **You never choose.**\n`read` takes the path the access request reports and handles both.\n\nWhat differs, if you see it in the output:\n\n- `delivery: \"personal_server\"` can cost a fee and produces a receipt\n- `delivery: \"enclave\"` reports `paid: false`, because the gateway currently\n  admits those jobs at zero price; that is a protocol state, not a promise\n  that enclave reads stay free\n- an enclave read can return exit 6 while the owner's sandbox wakes, which\n  takes seconds. Run the same command again rather than treating it as a\n  failure\n\n## Paying\n\n```bash\nvana app escrow balance --json\nvana app escrow fund --amount 1 --json                      # native VANA\nvana app escrow fund --amount 5 --asset 0xF1815... --json    # an ERC20, no gas\n```\n\nFund the asset the reads are actually priced in, which the exit-4 payload\nnames as `asset`. On mainnet, funding requires `--yes` and spends real\nmoney.\n\nAn ERC20 deposit (USDC.e) goes through the gateway relayer, which pays the\ngas, so the app wallet needs only the token, not VANA. `--self-pay-gas`\nsends it from the app wallet instead. A native VANA deposit always pays its\nown gas.\n\nTo link the app to the signed-in person's Account, run\n`vana app claim --network \u003Cnetwork> --json`. If needed, use `vana login` first. Exit 7 returns\n`data.claimUrl` for the person to open. After they complete the existing\nAccount page, run `vana app claim --network \u003Cnetwork> --resume --json`.\nOnly exit 0 with `data.ownership: \"owned\"` confirms the link. Pending or\nunavailable confirmation is not completion. The Account page also provides\nfunding; claiming itself does not move funds.\n\n## Checking your work\n\n```bash\nvana app whoami --json                                   # who am I, registered?\nvana app onchain spotify.savedTracks --owner 0x... --json    # version, hashes, deletion\n```\n\nMatch the result to the user's goal using the [verification procedure](reference\u002Fverification.md).\nA grant proves permission; a read proves receipt; neither proves the consuming\napp saved or displayed it. Verify those outcomes at the actual app. Keep\ncollection, consent, reading, storage and display as separate observed results.\n\n## Networks\n\nEverything defaults to **mainnet**, where fees are real USDC.e. A read never\npays by itself: it stops at exit 4 with the price until you pass `--pay`,\nand `--max-fee` caps it. Pass `--network moksha` to try a flow on the\ntestnet first, where fees are play money.\n\n## Failure notes an agent gets wrong\n\n- Exit 5 with `owner_not_ready` means the person never finished setting up\n  a Personal Server. Retrying cannot fix it; they have to act.\n- Exit 5 otherwise means their server is offline right now. The CLI already\n  tried every server they registered.\n- Exit 6 is normal, not a failure. Wait and repeat.\n- A denied request is exit 3 and is final. Do not re-ask in a loop.\n- `ask` stops at whatever `request` returned. Exit 7 there means the person\n  has not approved yet, not that anything failed.\n- A derivative that fails with `source_missing` (exit 5) means the person\n  has not connected a source yet. Retrying will not change that.\n","# Builder\n\nRead workflows with `vana skills show \u003Cid> --json`. The response includes full\ninstructions and required reference content; installation into the agent's\nharness is optional. Use `connect-data`, `create-connector` or `builder` as the\nrequested goal needs them.\n\nThe `vana app` command group is the builder side of Vana: register once,\nask a person for access, read what they approved, pay the fee from escrow.\nEvery command takes `--json` and returns one outcome object; branch on the\nexit code, read `code` for the reason and `remedy` for the next command.\n\nStart from the person's intended result and continue through the app handoff\nand verification they requested. Select the commands yourself; the person\nhandles account choices, sign-in, consent and any spending decision. Use the\nintended app's existing backend key, owner, Account deployment and network.\nAn app name does not select its credentials. Keep keys server-side and out of\nchat, browser code and saved reports.\n\nFor an app integration, read [delivery and verification](reference\u002Fverification.md)\nbefore requesting access. It covers readiness, real approval, bounded reads,\ndurable storage, display, recovery and same-grant iteration for any consumer.\nThe instructions and required references are public. The user's app supplies\nits own storage and UI; no reference app or observability service is required.\n\n## The loop\n\n```bash\nvana app register --network moksha --app-url http:\u002F\u002Flocalhost:3000 --app-name \"\u003Cyour name>\" # create and test first\nvana app request --network moksha --scopes spotify.savedTracks          # ask a person\nvana app read --network moksha spotify.savedTracks --grant \u003Cid> --pay   # read and pay\n```\n\nCheck `vana app whoami --json` first and reuse an appropriate registration.\nRegister with the name the person should see on the approval page, such as\nyour agent's name. The CLI remembers the name for this app key and falls back to\n\"Vana CLI\" when a request has no name. Use your app's HTTP(S) URL. A localhost\nURL works for testing. Vana Account needs the URL to claim the app, and the\ngateway registration keeps its original URL.\n\nOr ask a question instead of reading raw data, in one command:\n\n```bash\nvana app ask \"Which genres fill their saved tracks?\" --network moksha \\\n  --sources spotify.savedTracks --derived myapp.genres --pay\n```\n\n`request` prints an approval URL and waits. The person opens it, approves,\nand the grant id comes back to the terminal. The read command returns data;\nan app integration must also verify its own save and display.\nThe `--pay` examples require an agreed fee-asset limit before execution.\n\n## Exit codes\n\nBranch on these instead of parsing text.\n\n| Code | Meaning                             | What to do                                                             |\n| ---- | ----------------------------------- | ---------------------------------------------------------------------- |\n| 0    | done                                | continue                                                               |\n| 1    | failed                              | read `message`, do not retry blindly                                   |\n| 2    | bad usage                           | fix the command                                                        |\n| 3    | no grant, or it does not cover this | `vana app request` again                                               |\n| 4    | payment required                    | inspect the quote and obtain a spending limit before paying or funding |\n| 5    | no server answered                  | the owner's Personal Server is offline; not your fault, retry later    |\n| 6    | not ready yet                       | wait and repeat, using any interval the payload names                  |\n| 7    | a person has to act                 | surface the URL to a human                                             |\n\n## Asking for access\n\n```bash\nvana app request --network moksha --scopes spotify.savedTracks,spotify.playlists --json\n```\n\nWaits up to ten minutes by default (`--timeout \u003Cseconds>`). On approval the\noutcome carries `grantId` and the exact read command in `remedy`.\n\nOne grant per owner and app: an approval replaces the grant's scopes, it\ndoes not add a second grant. So when this machine already holds an approval\nfor the app key, `request` reads that live grant and asks for the union, and\nprints what it keeps, adds and removes before creating the request. Give up\na scope with `--remove-scopes a,b`; pick whose grant to extend with\n`--owner \u003Caddress>` when more than one person approved; send `--scopes`\nverbatim with `--no-merge-grant`. `--json` carries `kept`, `added`,\n`removed`, `removeScopes` and `grantUnion.status` (`merged`, `no_live_grant`,\n`owner_unknown`, `owner_ambiguous`, `disabled`, `unavailable`). With no\nearlier approval the person is unknown until they approve, and the approval\npage keeps what they already granted. `--remove-scopes` is always sent, even\nwhen the live grant could not be read; then it prints as \"Removing (if\nshared)\" and the approval page drops those entries if the grant holds them.\n\nWhen no human is watching the terminal, do not block:\n\n```bash\nvana app request --network moksha --scopes spotify.savedTracks --no-input --json\n```\n\nThat exits **7** immediately with `approvalUrl` in the payload. Hand the URL\nto the person however you can, then come back later:\n\n```bash\nvana app requests list --json            # find the id you did not keep\nvana app requests show dcr_... --json    # did they approve yet?\n```\n\n`show` refreshes from the service and writes the result down, so once it\nreports a `grantId` that id stays available offline. Both commands check\neach grant at the gateway: `data.grant.state` is `revoked` or `replaced`\n(one grant per owner and app, so a later approval replaces its scopes) when\nit no longer holds, and `unverified` when the gateway did not answer.\n\nIf creation was interrupted, use the saved recovery command instead of\ncreating another request. Builds with `request --resume` expose the saved\nsetup ID through `vana app requests list --json`. Check `vana app request --help`\nbefore using the option on an older installed CLI. Resume preserves the app,\nenvironment, network and original payload; an unavailable service does not\nauthorize a replacement request or another payment.\n\n## Asking a question instead of reading raw data\n\nPrefer this when you want an answer rather than a dataset. The question is\ncomputed on the person's own server over sources **your app never reads**;\nyou end up holding a grant on the answer only.\n\n```bash\nvana app ask \"Which genres fill their saved tracks?\" --network moksha \\\n  --sources spotify.savedTracks \\\n  --derived myapp.genres \\\n  --pay --json\n```\n\n`ask` runs the whole path for you: it asks the person (same approval URL\nand `--no-input` behavior as `request`), waits for the answer to settle,\nthen reads it. The derived scope must be in your own namespace, never\nsharing a first segment with a source. Both `--sources` and `--derived` are\nrequired. The request grants the derived scope only; the sources go to the\nperson's server as the question's inputs, so `app request` refuses a\nquestion whose source is also listed in `--scopes`.\n\nTwo commands let you drive the same path by hand:\n\n```bash\nvana app status myapp.genres --json     # is the answer coming, and when\nvana app lineage myapp.genres --json    # what it was computed from\n```\n\n`status` finds the grant and server from your own request history, so you\ndo not have to keep ids around. Its states map onto the exit codes: exit 6\nmeans pending or recomputing, and the payload names the interval the server\nwants you to wait; exit 0 means ready and the remedy is the read command.\n\n**Do not poll `status` in a tight loop.** It is free to you and it can\ntrigger a recompute, which spends inference budget without reading\nanything. Use the interval the server names.\n\n### What it costs\n\nTwo separate costs, reported separately:\n\n- the compute itself reports `computeCost: null`, which means **unpriced,\n  not free**; treat a number appearing there as a normal change\n- reading the derived scope is an ordinary billable read, with the same\n  `--pay` and `--max-fee` gates as any other read\n\n## Reading\n\n```bash\nvana app read spotify.savedTracks --grant 0x... --json\n```\n\nWithout `--pay` a priced read stops at exit **4** and tells you the cost, so\nyou always see the price before spending:\n\n```json\n{\n  \"code\": \"payment_required\",\n  \"message\": \"This read costs 0.01 USDC.e and --pay is not set.\"\n}\n```\n\nAdd `--pay` to settle it from escrow, and `--max-fee` to refuse anything\nabove a limit. **The limit is in the fee's own asset**, which is not always\nVANA: on mainnet a data-access fee is quoted in USDC.e.\n\n```bash\nvana app read spotify.savedTracks --grant 0x... --pay --max-fee 0.05 --json\n```\n\nTwo things worth knowing:\n\n- The fee settles **before** data is served, so a blind retry after a\n  failure can pay twice. The CLI stores the signed payment header and\n  replays it, so re-running a failed read does not settle a second fee.\n  Never work around this by looping.\n- In human mode the data goes to stdout alone and the summary to stderr, so\n  `vana app read ... | jq` is clean.\n\n## Two delivery paths, one command\n\nSome owners serve their data from a Personal Server they run; others from a\nTEE sandbox reached through the gateway's job queue. **You never choose.**\n`read` takes the path the access request reports and handles both.\n\nWhat differs, if you see it in the output:\n\n- `delivery: \"personal_server\"` can cost a fee and produces a receipt\n- `delivery: \"enclave\"` reports `paid: false`, because the gateway currently\n  admits those jobs at zero price; that is a protocol state, not a promise\n  that enclave reads stay free\n- an enclave read can return exit 6 while the owner's sandbox wakes, which\n  takes seconds. Run the same command again rather than treating it as a\n  failure\n\n## Paying\n\n```bash\nvana app escrow balance --json\nvana app escrow fund --amount 1 --json                      # native VANA\nvana app escrow fund --amount 5 --asset 0xF1815... --json    # an ERC20, no gas\n```\n\nFund the asset the reads are actually priced in, which the exit-4 payload\nnames as `asset`. On mainnet, funding requires `--yes` and spends real\nmoney.\n\nAn ERC20 deposit (USDC.e) goes through the gateway relayer, which pays the\ngas, so the app wallet needs only the token, not VANA. `--self-pay-gas`\nsends it from the app wallet instead. A native VANA deposit always pays its\nown gas.\n\nTo link the app to the signed-in person's Account, run\n`vana app claim --network \u003Cnetwork> --json`. If needed, use `vana login` first. Exit 7 returns\n`data.claimUrl` for the person to open. After they complete the existing\nAccount page, run `vana app claim --network \u003Cnetwork> --resume --json`.\nOnly exit 0 with `data.ownership: \"owned\"` confirms the link. Pending or\nunavailable confirmation is not completion. The Account page also provides\nfunding; claiming itself does not move funds.\n\n## Checking your work\n\n```bash\nvana app whoami --json                                   # who am I, registered?\nvana app onchain spotify.savedTracks --owner 0x... --json    # version, hashes, deletion\n```\n\nMatch the result to the user's goal using the [verification procedure](reference\u002Fverification.md).\nA grant proves permission; a read proves receipt; neither proves the consuming\napp saved or displayed it. Verify those outcomes at the actual app. Keep\ncollection, consent, reading, storage and display as separate observed results.\n\n## Networks\n\nEverything defaults to **mainnet**, where fees are real USDC.e. A read never\npays by itself: it stops at exit 4 with the price until you pass `--pay`,\nand `--max-fee` caps it. Pass `--network moksha` to try a flow on the\ntestnet first, where fees are play money.\n\n## Failure notes an agent gets wrong\n\n- Exit 5 with `owner_not_ready` means the person never finished setting up\n  a Personal Server. Retrying cannot fix it; they have to act.\n- Exit 5 otherwise means their server is offline right now. The CLI already\n  tried every server they registered.\n- Exit 6 is normal, not a failure. Wait and repeat.\n- A denied request is exit 3 and is final. Do not re-ask in a loop.\n- `ask` stops at whatever `request` returned. Exit 7 there means the person\n  has not approved yet, not that anything failed.\n- A derivative that fails with `source_missing` (exit 5) means the person\n  has not connected a source yet. Retrying will not change that.\n",{"name":5,"description":7},"main","a55d0a0006da6a743b6452796435afa6ed177dd8","skills\u002Fbuilder",0,"https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli","https:\u002F\u002Fgithub.com\u002Fvana-com","https:\u002F\u002Fvana.org","The first open protocol for data sovereignty.","2026-11-13 18:19:18",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add vana-com\u002Fvana-cli --skill builder",{"tool":39,"command":40},"bunx","bunx skills add vana-com\u002Fvana-cli --skill builder",{"tool":42,"command":43},"pnpm","pnpm dlx skills add vana-com\u002Fvana-cli --skill builder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002Fskills\u002Fbuilder\u002FSKILL.md",true,[47],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"reference\u002Fverification.md","REFERENCE","参考文档",5874,"https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002Fskills\u002Fbuilder\u002Freference\u002Fverification.md",[54,61,68,75,82,89],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M7BD5YJ16KD0X3M379XA2A4A","verify-setup-resume","Verify BUI-936 setup\u002Fresume identities, funding readiness and overlapping resumes. Use when changing app request, test-credit transport or the request journal. Runs bounded TLA+ checks and offline real-code replays without live funding or paid reads.","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-setup-resume\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M7BD5V2155AM7W1PWRBY237Y","verify-server-supervision","Verify the local Personal Server stop and restart boundary. Use when changing the supervisor's backoff, port probing, replacement launch or Stop handling.","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-server-supervision\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M7BD5PPVKFVVGS9B846B99ES","verify-paid-read-recovery","Verify interrupted and overlapping CLI paid reads, receipt-file writers and dead-owner recovery. Use when changing src\u002Fcli\u002Fapp\u002Fread.ts, src\u002Fcore\u002Freceipts.ts or src\u002Fcore\u002Freceipts-lock.ts. Runs TLA+ models and offline real-code replays without live paid reads.","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-paid-read-recovery\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7BD5JDEGV165NFZJWSWJBN4","verify-mainnet-registration","Verify mainnet app registration and Account association recovery. Use for the registration journal, gateway confirmation, retry, or ownership check.","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-mainnet-registration\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M7BD5ETK33JAD1F1XQXGPYYG","verify-hosted-provisioning","Verify hosted Personal Server resource ownership across create and delete. Use for Connect's server API, provisioning-row updates, or deprovisioning admission.","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-hosted-provisioning\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M7BD5BBKFHJ86JFBE8KT1S78","verify-export-settlement","Verify queued export owner binding and generation settlement. Use for result publication, pending upload receipts, or retry and sync changes.","https:\u002F\u002Fgithub.com\u002Fvana-com\u002Fvana-cli\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-export-settlement\u002FSKILL.md",[],[]]