paradedb-skill

---
name: paradedb-skill
description: >
license: MIT
---

# ParadeDB Skill

ParadeDB is one Postgres that unifies your application data, full-text search, vector retrieval, and aggregations via the `pg_search` extension.

Use this skill when users ask about:

- ParadeDB indexes, BM25 scoring, and relevance ranking
- Vector search and hybrid search (keyword + semantic, fused with reciprocal rank fusion)
- Tokenizers, token filters, fuzzy matching, and phrase queries
- Facets, aggregations, snippets/highlighting, joins, and query tuning

For up-to-date ParadeDB documentation, always fetch the documentation index
(`llms.txt`) using the bundled script at `scripts/paradedb-docs`.
Resolve that path relative to the directory containing this `SKILL.md`, not
relative to the current working directory or repo root.

```bash
scripts/paradedb-docs llms.txt
```

Once you have the list of urls, load the pages necessary to answer the user's question. For example:
```bash
scripts/paradedb-docs documentation/getting-started/environment.md
scripts/paradedb-docs documentation/full-text/match.md
scripts/paradedb-docs documentation/indexing/create-index.md
# etc
```

After a successful fetch, treat that content as cached session context and
reuse it for later ParadeDB questions in the same session if applicable.
Do not refetch on every turn when the previously fetched docs are still
available and relevant.

The tool uses curl internally and requires network access. Make sure you run it with network access.
If you have to ask the user for permission to run the tool, make sure to ask them to allow you to run
the command for all arguments so you can fetch every page.

Do **not** use any tool other than `scripts/paradedb-docs` to fetch documentation.

## Response Guidelines

1. Prefer runnable SQL examples over prose-only answers.
2. State ParadeDB/Postgres version assumptions when syntax may differ. Some features are only
   available in newer versions, so when you have database access and the answer depends on
   one, check first with `SELECT extversion FROM pg_extension WHERE extname = 'pg_search';`.
3. If behavior is uncertain, call it out explicitly instead of guessing.
4. Do not generate any of the deprecated syntax. The new syntax was released in
   version 0.20.0 and should be used exclusively unless the user requests the old syntax.
   If a query contains `paradedb`, it is using the old syntax. Use `pdb` instead.
5. In version 0.25.0, the BM25 index was renamed to the ParadeDB index, because it now
   powers vector search, aggregates, top K and filtering as well as BM25 scoring. Write
   `CREATE INDEX ... USING paradedb`, not `USING bm25`, which survives only as a
   backwards-compatible alias, and call it the ParadeDB index. Reserve "BM25" for the
   scoring function itself.
6. Vector search runs inside the ParadeDB index as of version 0.25.0, where it is a beta
   feature. ParadeDB indexes pgvector's `vector` type, but does not use pgvector's HNSW or
   IVFFlat indexes — do not suggest them for a vector column that is in a ParadeDB index.
   Fetch `documentation/indexing/indexing-vectors.md` and `documentation/vector/querying.md`
   before writing vector queries, and `documentation/hybrid/rrf.md` before writing hybrid ones.

## Network Failure Rules (Mandatory)

If any documentation cannot be fetched due to DNS/network/access errors:

1. State clearly that live docs could not be accessed and include the actual error.
2. If you have cached session docs from an earlier successful fetch, say that
   you can continue from that cached copy unless the user wants to stop.
3. If you do not have cached session docs, ask whether to proceed with
   local/repo-only context or to retry later.
4. Do **not** invent or infer doc URLs, page paths, or feature availability.
5. Do **not** present unverified links as real.
6. Label any fallback statements as assumptions and keep them minimal.

Never silently switch to guessed documentation structure when network access fails.