The usual way I used to find an agent skill was to search for a word I already knew. "slides". "frontend". "review". The results looked relevant, and I installed whatever name I recognized first. Then I spent the next half hour discovering that the skill was built for a neighbouring job: a deck generator when I needed a PDF, a design helper when I needed a React review, a writing polish skill when I needed a repository guide.
The problem was not that skills were hard to find. It was that I was searching by a label, not by the job I wanted to finish.
I now start the other way around. I write one sentence about the task, then I browse by topic. SkillHey Topics is built for that order. SkillHey is a curated library of 1,000+ AI agent skills. The Topics hub splits them into 23 lanes — development, design, writing, research, documents, images, video, and others — and then into more focused paths. Each skill page shows what the skill does, the source repository, when the repository was last updated, the install command, and the agents each author lists, such as Claude Code, Codex and Cursor.
This article walks through that habit with two lanes I use constantly: development and documents.
Start with a sentence, not a keyword
A keyword is too wide. "Documents" can mean a slide deck, a PDF, a Word file, a spreadsheet, or a Markdown file that still needs styling. "Frontend" can mean building a new interface, checking an existing component, or reviewing a React tree. If I search with those words, I get a mixed list and I start comparing names instead of outputs.
A sentence forces the output into the open:
- "Turn this technical note into a 12-page deck."
- "Review this React app for accessibility and performance issues."
- "Build two layout variants of this settings page and compare them."
Once the sentence exists, I open the Topics hub and pick a lane. I do not start in the global search box. The hub's job is to show the work a lane covers and the paths inside it. That is usually enough to stop me from installing the wrong neighbour.
Development: decide whether you are building a UI or reading a codebase
The Development lane is the widest one on the hub. Under it are paths for frontend work, APIs and backends, the terminal, refactoring, architecture, databases, React and Next.js, and more. If I stay on the parent page and click whatever looks familiar, I am back to keyword shopping.
So I ask a narrower question. If the sentence is about a page, a component, or turning a mockup into an interface, I go to Frontend Development. The path is about building and maintaining web frontends: React and Vue practices, CSS tools, component libraries, and component checks.
A few examples from that page show why the path matters. Impeccable is a frontend design skill for typography, layout, accessibility, responsive behaviour and iterating in the browser. Variant: UI Alternatives builds more than one component variant in the real page so you can compare trade-offs. React Doctor scans a React project for correctness, accessibility, architecture and performance findings, then follows the upstream workflow to work through them.
Those skills all sit near "frontend", but they are not interchangeable. One helps you shape an interface, one helps you compare options in place, and one helps you inspect a codebase you already have. If my actual sentence is "understand this repository before I change it", I leave the frontend path and look at codebase understanding, refactoring, or code review instead.
Before installing, I still read the skill page: the description, the source repository, the last push date, the install command, and the agents the author lists. Topics organizes the choice. It does not replace that reading.
Documents: name the file you need to hand over
Document work fails in a similar way. People ask an agent to "handle the document" and then wonder why they got a web slideshow when they needed a PDF, or a Markdown conversion when they needed a spreadsheet with checked formulas.
I open Documents and look at the paths: conversion and reports, presentations, PDF, Markdown, Word, OCR, and spreadsheets. If the sentence is about a talk or a review meeting, I continue to Presentation & Slides.
Frontend Slides is for building animated HTML presentations with a coding agent, including visual previews and turning an existing PowerPoint file into a web deck. Codex PPT takes articles, reports, papers and outlines and turns them into a visually consistent PPTX. If the job is a spreadsheet, Excel Spreadsheets (from Anthropic) is about creating and editing sheets with explicit assumptions, consistent formulas, formatting and recalculation checks. If the job is to style Markdown for publishing, Markdown to HTML converts the source into styled HTML and keeps code, math and diagrams.
Again, every one of these is a document skill. The useful distinction is the deliverable. Once I name that deliverable, the path is obvious, and the skill page is there to confirm the input and output.
A short routine I reuse
The habit now looks like this:
- Write one sentence that includes the deliverable, not only the domain.
- Open SkillHey Topics, pick a lane, then a path.
- Read two or three skill pages in that path and compare what they actually do.
- Check the source repository, when it was last updated, the install command, and the agents the author lists. Then install.
I still get skills wrong sometimes, usually when my sentence was vague. The Topics hub does not judge a skill for my repository. It just makes the job visible before I install anything. If you have a different way of choosing a skill, I would like to hear it: do you start with the task, or with a name you already know?
Disclosure: I am part of the SkillHey team.
Top comments (0)