/setup
Make a repository Superset-ready — author .superset/config.json with setup/teardown/run scripts so every new workspace boots configured, then verify with a real workspace. Use when the user wants to set up a project or repo for Superset, configure workspace setup scripts, or fix
$ npx -y skills add superset-sh/superset --skill setup --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/setup
Context preview
The summary Claude sees to decide when to auto-load this skill.
Make a repository Superset-ready — author .superset/config.json with setup/teardown/run scripts so every new workspace boots configured, then verify with a real workspace. Use when the user wants to set up a project or repo for Superset, configure workspace setup scripts, or fix
SKILL.md
setup.SKILL.mdname: setup
description: Make a repository Superset-ready — author .superset/config.json with setup/teardown/run scripts so every new workspace boots configured, then verify with a real workspace. Use when the user wants to set up a project or repo for Superset, configure workspace setup scripts, or fix a failing workspace setup.
argument-hint: optional notes about the project's setup needs
Superset Project Setup
Goal: every new workspace (isolated git worktree) for this repo comes up ready — dependencies installed, env present, services reachable — without manual steps.
1. Inspect the repo
Work out what a fresh worktree needs, and ask about anything ambiguous:
- Package manager and install command (lockfiles decide: bun/pnpm/yarn/npm, cargo, uv, ...)
- Env files: `.env` is usually gitignored, so new worktrees need it copied from the main checkout or generated from `.env.example`
- Services (docker-compose, databases) and dev command + ports
- Monorepo layout (does setup need a `cwd`?)
2. Author `.superset/config.json`
This file is what wires lifecycle scripts in — a bare `setup.sh` without `config.json` is NOT picked up. Schema:
{
"setup": ["./.superset/setup.sh"],
"teardown": ["./.superset/teardown.sh"],
"run": ["bun dev"],
"cwd": "optional/subdir"
}Each key is an array of shell commands run inside the worktree on workspace create / delete / run. Guidelines:
- Setup must be idempotent and fast (aim for under a minute; slow steps make every workspace creation painful)
- Copy secrets/env from the main checkout at setup time — never commit them
- `.superset/config.local.json` (gitignored) lets an individual user extend scripts with `before`/`after` arrays without touching the shared config
Show the user the proposed files and get explicit approval before writing.
3. Verify for real
Create a throwaway workspace with `superset workspaces create --project <id> --name "setup-test"` and watch the "Workspace Setup" terminal output. Fix and repeat until it completes cleanly, then delete the test workspace. Setup is not done until a real workspace boots green.
Read more
name: setup description: Make a repository Superset-ready — author .superset/config.json with setup/teardown/run scripts so every new workspace boots configured, then verify with a real workspace. Use when the user wants to set up a project or repo for Superset, configure workspace setup scripts, or fix a failing workspace setup. argument-hint: optional notes about the project's setup needs
Superset Project Setup
Goal: every new workspace (isolated git worktree) for this repo comes up ready — dependencies installed, env present, services reachable — without manual steps.
1. Inspect the repo
Work out what a fresh worktree needs, and ask about anything ambiguous:
- Package manager and install command (lockfiles decide: bun/pnpm/yarn/npm, cargo, uv, ...)
- Env files: `.env` is usually gitignored, so new worktrees need it copied from the main checkout or generated from `.env.example`
- Services (docker-compose, databases) and dev command + ports
- Monorepo layout (does setup need a `cwd`?)
2. Author `.superset/config.json`
This file is what wires lifecycle scripts in — a bare `setup.sh` without `config.json` is NOT picked up. Schema:
{
"setup": ["./.superset/setup.sh"],
"teardown": ["./.superset/teardown.sh"],
"run": ["bun dev"],
"cwd": "optional/subdir"
}Each key is an array of shell commands run inside the worktree on workspace create / delete / run. Guidelines:
- Setup must be idempotent and fast (aim for under a minute; slow steps make every workspace creation painful)
- Copy secrets/env from the main checkout at setup time — never commit them
- `.superset/config.local.json` (gitignored) lets an individual user extend scripts with `before`/`after` arrays without touching the shared config
Show the user the proposed files and get explicit approval before writing.
3. Verify for real
Create a throwaway workspace with `superset workspaces create --project <id> --name "setup-test"` and watch the "Workspace Setup" terminal output. Fix and repeat until it completes cleanly, then delete the test workspace. Setup is not done until a real workspace boots green.
Code Editor for the AI Agents Era - Run an army of Claude Code, Codex, etc. on your machine
Other skills on superset.
- /10x
Personalized audit that teaches advanced Superset features the user isn't using yet — automations, parallel agents, tasks, multi-host, terminals, custom commands, MCP. Use when the user wants to get more out of Superset, learn advanced Superset features, or 10x their Superset
Open skill - /automate
Turn a recurring chore into a Superset automation — drafts the agent prompt, confirms schedule and target, creates it with the CLI, and reviews the first run together. Use when the user wants a scheduled or recurring agent, a daily/weekly job, or to automate a repeating task
Open skill - /contribute
Set up a Superset open-source contribution — fork and clone superset-sh/superset, run local dev setup, and follow the repo's contribution rules through to a merge-ready PR. Use when the user wants to contribute to Superset, fix a Superset bug themselves, or prepare a PR against
Open skill - /doctor
Diagnose and fix Superset problems — connection failures, offline hosts, terminals not attaching, auth or update issues. Use when the user reports something broken or misbehaving in Superset itself, before filing feedback.
Open skill - /feedback
Collect and submit feedback about Superset — bug reports, feature requests, or general feedback — privately to the Superset team or as a public GitHub issue. Use when the user wants to report a Superset bug, request a feature, or send feedback about Superset.
Open skill - /orchestrate
Coordinate multiple terminal coding agents through the Superset CLI by creating isolated workspaces, launching workers, sending follow-ups, reading terminal output, tracking dependencies, and collecting structured results. Use when asked to delegate or parallelize coding work,
Open skill

