Agentic skills

Some tables in this database came from a legacy load and are named with the prefix `eval_lt_`. Find every table whose name starts with `eval_lt_` and report them. This is a read-only check. End your answer with one line per table, each of exactly this form:

TABLE: <table_name>

Give me an overview of the `eval_describe` table: its columns with their types, and how many rows it holds. This is a read-only check — do not modify anything. End your answer with one line per column, then two final lines, of exactly these forms. Write each `<type>` exactly as the API reports it, not as a synonym; for a nested type, write the outer type name with its element type and length in angle brackets (a 4-element vector of 8-bit ints would read `fixed_size_list<int8, 4>`):

COLUMN: <column_name> = <type>
ROWS: <row_count>
COLUMNS: <number_of_columns>

How is the `eval_table_stats` table laid out in storage? Report its total size on disk and its fragment layout. This is a read-only check. End your answer with two lines of exactly this form:

BYTES: <total_size_in_bytes>
FRAGMENTS: <number_of_fragments>

Create a new table called `eval_created_products` in this database with three columns: `sku` (string), `name` (string), and `price` (float64). Populate it with exactly these 4 rows:

| sku | name | price |
|---------|------------------|--------|
| SKU-001 | Espresso Machine | 249.99 |
| SKU-002 | Milk Frother | 39.5 |
| SKU-003 | Coffee Grinder | 89.0 |
| SKU-004 | Digital Scale | 24.95 |

Create a new, empty table called `eval_empty_events` in this database, ready for an event-logging pipeline to start writing into later. It needs three columns: `event_name` (string), `severity` (int64), and `payload` (string) — and no rows yet.

The `eval_drop_me` table was created by a test run and is no longer needed. Drop it from the database — and nothing else.

My current DB has these 5 tables that join; how should I set up my tables in LanceDB?

```
products    (product_id BIGINT PK, name TEXT, description TEXT, price NUMERIC(10,2), category_id BIGINT FK, brand_id BIGINT FK)
categories  (category_id BIGINT PK, name TEXT)
brands      (brand_id BIGINT PK, name TEXT, country TEXT)
reviews     (review_id BIGINT PK, product_id BIGINT FK, rating SMALLINT, body TEXT)
order_items (order_id BIGINT, product_id BIGINT FK, quantity INT, unit_price NUMERIC(10,2))
```

In LanceDB the app will run one query: semantic search over product descriptions, filtered by category name and brand name, where every hit shows the product's name, price, category name, brand name, and average review rating. Order analytics stays in our warehouse. Description embeddings are 384-dimensional float32 vectors.

Set the tables up in this database as you recommend: create them empty (schema only, no rows). Name the table the product search runs against `eval_schema_search`, and give any other table you create the `eval_schema_` prefix. Explain your design in your answer.

Append these 5 new products to the `eval_insert_rows` table (the embedding columns can be left null):

| id | title | category | price_usd | relevance_score |
|-----|--------------|-----------|-----------|-----------------|
| 100 | Clearance A | clearance | 9.99 | 0.1 |
| 101 | Clearance B | clearance | 10.99 | 0.1 |
| 102 | Clearance C | clearance | 11.99 | 0.1 |
| 103 | Clearance D | clearance | 12.99 | 0.1 |
| 104 | Clearance E | clearance | 13.99 | 0.1 |

All 'toys' products have been discontinued. Delete every row in category `toys` from the `eval_delete_rows` table — and nothing else.

The `eval_purge` table was loaded from a corrupted export and every row in it is suspect. Clear out all of its rows — but keep the table itself (and its schema) in place so it can be reloaded.

Editorial flagged every 'books' product in the `eval_update_rows` table for re-review: set `relevance_score` to 0 for all rows in category `books`. Don't touch any other rows.

Run a flash sale on the `eval_discount` table: cut the price of every product in category `electronics` by 10% — each one's `price_usd` becomes 90% of its current value. Leave every other category's prices alone.

Sync the `eval_upsert` table with this batch of refurbished products, matching on `id`: update the row if the id already exists, insert it if not — as one upsert operation, not separate update and insert passes. The embedding columns can be left null.

| id | title | category | price_usd | relevance_score |
|-----|-----------------------|----------|-----------|-----------------|
| 2 | Refurbished Product 2 | refurb | 19.99 | 0.5 |
| 6 | Refurbished Product 6 | refurb | 29.99 | 0.5 |
| 200 | Refurb Special A | refurb | 15.0 | 0.5 |
| 201 | Refurb Special B | refurb | 18.0 | 0.5 |

Analytics needs integer cents. Add a `price_cents` integer column to the `eval_add_column` table, backfilled for every existing row as the price in cents (`price_usd` × 100, rounded to the nearest integer).

Rename the `price_usd` column of the `eval_rename_column` table to `price`, in place, keeping the data — do not rebuild or rewrite the table.

The legacy `image_clip_v1` embedding column of the `eval_drop_column` table is superseded and wasting storage. Remove that column — keep everything else.

Downstream tooling needs 64-bit floats: change the type of the `relevance_score` column in the `eval_cast_column` table from float32 to float64, in place, keeping the values.

Make sure my ingest pattern will be performant. My ingest script is `ingest.py` in your working directory; it creates the table `eval_ingest_events` in this database and loads the day's 1,000 events into it. Fix whatever would make the ingest slow or hurt the table, keeping the same table name, schema, and rows, then run it against this database so the table ends up holding exactly those 1,000 events.

How many products in the `eval_filter_count` table are in category `books` with a price above $100? This is a read-only check. End your answer with a line of exactly this form:

COUNT: <n>

Which products in the `eval_filter_ids` table are in category `electronics` and priced under $50? This is a read-only check. End your answer with one line per matching product, each of exactly this form:

ID: <id>

Look up the product with id 12 in the `eval_lookup_row` table and report its title. This is a read-only check. End your answer with a line of exactly this form:

TITLE: <title>

What are the 3 cheapest products in the `eval_cheapest` table? This is a read-only check. End your answer with a line of exactly this form, ids ordered from cheapest up:

CHEAPEST: <id>,<id>,<id>

Our storefront lists the `eval_pagination` table's products cheapest-first, 3 to a page. A customer is looking at page 2 — which products do they see? This is a read-only check. End your answer with a line of exactly this form, the three ids in display (price-ascending) order:

PAGE2: <id>,<id>,<id>

I have a LanceDB table called `eval_pick_column`. I want to let users upload a photo and find visually similar products. Which column should the similarity search run against? If there's more than one candidate, tell me which one to use and why. This is a read-only check — do not modify the table, its rows, or its metadata. End your answer with a line of exactly this form, naming the single column to use:

RECOMMENDATION: <column_name>

A shopper is viewing product 5 in the `eval_vector_search` table and we want a 'similar items' shelf. Using product 5's `image_clip_v2` embedding as the query, find the single most visually similar OTHER product. This is a read-only check. End your answer with a line of exactly this form:

MATCH: <id>

Same 'similar items' feature, but constrained to a department: using product 8's `image_clip_v2` embedding as the query on the `eval_vector_filtered` table, find the single most similar product in category `books` (product 8 itself is not in that category). This is a read-only check. End your answer with a line of exactly this form:

MATCH: <id>

A customer remembers a product description mentioning 'waterproof'. Using full-text search on the `eval_fts_search` table, find which product that is. This is a read-only check. End your answer with a line of exactly this form:

MATCH: <id>

Marketing wants a list of every product in the `eval_fts_multi` table whose description mentions 'wireless'. Use full-text search to find them all. This is a read-only check. End your answer with one line per matching product, each of exactly this form:

ID: <id>

Find the product in the `eval_hybrid_search` table most relevant to a shopper who typed the keyword 'solar' and whose taste profile is product 4's `image_clip_v2` embedding — i.e. combine keyword relevance and vector similarity (a hybrid search). This is a read-only check. End your answer with a line of exactly this form:

MATCH: <id>

Before we ship a price filter on the `eval_explain_plan` table, confirm from the server's query plan whether a filter on `price_usd` (for example `price_usd < 50`) is served by an index or by scanning the table. This is a read-only check — do not build or drop anything. End your answer with exactly one of these lines:

PLAN: index
PLAN: scan

Queries that filter the `eval_build_index` table by `category` are slow. Build the appropriate index to speed them up.

Vector similarity queries against the `image_clip_v2` column of the `eval_vector_index` table are running as brute-force scans. Build an ANN index on that column using cosine distance, and make sure it finishes building.

Enable keyword (full-text) search over the `body_text` column of the `eval_fts_index` table, and make sure the index finishes building.

Audit the indexes on the `eval_index_report` table: what indexes exist, and how many rows does the index on `category` cover? This is a read-only check. End your answer with one line per index plus one final line, of exactly these forms:

INDEX: <index_name>
INDEXED_ROWS: <rows covered by the category index>

The scalar index on `price_usd` of the `eval_index_coverage` table was built a while ago, and data has landed in the table since. Check the index's coverage: how many rows does it currently cover, and how many rows are not yet indexed? This is a read-only check — do not rebuild or modify anything. End your answer with two lines of exactly this form:

INDEXED: <rows covered by the index>
UNINDEXED: <rows not yet covered>

The index on `price_usd` in the `eval_drop_index` table was an experiment and is slowing down writes. Drop that index.

How many versions does the `eval_versions` table have? This is a read-only check — do not create new versions. End your answer with a line of exactly this form:

VERSIONS: <n>

Without modifying the `eval_timetravel` table, compare it to its past: how many rows did it have at version 1, and how many does it have now? End your answer with two lines of exactly this form:

THEN: <rows at version 1>
NOW: <rows now>

Someone ran a bad cleanup against the `eval_restore` table and rows went missing. Roll the table back to the version immediately before the deletion, so the missing rows are back.

We're about to run a risky migration on the `eval_tag_create` table. Tag its current version as `prod-baseline` so we can refer back to it later.

The `eval_tag_read` table's version tagged `release-v1` is what we shipped. Without modifying the table, compare then and now: how many rows did it have at the `release-v1` tag, and how many does it have now? End your answer with two lines of exactly this form:

TAGGED: <rows at the release-v1 tag>
NOW: <rows now>

The `latest` tag on the `eval_tag_move` table still points at an old version, but the table has moved on since. Update the `latest` tag so it points at the table's current version. Leave any other tags alone.

The `deprecated` tag on the `eval_tag_delete` table is obsolete. Remove that tag — leave any other tags alone.

Compare version 3 and version 7 of the `eval_history_compare` table and explain, in plain English, what happened to it in between — cover the schema, the indexes, and the data. This is a read-only investigation: do not modify the table.

Report only what changed AFTER version 3, up to and including version 7 — version 3 is the starting point, so whatever happened at version 3 itself is not one of the changes.

End your answer with three lines of exactly these forms. The first two are comma-separated lists of column names (or NONE): the columns added in that range, and the columns that gained an index in that range. The third is exactly one of the five words offered, describing the row-level data changes in that range:

COLUMNS_ADDED: <column_name>[, <column_name>...]
INDEXES_ADDED: <column_name>[, <column_name>...]
DATA_CHANGES: APPEND_THEN_DELETE | DELETE_THEN_APPEND | APPEND_ONLY | DELETE_ONLY | NONE

Our last schema review of the `eval_history_since` table signed off at {cutoff}. Did any schema or index changes happen to that table since then? Explain in plain English what you find, and say which changes were not schema or index changes so we know they were considered. This is a read-only investigation: do not modify the table.

This table also has columns and indexes that predate that timestamp — those are not what the review is asking about, so report only what changed at or after it.

End your answer with four lines of exactly these forms: every table version at or after that timestamp that changed the schema or an index — version numbers only, comma-separated, ascending (or NONE); the column added by a schema change at or after that timestamp (or NONE); the column covered by an index built at or after that timestamp (or NONE); and every table version at or after that timestamp whose change was NOT a schema or index change — version numbers only, comma-separated, ascending (or NONE):

CHANGED_VERSIONS: <version>[, <version>...]
COLUMN_ADDED: <column_name>
INDEX_ADDED: <column_name>
OTHER_CHANGES: <version>[, <version>...]

Someone added a column called `foo` to the `eval_history_column_job_{db}` table and nobody wrote down why. Find the exact version where `foo` appeared, then find the background job that was pinned to that same table version and report what it is doing and its current state. There are several jobs on this table, pinned to different versions of it, so make sure the one you report is the one pinned to that version. This is a read-only investigation: do not cancel or modify anything.

End your answer with four lines of exactly these forms (full job id, no truncation). Write `<job_type>` and `<current_state>` exactly as the API reports them, not as synonyms or prose:

VERSION: <version_number>
JOB: <job_id>
TYPE: <job_type>
STATE: <current_state>

Document the two image-embedding columns in the `eval_add_metadata` table: write a clear description for each, tag each with its field type, the model that produced it, and its version, mark the newer one as the latest, and group both under a single logical column.

The `model` tag on the `image_clip_v1` column of `eval_delete_metadata` is wrong. Remove just that tag — leave the column's description and other tags alone.

Some columns in the `eval_lin_origin` table were generated by the platform rather than loaded with the data. Investigate the column `title_sentiment`: is it produced by a UDF or by a SQL expression, what produces it, and which columns does it read? This is a read-only investigation: do not modify the table.

End your answer with lines of exactly these forms — one INPUT line per input column. Write the generator exactly as the table's own metadata records it (the UDF's registered name, or the SQL expression), not a paraphrase:

KIND: <udf or expression>
GENERATOR: <udf name or SQL expression>
INPUT: <input_column_name>

We want to drop the `price_usd` column from the `eval_lin_deps` table, but some of the table's generated columns are derived from other columns. Find every column that depends on `price_usd` — directly, or indirectly through another generated column. This is a read-only investigation: do not modify the table.

End your answer with one line per dependent column, each of exactly this form (do not list `price_usd` itself):

DEPENDENT: <column_name>

The generated column `discounted_price` in the `eval_lin_job_{db}` table is filled in by a background refresh job, and we need to know which job that is. There is more than one job on this table (a long-lived database can also hold finished or cancelled leftovers), so make sure the one you report is the currently-running job that refreshes `discounted_price`. This is a read-only investigation: do not cancel or modify anything.

End your answer with three lines of exactly these forms (full job id, no truncation). Write `<job_type>` and `<current_state>` exactly as the API reports them, not as synonyms or prose:

JOB: <job_id>
TYPE: <job_type>
STATE: <current_state>

Create a namespace called `analytics` in this database, ready for new tables to be organized under it.

Under the `staging` namespace of this database, create a table called `sessions` with columns `session_id` (string) and `duration_s` (float64), holding exactly these 2 rows:

| session_id | duration_s |
|------------|------------|
| a1b2 | 12.5 |
| c3d4 | 3.25 |

What tables live inside the `warehouse` namespace of this database? This is a read-only check. End your answer with one line per table, each of exactly this form:

TABLE: <table_name>

Our SRE dashboards read from the `ops` namespace of this database, which holds a `latency` table of per-service p99 latency readings. Which service has the highest `p99_ms`, and what is that value? This is a read-only check. End your answer with two lines of exactly this form:

SERVICE: <service_name>
P99: <p99_ms value>

Create a branch called `experiment-reindex` on the `eval_create_branch` table, off its current state.

Switch to the `wip-branch` branch of the `eval_switch_branch` table and add a description to its `category` column. The change should land on `wip-branch`, not on main.

The `ready-to-cherry-pick` branch of the `eval_cherry_pick` table has been reviewed and approved. Cherry-pick it onto main so its changes land on the main table.

We no longer need the `stale-2024` branch on the `eval_delete_branch` table. Delete it.

What jobs are currently running against the `eval_job_list_{db}` table? Give each one's type and current state. This is a read-only check — do not cancel or modify anything. End your answer with one line per currently-running job, each of exactly this form (full job id, no truncation). Write `<job_type>` and `<current_state>` exactly as the API reports them, not as synonyms or prose — a compaction job that had failed would read `RUNNING: j1-xy-0ab-cdef | table_compaction | failed`:

RUNNING: <job_id> | <job_type> | <current_state>

An automated maintenance job was recently started against the `eval_job_describe_{db}` table. Find it and report what kind of job it is and its current status. Do not cancel or modify it. End your answer with lines of exactly these forms (full job id, no truncation). Write the type and state exactly as the API reports them, not as synonyms or prose — a compaction job that had failed would read `TYPE: table_compaction` and `STATE: failed`:

JOB: <job_id>
TYPE: <job_type>
STATE: <current_state>

A cache-prewarm job against the `eval_job_cancel_{db}` table is hogging resources. Cancel it, and leave every other job alone. End your answer with a line of exactly this form (the full id of the job you cancelled, no truncation):

CANCELLED: <job_id>

Set up a small semantic-search demo from scratch in this database. Create a new table called `eval_embed_search` with exactly three columns: `id` (int64), `text` (string), and `embedding` — a fixed-size vector of floats holding an embedding of `text`, computed with the `all-MiniLM-L6-v2` sentence-transformers model (embed each `text` exactly as written; use that same model for every row and for the query below). Populate it with exactly these 8 rows:

| id | text |
|----|------|
| 1 | Espresso machine with a 15-bar pump for rich, crema-topped coffee |
| 2 | Burr coffee grinder for fresh, evenly ground espresso beans |
| 3 | Pour-over coffee kettle with a gooseneck spout for slow brewing |
| 4 | Reusable coffee filter for drip brewers and pour-over cones |
| 5 | Waterproof hiking boots for rocky mountain trails |
| 6 | Lightweight hiking backpack with a hydration sleeve for day trails |
| 7 | Trekking poles for steep mountain trail descents |
| 8 | Merino wool hiking socks for long days on the trail |

Then run two vector searches against the table, both using cosine distance: (1) a 'similar items' search using row 2's own stored embedding as the query, returning the 3 nearest OTHER rows; (2) a text search — embed the query `gear for a mountain hike` with the same model and return the 3 nearest rows. End your answer with two lines of exactly this form, ids comma-separated, nearest first:

NEAREST: <id>,<id>,<id>
QUERY_HITS: <id>,<id>,<id>

The `eval_index_all` table is about to back our product search page. The page will run: visual similarity search on the `image_clip_v2` embeddings (cosine distance), keyword search over `body_text`, exact-match filters on `category`, and range filters on `price_usd` — often combined with the searches. Today the table has no indexes at all. Build all the indexes this table will need to make search fast, and make sure every one of them finishes building. Don't build indexes the page won't use — each one costs build time and slows writes — and note that `image_clip_v1` is a legacy column nothing queries anymore. Do not modify the table's rows or schema.

We're choosing an embedding model for the `body_text` column of the `eval_embed_branches` table (24 product descriptions) and want to compare 3 candidates side by side without touching the production data. The candidates: `all-MiniLM-L6-v2`, `bge-small-en-v1.5`, and `gte-small`. Run the experiment on branches: for each candidate, create a branch of the table off main and, on that branch only, add a fixed-size float vector column called `body_embedding` holding that model's embedding of every row's `body_text` (embed the text exactly as stored). Then run the same search on each branch, using cosine distance — the 3 products most similar to the query `a paperback novel to read on the beach`, embedded with that branch's model — so we can compare what each model returns. Main must be left exactly as it is: no new column, no new rows, no other writes. End your answer with one line per branch, each of exactly this form (the model named the way its provider does, e.g. `all-MiniLM-L6-v2`; the three ids comma-separated, most similar first):

BRANCH: <branch_name> | <embedding_model> | <id>,<id>,<id>

Convert this Parquet dataset to Lance and add a vector column from the description field. The dataset is `products.parquet` in your working directory. Load it into a new table called `eval_parquet_products` in this database, keeping every Parquet column and row exactly as they are, and add a column `description_embedding`: a fixed-size vector of floats holding an embedding of each row's `description`, computed with a text-embedding model of your choice (the same model for every row).