From ade-bench
Install or verify the ade-bench harness, the Python project that actually runs the benchmark tasks this plugin generates. Use when ade-bench isn't yet on the user's machine, when a generated task fails because the harness is missing, or when the user explicitly asks to set up ade-bench. Also invoked automatically by plan-tasks and create-task when they detect ade-bench is missing.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ade-bench:setup [--path <install-path>][--path <install-path>]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The plugin generates task definitions. ade-bench (a separate Python project) is what actually executes them inside Docker against the user's data. This skill makes ade-bench available so generated tasks can be run.
The plugin generates task definitions. ade-bench (a separate Python project) is what actually executes them inside Docker against the user's data. This skill makes ade-bench available so generated tasks can be run.
Default install location: ~/.ade-bench. The skill git clones ade-bench there, runs uv sync to install Python deps, and uv tool install . to put the ade CLI on PATH.
--path <install-path>: Where to install ade-bench. Default: ~/.ade-bench.Resolve ~ to the user's home directory. Use the resolved absolute path in every step below.
Run these in parallel and collect the results:
command -v gitcommand -v uvcommand -v dockerIf any of the three is missing, stop and tell the user what's missing and how to install it:
brew install git, apt install git, etc.).curl -LsSf https://astral.sh/uv/install.sh | sh (then restart the shell or source ~/.zshrc).If docker is installed but not running, that's fine for setup — flag it but proceed. Docker only needs to be running when tasks actually execute.
Two checks, in order:
test -f <install-path>/pyproject.toml && grep -q 'name = "ade-bench"' <install-path>/pyproject.toml
command -v ade
If either succeeds:
ade --help to confirm the CLI works.If <install-path> exists but is not a valid ade-bench checkout (different repo, partial clone, leftover files), stop and ask the user whether to remove and reinstall or pick a different path. Do not silently overwrite.
If nothing is installed, proceed to Step 4.
git clone https://github.com/dbt-labs/ade-bench.git <install-path>
If the clone fails, report the error verbatim and stop. The most common reasons are no network, GitHub auth issues, or <install-path> already existing as a non-empty directory.
cd <install-path> && uv sync
This builds a local virtualenv at <install-path>/.venv and installs all Python deps. Expect this to take 30 seconds to a couple of minutes depending on network speed.
ade CLI Globallycd <install-path> && uv tool install .
uv tool install puts the ade entry point on the user's PATH (under ~/.local/bin by default). After this, ade run … works from any directory.
Verify:
command -v ade && ade --help
If ade is not found after uv tool install, the user's ~/.local/bin is probably not on PATH. Tell them:
"
adewas installed but isn't on PATH. Add~/.local/binto your PATH — for zsh, run:echo 'export PATH=\"$HOME/.local/bin:$PATH\"' >> ~/.zshrc && source ~/.zshrc"
Don't modify the user's shell config yourself.
ade-bench ships several bundled dbt projects (airbnb, f1, quickbooks, …) along with reference DuckDB files used as the source database for those projects. The .duckdb files live in a GitHub release (dbt-labs/ade-bench:databases), not in the repo itself — <install-path>/shared/databases/duckdb/ is empty after git clone. Without these files, any task targeting a bundled project fails at setup_duckdb with "DuckDB database '' not found at ".
The release currently totals ~225 MB. Skip this step only if the user has explicitly said they'll exclusively use their own dbt projects with their own DuckDB files (the generators write db_dir into task.yaml for those — bundled databases aren't consulted).
Compare the number of .duckdb files locally present against the expected count from the GitHub release. Skip the download only when they match exactly — a partial state (e.g., 10 of 11 files) should fall through to Step 7.2 so gh release download can fetch the missing file(s).
present=$(ls <install-path>/shared/databases/duckdb/*.duckdb 2>/dev/null | wc -l | tr -d ' ')
if [ "$present" -gt 0 ]; then
expected=$(gh release view databases --repo dbt-labs/ade-bench \
--json assets \
--jq '[.assets[] | select(.name | endswith(".duckdb"))] | length' 2>/dev/null)
if [ -n "$expected" ] && [ "$present" -eq "$expected" ]; then
# All files present — skip the rest of Step 7 and report "databases already present"
:
fi
fi
Notes:
gh release view API call only when some files are already present, so the first-run path is unaffected.gh isn't installed or isn't authenticated, the expected lookup returns empty and the check falls through to Step 7.2 (which has its own gh-missing branch with manual-download instructions). Consistent.Stash the expected value if you got one — Step 7.4 uses it for the user-facing report.
gh availability and authcommand -v gh && gh auth status
gh missing → tell the user to either install it (brew install gh) or download the release assets manually from https://github.com/dbt-labs/ade-bench/releases/tag/databases into <install-path>/shared/databases/duckdb/. Skip the download and continue to Step 8.gh present but not authenticated → tell the user to run gh auth login and re-invoke /ade-bench:setup. Skip the download and continue to Step 8.gh release download databases \
--repo dbt-labs/ade-bench \
--pattern "*.duckdb" \
--dir <install-path>/shared/databases/duckdb
If the command fails partway through (network, auth expiry), report the error verbatim and continue. The user can rerun the same command later — gh release download skips files that already exist.
Do not block the rest of setup on a download failure. Snowflake-only users don't need these, and a partial download can be completed manually later.
present=$(ls <install-path>/shared/databases/duckdb/*.duckdb 2>/dev/null | wc -l | tr -d ' ')
size=$(du -sh <install-path>/shared/databases/duckdb 2>/dev/null | cut -f1)
Use the expected value from Step 7.1 if you have it. Report the count as <present>/<expected> so a partial state is visually obvious — e.g.:
DuckDB DBs: 11/11 files (224 MB)DuckDB DBs: 10/11 files (210 MB) — re-run /ade-bench:setup to fetch the missing fileDuckDB DBs: 11 files (224 MB) — fall back to just the count.docker ps
If it fails:
If Docker isn't running, that's fine for now — flag it but don't block. The user only needs it when running tasks.
.env (Conditional)Only if the user has indicated they'll be running Snowflake-targeted tasks (or if the calling skill detected a Snowflake project). Skip for DuckDB-only users.
test -f <install-path>/.env || cp <install-path>/.env.example <install-path>/.env
Tell the user:
"I copied
.env.exampleto.envat<install-path>/.env. Open it and fill in your Snowflake credentials before running Snowflake tasks. Required vars:SNOWFLAKE_ACCOUNT,SNOWFLAKE_USER,SNOWFLAKE_PASSWORD,SNOWFLAKE_ROLE,SNOWFLAKE_WAREHOUSE."
Do not prompt for credentials. Do not write credential values to any file. The user fills in .env themselves.
Summarize for the user:
ade-bench setup complete.
Install path: <install-path>
CLI on PATH: ade (verified with `ade --help`)
DuckDB DBs: <present>/<expected> files (<size>) | <present> files (<size>) if expected unknown | not downloaded — install `gh` and rerun, or download manually
Docker: <running | installed but not running | not installed>
Snowflake env: <.env created at <path>, fill in credentials | not initialized — DuckDB-only>
Next: run `/ade-bench:plan-tasks <project-path>` or `/ade-bench:create-task <project-path>` to generate your first benchmark tasks.
.env.example to .env. The user fills it in.open -a Docker or anything similar — it's surprising and sometimes wrong.~/.ade-bench. Honor --path if provided, but don't invent alternative defaults.npx claudepluginhub typedef-ai/ade-bench-plugin --plugin ade-benchSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.