# You don't need to remember 22 command names — the AI already knows them

> Over the past month or so I've built 22 slash commands that automate different parts of my documentation workflow with OpenCode. But at some point around command number 15, I noticed that I didn't know what commands I had. So I built an automated system that lets the AI discover commands for me and suggests the best one bases on intent.

_Published March 5, 2026 · https://marcioflorindo.com/blog-discovery-system.html_

Here is something I hadn't thought about when I started building custom commands for OpenCode: the more you build, the harder they are to find.

Over the past month or so I've built 22 slash commands that automate different parts of my documentation workflow: research, drafting, auditing, reviewing, renaming, triaging, and more. Each command solves a real problem. But at some point around command number 15, I noticed that I didn't know what commands I had. I even realized that I was describing tasks to the AI when I already had a command for exactly that task.

If that was happening to me (the person who built all of them), it was going to be worse for anyone else on my team. And with other people starting to contribute commands to the shared repo, this was only going to get worse.

If you are not familiar with OpenCode, it is an [open-source AI coding agent](https://opencode.ai/) that runs in the terminal. It supports custom slash commands, reusable skill files, and MCP tool integrations, which is what makes this kind of automation possible.

So I built a system that lets the AI discover commands for you.

## The problem with growing toolkits

When you have 5 commands, you remember them all. `/research`, `/draft`, `/audit`: easy. When you have 22 spread across content creation, quality assurance, maintenance, and workflow categories, the mental overhead becomes real. You find yourself thinking "I know there's a command for this..." and then either searching through folders or just doing the task by hand because that feels faster than looking up the right command name.

I realized that if the AI is already processing natural language, why should the user have to remember exact command names when they could just describe what they want?

## Three pieces, one system

The discovery system has three parts. They work together in a way that turned out to be more useful than any of them individually.

### The index: a skill file

The first piece is a reusable instruction file (what OpenCode calls a "skill") that serves as an auto-generated index of every installed command with its description. It looks like a simple table:

| Command | Description |
|---------|-------------|
| `/api-docs` | Create and review API documentation |
| `/audit` | Audit a product's documentation for structure, content, and style issues |
| `/changelog` | Create product changelog entries |
| `/draft` | Produce a complete file draft with correct content type and formatting |
| `/research` | Gather context for a ticket before writing |
| ... | ... |

But what makes it powerful is the routing instructions baked into the skill. When the AI loads this index, it knows that its job is to *route the user to the right command*, not to analyze the command or ask clarifying questions. If the user says "I need to check if our docs match the style guide," the AI immediately responds with: "You can run `/review-doc path/to/file`, which checks documentation against the style guide." No intermediate questions, no analysis. The command itself has its own intake flow.

The skill description is also carefully worded to trigger on a wide range of documentation tasks. The frontmatter says: *"Load this FIRST when the user wants to draft, audit, review, compare, rename, research, or do any documentation task (a custom command likely exists for it)."* This means the AI loads the index proactively, even when the user does not explicitly ask for help finding a command.

### The cataloger: `/commands`

The second piece is the `/commands` command itself. When you run it, it scans every command and skill on your machine, groups them by category, and presents a clean inventory. But the real work happens silently at the end: it regenerates the skill index file.

This means the index is always current. When a teammate contributes a new command, all anyone had to do is run `/commands` once and the discovery system knows about the new addition. No separate configuration step, no manual index maintenance.

I deliberately avoided building any automation around this (no cron jobs, no git hooks, no post-install scripts) because everyone has a different workflow. Instead, you run `/commands` when you want to see what is installed, and as a side effect it refreshes the index.

### The planner: `/plan-workflow`

The third piece addresses a different question: not "which command do I use?" but "I have a complex task: what sequence of commands should I run?"

`/plan-workflow` takes a high-level intent and produces an ordered execution plan. For example:

**Input:** "I just got assigned a new ticket and need to write docs for it"

**Output:**

```
## Workflow plan: new ticket to published docs

1. /research TICKET-123 — gather context from the ticket tracker, wiki, and existing docs
2. /draft — produce a complete file draft with correct content type
3. /review-doc path/to/draft.mdx — check the draft against the style guide

> Want me to start with step 1?
```

The command reads the skill index first, matches every command whose description is relevant to the intent, considers supporting and validation steps, and arranges them in a logical sequence. It does not invent commands that do not exist; if nothing matches, it says so.

## What this looks like in practice

Here is a real scenario. A teammate installs the command suite for the first time. They have 22 commands they have never used before, and the only step they have to take is running `/commands` once. The next morning, they open OpenCode and say:

> "I need to figure out what to work on today."

The AI loads the skill index (because the description matches "daily triage" and "catchup"), scans the commands, and responds:

> You can run `/triage`, which gives you a daily summary of your open tickets. Or `/catchup` if you want a broader view of what happened since you last checked.

The teammate did not need to know those commands existed. They did not need to read any documentation. They described their intent, and the system routed them.

Later, they pick up a ticket and say:

> "I need to write docs for this feature."

The AI suggests `/research` to start, then `/draft` when they are ready to write, then `/review-doc` to check the output. A complete workflow, surfaced from a single sentence.

## The self-maintaining part

The thing I like most about this system is that it maintains itself through normal use. There is no separate "admin" workflow. The cycle is:

1. Someone creates a new command (or installs one from the shared repo)
2. They run `/commands` to see their full setup
3. The skill index is silently regenerated
4. Every future conversation benefits from the updated index

When the index was first generated, it had 15 commands. Today it has 22. At no point did I have to manually update a configuration file or maintain a separate registry. The system grew with the toolkit.

This also means the discovery system scales. If the team eventually has 40 or 50 commands (some personal, some shared, some project-specific), the same three pieces still work. The index gets longer, but the routing logic stays the same: match the user's intent to a command description, suggest it, move on.

## What I would do differently

If I were starting over, I would have built the discovery system earlier, around command number 5, not command number 15. The marginal cost of maintaining the skill index is essentially zero (it auto-generates), and the benefit compounds with every new command. I spent too much time where commands existed but were underused simply because I forgot about them in the moment.

## Try it yourself

If you are using OpenCode or another AI coding assistant that supports custom commands, the pattern is straightforward:

1. **Create a skill/instruction file** that lists all your commands with descriptions
2. **Write routing instructions** into that file so the AI suggests commands rather than analyzing them
3. **Build a cataloger command** that regenerates the index whenever your toolkit changes
4. **Optionally, add a planner** that can chain commands into multi-step workflows

The specific implementation depends on your tool, but the principle is the same: let the AI be the expert on its own capabilities so you can focus on describing what you need done.

After that, just describe what you want to do. The AI will find the right command for you.