Subsalt

View saved version →

---
name: subsalt-data-analysis
description: Guide an authorized user through safe exploration of Subsalt metadata, synthetic data, cohorts, and Secure Compute.
---

Use this skill for requests to explore or analyze data available through Subsalt.

- Identify the user's analytical goal before choosing a tool. Use metadata and workspace tools to find a permitted database, cohort, or Secure Compute grid.
- Use `synthetic_run_query` only for a single read-only SELECT against an identified built cohort. Keep queries narrowly scoped, use an explicit small limit for sample rows, and report if the result is truncated or stale.
- Prefer descriptive and read-only tools while the user is still deciding what to do. Do not create, edit, delete, build, lock, publish, report, recount, or close anything without an explicit confirmation immediately before that action.
- Treat identifiers returned by Subsalt as internal references. Use them in follow-up calls when needed, but do not claim that a resource exists unless the server returned it.
- When working with Secure Compute, retrieve the analysis-plan guidance before preparing a publication. Describe the proposed plan in plain language and confirm it before locking a plan or submitting a publication.
- Explain results faithfully: distinguish synthetic data from privacy-preserving Secure Compute output, retain caveats about banding, withholding, truncation, and staleness, and never infer unreleased values.

View saved version →

---
name: subsalt-get-started
description: Help a user connect their Subsalt account and begin a safe data-analysis workflow.
---

Use this skill when a user is setting up Subsalt or asks how to start working with their Subsalt data.

1. Explain that Subsalt uses the user's existing Subsalt account and permissions. If sign-in is required, direct the user to complete the browser sign-in flow; never ask for passwords, access tokens, or API keys in chat.
2. Start with the user's goal. For a general orientation, retrieve the available workspaces and databases, then explain what is available at a high level.
3. Use synthetic-data tools for exploratory SQL only after identifying a built cohort. State whether results are synthetic and note any returned truncation or staleness indicators.
4. Before any state-changing action—creating, editing, deleting, building, locking a plan, submitting Secure Compute work, requesting a Secure Compute report, or closing a session—summarize the effect and ask for explicit confirmation. Never treat a request to explore or describe as approval to make a change.
5. For Secure Compute, explain that the workflow is privacy preserving and use the server's plan guidance before drafting or submitting a publication. Do not present released values as exact when the result says they are banded or withheld.
6. If the user lacks access or an operation is unavailable, report that plainly and suggest the relevant Subsalt administrator or support channel. Do not retry a failed write action without the user's direction.