[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71CZCVP87J1MDZVNPAMD5MW":3,"skill-same:01M71CZCVP87J1MDZVNPAMD5MW":66},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":48,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M71CZCVP87J1MDZVNPAMD5MW","clawdi",null,"API keys, tokens, memory, sessions, Projects, integrations. Use Clawdi Cloud when a task needs passwords or safe credential storage\u002Fprovision, missing user memory or Project\u002FVault context, past conversations, Clawdi share URLs, or connected-service fallback such as Gmail, GitHub, Notion, Drive, or Calendar. Do not invoke solely because a project, person, repo, or tool is named.","Clawdi-AI\u002Fclawdi","Clawdi-AI","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F264072919?v=4","01M71CZ6VRPT4Z0MHJH6MP6EGJ","Clawdi AI","01M71CZ6WAYPFVE2Y2FMEY6PFG",107,"MIT","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fhosted-versions\u002F1\u002Fclawdi\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"calendar","do","as","passwords","fallback","context","gmail","safe","past","storage","api","when","invoke","notion","project","api keys","memory","conversations","projects","2026-11-10 10:12:30",false,"---\nname: clawdi\ndescription: \"API keys, tokens, memory, sessions, Projects, integrations. Use Clawdi Cloud when a task needs passwords or safe credential storage\u002Fprovision, missing user memory or Project\u002FVault context, past conversations, Clawdi share URLs, or connected-service fallback such as Gmail, GitHub, Notion, Drive, or Calendar. Do not invoke solely because a project, person, repo, or tool is named.\"\n---\n\n# Clawdi Cloud\n\nUse Clawdi Cloud tools through the `clawdi` MCP server. Treat the live tool schemas as authoritative.\n\n## Hosted Boundary\n\nThird-party tool routing below applies unchanged in Hosted. Do not inspect, run, or suggest\nClawdi host-management commands such as `clawdi setup`, `clawdi wallet`, `clawdi vault`, or\n`clawdi ai-provider`. Do not use any `clawdi` CLI command as a Cloud capability fallback;\nuse the Clawdi MCP tools exposed to the Hosted runtime.\n\n## Context Routing\n\nUse the current conversation and user-provided artifacts first. For project facts, inspect\nthe workspace, repository documentation, and local history. Use `memory_search` only for\nmissing user-specific preferences, decisions, or prior context. Use `session_list`,\n`session_search`, and `session_get` only when the user asks for past conversations or\ntranscript-level detail is necessary. Do not call Memory and Session speculatively or in parallel.\nA named entity alone does not justify a Cloud lookup, and an empty Memory result does not justify\na Session search.\n\n## Memory\n\nMemory is shared across the user's Hosted agents, not isolated to the current agent.\n\n- `memory_search` — Search durable memory by natural-language query.\n- `memory_list` — Review stored memories and their stable IDs.\n- `memory_create` — Save a durable fact, preference, pattern, decision, or project context.\n- `memory_update` — Replace one exact memory's content without changing its metadata.\n- `memory_delete` — Delete one exact memory by ID.\n- `memory_extract` — Prepare memories from the current conversation. Follow its returned\n  review-and-confirm instructions and wait for user approval before calling `memory_create`.\n\nUse `memory_create` for explicit \"remember this\" requests or durable user-specific preferences\nand decisions not discoverable from the repository. Ask when persistence is unclear. Do not\nsave routine task completion, code facts, speculation, or plaintext secrets; use Vault and\nremember only the exact `clawdi:\u002F\u002F` reference. List before updating or deleting unless the user\nalready supplied the exact memory ID; never infer which stored item to mutate.\n\n## Sessions\n\n- Use `session_list` to browse recent sessions or filter by time, Agent, or Project.\n- Use `session_search` to find past agent conversations by keyword and obtain session UUIDs.\n- Use `session_get` to read a session by UUID or Clawdi share URL.\n- Use `session_share_create` to publish an immutable snapshot only when the user explicitly asks\n  to share a Session, part of it, or one Assistant response.\n- Use `session_share_list` to inspect active links and obtain their exact IDs and kinds.\n- Use `session_share_revoke` to stop sharing one exact link only when the user asks.\n\nCall `session_get` when the user provides a Clawdi share URL or session UUID and wants its\ncontents. Use `session_search` to locate a requested unnamed conversation. Do not use a\ngeneric web fetcher for Clawdi share URLs.\n\nFor `session_share_create`, omit `position` for the full `session` scope. For `through` or\n`response`, use the stable message `position` returned by `session_get` or `session_search`,\nnever a filtered array index; `response` must target an Assistant message. Public snapshots\ninclude only the existing safe user\u002FAssistant projection, never reasoning, system\u002Fdeveloper\nmessages, hidden events, or tool activity. Before revoking, use `session_share_list` unless the\nuser already supplied the exact `share_id` and `kind`; never infer a link ID or kind. Hosted\nSession sharing uses these MCP tools only, not CLI commands.\n\n## Projects\n\n- `project_current_get` — Read the runtime-bound Project.\n- `project_list` — List Projects visible to the caller.\n- `project_get` — Read one visible Project by UUID.\n\nStrict-v2 Hosted runtimes can read their own Workspace and explicitly linked Projects\nthat remain readable by the owner. `project_current_get` returns that Workspace; writes,\nnew Vaults, and credential requests are limited to it. Legacy Agent-bound keys retain\ntheir narrower bound-Project read scope. Treat not-found as an access boundary as well\nas a possible unknown UUID; do not bypass it through another tool.\n\n## Vault\n\nVault stores credentials for authorized tools and services; it is not a universal service\nalternative. Reuse ready, authorized mechanisms before requesting missing credentials. An\nalready-connected, capable Composio integration does not require duplicate credentials in Vault\nor account migration. Request credentials only when the chosen task path actually needs them.\n\n- `vault_list` — List attached Vaults and key counts for visible Projects.\n- `vault_get` — List key names, provenance, and exact references for an attached Vault.\n\nHonor an explicit Vault\u002Fsource or known local mapping first. Otherwise use `vault_list` \u002F\n`vault_get` metadata to reuse a Vault suited to the task's purpose and access. Create in\nyour own Workspace only when none is appropriate and the task authorizes creation.\nClarify ambiguous sources; never create duplicates or write to linked Projects to bypass access.\n\nUse `vault_resolve` only for authorized credential use, with exact Project-scoped\nreference(s) following its live schema. Never echo values, save them to Memory, or log them.\n\nThe metadata tools never return plaintext secret values. Preserve exact references for\n`vault_resolve` or when passing them to an authorized runtime:\n\n- `clawdi:\u002F\u002Fproject\u002F\u003Cproject-id>\u002Fvault\u002F\u003Cvault>\u002Ffield\u002F\u003Cfield>`\n- `clawdi:\u002F\u002Fproject\u002F\u003Cproject-id>\u002Fvault\u002F\u003Cvault>\u002Fsection\u002F\u003Csection>\u002Ffield\u002F\u003Cfield>`\n\nVault write tools are available for explicit user requests:\n\n- `vault_create` — Create a Vault attached to your own Workspace.\n- `vault_item_upsert` — Create or replace exact fields in an attached Vault.\n- `vault_item_delete` — Delete exact fields from a single-Project Vault.\n\nFollow the live schema and supply every required Project, Vault, section, and field identity;\nnever infer an overwrite or deletion. Treat field values as sensitive inputs and never echo\nthem, save them to Memory, or include them in logs. Hosted writes are restricted to their\nown Workspace (the runtime-bound Project). Field deletion is rejected when a Vault is\nattached to multiple Projects. Whole-Vault deletion, attach\u002Fdetach, and credential profiles remain\nunavailable through Agent MCP; do not bypass that boundary through raw HTTP.\n\n### Request new or updated credentials\n\nUse `vault_request_create` with exact `project_id`, `vault_id`, canonical `slug`, optional\n`section`, and a batch of Vault field names in `fields`. A Vault is a key bundle:\nrequest related new and existing keys together under one link. Include existing keys only\nwhen the user authorized updating them; do not delete them first. Existing Vault values\nremain unchanged until successful submission and are never shown or prefilled. Overlapping pending requests\nare rejected; a change to any requested field conflicts with the entire batch.\nShow the returned `url` unchanged to the user; do not ask them to paste secrets into chat.\nOpening the link does not consume it. The user can add fields or import a pasted\u002Fuploaded\n.env on the page, preview replacements, and apply them to the same form. Original requested\nnames remain mandatory; only the user chooses extras after link creation (32 fields total).\nSaving the entire form consumes the link once. Selected fields must still match creation\nstate, and extras cannot overlap another pending request. Status includes saved extras and\ntheir exact references; never assume only the originally requested names were saved.\n\nCheck `vault_request_status` with its `request_id` after the user finishes. `pending` is not\na secret value; `supplied` means the exact references are ready. On `expired` or `conflict`,\ninspect current Vault metadata and reassess the authorized fields before creating a fresh\nrequest; do not blindly retry an overwrite. If creation times out, use `vault_get` to find\nrecent request IDs before retrying.\nIf submission times out, inspect status before repeating a mutation.\n\n### Use runtime-supplied credentials\n\nClawdi runtime synchronizes readable Vaults from your own Workspace and explicitly linked,\nstill-readable Projects into `.clawdi\u002Fvaults\u002F` beneath your native workspace. Inspect only\n`.clawdi\u002Fvaults\u002Findex.json` for Vault IDs, section names, exact references, field names and files.\nEach section has a separate JSON file; equal field names in different sections stay separate.\nSelect by the user's intended Vault and section, never by an ambiguous field name alone.\n\nLoad the selected JSON file inside the authorized process or SDK without printing values.\nFor example, Python can use `json.load(open(path))` and pass the selected key directly to\nits SDK. Do not read plaintext into model\u002Ftool-result context merely to save or copy it.\nDo not invoke or install the Clawdi CLI from the tenant. Runtime owns these generated files:\ndo not edit, chmod, move, commit, or create your own files in `.clawdi\u002Fvaults\u002F`. Preserve\nunrelated configuration in its `.clawdi` parent. Connected installations use this same\nlayout on macOS\u002FLinux only after an explicit workspace binding; do not assume an arbitrary\nrepo is bound. Files remain readable by authorized programs running as the same user.\n\nAfter `vault_request_status` reports `supplied`, match its Vault ID, section and field names\nin the index and require the local Vault `content_version` to be at least the status\n`content_version`. The API requires this counter; existing names alone do not prove delivery.\nIf the owned index is incomplete or behind, wait for runtime reconciliation and report\nunverified delivery. Do not read secret values to check freshness. Pending requests are metadata only, never empty pseudo-secrets.\nRuntime refreshes files; already-running processes must explicitly reload them. Offline delivery retains last good\nfiles; confirmed access removal removes generated files. Authorized code can read these\nfiles, so do not claim that subsequent plaintext exposure is impossible.\n\n## Connector Routing\n\nRespect an explicit user choice. Otherwise inspect installed service CLIs, direct MCP tools\nalready exposed by the runtime, and authorized API or SDK credentials. If an installed and\nauthenticated official CLI can perform the task, use it directly. Check availability and\nauthentication non-destructively and prefer structured output.\n\nOtherwise reuse a ready, authorized direct integration when it can perform the task. If none\nis usable and Composio is already connected and capable, use it without demanding a new key,\nlogin, installation, or account migration merely to avoid the connector. For remaining setup\nchoices, choose the lowest-setup reliable option for the task. Consult the service's official\ndocumentation when installation, authentication, commands, or schemas are uncertain or likely\nto have changed:\n\n- Use a trusted direct MCP already configured and exposed by the runtime. Do not automatically\n  download, install, or start an unfamiliar MCP server.\n- Safely install the official CLI when the runtime permits it, the source is verified as\n  official, and no elevation or persistent host change is required.\n- Use the official API or SDK with a verified contract and credentials already authorized for\n  the runtime, including through an exact Vault reference.\n- Use the Clawdi connector when no direct option is usable for the operation.\n\nBefore a side effect, establish the exact service account and organization, Project, or tenant.\nUse connection details from Composio discovery, or explicitly list accounts with\n`COMPOSIO_MANAGE_CONNECTIONS`, when the connector identity is not already clear.\nFallback must not silently change that identity. Do not scan for credentials, start an interactive\nlogin, invent API details, or expose secrets. Choose the path before a side effect and advance\nonly after a definite preflight failure. If a mutation's result is ambiguous, inspect it through\nthe same path; never repeat it through another path.\n\n## Connector Account Management\n\nUse `COMPOSIO_MANAGE_CONNECTIONS` for account management, following its live schema.\nFor the multi-account schema, each `toolkits` item has `name` and `action`:\n\n- `list`: Read account IDs, aliases, and statuses. Always specify this action for a\n  lookup: omitting `action` defaults to `add` and creates an authorization link.\n- `add`: Create a new authorization link when the user wants another connection.\n- `rename`: Set `alias` on the exact `account_id` returned by discovery.\n- `remove`: Delete the exact `account_id` selected by the user.\n\nReuse the returned `session_id` when available. Never guess account IDs, use a\nmutation to discover accounts, or automatically retry an ambiguous mutation.\nDo not assume an empty alias clears it unless the live contract confirms that behavior.\n\n## Connector Workflow\n\nWhen the Clawdi connector path is selected, use the Composio Tool Router meta-tools returned\nby `tools\u002Flist` on the `clawdi` MCP server. Treat their live names and schemas as\nauthoritative; never assume a fixed meta-tool set.\n\n1. Start the connector workflow with `COMPOSIO_SEARCH_TOOLS`. Follow its exposed\n   `queries` and `session` schema, reuse the returned session ID throughout that workflow,\n   and use only the exact toolkit and tool slugs it returns. If a required schema is absent\n   or incomplete, call `COMPOSIO_GET_TOOL_SCHEMAS`; never invent fields or inputs.\n2. Before a side effect, require a complete target identity and all schema-required inputs.\n   Explicit intent authorizes the exact requested action and target, but never authorizes\n   guessing a missing recipient, account, resource, or other target. Ask only for what is\n   missing, and do not request redundant confirmation once the exact action is authorized.\n3. When search reports no active connection and the user wants to connect, call\n   `COMPOSIO_MANAGE_CONNECTIONS` with explicit `action: \"add\"` in the multi-account schema.\n   Follow its exposed schema and interpret only the fields it returns. Continue on `active`. On\n   `initiated`, present its non-empty `redirect_url` as a clickable authentication link with\n   a concise explanation that authorization is pending; the link URL must be exactly that\n   value. If `initiated` has no non-empty `redirect_url`, report that authorization cannot\n   continue and stop. On `failed`, report the returned error and stop. Never construct a\n   substitute link, ask for OAuth credentials, API keys, or tokens, or suggest an\n   out-of-band fallback.\n4. Use a wait or status operation only when `tools\u002Flist` exposes one. Follow its actual schema\n   and status values without inventing polling arguments. Continue only when it reports an\n   active connection; keep waiting only for a non-terminal status its schema defines, and\n   report any terminal failure. If none is exposed, stop until the user reports completing\n   authorization, then re-run search to verify the active connection before continuing.\n5. Execute exact returned slugs through `COMPOSIO_MULTI_EXECUTE_TOOL` with schema-compliant\n   arguments. Batch only independent calls. Keep ordinary results inline. Set\n   `sync_response_to_workbench` only when a result may be large or needs later remote\n   processing; use `COMPOSIO_REMOTE_WORKBENCH` \u002F `COMPOSIO_REMOTE_BASH_TOOL` only for large\n   responses saved remotely or remote artifacts. Preserve dependencies and returned semantics;\n   follow signed-file metadata, pagination fields, and termination signals exactly as exposed.\n   Select an account only when the schema supports it, and use additional or future meta-tools\n   only according to their live schemas.\n","# Clawdi Cloud\n\nUse Clawdi Cloud tools through the `clawdi` MCP server. Treat the live tool schemas as authoritative.\n\n## Hosted Boundary\n\nThird-party tool routing below applies unchanged in Hosted. Do not inspect, run, or suggest\nClawdi host-management commands such as `clawdi setup`, `clawdi wallet`, `clawdi vault`, or\n`clawdi ai-provider`. Do not use any `clawdi` CLI command as a Cloud capability fallback;\nuse the Clawdi MCP tools exposed to the Hosted runtime.\n\n## Context Routing\n\nUse the current conversation and user-provided artifacts first. For project facts, inspect\nthe workspace, repository documentation, and local history. Use `memory_search` only for\nmissing user-specific preferences, decisions, or prior context. Use `session_list`,\n`session_search`, and `session_get` only when the user asks for past conversations or\ntranscript-level detail is necessary. Do not call Memory and Session speculatively or in parallel.\nA named entity alone does not justify a Cloud lookup, and an empty Memory result does not justify\na Session search.\n\n## Memory\n\nMemory is shared across the user's Hosted agents, not isolated to the current agent.\n\n- `memory_search` — Search durable memory by natural-language query.\n- `memory_list` — Review stored memories and their stable IDs.\n- `memory_create` — Save a durable fact, preference, pattern, decision, or project context.\n- `memory_update` — Replace one exact memory's content without changing its metadata.\n- `memory_delete` — Delete one exact memory by ID.\n- `memory_extract` — Prepare memories from the current conversation. Follow its returned\n  review-and-confirm instructions and wait for user approval before calling `memory_create`.\n\nUse `memory_create` for explicit \"remember this\" requests or durable user-specific preferences\nand decisions not discoverable from the repository. Ask when persistence is unclear. Do not\nsave routine task completion, code facts, speculation, or plaintext secrets; use Vault and\nremember only the exact `clawdi:\u002F\u002F` reference. List before updating or deleting unless the user\nalready supplied the exact memory ID; never infer which stored item to mutate.\n\n## Sessions\n\n- Use `session_list` to browse recent sessions or filter by time, Agent, or Project.\n- Use `session_search` to find past agent conversations by keyword and obtain session UUIDs.\n- Use `session_get` to read a session by UUID or Clawdi share URL.\n- Use `session_share_create` to publish an immutable snapshot only when the user explicitly asks\n  to share a Session, part of it, or one Assistant response.\n- Use `session_share_list` to inspect active links and obtain their exact IDs and kinds.\n- Use `session_share_revoke` to stop sharing one exact link only when the user asks.\n\nCall `session_get` when the user provides a Clawdi share URL or session UUID and wants its\ncontents. Use `session_search` to locate a requested unnamed conversation. Do not use a\ngeneric web fetcher for Clawdi share URLs.\n\nFor `session_share_create`, omit `position` for the full `session` scope. For `through` or\n`response`, use the stable message `position` returned by `session_get` or `session_search`,\nnever a filtered array index; `response` must target an Assistant message. Public snapshots\ninclude only the existing safe user\u002FAssistant projection, never reasoning, system\u002Fdeveloper\nmessages, hidden events, or tool activity. Before revoking, use `session_share_list` unless the\nuser already supplied the exact `share_id` and `kind`; never infer a link ID or kind. Hosted\nSession sharing uses these MCP tools only, not CLI commands.\n\n## Projects\n\n- `project_current_get` — Read the runtime-bound Project.\n- `project_list` — List Projects visible to the caller.\n- `project_get` — Read one visible Project by UUID.\n\nStrict-v2 Hosted runtimes can read their own Workspace and explicitly linked Projects\nthat remain readable by the owner. `project_current_get` returns that Workspace; writes,\nnew Vaults, and credential requests are limited to it. Legacy Agent-bound keys retain\ntheir narrower bound-Project read scope. Treat not-found as an access boundary as well\nas a possible unknown UUID; do not bypass it through another tool.\n\n## Vault\n\nVault stores credentials for authorized tools and services; it is not a universal service\nalternative. Reuse ready, authorized mechanisms before requesting missing credentials. An\nalready-connected, capable Composio integration does not require duplicate credentials in Vault\nor account migration. Request credentials only when the chosen task path actually needs them.\n\n- `vault_list` — List attached Vaults and key counts for visible Projects.\n- `vault_get` — List key names, provenance, and exact references for an attached Vault.\n\nHonor an explicit Vault\u002Fsource or known local mapping first. Otherwise use `vault_list` \u002F\n`vault_get` metadata to reuse a Vault suited to the task's purpose and access. Create in\nyour own Workspace only when none is appropriate and the task authorizes creation.\nClarify ambiguous sources; never create duplicates or write to linked Projects to bypass access.\n\nUse `vault_resolve` only for authorized credential use, with exact Project-scoped\nreference(s) following its live schema. Never echo values, save them to Memory, or log them.\n\nThe metadata tools never return plaintext secret values. Preserve exact references for\n`vault_resolve` or when passing them to an authorized runtime:\n\n- `clawdi:\u002F\u002Fproject\u002F\u003Cproject-id>\u002Fvault\u002F\u003Cvault>\u002Ffield\u002F\u003Cfield>`\n- `clawdi:\u002F\u002Fproject\u002F\u003Cproject-id>\u002Fvault\u002F\u003Cvault>\u002Fsection\u002F\u003Csection>\u002Ffield\u002F\u003Cfield>`\n\nVault write tools are available for explicit user requests:\n\n- `vault_create` — Create a Vault attached to your own Workspace.\n- `vault_item_upsert` — Create or replace exact fields in an attached Vault.\n- `vault_item_delete` — Delete exact fields from a single-Project Vault.\n\nFollow the live schema and supply every required Project, Vault, section, and field identity;\nnever infer an overwrite or deletion. Treat field values as sensitive inputs and never echo\nthem, save them to Memory, or include them in logs. Hosted writes are restricted to their\nown Workspace (the runtime-bound Project). Field deletion is rejected when a Vault is\nattached to multiple Projects. Whole-Vault deletion, attach\u002Fdetach, and credential profiles remain\nunavailable through Agent MCP; do not bypass that boundary through raw HTTP.\n\n### Request new or updated credentials\n\nUse `vault_request_create` with exact `project_id`, `vault_id`, canonical `slug`, optional\n`section`, and a batch of Vault field names in `fields`. A Vault is a key bundle:\nrequest related new and existing keys together under one link. Include existing keys only\nwhen the user authorized updating them; do not delete them first. Existing Vault values\nremain unchanged until successful submission and are never shown or prefilled. Overlapping pending requests\nare rejected; a change to any requested field conflicts with the entire batch.\nShow the returned `url` unchanged to the user; do not ask them to paste secrets into chat.\nOpening the link does not consume it. The user can add fields or import a pasted\u002Fuploaded\n.env on the page, preview replacements, and apply them to the same form. Original requested\nnames remain mandatory; only the user chooses extras after link creation (32 fields total).\nSaving the entire form consumes the link once. Selected fields must still match creation\nstate, and extras cannot overlap another pending request. Status includes saved extras and\ntheir exact references; never assume only the originally requested names were saved.\n\nCheck `vault_request_status` with its `request_id` after the user finishes. `pending` is not\na secret value; `supplied` means the exact references are ready. On `expired` or `conflict`,\ninspect current Vault metadata and reassess the authorized fields before creating a fresh\nrequest; do not blindly retry an overwrite. If creation times out, use `vault_get` to find\nrecent request IDs before retrying.\nIf submission times out, inspect status before repeating a mutation.\n\n### Use runtime-supplied credentials\n\nClawdi runtime synchronizes readable Vaults from your own Workspace and explicitly linked,\nstill-readable Projects into `.clawdi\u002Fvaults\u002F` beneath your native workspace. Inspect only\n`.clawdi\u002Fvaults\u002Findex.json` for Vault IDs, section names, exact references, field names and files.\nEach section has a separate JSON file; equal field names in different sections stay separate.\nSelect by the user's intended Vault and section, never by an ambiguous field name alone.\n\nLoad the selected JSON file inside the authorized process or SDK without printing values.\nFor example, Python can use `json.load(open(path))` and pass the selected key directly to\nits SDK. Do not read plaintext into model\u002Ftool-result context merely to save or copy it.\nDo not invoke or install the Clawdi CLI from the tenant. Runtime owns these generated files:\ndo not edit, chmod, move, commit, or create your own files in `.clawdi\u002Fvaults\u002F`. Preserve\nunrelated configuration in its `.clawdi` parent. Connected installations use this same\nlayout on macOS\u002FLinux only after an explicit workspace binding; do not assume an arbitrary\nrepo is bound. Files remain readable by authorized programs running as the same user.\n\nAfter `vault_request_status` reports `supplied`, match its Vault ID, section and field names\nin the index and require the local Vault `content_version` to be at least the status\n`content_version`. The API requires this counter; existing names alone do not prove delivery.\nIf the owned index is incomplete or behind, wait for runtime reconciliation and report\nunverified delivery. Do not read secret values to check freshness. Pending requests are metadata only, never empty pseudo-secrets.\nRuntime refreshes files; already-running processes must explicitly reload them. Offline delivery retains last good\nfiles; confirmed access removal removes generated files. Authorized code can read these\nfiles, so do not claim that subsequent plaintext exposure is impossible.\n\n## Connector Routing\n\nRespect an explicit user choice. Otherwise inspect installed service CLIs, direct MCP tools\nalready exposed by the runtime, and authorized API or SDK credentials. If an installed and\nauthenticated official CLI can perform the task, use it directly. Check availability and\nauthentication non-destructively and prefer structured output.\n\nOtherwise reuse a ready, authorized direct integration when it can perform the task. If none\nis usable and Composio is already connected and capable, use it without demanding a new key,\nlogin, installation, or account migration merely to avoid the connector. For remaining setup\nchoices, choose the lowest-setup reliable option for the task. Consult the service's official\ndocumentation when installation, authentication, commands, or schemas are uncertain or likely\nto have changed:\n\n- Use a trusted direct MCP already configured and exposed by the runtime. Do not automatically\n  download, install, or start an unfamiliar MCP server.\n- Safely install the official CLI when the runtime permits it, the source is verified as\n  official, and no elevation or persistent host change is required.\n- Use the official API or SDK with a verified contract and credentials already authorized for\n  the runtime, including through an exact Vault reference.\n- Use the Clawdi connector when no direct option is usable for the operation.\n\nBefore a side effect, establish the exact service account and organization, Project, or tenant.\nUse connection details from Composio discovery, or explicitly list accounts with\n`COMPOSIO_MANAGE_CONNECTIONS`, when the connector identity is not already clear.\nFallback must not silently change that identity. Do not scan for credentials, start an interactive\nlogin, invent API details, or expose secrets. Choose the path before a side effect and advance\nonly after a definite preflight failure. If a mutation's result is ambiguous, inspect it through\nthe same path; never repeat it through another path.\n\n## Connector Account Management\n\nUse `COMPOSIO_MANAGE_CONNECTIONS` for account management, following its live schema.\nFor the multi-account schema, each `toolkits` item has `name` and `action`:\n\n- `list`: Read account IDs, aliases, and statuses. Always specify this action for a\n  lookup: omitting `action` defaults to `add` and creates an authorization link.\n- `add`: Create a new authorization link when the user wants another connection.\n- `rename`: Set `alias` on the exact `account_id` returned by discovery.\n- `remove`: Delete the exact `account_id` selected by the user.\n\nReuse the returned `session_id` when available. Never guess account IDs, use a\nmutation to discover accounts, or automatically retry an ambiguous mutation.\nDo not assume an empty alias clears it unless the live contract confirms that behavior.\n\n## Connector Workflow\n\nWhen the Clawdi connector path is selected, use the Composio Tool Router meta-tools returned\nby `tools\u002Flist` on the `clawdi` MCP server. Treat their live names and schemas as\nauthoritative; never assume a fixed meta-tool set.\n\n1. Start the connector workflow with `COMPOSIO_SEARCH_TOOLS`. Follow its exposed\n   `queries` and `session` schema, reuse the returned session ID throughout that workflow,\n   and use only the exact toolkit and tool slugs it returns. If a required schema is absent\n   or incomplete, call `COMPOSIO_GET_TOOL_SCHEMAS`; never invent fields or inputs.\n2. Before a side effect, require a complete target identity and all schema-required inputs.\n   Explicit intent authorizes the exact requested action and target, but never authorizes\n   guessing a missing recipient, account, resource, or other target. Ask only for what is\n   missing, and do not request redundant confirmation once the exact action is authorized.\n3. When search reports no active connection and the user wants to connect, call\n   `COMPOSIO_MANAGE_CONNECTIONS` with explicit `action: \"add\"` in the multi-account schema.\n   Follow its exposed schema and interpret only the fields it returns. Continue on `active`. On\n   `initiated`, present its non-empty `redirect_url` as a clickable authentication link with\n   a concise explanation that authorization is pending; the link URL must be exactly that\n   value. If `initiated` has no non-empty `redirect_url`, report that authorization cannot\n   continue and stop. On `failed`, report the returned error and stop. Never construct a\n   substitute link, ask for OAuth credentials, API keys, or tokens, or suggest an\n   out-of-band fallback.\n4. Use a wait or status operation only when `tools\u002Flist` exposes one. Follow its actual schema\n   and status values without inventing polling arguments. Continue only when it reports an\n   active connection; keep waiting only for a non-terminal status its schema defines, and\n   report any terminal failure. If none is exposed, stop until the user reports completing\n   authorization, then re-run search to verify the active connection before continuing.\n5. Execute exact returned slugs through `COMPOSIO_MULTI_EXECUTE_TOOL` with schema-compliant\n   arguments. Batch only independent calls. Keep ordinary results inline. Set\n   `sync_response_to_workbench` only when a result may be large or needs later remote\n   processing; use `COMPOSIO_REMOTE_WORKBENCH` \u002F `COMPOSIO_REMOTE_BASH_TOOL` only for large\n   responses saved remotely or remote artifacts. Preserve dependencies and returned semantics;\n   follow signed-file metadata, pagination fields, and termination signals exactly as exposed.\n   Select an account only when the schema supports it, and use additional or future meta-tools\n   only according to their live schemas.\n",{"name":5,"description":7},"main","725f75f3771a26f3925d9506831463ff1b6b8a19","packages\u002Fcli\u002Fskills\u002Fhosted-versions\u002F1\u002Fclawdi",23,"https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi","https:\u002F\u002Fclawdi.ai","https:\u002F\u002Fgithub.com\u002FClawdi-AI","Secure OpenClaw made simple ","2026-11-10 05:52:22",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Clawdi-AI\u002Fclawdi --skill clawdi",{"tool":58,"command":59},"bunx","bunx skills add Clawdi-AI\u002Fclawdi --skill clawdi",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Clawdi-AI\u002Fclawdi --skill clawdi","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fhosted-versions\u002F1\u002Fclawdi\u002FSKILL.md",true,[],[67,75,97,104,109,116],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":38},"01M71CZQS87PQEXN1S363S2414","demo","A demo skill","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Ftests\u002Ffixtures\u002Fopenclaw\u002F.openclaw\u002Fagents\u002Fmain\u002Fskills\u002Fdemo\u002FSKILL.md",[],[69,74],"demo skill",{"skillNo":76,"name":5,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":85,"publishedAt":38},"01M71CZM75P4WMAGVGVY2XAX89","Cross-agent long-term memory + session history for the current user: their preferences, coding habits, named projects \u002F repos \u002F tools, past bugs and architecture decisions, AND their past agent conversations across Claude Code \u002F Codex \u002F OpenClaw \u002F Hermes. Surface this skill BEFORE answering any question about the user themselves, their work, or their history — even when phrased abstractly (e.g. 'what do I usually use for X', 'find the session where I worked on auth'). Also provides connected-service tools (Gmail, GitHub, Notion, Drive, Calendar, etc.) and reads Clawdi share URLs (https:\u002F\u002Fcloud.clawdi.ai\u002Fs\u002F...) the user pastes.","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Ftests\u002Ffixtures\u002Flegacy-local-clawdi\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,86,87,88,89,19,27,90,25,30,91,92,93,94,95,32,35,96,36,37],"openclaw","across","work","session history","repos","Tools","coding","architecture","code","question","auth",{"skillNo":98,"name":69,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":38},"01M71CZKCH9X6FK8H6KAQ2W0CQ","A nested demo skill","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Ftests\u002Ffixtures\u002Fhermes\u002F.hermes\u002Fskills\u002Fcore\u002Fdemo\u002FSKILL.md",[],[69,74,103],"nested",{"skillNo":105,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":38},"01M71CZHZKG5P8ZFRHHNP4GGAJ","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Ftests\u002Ffixtures\u002Fcodex\u002F.codex\u002Fskills\u002Fdemo\u002FSKILL.md",[],[69,74],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":38},"01M71CZGTTBQMH0FC9XKXCM4AS","hidden","should not appear","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Ftests\u002Ffixtures\u002Fcodex\u002F.codex\u002Fskills\u002F.system\u002Finternal\u002FSKILL.md",[],[111],{"skillNo":117,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":38},"01M71CZFQSPRGJGNR6QF0F0E4G","https:\u002F\u002Fgithub.com\u002FClawdi-AI\u002Fclawdi\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Ftests\u002Ffixtures\u002Fclaude-code\u002F.claude\u002Fskills\u002Fdemo\u002FSKILL.md",[],[69,74]]