sync: render skills from pinecone-io/skills@d1ee173

Generated by tools/build.py. Do not edit by hand — edits here are
overwritten by the next sync.

Author: arjunpatel7

skills/pinecone-full-text-search/SKILL.md

@@ -391,7 +391,9 @@ for m in resp.matches:
     - `dense_vector`: `{"type":"dense_vector", "field":"<dense_field>", "values":[/*floats*/]}`.
     - `sparse_vector`: `{"type":"sparse_vector", "field":"<sparse_field>", "sparse_values":{"indices":[...],"values":[...]}}` — note `sparse_values` (NOT `values`) for sparse clauses.
 - **Single-term prefix wildcards aren't supported.** `auto*` doesn't work in `query_string`; use phrase prefix (`"machine lea"*` — phrase must contain at least two terms, last term is matched as prefix).
-- **Indexes can't be created in CMEK-enabled projects alongside any `full_text_search` field, no backup/restore, no fuzzy or regex search, no S3 bulk import** for document-shaped indexes in `2026-07`. If any of these are hard requirements, the document-schema FTS surface isn't yet ready.
+- **Indexes can't be created in CMEK-enabled projects alongside any `full_text_search` field, no backup/restore** for document-shaped indexes in `2026-07`. If either of these is a hard requirement, the document-schema FTS surface isn't yet ready.
+- **Fuzzy (`term~N`) and regex (`field:/pattern/`) search are supported**, but only under `type: "query_string"` — see [Query syntax](https://docs.pinecone.io/guides/search/full-text-search/query-syntax) and `references/querying.md`. Neither works under `type: "text"`.
+- **Bulk import from object storage is supported by Pinecone for document-shaped indexes** (see [Import data](https://docs.pinecone.io/guides/index-data/import-data)) — this skill just doesn't implement it. Use `documents.upsert` / `documents.batch_upsert` (via `scripts/ingest.py`, see above) for ingestion here, or a dedicated import skill when one exists.
 
 ## Extension points
 

skills/pinecone-full-text-search/references/ingestion.md

@@ -298,7 +298,7 @@ This adapter also gives you a single chokepoint for retries, rate-limit backoff,
 
 ## Limits to be aware of
 
-- **No bulk import (S3 import job)** for document-shaped indexes in `2026-07`. Load through `documents.upsert` / `documents.batch_upsert`.
+- **Bulk import (from object storage) is out of scope for this skill, not unsupported by Pinecone.** Pinecone supports bulk import for document-shaped indexes in `2026-07` (JSON Lines format — see [Import data](https://docs.pinecone.io/guides/index-data/import-data)); this skill just doesn't implement it. Load through `documents.upsert` / `documents.batch_upsert` here, or use a dedicated import skill when one exists.
 - **No backup/restore.** If you need recoverability, snapshot your source data, not the index.
 - **No CMEK projects alongside any `full_text_search` field** — such indexes can't be created in CMEK-enabled projects.
 - **Indexing latency**: documents become searchable in ≲1 minute typically; multi-field schemas can take slightly longer.

skills/pinecone-full-text-search/references/querying.md

@@ -58,8 +58,12 @@ Supported operators (full table in the public docs, summarized here):
 | Phrase slop    | `"…"~N`             | `body:("fast search"~2)`          |
 | Boost          | `term^N`            | `body:(machine^3 learning)`       |
 | Phrase prefix  | `"… word"*`         | `body:("james w"*)`               |
+| Fuzzy term     | `term~N` or `term~` | `body:(compxter~1)`               |
+| Regex          | `field:/pattern/`   | `body:/comput.*/`                 |
 | Cross-field    | `f1:(…) OR f2:(…)`  | `title:(quantum) OR body:(quantum machine)` |
 
+Fuzzy (`~N`, edit distance 0-2; bare `~` picks a distance from term length) and regex (`/…/`, matched against analyzed tokens, not raw field text) are `query_string`-only — the `~` and `/…/` syntax is treated as literal text under `type: "text"`. Fuzzy matching is best-effort on stemmed fields, since a typo can shift which stem a term normalizes to; it's most reliable on fields without stemming.
+
 **Cross-field clauses** are unique to `query_string` — they let one expression target multiple text-searchable fields with their own sub-clauses. Optionally pass a top-level `fields` array on the clause to restrict scope; omitted, the query runs against every text-searchable field in the schema.
 
 ```python