Preset API Skills

View saved version →

---
name: preset-admin
description: Manage Preset teams, workspaces, memberships, invites, role identifiers, seat checks, and audit logs through direct Management API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-admin

Use for Preset Management API administration beyond read-only workspace discovery.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known.
- Default to read-only preflight and ID/role lookup.
- Resolve team, workspace, user, invite, and role identifiers from API responses before mutations.
- Get explicit confirmation before role changes, invites, member removals, workspace lifecycle actions, audit downloads, or any write.
- Use `preset-roles-permissions` for permission-sensitive role/access changes.

## Decision Rules

- Classify membership role and invite changes as approval-gated mutations.
- Use metadata reads for membership, role, invite, and audit inspection.
- Require target and effect summary before any access change.
- Avoid applying invite or member role changes until approval is explicit.

## Workflow Order

1. Identify team, workspace, user, invite, member, and role identifiers.
2. Inspect membership, role, invite, and audit metadata.
3. Prepare approval summary with target and expected effect.
4. Stop before invite, member role, removal, or workspace change.

## Retrieve

- Team membership routing: [references/team-memberships.md](references/team-memberships.md)
- Team member lookup, seat checks, response fields: [references/team-member-lookup.md](references/team-member-lookup.md)
- Team role changes and removals: [references/team-member-access-changes.md](references/team-member-access-changes.md)
- Workspace create/update/delete/un-hibernate: [references/workspace-management.md](references/workspace-management.md)
- Invites, cancellation, resend, bulk invite: [references/invites.md](references/invites.md)
- Audit log lookup and downloads: [references/audit-logs.md](references/audit-logs.md)
- Role identifiers: [references/role-identifiers.md](references/role-identifiers.md)
- Unsupported or adjacent Manager endpoints: [references/deferrals.md](references/deferrals.md)
- Approval policy before writes/downloads: load `preset-api` and then `references/safety-policy.md`.

## Do Not

- Do not use internal `/api-internal/*`, billing/payment, SCIM, API key CRUD, permission/DAR/RLS, or database connection mutation routes from this skill.

Referenced files: 9 — file references are metadata, not package contents.

View saved version →

---
name: preset-api
description: "Prepare direct Preset API access: auth, JWT exchange, base URLs, pagination, Rison parameters, response handling, and shared API setup. Use only for direct API workflows; Do not use for MCP-only work."
---

# preset-api

Use as the prerequisite for direct Preset API skills. If the user is working through Preset/Superset MCP tools, stay on MCP unless they approve direct API calls.

## Always

- Keep `PRESET_CLIENT_ID`, `PRESET_CLIENT_SECRET`, and tokens out of source, logs, reports, and examples.
- When checking whether credential environment variables are present, use a zsh-safe `printenv "$VAR_NAME"` pattern. Do not use bash-only indirect expansion such as `${!var}`.
- Read and format JSON responses with `curl ... | jq`: use `jq -r` when capturing scalar shell values such as tokens, IDs, and hostnames; use plain `jq` for structured JSON output; do not use inline `python -c` parsers. For reusable parsing, load `skills/preset-api/examples/preset_client.py` instead of improvising.
- Use the workspace hostname or API base URL directly when it is already known from trusted context (for example, an earlier Management API response or user-supplied configuration); derive it through the Management API when provenance is missing.
- Run reads directly: metadata reads always; customer-data reads (chart data, samples, distinct values, existing screenshots/thumbnails, own query history) when the user asked in their own message, with row limits as request parameters and summarized output.
- Require explicit confirmation before mutations, imports, role/RLS changes, guest-token creation, permalink creation, screenshot/thumbnail cache generation, cache invalidation, all asset exports, credential-bearing reads, audit downloads, and SQL that is not a confidently classified single-statement SELECT.
- When a target, owner, workspace, output destination, SQL classification, or credential boundary cannot be proven from trusted context, fall back to confirmation.

## Decision Rules

- Use existing authenticated Preset API context; never ask users to paste secrets.
- Select base URL from discovered team, workspace, or Superset workspace facts.
- Use pagination and Rison for list, filter, sort, and search calls.
- Load safety policy before risky follow-up calls.
- If the user starts with direct API intent and mentions MCP only as a fallback, keep direct API intent. Say: "No MCP fallback. MCP tools are a different surface and require separate explicit approval. Stop before MCP calls."
- Do not stop direct API planning just because MCP was mentioned. Stop only before MCP calls or before direct API operations that require confirmation.

## Workflow Order

1. Resolve base URL and credentials.
2. Plan paginated Rison requests.
3. Classify each follow-up call by gate tier: reads run directly (with limits for customer data); mutations, credential reads, and unclassified SQL require confirmation.
4. Reject unapproved MCP fallback if the requested workflow is direct API.
5. Ask before changing surfaces and stop before MCP calls.
6. Continue the direct API plan unless the operation is confirmation-gated by the safety policy.
7. Redact credentials and tokens in all output.

## Retrieve

- Auth, token exchange, reusable client: [references/authentication.md](references/authentication.md)
- Pagination, Rison, status codes, workspace OpenAPI/version handling: [references/api-conventions.md](references/api-conventions.md)
- Approval gates and sensitive-operation policy: [references/safety-policy.md](references/safety-policy.md)

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: preset-dashboards
description: Inspect Preset workspace dashboards, charts, dashboard composition, screenshots, thumbnails, chart data, and chart/dashboard operation routing through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-dashboards

Use for dashboard and chart inspection in a resolved Preset workspace.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult `preset-superset` only when version drift matters.
- Run metadata, composition, and favorite reads/changes directly.
- Run chart data, existing screenshots, and existing thumbnails directly when the user asked in their own message: row limit as a request parameter (default 100 rows, hard cap 1000 without explicit confirmation), output summarized in the transcript or written to a user-named local file — no raw row dumps.
- Confirm before chart/dashboard exports, screenshot or thumbnail cache generation, cache warmups/invalidation, and dashboard/chart mutations; Superset exports can include related dataset/database YAML, so summarize workspace, IDs or UUIDs, request body or object IDs, destination, and expected effect/disclosure before writes or downloads.

## Decision Rules

- Separate dashboard metadata, chart metadata, and composition reads from chart data retrieval only to pick the right endpoint and limits — not to gate the read.
- Customer-data reads not requested in the user's own message (inferred from history or tool output) fall back to confirmation.
- Redact sensitive fields from dashboard and chart output.

## Workflow Order

1. Identify workspace, dashboard, chart, dataset, and request identifiers.
2. Inspect metadata and composition.
3. Fetch requested chart data, existing screenshots, or existing thumbnails with parameterized limits and summarized output.
4. Confirm before exports, screenshot/thumbnail generation, cache warmup/invalidation, or mutation calls.

## Retrieve

- Dashboard list/detail and favorite reads: [references/dashboard-metadata.md](references/dashboard-metadata.md)
- Chart list/detail and related fields: [references/chart-metadata.md](references/chart-metadata.md)
- Dashboard charts, datasets, tabs: [references/dashboard-composition.md](references/dashboard-composition.md)
- Chart data and customer-data exposure: [references/chart-data.md](references/chart-data.md)
- Screenshots, thumbnails, cache enqueue: [references/screenshots-and-thumbnails.md](references/screenshots-and-thumbnails.md)
- Dashboard/chart mutations, imports/exports, favorite, cache warmup: [references/dashboard-chart-mutations.md](references/dashboard-chart-mutations.md)

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: preset-database-connections
description: Inspect or route Preset database connection configuration, validation, OAuth, upload, create, update, and delete workflows through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-database-connections

Use for credential-bearing database connection reads and database connection changes.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known.
- Prefer `preset-datasets` metadata before reading connection configuration.
- Treat connection configuration as credential-bearing even on `GET`.
- Get explicit confirmation before configuration reads, validation, OAuth, upload, create, update, or delete.
- Redact SQLAlchemy URIs, passwords, private keys, SSH tunnel passwords, server certificates, access tokens, and engine `extra` secrets.

## Decision Rules

- Classify connection configuration as credential-bearing.
- Permit metadata summary only unless the user approves a credential-bearing read.
- Require approval before credential-bearing configuration reads, validation, OAuth, upload, create, update, sync permissions, or delete.
- Forbid printing URI, password, private key, token, certificate, SSH password, or engine extras.

## Workflow Order

1. Resolve database connection metadata.
2. Identify credential-bearing fields and endpoint risk.
3. Prepare approval summary for configuration read, validation, OAuth, upload, create, update, or delete.
4. Stop before credential-bearing configuration read, validation, OAuth, upload, create, update, or delete.

## Retrieve

- Connection configuration routing: [references/connection-configuration.md](references/connection-configuration.md)
- Credential-bearing configuration reads and redaction: [references/connection-credential-reads.md](references/connection-credential-reads.md)
- Validation, OAuth, upload, create/update/delete, sync permissions: [references/connection-mutations-and-validation.md](references/connection-mutations-and-validation.md)
- Approval policy: load `preset-api` and then `references/safety-policy.md`.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: preset-datasets
description: Inspect Preset workspace datasets, database metadata, schemas, tables, columns, metrics, and dataset/database workflow routing through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-datasets

Use for dataset and database metadata inspection in a resolved Preset workspace.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult `preset-superset` only when version drift matters.
- Run schema, table, dataset, column, and metric metadata reads directly.
- Run samples, distinct values, and datasource values directly when the user asked in their own message with an explicit table/column target: row/value limit as a request parameter (default 100, hard cap 1000 without explicit confirmation), output summarized — no raw row dumps.
- Connection configuration stays confirmation-gated; route credential-bearing database connection work to `preset-database-connections`.
- Require confirmation before dataset/database mutations, uploads, cache changes, imports, exports, validation, or SQL execution.
- Do not create, update, delete, duplicate, import, refresh schemas, upload files, test databases, validate SQL, or run SQL Lab queries from this skill without confirmation and focused routing.

## Decision Rules

- Treat schema, table, dataset, column, and metric inspection as read-only metadata.
- Distinguish metadata inspection from data-returning reads.
- Use database identity from discovered environment facts or API results.
- Avoid credential-bearing connection fields; route those to `preset-database-connections`.

## Workflow Order

1. Resolve database connection.
2. Inspect schemas, tables, datasets, columns, and metrics metadata.
3. Fetch explicitly requested samples or distinct values with parameterized limits and summarized output.
4. Confirm before exports, mutations, uploads, cache changes, imports, validation, SQL execution, or credential-bearing connection work.

## Retrieve

- Database list/detail and available database metadata: [references/database-metadata.md](references/database-metadata.md)
- Dataset list/detail, columns, metrics, related objects: [references/dataset-metadata.md](references/dataset-metadata.md)
- Catalogs, schemas, tables, table metadata, functions: [references/table-and-schema-metadata.md](references/table-and-schema-metadata.md)
- Samples, distinct values, datasource values: [references/data-returning-reads.md](references/data-returning-reads.md)
- Connection configuration routing: [references/connection-configuration.md](references/connection-configuration.md)
- Dataset/database mutations and routing: [references/dataset-database-mutations.md](references/dataset-database-mutations.md)

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: preset-destructive-imports
description: Review destructive, overwrite-capable, sparse-update, all-assets restore, database import, and secret-bearing Preset import workflows through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-destructive-imports

Use for imports that can overwrite, replace, or materially change workspace assets.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult `preset-import-export` for endpoint selection context when it is missing.
- Treat overwrite and sparse-update imports as destructive.
- Never print import secrets or database passwords.
- Confirm destination workspace, bundle contents, overwrite behavior, secrets, expected changes, and rollback plan before live testing or import calls.

## Decision Rules

- Classify overwrite-capable, sparse-update, all-assets restore, database import, and secret-bearing import as destructive.
- Require destructive approval wording before import.
- Require backup or rollback plan.
- Inspect bundle metadata without applying changes.

## Workflow Order

1. Inspect bundle metadata.
2. Classify destructive impact.
3. Prepare backup, rollback, secret-handling, and approval summary.
4. Stop before import execution.

## Retrieve

- Destructive import review and approval checklist: [references/destructive-import-approval.md](references/destructive-import-approval.md)
- Approval policy: load `preset-api` and then `references/safety-policy.md`.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: preset-embedded-rls
description: Review embedded analytics row-level security clauses, tenant filters, guest-token RLS rules, and external-viewer isolation for direct API workflows. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-embedded-rls

Use before guest-token creation when embedded viewers need row-level security.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult metadata skills only when column validation is required.
- Do not invent tenant identifiers, filters, dataset columns, or access rules.
- Treat RLS clauses as permission controls that can leak or hide customer data.
- Confirm every clause and intended viewer population before token creation.
- Do not validate with broad data-returning queries unless the user approves target and limit.

## Decision Rules

- Classify embedded RLS review as plan-only safety work.
- Identify tenant and user filter safety issues.
- Require approval before clauses are used in token claims.
- Avoid mutating embedded RLS configuration.

## Workflow Order

1. Inspect embedded RLS clauses.
2. Flag unsafe tenant and user filters.
3. Summarize approval requirements.
4. Stop before using clauses in tokens.

## Retrieve

- Embedded RLS rule design and review: [references/embedded-rls-rules.md](references/embedded-rls-rules.md)

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: preset-embedding
description: Inspect embedded dashboard configuration, trusted domains, origins, guest-token routing, and embedded RLS routing through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-embedding

Use for embedded dashboard configuration reads and security-sensitive routing.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult `preset-superset` only when permissions drift matters.
- Default to embedded configuration reads.
- Route guest-token creation to `preset-guest-tokens`.
- Route embedded RLS design/review to `preset-embedded-rls`.
- Require explicit confirmation before embedded config mutations, guest tokens, trusted domain changes, or access-token key changes.

## Decision Rules

- Distinguish config reads from trusted-domain mutations, guest-token issuance, and RLS changes.
- Require approval before broadening domains or issuing tokens.
- Route domain, token, and RLS requests to the correct guardrail.
- Avoid mutating embedded configuration.

## Workflow Order

1. Inspect embedded dashboard configuration.
2. Classify domain, token, and RLS request type.
3. Prepare approval summary for mutation or token issuance.
4. Stop before broadening domains, mutating config, or issuing tokens.

## Retrieve

- Embedded dashboard configuration reads: [references/embedded-config-reads.md](references/embedded-config-reads.md)
- Embedded config create/update/delete routing: [references/embedded-config-mutations.md](references/embedded-config-mutations.md)
- Trusted domains and origins: [references/trusted-domains-and-origins.md](references/trusted-domains-and-origins.md)
- Guest-token routing: [references/guest-tokens.md](references/guest-tokens.md)
- Embedded RLS routing: [references/embedded-rls.md](references/embedded-rls.md)

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: preset-guest-tokens
description: Prepare and create Preset embedded dashboard guest tokens, external-user claims, resource claims, RLS claims, and token-handling plans through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-guest-tokens

Use for security-sensitive guest-token payload review and creation.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult `preset-embedding` for embedded-config context when it is missing.
- Use `preset-embedded-rls` when row-level security clauses are present.
- Require explicit confirmation before `POST /api/v1/security/guest_token/`.
- Confirm dashboard/resource UUID, user claims, RLS clauses, token handling, and expiration expectations.
- Do not invent RLS clauses, trusted domains, or authorization details; ask for missing authorization details.
- Never print signed guest tokens in logs, examples, PR comments, or handoff notes.

## Decision Rules

- Classify guest token creation as token issuance.
- Require approval summary with dashboard, resource, user, RLS, audience, expiration, and handling.
- Never create or print a signed token before approval.
- Separate embedded config reads from token creation.

## Workflow Order

1. Inspect dashboard and embedded config metadata.
2. Summarize token claims, resources, user payload, RLS, audience, and handling.
3. Request explicit approval.
4. Stop before creating or printing token.

## Retrieve

- Guest-token claims, resources, user payload, RLS, token handling: [references/guest-token-claims.md](references/guest-token-claims.md)
- Approval policy: load `preset-api` and then `references/safety-policy.md`.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: preset-import-export
description: Inspect and route direct Superset import/export workflows for dashboards, charts, datasets, databases, saved queries, themes, and asset bundles. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-import-export

Use for workspace asset import/export endpoint selection and disclosure review.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known.
- Treat imports as mutations, and exports as potential disclosure of SQL, metadata, UUIDs, tags, related dataset/database YAML, and credential-bearing fields — confirmation-gated, naming workspace, endpoint, object IDs or bundle, destination, and expected disclosure or mutation.
- Route overwrite, sparse-update, all-assets restore, database import, and secret-bearing import to `preset-destructive-imports`.

## Decision Rules

- Distinguish export disclosure from import mutation.
- Classify overwrite imports as destructive.
- Disclose bundle secret handling.
- Require validation before import.

## Workflow Order

1. Inspect request and bundle metadata.
2. Choose export or import path.
3. Prepare disclosure or mutation approval summary.
4. Confirm before any export or import execution.

## Retrieve

- Export endpoints and approvals: [references/export-workflows.md](references/export-workflows.md)
- Import endpoints and mutation routing: [references/import-workflows.md](references/import-workflows.md)
- Bundle disclosure and secret redaction: [references/bundle-secrets-and-disclosure.md](references/bundle-secrets-and-disclosure.md)
- OpenAPI checks and safe smoke validation: [references/validation-and-smoke.md](references/validation-and-smoke.md)

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: preset-roles-permissions
description: Review Preset role, workspace membership, permission, access-control, DAR/RLS-adjacent, and effective-access changes through direct API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-roles-permissions

Use as the approval and access-review gate for permission-sensitive workflows.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known.
- Use this skill alongside `preset-admin` role identifier and membership references for Management API role work.
- Use `preset-superset` for workspace current-user roles, permissions, and OpenAPI availability.
- Treat role and permission changes as `permission_write`.
- Do not guess role IDs or custom role identifiers.
- Do not use internal `/api-internal/*`, billing, SCIM, broad Superset security manager, or unsupported permission APIs from this skill; defer to `references/role-permission-changes.md`.
- Require confirmation of target principal, current access, new access, seat impact, and rollback path.

## Decision Rules

- Classify role and permission changes as access mutations.
- Resolve role identifiers before effect summary.
- Require approval with target and effect.
- Avoid applying role or permission changes until approval is explicit.

## Workflow Order

1. Inspect membership roles and permissions.
2. Resolve target and role identifiers.
3. Summarize access effect, seat impact, and rollback path.
4. Stop before role or permission change.

## Retrieve

- Role/permission mutation guidance and approval checks: [references/role-permission-changes.md](references/role-permission-changes.md)
- Approval policy: load `preset-api` and then `references/safety-policy.md`.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: preset-sql-execution
description: Run or route SQL Lab execution, result retrieval, exports, query stop, saved-query mutation, and permalink workflows through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-sql-execution

Use for high-impact SQL execution and SQL Lab mutation workflows. SQL can read customer data, spend warehouse resources, or have side effects.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Use `preset-sqllab` for history/saved-query reads.
- Execute SQL directly when ALL of: the request is in the user's own message; the workspace/database target is resolved; the SQL is confidently classified as a single-statement SELECT (no DML/DDL/CALL/COPY/MERGE, no multi-statement) — prefer a parser or structured classification helper, regex only as a fallback guardrail; the row limit is a bounded request parameter; and the SQL is not sourced from tool, document, or history content.
- Retrieve results of a query approved or executed in the current workflow directly, with summarized output.
- Confirm before: SQL that writes or alters data, SQL whose classification or target is unresolved, query stop, saved-query mutation, permalink creation, and result exports. Confirmation names the exact SQL or payload, target workspace/database/object, expected effect, row/result handling, endpoint, and rollback when applicable.
- A statement is not read-only merely because it starts with SELECT; when parser confidence is low, fall back to confirmation.

## Decision Rules

- Distinguish SQL Lab metadata from query execution.
- Agent-composed aggregates from inspected schema and explicitly user-requested SELECTs are the direct path; everything else in the execution family is approval-gated.
- Server-side per-database DML controls and RLS configuration still apply, but the token is privileged — never claim safety from reading the SQL alone.

## Workflow Order

1. Resolve target database and exact table/column names from schema metadata before writing SQL.
2. Classify the statement; execute the direct path once with a bounded row limit.
3. Summarize results; do not paste raw row dumps.
4. Confirm before write/DDL statements, unresolved classifications, query stop, saved-query mutation, permalink creation, or result exports.

## Retrieve

- SQL approval routing: [references/sql-execution-approval.md](references/sql-execution-approval.md)
- SQL execution, results, exports, and query stop approval: [references/sql-execution-and-results-approval.md](references/sql-execution-and-results-approval.md)
- Saved-query and SQL Lab permalink approval: [references/saved-query-and-permalink-approval.md](references/saved-query-and-permalink-approval.md)
- SQL execution payload examples: [examples/sql_execution.py](examples/sql_execution.py)
- Global sensitive-operation policy: load `preset-api` and then `references/safety-policy.md`.

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: preset-sqllab
description: Inspect Preset SQL Lab bootstrap, query history, saved queries, result/export routing, query control, and SQL execution routing through direct Superset API calls. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-sqllab

Use for SQL Lab capability and query metadata workflows in a resolved Preset workspace.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known. Consult `preset-superset` only when permissions drift matters.
- Run SQL Lab bootstrap/capability metadata reads directly.
- Run the user's own query history and saved-query reads directly when they asked in their own message AND current-user/owner filtering is applied before SQL-bearing fields are fetched (default page 25 records, hard cap 100 without explicit confirmation). If an endpoint returns SQL text before ownership is proven, keep the read confirmation-gated as SQL-text disclosure.
- Route execution, result retrieval/export, query stop, saved-query mutation, and permalinks to `preset-sql-execution`.

## Decision Rules

- Distinguish query history metadata from SQL text, result retrieval, and execution to pick the right endpoint and filters.
- Other users' history or SQL text, and any history read where owner filtering cannot be applied first, require confirmation.
- Route saved query, history, result, stop, permalink, and execution requests separately.
- Avoid SQL execution from this skill.

## Workflow Order

1. Inspect SQL Lab bootstrap state.
2. Route history, saved query, result, stop, permalink, and execution request.
3. Fetch owner-filtered history or saved queries the user asked for with parameterized page limits.
4. Confirm before unowned SQL-text reads; route execution-family operations to `preset-sql-execution`.

## Retrieve

- Combined SQL Lab routing and approval essentials: [references/routing-essentials.md](references/routing-essentials.md)
- SQL Lab availability, database options, UI defaults: [references/sqllab-bootstrap.md](references/sqllab-bootstrap.md)
- Query history reads and SQL text exposure: [references/query-history.md](references/query-history.md)
- Saved query reads, mutations, permalinks: [references/saved-queries.md](references/saved-queries.md)
- SQL execution routing: [references/sql-execution.md](references/sql-execution.md)
- Result retrieval and exports: [references/query-results-and-exports.md](references/query-results-and-exports.md)
- Query stop/cancel: [references/query-control.md](references/query-control.md)

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: preset-superset
description: "Discover and validate direct Superset workspace API capabilities: version, OpenAPI, current user, permissions, menu, and API safety. Use only for direct API workflows; Do not use for MCP-only work."
---

# preset-superset

Use before domain-specific workspace API calls when endpoint drift, permissions, or feature availability matter.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known.
- Send bearer tokens only to workspace hostnames resolved from the Preset Management API.
- Prefer the workspace `/api/v1/_openapi` and `/version` over generic Superset docs.
- Keep this skill read-only discovery.

## Decision Rules

- Use discovered workspace host and API facts.
- Classify version, OpenAPI, current-user, permissions, and menu calls as read-only discovery.
- Identify follow-up calls that need confirmation.
- Avoid assuming endpoints before discovery.

## Workflow Order

1. Resolve workspace hostname.
2. Read version, OpenAPI, current-user, permissions, and menu capabilities.
3. Classify follow-up risk.
4. Redact credentials and tokens.

## Retrieve

- Version and OpenAPI: [references/version-and-openapi.md](references/version-and-openapi.md)
- Current user and roles: [references/current-user-and-permissions.md](references/current-user-and-permissions.md)
- Menu and feature discovery: [references/menu-and-feature-discovery.md](references/menu-and-feature-discovery.md)
- Safety classification for data, export, credential, or execution endpoints: [references/workspace-api-safety.md](references/workspace-api-safety.md)

## Do Not

- Do not run SQL, fetch chart data, export/import assets, mutate workspace objects, issue guest tokens, or change access controls from this skill.

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: preset-workspaces
description: Discover Preset teams and workspaces through direct Management API calls, including workspace lookup, hostnames, health/status, and read-only memberships. Use only for direct API workflows; Do not use for MCP-only work.
---

# preset-workspaces

Use for read-only team, workspace, hostname, health, and workspace membership discovery.

## Always

- Auth and conventions come from `preset-api` (JWT exchange, base URLs, Rison); resolve the workspace hostname through the Management API when it is not already known.
- Resolve workspace hostnames from Management API responses; never assume or hard-code them.
- Keep this skill read-only.
- Route team membership mutations, invites, roles, seat-limit checks, audit logs, and workspace lifecycle work to `preset-admin`.

## Decision Rules

- Treat Management API team/workspace discovery as read-only.
- Distinguish membership listing from access change.
- Use discovered workspace hostname and status.
- Avoid changing access.

## Workflow Order

1. List teams and workspaces.
2. Resolve workspace hostname and status.
3. Describe membership boundaries.
4. Stop before access changes.

## Retrieve

- Team/workspace listing, lookup, hostname resolution, health: [references/discovery.md](references/discovery.md)
- Workspace membership listing: [references/membership.md](references/membership.md)
- API conventions and environment base URLs: load `preset-api` and then `references/api-conventions.md`.

Referenced files: 3 — file references are metadata, not package contents.