Skills: Getting Your Opinions Back

Skills are the backbone of working with Claude. A skill is a horizontal talent you want applied to a session: not a command you trigger, not an agent that acts on your behalf, but instructions that get pulled in just in time. The mechanism is simple and worth seeing. When Claude Code starts it loads your agents.md, then scans .claude/skills/, reading the name and description out of each SKILL.md. When you type a prompt, part of its thinking is matching that prompt against those descriptions, and if one fits, the skill gets loaded. Nothing magic, just text.

The question is whose text. Any skill you can think of has already been made, and when I asked for Postgres best practices Claude went and fetched the Supabase skill, an index SKILL.md with a pile of reference files behind it. It's good work, and if you don't know Postgres it has your back. But I happen to know a lot about full text search, and their advanced full text search reference does the thing everyone does: throw an English dictionary at everything. Stem a list of names and Troy Hunt shows up when someone searches for "hunting". Names, tags, cities and SKUs need the simple dictionary, concatenated with English in both the tsvector and the query, and the literal matches should rank higher. I want that opinion in a skill, so I dictate one with Wispr Flow.

I am very particular about how I like full text search engines to work with Postgres. I don't want to get too detailed on it, but straight away, if I'm working with a blob of text or a large corpus of text, the English dictionary is fine. However, if I'm working with things like names, tags, locations, cities, countries, or things that are literal values, I want to use a simple dictionary. That means for the index to work correctly, I need to concatenate the English catalog with the simple catalog for the search to be effective. This applies to both the queries and also the tsvector work. So what I want you to do is to create a Postgres skill for me that is aware of these things. Go online and research the Postgres documentation for what I'm talking about to make sure that this skill is complete. That's step one. Step two is to go into the Supabase Postgres best practices and supersede their advanced full text search. Maybe inside of the SKILL.md, say that when I'm working with full text searches, favor mine.

Opus 5.5 builds postgres-full-text-search and drops an override into the Supabase skill (it warns me the change won't go upstream, which is exactly right). I forgot to ask for ranking, which it added anyway. Then the real test: a vague prompt with no mention of the skill, to see if Claude picks it up on its own. The last two sentences are the guardrail I tack on so it shows me code instead of doing work.

I want to understand how full text indexing works with Postgres. Say I have a typical table for a product catalog that has a short summary, a long description, a set of tags, a name and a SKU. Let's go with that. And you can kind of just make it up for now. Show me what the command would look like to index that table, and then show me what the query would look like. Don't do any actual work. I just want to see what the code would look like.

It loads the skill through the Skill tool (your first look at tools, more on those later), and the index it writes uses to_tsvector with the simple dictionary for SKU and name and English for summary and description, and the query uses websearch_to_tsquery with the catalogs concatenated and ranked. That is exactly what I would have written, and I never had to ask. That's the power of skills: you get your opinions back, every time. Whether you use other people's skills, your own, or split them into fine-grained pieces you combine (a BDD skill plus an Elixir skill, say) is an art form I'm leaving to you. If you want the search approach itself, I wrote it up on Medium back in 2022 and there's a video on my YouTube channel where you can watch me stumble through it with the sci-fi Stack Exchange database.