npm - opencode-skills-collection - Versions diffs - 3.1.10 → 3.1.11 - Mend

opencode-skills-collection 3.1.10 → 3.1.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (66) hide show

package/bundled-skills/pre-release-review/references/report-template.md ADDED Viewed

@@ -0,0 +1,91 @@
+# Pre-release Review Report Template
+Use this template for the final report. Translate headings to the user's language if useful, but
+keep the same sections, priority labels, conclusion values, and finding fields.
+## Priority definitions
+- `P0` - Block release. A production deploy is likely to fail, corrupt data, expose secrets, break
+  compatibility, or require a missing manual action.
+- `P1` - High risk, must confirm before release. Evidence suggests a production dependency,
+  migration, config, cache, queue, asset, or service-order risk.
+- `P2` - Medium risk or ambiguous gap. Not clearly blocking, but should be checked before release
+  because the diff introduces uncertainty.
+- `P3` - Low-risk note. Do not include P3 in the main report unless the user asks for a complete
+  audit log.
+## Conclusion values
+- `BLOCKED` - At least one P0 finding exists.
+- `NEEDS_CONFIRMATION` - No P0 was found, but one or more P1/P2 items need confirmation.
+- `NO_BLOCKER_FOUND` - No P0-P2 finding or release confirmation item was found from available
+  evidence. Neutral verification limits may still be listed separately.
+## Findings versus Unable To Verify
+- Put diff-linked production risks in `Findings`. Examples: a new env var whose production value
+  cannot be verified, a schema change with unclear migration execution, or a new queue whose
+  infrastructure is not confirmed.
+- Any P1 or P2 finding means the conclusion is `NEEDS_CONFIRMATION` unless a P0 makes it `BLOCKED`.
+- Put only neutral tool or access limits in `Unable To Verify`. Examples: remote PR access is
+  unavailable, deployment platform access is unavailable, or owner inference failed without a
+  specific release-critical change.
+- If an access/tool limitation prevents confirmation of a release-critical diff change, promote it
+  to a P1/P2 finding instead of leaving it only in `Unable To Verify`.
+## Owner inference
+- Prefer `git blame` on changed lines for the file and line that caused the finding.
+- If blame is unavailable or misleading, use `git log --format="%h %an %s" -- <path>`.
+- If several commits contributed to the same release risk, list all relevant author names.
+- Mark owners as "inferred" and do not expose email addresses.
+- If no owner can be inferred, write `Unknown (not inferable from local git evidence)`.
+## Secret redaction
+- Never print secret values, even partially, unless the value is already a harmless placeholder such
+  as `example`, `changeme`, or `REDACTED`.
+- Report secrets as: path, line, variable/key name, type, and redacted hint.
+- Example: `config/prod.env:12` - `PAYMENT_API_KEY`, suspected API key, value redacted.
+- Do not paste PEM blocks, JWTs, cookies, session IDs, private keys, passwords, certificates, or
+  cloud credentials into the report.
+## Final report shape
+```markdown
+# Production Release Readiness Review
+## Scope
+- Range: <base>..<head> | PR <number> | latest 5 commits fallback
+- Current branch: <branch>
+- Head commit: <hash>
+- Compared from: <tag/hash/pr-base>
+- Commit count: <count>
+- Dirty worktree: <yes/no and short note>
+- Commands used: <short list of read-only commands>
+## Conclusion
+`BLOCKED` | `NEEDS_CONFIRMATION` | `NO_BLOCKER_FOUND`
+## Findings
+| Priority | Module | Finding | Evidence | Inferred owner | Risk | Recommended action |
+| --- | --- | --- | --- | --- | --- | --- |
+| P0/P1/P2 | <area/service> | <short issue> | <file:line or commit/range> | <name(s) or unknown> | <why it matters> | <release action> |
+## Deployment Order / Release Actions
+- <Only include when relevant. State service order, migrations, queue/cache/resource actions, and compatibility constraints.>
+## Unable To Verify
+- <Tooling, auth, remote, production-config, or repository limits that prevent confirmation.>
+```
+## Finding writing rules
+- Keep each finding actionable and short.
+- Include only P0-P2 or explicit confirmation risks.
+- Do not include clean categories like "database OK" or "security OK".
+- Use evidence-driven wording: "schema changed but no migration file changed" is better than
+  "maybe migration missing".
+- If risk is ambiguous, say exactly what must be confirmed before release.
+- If no findings exist, omit the `Findings` table and write:
+  `No P0-P2 release blockers or confirmation items were found from the available repository evidence.`

package/bundled-skills/re-create/SKILL.md ADDED Viewed

@@ -0,0 +1,251 @@
+---
+name: re-create
+description: "Completely delete and rewrite a file or module from scratch when structural rot makes patching impossible."
+risk: critical
+source: community
+date_added: "2026-06-27"
+---
+# re-create — Controlled Erasure & Rebuild Protocol
+## Overview
+> Hollow Purple is Gojo's most destructive technique — blue and red combined into total erasure of the target. But Gojo doesn't use it carelessly. He knows exactly what he's erasing and why. Same here: this skill is the nuclear option, invoked only when patching is the wrong call, executed with full control over what gets erased and what must survive.
+Rewrites are dangerous not because rebuilding is hard, but because it is easy to silently erase behavior that was working and expected. This skill enforces a complete inventory of what must survive before a single line is deleted, and a full verification that everything survived after the rebuild.
+---
+## When to Use This Skill
+- Use when a file, module, or component needs to be completely deleted and rewritten from scratch
+- Use when structural rot is so deep that individual fixes would only make it worse
+- Use when accumulated technical debt makes the code unmaintainable
+- Use when the target is fundamentally broken and beyond saving
+- **DO NOT** use for partial refactors, single-function fixes, or targeted edits
+---
+## How It Works
+### PHASE 1 — Justify the Erasure
+The AI must prove that a full rewrite is necessary. It must answer all of the following:
+1. **What specifically is broken or unsalvageable?**
+   - Not "it's messy" — specific structural problems that make targeted fixes impossible or counterproductive
+2. **Why would targeted edits make things worse, not better?**
+   - Patching on top of rot, compounding complexity, architectural mismatch
+3. **What is the concrete cost of keeping the current implementation?**
+   - Maintenance burden, bug surface, performance, developer velocity
+If the AI cannot clearly answer all three, it must fall back to targeted edits instead of a rewrite. A rewrite is not a reward for messy code — it is a last resort.
+> **The bar is high.** "This code is ugly" does not justify hollow purple. "The architecture assumes X but the system now requires Y and every patch makes the mismatch worse" does.
+---
+### PHASE 2 — Read the Target Completely
+Before proposing deletion, the AI must read the entire target (file, module, or component) in full.
+The AI must identify and catalog:
+1. **Public interfaces** — functions, classes, types, or exports that other parts of the codebase call
+2. **Implicit contracts** — behaviors that other files depend on even if not formally typed
+3. **Working behaviors** — things the current implementation does correctly that must continue to work
+4. **Non-obvious logic** — edge cases, guards, or special handling that looks incidental but is intentional
+5. **Blast radius** — every file in the codebase that imports from or depends on the target
+> **The AI cannot skip this phase even if it has read the file before.** The purpose is not familiarity — it is building the Preservation List.
+---
+### PHASE 3 — Erasure Declaration (User Must Confirm)
+The AI outputs a complete erasure plan and **waits for user confirmation before deleting or writing anything.**
+```
+HOLLOW PURPLE — ERASURE PLAN
+─────────────────────────────────────────
+TARGET FOR ERASURE:
+  [file path or module name]
+WHY TARGETED FIXES ARE WRONG:
+  [specific justification — architectural rot, fundamental mismatch, etc.]
+PRESERVATION LIST (must survive the rewrite):
+  - [public interface / export 1] → [what it does, who depends on it]
+  - [public interface / export 2] → [what it does, who depends on it]
+  - [working behavior 1]          → [what it does, why it must be kept]
+  - [non-obvious logic 1]         → [what it guards against]
+BLAST RADIUS (files that depend on the target):
+  - [file path] → depends on [what specifically]
+  - [file path] → depends on [what specifically]
+NEW IMPLEMENTATION PLAN:
+  [Description of what the rebuild will look like — structure, approach, key decisions]
+WHAT WILL NOT BE PRESERVED:
+  [Anything intentionally dropped and why — dead code, deprecated behavior, etc.]
+─────────────────────────────────────────
+Confirm to proceed with erasure and rebuild.
+```
+> **Nothing is deleted until the user explicitly confirms.** A reply of "yes", "confirmed", "do it", or equivalent counts. Silence does not.
+---
+### PHASE 4 — Controlled Erasure
+User confirms → the target is deleted. Rules for this phase:
+- **Delete cleanly.** Not commented out, not renamed to `_old`, not archived in place — deleted.
+- **Delete only the declared target.** Nothing outside the declared scope is touched during erasure.
+- **Pause if scope expands.** If deletion reveals unexpected dependencies not in the blast radius list, the AI stops and reports before continuing.
+---
+### PHASE 5 — Rebuild Against the Preservation List
+The AI writes the new implementation. Rules:
+1. **Every item on the Preservation List is an obligation.** The rebuild is not complete until every preserved interface, behavior, and edge case is implemented and checked off.
+2. **Match the blast radius expectations.** Files that depended on the old implementation must be able to use the new one without changes — unless changes to dependent files were declared in Phase 3.
+3. **No bonus features.** The rebuild implements what was declared. New improvements, extra functionality, and cleanup of adjacent things are a separate task.
+4. **Follow existing codebase conventions.** The new implementation must use the same patterns, naming conventions, and style as the surrounding codebase — not whatever the AI prefers.
+The AI tracks preservation progress explicitly:
+```
+REBUILD PROGRESS
+─────────────────────────────────────────
+Preservation List:
+  ✓ [interface 1]         → implemented
+  ✓ [working behavior 1]  → implemented
+  ✗ [non-obvious logic 1] → pending
+─────────────────────────────────────────
+```
+---
+### PHASE 6 — Blast Radius Verification
+After the rebuild is complete, the AI checks every file in the blast radius:
+1. **Re-read each dependent file** and confirm it can still use the new implementation
+2. **Verify each dependency** — the function signatures, exports, and behaviors it relied on are present in the rebuild
+3. **Flag any breakage** — if a dependent file now has a mismatch, report it and propose a fix before declaring done
+Final verification report:
+```
+HOLLOW PURPLE — VERIFICATION
+─────────────────────────────────────────
+Preservation List:          ALL ITEMS ✓
+Blast radius files checked:
+  - [file] → ✓ compatible with new implementation
+  - [file] → ✓ compatible with new implementation
+New issues introduced:      NONE / [describe if found]
+─────────────────────────────────────────
+Status: CLEAN ✓  /  NEEDS FOLLOW-UP ⚠
+```
+---
+## Self-Ask Before Erasure
+The AI must answer all four before Phase 4 begins:
+| # | Question | Required |
+|---|---|---|
+| 1 | Have I read the entire target and built a complete Preservation List? | Yes — or read more |
+| 2 | Have I identified the full blast radius? | Yes — or search more |
+| 3 | Has the user confirmed the erasure plan? | Yes — or wait |
+| 4 | Is the erasure scoped exactly to what was declared? | Yes — or re-declare |
+---
+## Hard Rules (Never Violated)
+- **No deletion before user confirmation.** Ever.
+- **No deletion before the Preservation List is complete.** You cannot protect what you haven't inventoried.
+- **No "clean up while I'm at it" during rebuild.** The rebuild scope is exactly what was declared.
+- **No undeclared blast radius expansion.** If a dependent file wasn't in the list, stop and report it.
+- **No skipping Phase 6.** The rebuild is not done until blast radius files are verified.
+- **No rewrites disguised as refactors.** If more than 80% of a file is being changed, this protocol applies.
+---
+## What This Skill Prevents
+- Rewrites that silently drop working edge-case logic that wasn't documented
+- Rebuilds that break dependent files because their interfaces changed
+- Rewrites done for the wrong reason (style preference, boredom) when a targeted fix would have been better
+- Partial rebuilds that leave the codebase in a broken half-old-half-new state
+- Blast radius files breaking silently with no one noticing until runtime
+---
+## Quick Reference
+| Phase | Action | Deletes/Writes Code? |
+|---|---|---|
+| 1 — Justify | Prove erasure is necessary | ❌ No |
+| 2 — Read | Read target fully, build Preservation List | ❌ No |
+| 3 — Declare | Output erasure plan, wait for confirmation | ❌ No |
+| 4 — Erase | Delete the declared target | 🗑️ Deletes only |
+| 5 — Rebuild | Write new implementation against Preservation List | ✅ Writes |
+| 6 — Verify | Check Preservation List + blast radius | ❌ No |
+---
+## Security & Safety Notes
+- **Authorized Use Only:** This skill involves destructive capabilities (deleting files). Always ensure you have appropriate authorization and backups before triggering a full rebuild.
+- **Explicit Confirmation Required:** No code should ever be deleted without explicit user confirmation of the Erasure Plan.
+---
+## Examples
+### Example 1: Triggering a full module rewrite
+```text
+User: "The authentication module is beyond saving. Rewrite this from scratch."
+AI: [Outputs HOLLOW PURPLE — ERASURE PLAN]
+"Confirm to proceed with erasure and rebuild."
+User: "Confirmed."
+AI: [Executes Phase 4 and 5: Controlled Erasure and Rebuild against the Preservation List]
+```
+### Example 2: Erasure correctly rejected in Phase 1
+```text
+User: "This data formatting script is a mess, rewrite it from scratch."
+AI: [Evaluates Phase 1 criteria]
+"I cannot justify a full rewrite. While the code is messy, the structural rot is not deep enough to make patching impossible. The blast radius is limited, and targeted edits will improve it without the risk of erasing undocumented behaviors. I will proceed with surgical refactoring instead."
+```
+---
+## Trigger Phrases
+- "rewrite this from scratch"
+- "delete this and redo it"
+- "this is beyond saving / beyond repair"
+- "the whole module / component / file is broken"
+- "start over on this"
+- Any situation where patching would compound the problem rather than solve it
+---
+## Limitations
+- The AI must explicitly justify the rewrite and receive user confirmation before deleting anything.
+- The rebuild scope must exactly match what was declared (no bonus features or extra cleanup).
+- Does not apply to partial refactoring, single-function fixes, or targeted bug fixes.
+- It requires identifying the full blast radius upfront to avoid silently breaking dependencies.

package/bundled-skills/weaviate/SKILL.md ADDED Viewed

@@ -0,0 +1,132 @@
+---
+name: weaviate
+description: "Search, query, inspect, create, and import data into Weaviate vector database collections using official scripts and references."
+category: databases
+risk: critical
+source: community
+source_repo: weaviate/agent-skills
+source_type: official
+date_added: "2026-06-29"
+author: Weaviate
+tags: [weaviate, vector-database, semantic-search, hybrid-search, data-import]
+tools: [python, weaviate]
+license: "BSD-3-Clause"
+license_source: "https://github.com/weaviate/agent-skills/blob/main/LICENSE"
+---
+# Weaviate Database Operations
+This skill provides comprehensive access to Weaviate vector databases including search operations, natural language queries, schema inspection, data exploration, filtered fetching, collection creation, and data imports.
+## When to Use This Skill
+- Use when the user needs to inspect Weaviate collections, schemas, or data distribution.
+- Use when running semantic, hybrid, keyword, filtered, or Query Agent searches against Weaviate.
+- Use when importing CSV, JSON, JSONL, or PDF data into a Weaviate collection.
+- Use when creating example data or a collection for a Weaviate-backed workflow.
+### Weaviate Cloud Instance
+If the user does not have an instance yet, direct them to the cloud console to register and create a free sandbox. Create a Weaviate instance via [Weaviate Cloud](https://console.weaviate.cloud/signin?utm_source=github&utm_campaign=agent_skills).
+## Environment Variables
+**Required:**
+- `WEAVIATE_URL` - Your Weaviate Cloud cluster URL
+- `WEAVIATE_API_KEY` - Your Weaviate API key
+**External Provider Keys (auto-detected):**
+Set only the keys your collections use, refer to [Environment Requirements](references/environment_requirements.md) for more information.
+## Script Index
+### Search & Query
+- [Query Agent - Ask Mode](references/ask.md): Use when the user wants a **direct answer** to a question based on collection data. The Query Agent synthesizes information from one or more collections and returns a structured response with source citations (collection name and object ID).
+- [Query Agent - Search Mode](references/query_search.md): Use when the user wants to **explore or browse raw objects** across one or more collections. Unlike ask mode, this returns the actual data objects rather than a synthesized answer.
+- [Hybrid Search](references/hybrid_search.md): **Default choice for most searches.** Provides a good balance of semantic understanding and exact keyword matching. Use this when you are unsure which search type to pick.
+- [Semantic Search](references/semantic_search.md): Use for finding **conceptually similar content** regardless of exact wording. Best when the intent matters more than specific keywords.
+- [Keyword Search](references/keyword_search.md): Use for finding **exact terms, IDs, SKUs, or specific text patterns**. Best when precise keyword matching is needed rather than semantic similarity.
+### Collection Management
+- [List Collections](references/list_collections.md): Use to **discover what collections exist** in the Weaviate instance. This should typically be the first step before performing any search or data operation.
+- [Get Collection Details](references/get_collection.md): Use to **understand a collection's schema** — its properties, data types, vectorizer configuration, replication factor, and multi-tenancy status. Helpful before running searches or imports.
+- [Explore Collection](references/explore_collection.md): Use to **analyze data distribution, top values, and inspect actual content** in a collection. Helpful for understanding what data looks like before querying.
+- [Create Collection](references/create_collection.md): Use to **create new collections with custom schemas** before importing data. Do not specify a vectorizer unless the user explicitly requests one (the default `text2vec_weaviate` is used).
+### Data Operations
+- [Fetch and Filter](references/fetch_filter.md): Use to **retrieve specific objects by ID** or **strictly filtered subsets** of data. Best for precise data retrieval rather than search.
+- [Import Data](references/import_data.md): **Use this when the user asks to import, load, or ingest a file (CSV, JSON, JSONL, PDF) into a collection.**
+- [Create Example Data](references/example_data.md): Use to create example data for immediate use of other skills, if no data is available or user requests some toy data.
+## Recommendations
+1. **Start by listing collections** if you don't know what's available:
+   ```bash
+   uv run scripts/list_collections.py
+   ```
+2. **Ask the user** if they want to **create example data** if nothing is available and the user requests it. Otherwise continue.
+   ```bash
+   uv run scripts/example_data.py
+   ```
+3. **Get collection details** to understand the schema:
+   ```bash
+   uv run scripts/get_collection.py --name "COLLECTION_NAME"
+   ```
+4. **Explore collection data** to see values and statistics:
+   ```bash
+   uv run scripts/explore_collection.py "COLLECTION_NAME"
+   ```
+5. **Create a collection** if importing a new CSV, JSON, or JSONL file — the collection must exist before importing:
+   ```bash
+   uv run scripts/create_collection.py CollectionName \
+     --properties '[{"name": "title", "data_type": "text"}, {"name": "body", "data_type": "text"}]'
+   ```
+   > Do not specify a vectorizer unless the user explicitly requests one.
+6. **Import data** into an existing collection:
+   ```bash
+   uv run scripts/import.py "data.csv" --collection "CollectionName"
+   ```
+   > For PDF imports, the collection is created automatically — skip step 5.
+7. **Choose the right search type:**
+   - Get AI-powered answers with source citations across multiple collections → `ask.py`
+   - Get raw objects from multiple collections → `query_search.py`
+   - General search → `hybrid_search.py` (default)
+   - Conceptual similarity → `semantic_search.py`
+   - Exact terms/IDs → `keyword_search.py`
+## Output Formats
+All scripts support:
+- **Markdown tables** (default and recommended)
+- **JSON** (`--json` flag)
+## Error Handling
+Common errors:
+- `WEAVIATE_URL not set` → Set the environment variable
+- `Collection not found` → Use `list_collections.py` to see available collections
+- `Authentication error` → Check API keys for both Weaviate and vectorizer providers
+## Limitations
+- This skill requires a reachable Weaviate instance and valid credentials before live operations can succeed.
+- Data import, collection creation, and query-agent operations can change or expose user data; confirm the target instance and collection before running scripts.
+- The included scripts are Weaviate-focused and do not replace broader data-governance, backup, or production migration procedures.

package/bundled-skills/weaviate/references/ask.md ADDED Viewed

@@ -0,0 +1,36 @@
+# Query Agent - Ask Mode
+Generate AI-powered answers with source citations using the Weaviate Query Agent.
+## Usage
+```bash
+uv run scripts/ask.py --query "USER_QUESTION" --collections "Collection1,Collection2" [--json]
+```
+## Parameters
+| Parameter | Flag | Required | Default | Description |
+|-----------|------|----------|---------|-------------|
+| `--query` | `-q` | Yes | — | Natural language question |
+| `--collections` | `-c` | Yes | — | Comma-separated collection names to query across |
+| `--json` | — | No | `false` | Output in JSON format |
+## Output
+- **Default**: Markdown-formatted answer with a sources table
+- **JSON**: Structured response with `answer` and `sources` fields
+## Examples
+Ask a question across multiple collections:
+```bash
+uv run scripts/ask.py --query "What are the main topics in the dataset?" --collections "Articles,Reports"
+```
+JSON output:
+```bash
+uv run scripts/ask.py --query "Summarize recent findings" --collections "Research" --json
+```

package/bundled-skills/weaviate/references/create_collection.md ADDED Viewed

@@ -0,0 +1,152 @@
+# Create Collection
+Create a new Weaviate collection with a custom schema, optional vectorizer, and multi-tenancy support.
+## Usage
+```bash
+uv run scripts/create_collection.py CollectionName --properties '[...]' [--description "..."] [--vectorizer "..."] [--replication-factor N] [--multi-tenancy] [--auto-tenant-creation] [--json]
+```
+## Parameters
+| Parameter | Flag | Required | Default | Description |
+|-----------|------|----------|---------|-------------|
+| `name` | — | Yes (positional) | — | Collection name (auto-capitalized per GraphQL convention) |
+| `--properties` | `-p` | Yes | — | JSON array of property definitions |
+| `--description` | `-d` | No | — | Collection description — **strongly recommended**. Weaviate agents (Query Agent, Personalization Agent) read this to understand what the collection contains and decide which collection to query |
+| `--vectorizer` | `-v` | No | `text2vec_weaviate` | Vectorizer module to use |
+| `--replication-factor` | `-r` | No | — | Replication factor (defers to server default when not set) |
+| `--multi-tenancy` | `-m` | No | `false` | Enable multi-tenancy for data isolation |
+| `--auto-tenant-creation` | `-a` | No | `false` | Auto-create tenants on insert (requires `--multi-tenancy`) |
+| `--json` | — | No | `false` | Output in JSON format |
+## Property Definition Format
+```json
+{
+  "name": "property_name",
+  "data_type": "text",
+  "description": "Optional description",
+  "tokenization": "word",
+  "index_filterable": true,
+  "index_searchable": true,
+  "index_range_filters": false,
+  "nested_properties": []
+}
+```
+- `name` (required): Property name
+- `data_type` (required): One of the supported data types below
+- `description` (optional): Human-readable description — **strongly recommended**. The Query Agent reads property descriptions to understand your schema, choose the right collection, and construct accurate queries. Good descriptions include units, formats, and valid values (e.g., `"Price in US dollars (USD)"`, `"ISO two-character country code"`, `"Date the paper was published on arXiv"`)
+- `tokenization` (optional): For text types — `word`, `lowercase`, `whitespace`, or `field`
+- `index_filterable` (optional): Enable roaring-bitmap filter index for `where` clauses. Default `true` for all types except `blob`, `geoCoordinates`, `object`, `object[]`, `phoneNumber`
+- `index_searchable` (optional): Enable BM25/inverted index for keyword and hybrid search. Only applies to `text` and `text[]`. Default `true`
+- `index_range_filters` (optional): Enable range-comparison index (`>`, `<`, `>=`, `<=`, `between`) for `int`, `int[]`, `number`, `number[]`, `date`, `date[]`. Default `false` — **set to `true` for any numeric or date field you plan to range-filter**
+- `nested_properties` (optional): For `object` / `object[]` types — array of nested property definitions
+## Supported Data Types
+`text`, `text[]`, `boolean`, `boolean[]`, `int`, `int[]`, `number`, `number[]`, `date`, `date[]`, `uuid`, `uuid[]`, `geoCoordinates`, `phoneNumber`, `blob`, `object`, `object[]`
+Aliases: `bool` → `boolean`, `bool[]` → `boolean[]`
+## Supported Vectorizers
+`text2vec_weaviate`, `text2vec_openai`, `text2vec_cohere`, `text2vec_huggingface`, `text2vec_palm`, `text2vec_jinaai`, `text2vec_voyageai`, `text2vec_contextionary`, `text2vec_transformers`, `text2vec_gpt4all`, `text2vec_ollama`, `multi2vec_clip`, `multi2vec_bind`, `multi2vec_palm`, `img2vec_neural`, `ref2vec_centroid`, `none`
+## Inferring Schema from Data Files
+Before creating a collection, inspect a few rows from the source file to understand field names and value types. Use the commands below — they read only the first 3 objects and are safe on large files.
+**CSV:**
+```bash
+python3 -c "
+import csv, json
+with open('data.csv') as f:
+    rows = list(csv.DictReader(f))[:3]
+print(json.dumps(rows, indent=2))
+"
+```
+**JSON:**
+```bash
+python3 -c "
+import json
+print(json.dumps(json.load(open('data.json'))[:3], indent=2))
+"
+```
+**JSONL:**
+```bash
+python3 -c "
+import json
+lines = []
+with open('data.jsonl') as f:
+    for line in f:
+        if len(lines) >= 3: break
+        if line.strip(): lines.append(json.loads(line))
+print(json.dumps(lines, indent=2))
+"
+```
+From the sample, map each field to a Weaviate data type:
+| Value looks like | data_type |
+|---|---|
+| `"hello"`, any text | `text` |
+| `123`, `"123"` | `int` |
+| `1.5`, `"1.5"` | `number` |
+| `true`/`false` | `boolean` |
+| `"2024-01-15"`, `"2024-01-15T10:30:00Z"` | `date` |
+| UUID-shaped string | `uuid` |
+| List of strings | `text[]` |
+| List of numbers | `int[]` or `number[]` |
+| Nested object | `object` |
+**Important:** `id`, `_id`, and `_additional` are reserved by Weaviate — never use them as property names. If they appear in your data, use `--skip-fields` or `--mapping` in `import.py` to handle them.
+## Examples
+Basic collection:
+```bash
+uv run scripts/create_collection.py Article \
+  --description "News articles with title and full body text." \
+  --properties '[
+    {"name": "title", "data_type": "text", "description": "Title of the article"},
+    {"name": "body", "data_type": "text", "description": "Full text body of the article"}
+  ]'
+```
+Collection with various data types, descriptions, and recommended index flags:
+```bash
+uv run scripts/create_collection.py Product \
+  --description "E-commerce product catalog with pricing, brand, stock status, and tags." \
+  --properties '[
+    {"name": "name", "data_type": "text", "description": "Name or title of the product"},
+    {"name": "sku", "data_type": "text", "index_searchable": false, "description": "Stock-keeping unit identifier"},
+    {"name": "price", "data_type": "number", "index_range_filters": true, "description": "Product price in US dollars (USD)"},
+    {"name": "created_at", "data_type": "date", "index_range_filters": true, "description": "Date the product was added to the catalog"},
+    {"name": "in_stock", "data_type": "boolean", "description": "Whether the product is currently in stock"},
+    {"name": "tags", "data_type": "text[]", "description": "List of descriptive tags for the product"}
+  ]'
+```
+With explicit vectorizer:
+```bash
+uv run scripts/create_collection.py Article \
+  --description "News articles with title and full body text." \
+  --properties '[{"name": "title", "data_type": "text", "description": "Title of the article"}]' \
+  --vectorizer "text2vec_openai"
+```
+With multi-tenancy:
+```bash
+uv run scripts/create_collection.py Workspace \
+  --properties '[{"name": "content", "data_type": "text"}]' \
+  --multi-tenancy --auto-tenant-creation
+```