clawdi 0.14.72 → 0.14.74

package/skills/hosted-versions/2/clawdi/SKILL.md

@@ -1,213 +0,0 @@
----
-name: clawdi
-description: "Use Clawdi Cloud for missing user memory, past sessions, Project or Vault context, Clawdi share URLs, and connected-service fallback such as Gmail, GitHub, Notion, Drive, or Calendar. Prefer an authenticated official service CLI; otherwise choose a trusted direct MCP, safely installable official CLI, official API or SDK, or the Clawdi connector as fallback. Do not invoke solely because a project, person, repo, or tool is named."
----
-
-# Clawdi Cloud
-
-Use Clawdi Cloud tools through the `clawdi` MCP server. Treat the live tool schemas as authoritative.
-
-## Hosted Boundary
-
-Third-party tool routing below applies unchanged in Hosted. Do not inspect, run, or suggest
-Clawdi host-management commands such as `clawdi setup`, `clawdi wallet`, `clawdi vault`, or
-`clawdi ai-provider`.
-
-## Context Routing
-
-Use the current conversation and user-provided artifacts first. For project facts, inspect
-the workspace, repository documentation, and local history. Use `memory_search` only for
-missing user-specific preferences, decisions, or prior context. Use `session_list`,
-`session_search`, and `session_get` only when the user asks for past conversations or
-transcript-level detail is necessary. Do not call Memory and Session speculatively or in parallel.
-A named entity alone does not justify a Cloud lookup, and an empty Memory result does not justify
-a Session search.
-
-## Memory
-
-Memory is shared across the user's Hosted agents, not isolated to the current agent.
-
-- `memory_search` — Search durable memory by natural-language query.
-- `memory_list` — Review stored memories and their stable IDs.
-- `memory_create` — Save a durable fact, preference, pattern, decision, or project context.
-- `memory_update` — Replace one exact memory's content without changing its metadata.
-- `memory_delete` — Delete one exact memory by ID.
-- `memory_extract` — Prepare memories from the current conversation. Follow its returned
-  review-and-confirm instructions and wait for user approval before calling `memory_create`.
-
-Use `memory_create` for explicit "remember this" requests or durable user-specific preferences
-and decisions not discoverable from the repository. Ask when persistence is unclear. Do not
-save routine task completion, code facts, speculation, or plaintext secrets; use Vault and
-remember only the exact `clawdi://` reference. List before updating or deleting unless the user
-already supplied the exact memory ID; never infer which stored item to mutate.
-
-## Sessions
-
-- Use `session_list` to browse recent sessions or filter by time, Agent, or Project.
-- Use `session_search` to find past agent conversations by keyword and obtain session UUIDs.
-- Use `session_get` to read a session by UUID or Clawdi share URL.
-
-Call `session_get` when the user provides a Clawdi share URL or session UUID and wants its
-contents. Use `session_search` to locate a requested unnamed conversation. Do not use a
-generic web fetcher for Clawdi share URLs.
-
-## Projects
-
-- `project_current_get` — Read the runtime-bound Project.
-- `project_list` — List Projects visible to the caller.
-- `project_get` — Read one visible Project by UUID.
-
-Strict-v2 Hosted runtimes can read their own Workspace and explicitly linked Projects
-that remain readable by the owner. `project_current_get` returns that Workspace;
-writes, new Vaults, and credential requests are limited to that Workspace. Legacy
-Agent-bound keys retain their narrower bound-Project read scope. Treat not-found as
-an access boundary as well as a possible unknown UUID; never bypass it with another tool.
-
-## Vault
-
-- `vault_list` — List attached Vaults and key counts for visible Projects.
-- `vault_get` — List key names, provenance, and exact references for an attached Vault.
-
-Honor the user-selected Vault or existing local binding first; never silently switch
-sources. Otherwise inspect `vault_list` / `vault_get` metadata and reuse a Vault matching
-the task's purpose and intended access. Create in the current Workspace only when none
-is appropriate and creation is within the authorized task. Ask for the exact target only
-when ambiguity affects purpose or access. Linked Vaults can be synced read-only; do not
-request or modify fields outside the write boundary, or create duplicates to bypass access.
-
-Use `vault_sync` to save credentials locally for task use. The metadata tools return
-key names and exact references, never secret values. Preserve those references when
-passing them to an authorized runtime:
-
-- `clawdi://project/<project-id>/vault/<vault>/field/<field>`
-- `clawdi://project/<project-id>/vault/<vault>/section/<section>/field/<field>`
-
-Vault write tools are available for explicit user requests:
-
-- `vault_create` — Create a Vault attached to the runtime-bound Project.
-- `vault_item_upsert` — Create or replace exact fields in an attached Vault.
-- `vault_item_delete` — Delete exact fields from a single-Project Vault.
-
-Follow the live schema and supply every required Project, Vault, section, and field identity;
-never infer an overwrite or deletion. Treat field values as sensitive inputs and never echo
-them, save them to Memory, or include them in logs. Hosted writes are restricted to the
-runtime-bound Project, and field deletion is rejected when a Vault is attached to multiple
-Projects. Whole-Vault deletion, attach/detach, and credential profiles remain
-unavailable through Agent MCP; do not bypass that boundary through raw HTTP.
-
-### Request missing credentials
-
-Use `vault_request_create` with exact `project_id`, `vault_id`, canonical `slug`, optional
-`section`, and a batch of environment field names in `fields`. A Vault is a key bundle:
-request related keys together under one link. Supplied or already-pending fields are rejected.
-Show the returned `url` unchanged to the user; do not ask them to paste secrets into chat.
-Opening the link does not consume it. Saving all requested fields consumes it once.
-
-Check `vault_request_status` with its `request_id` after the user finishes. `pending` is not
-a secret value; `supplied` means the exact references are ready. On `expired` or `conflict`,
-inspect the Vault and request only still-missing fields; never replace an existing value to
-retry. If creation times out, use `vault_get` to find recent request IDs before retrying.
-If submission times out, inspect status before repeating a mutation.
-
-### Save and refresh credentials locally
-
-After a request is `supplied`, use `vault_sync` to save credentials locally by default.
-Every call requires `path`: choose a supported env filename in this Agent's authenticated
-workspace based on project conventions and Vault purpose, such as `.env.stripe` or
-`stripe.env`, without routine user reconfirmation. Report the chosen path. A file without
-a binding also requires `project_id`, `vault_id`, and optional `section`. Omit `section`
-for the entire Vault; an empty string selects unsectioned fields. If sections reuse names,
-select one section per file. The target must be untracked, Git-ignored, and not a symlink.
-Check only file/path metadata when choosing a target; never read env contents into the
-conversation. Let `vault_sync` reuse the binding internally and reject local conflicts.
-
-Before later task use, call `vault_sync` with the same explicit `path` when a refresh is
-needed; omit source arguments to reuse that file's durable binding. It adds, updates
-and deletes managed fields while preserving unrelated assignments. Conflicting sources
-or local edits stop the write; restore the managed assignment or choose a new file.
-Return only file path, status and counts; never print keys or the file, log secrets, or
-save them to Memory. Sync does not upload local edits, run in the background, or reload
-a running process's environment. It requires the standalone local MCP adapter; remote-only
-HTTP cannot write files. Do not invent a CLI fallback or script synchronization.
-
-For explicit import/write, pass fields to `vault_item_upsert`; use
-`vault_item_delete` for exact batch deletions. Never upload local edits automatically.
-
-## Connector Routing
-
-Respect an explicit user choice. Otherwise inspect installed service CLIs, direct MCP tools
-already exposed by the runtime, and authorized API or SDK credentials. If an installed and
-authenticated official CLI can perform the task, use it directly. Check availability and
-authentication non-destructively and prefer structured output.
-
-Otherwise choose the lowest-setup reliable option for the task. Consult the service's official
-documentation when installation, authentication, commands, or schemas are uncertain or likely
-to have changed:
-
-- Use a trusted direct MCP already configured and exposed by the runtime. Do not automatically
-  download, install, or start an unfamiliar MCP server.
-- Safely install the official CLI when the runtime permits it, the source is verified as
-  official, and no elevation or persistent host change is required.
-- Use the official API or SDK with a verified contract and credentials already authorized for
-  the runtime, including through an exact Vault reference.
-- Use the Clawdi connector when no direct option can perform the operation.
-
-Before a side effect, establish the exact service account and organization, Project, or tenant.
-Use connection details from Composio discovery, or explicitly list accounts with
-`COMPOSIO_MANAGE_CONNECTIONS`, when the connector identity is not already clear.
-Fallback must not silently change that identity. Do not scan for credentials, start an interactive
-login, invent API details, or expose secrets. Choose the path before a side effect and advance
-only after a definite preflight failure. If a mutation's result is ambiguous, inspect it through
-the same path; never repeat it through another path.
-
-## Connector Account Management
-
-Use `COMPOSIO_MANAGE_CONNECTIONS` for account management, following its live schema.
-For the multi-account schema, each `toolkits` item has `name` and `action`:
-
-- `list`: Read account IDs, aliases, and statuses. Always specify this action for a
-  lookup: omitting `action` defaults to `add` and creates an authorization link.
-- `add`: Create a new authorization link when the user wants another connection.
-- `rename`: Set `alias` on the exact `account_id` returned by discovery.
-- `remove`: Delete the exact `account_id` selected by the user.
-
-Reuse the returned `session_id` when available. Never guess account IDs, use a
-mutation to discover accounts, or automatically retry an ambiguous mutation.
-Do not assume an empty alias clears it unless the live contract confirms that behavior.
-
-## Connector Workflow
-
-When the Clawdi connector path is selected, use the Composio Tool Router meta-tools returned
-by `tools/list` on the `clawdi` MCP server. Treat their live names and schemas as
-authoritative; never assume a fixed meta-tool set.
-
-1. Start the connector workflow with `COMPOSIO_SEARCH_TOOLS`. Follow its exposed
-   `queries` and `session` schema, reuse the returned session ID throughout that workflow,
-   and use only the exact toolkit and tool slugs it returns. If a required schema is absent
-   or incomplete, call `COMPOSIO_GET_TOOL_SCHEMAS`; never invent fields or inputs.
-2. Before a side effect, require a complete target identity and all schema-required inputs.
-   Explicit intent authorizes the exact requested action and target, but never authorizes
-   guessing a missing recipient, account, resource, or other target. Ask only for what is
-   missing, and do not request redundant confirmation once the exact action is authorized.
-3. When search reports no active connection and the user wants to connect, call
-   `COMPOSIO_MANAGE_CONNECTIONS` with explicit `action: "add"` in the multi-account schema.
-   Follow its exposed schema and interpret only the fields it returns. Continue on `active`. On
-   `initiated`, present its non-empty `redirect_url` as a clickable authentication link with
-   a concise explanation that authorization is pending; the link URL must be exactly that
-   value. If `initiated` has no non-empty `redirect_url`, report that authorization cannot
-   continue and stop. On `failed`, report the returned error and stop. Never construct a
-   substitute link, ask for OAuth credentials, API keys, or tokens, or suggest an
-   out-of-band fallback.
-4. Use a wait or status operation only when `tools/list` exposes one. Follow its actual schema
-   and status values without inventing polling arguments. Continue only when it reports an
-   active connection; keep waiting only for a non-terminal status its schema defines, and
-   report any terminal failure. If none is exposed, stop until the user reports completing
-   authorization, then re-run search to verify the active connection before continuing.
-5. Execute exact returned slugs through `COMPOSIO_MULTI_EXECUTE_TOOL` with schema-compliant
-   arguments. Batch only independent calls. Keep ordinary results inline. Set
-   `sync_response_to_workbench` only when a result may be large or needs later remote
-   processing; use `COMPOSIO_REMOTE_WORKBENCH` / `COMPOSIO_REMOTE_BASH_TOOL` only for large
-   responses saved remotely or remote artifacts. Preserve dependencies and returned semantics;
-   follow signed-file metadata, pagination fields, and termination signals exactly as exposed.
-   Select an account only when the schema supports it, and use additional or future meta-tools
-   only according to their live schemas.