Your CLI, at work.

Skills are workflows

A skill is not a wrapper around one command. It is a job you would replay without explaining it again: find the meeting, pull the transcript, write the summary, show it to you, post it. If a skill would only run one command, skip it; your agent can read the CLI's own help for that.

• Five to start, never thirty. Only a workflow you have run at least twice earns a skill. Your first sitting writes two. Toolkits that ship their own skills are already organized. The count here is for skills you write.
• Your words, not the API's. Each skill's description says what it does, then "Use when ..." in the words you would actually say. That line is how your agent picks it.
• Where they live. In your workbench, in .claude/skills/ (Claude Code) and .agents/skills/ (Codex), the same file in both. They travel with the workbench and show up in both apps.
• Read first, then write. A skill that sends or changes something runs a dry run or shows the exact preview, uses a test channel the first time, and waits for your yes.

Want a skill in every project? See Want it in every project? in Build Your Own CLI.

Skills call skills

There are two kinds of skill, and one rule between them.

• Skills that work with one CLI come first. Each knows the exact commands of one CLI and does one job with it: zoom-latest-transcript finds a meeting and pulls its transcript.
• Skills that combine CLIs call those skills, by name, and hold no CLI commands at all. When a CLI changes, you fix the one skill that knows it, and every skill that calls it keeps working.
• Keep each CLI about one service. Don't build an "after-the-meeting CLI" that does Zoom and Slack. Combine them in a skill.

The worked example, if you have the Zoom and Slack CLIs from the vault. The Zoom example needs a paid Zoom plan with cloud recording, a bot you made in each service, and a test channel.

after-the-meeting
# combines two CLIs; calls skills, holds no CLI commands
  1. zoom-latest-transcript
     # knows zoom-cli.py: finds the meeting, pulls the transcript
  2. writes a summary, the decisions and the action items
  3. shows you the draft and the channel, and waits
  4. slack-post
     # knows slack-cli; ships with the Slack CLI Toolkit
  5. says where it posted, and under which bot's name

No names of people, clients or channels go in the skill. The channel comes from you when it runs, and if you don't say, your agent asks.

The two skills that make more skills

Both ship as templates in the blueprint. Your agent fills them in and saves them, on your yes.

• Save as a skill. When a job with no skill has worked twice, your agent offers: "Want me to save this as a skill?" On a yes it drafts the skill from what actually ran, shows you the name and where it goes, and waits. Your skill set grows from what you really do, not from a list you guessed at.
• Sharpen a skill's description. Your agent picks a skill by reading its description. A correct skill with a vague description never gets picked. This one asks you for three ways you would ask, rewrites the description to match, tests all three, and changes nothing else in the skill.

One line tells your agent it's there

Your agent reads AGENTS.md (Codex) and CLAUDE.md (Claude Code) at the start of every session, so everything in them costs space every time. One line per CLI is enough: what it reaches, how to run it, and where its skills are. Not the docs.

- zoom-cli: Zoom meetings, recordings and transcripts. Run: infisical run -- python3 ~/scripts/zoom-cli/zoom-cli.py. Skills: zoom-latest-transcript, after-the-meeting (.claude/skills/ and .agents/skills/). Check a skill first, then the CLI's --help. Read only unless a skill says otherwise. Never run a delete command. Keys come through infisical run.

This example has the Zoom credentials in Infisical. If yours come from the setup in the Zoom Automation Hub card instead, drop infisical run -- and the last sentence. Keep the read-only sentence on every CLI you borrow: a borrowed CLI has no limits of its own, and zoom-cli.py can delete meetings and recordings. On Windows, the Run part is python $HOME\scripts\zoom-cli\zoom-cli.py, with infisical run -- in front if you use Infisical.

If your CLAUDE.md already has the line @AGENTS.md, one copy in AGENTS.md covers both apps. Your agent shows you the line and where it goes before it adds it.

Keys, identity and more than one account

• Keys through Infisical. You store the key in the Infisical dashboard and run infisical init once at the root of your workbench. Your agent runs the CLI as infisical run -- <cli> ..., so the key reaches that one command and nothing else. A borrowed CLI with its own local profile, set up by you in your own terminal with history turned off for that window, is fine too. New to this? Keys, the First Time.
• Writes go out as a named bot or app, not as you. A Slack app with a bot user, a Zoom Server-to-Server app: give it a clear name and only the access its workflows need. People can tell what came from your agent. If the service has no bot option, every write's preview says "This goes out as you" and waits.
• More than one account. One profile per account, with a plain name such as work or personal. The account is named on every command, and every write's preview says which one.

Four ways to pick the account. Most people use the first two together.

• A preset in the skill. The client workflow always uses the client's account. Cleanest for anything that goes to other people.
• A default in the pointer line. "Default account: work."
• By the recipient. The skill checks the email domain or the channel's workspace and picks the matching account.
• Said in the ask. "Use personal for this one."

And one rule over all four: if the request doesn't name the account and no rule covers it, your agent asks. No guessing.

Keeping it current

• Keep the MCP or connector for the first week. The CLI does the work; if something breaks, the connector still runs while you fix it. The end date goes in your maintenance note.
• When the service changes, capture its docs again (Firecrawl by default, as in Build Your Own CLI) and rebuild the method list. For a borrowed CLI, its vault card has the update step. It is an ask you run when the service changes. To run it on its own, see Goals and Loops.
• Count your skills. The maintenance note keeps the count of skills you wrote for each CLI. Toolkits that ship their own skills are already organized. The count here is for skills you write.

What happens in the hour

Ten checkpoints, each with a pause for your yes. Here they are in six groups.

• It copies the blueprint to work/put-your-cli-to-work/ and finds your CLI: your part 2 build, or a vault CLI you already set up. No CLI yet? It points you to Build Your Own CLI and stops.
• It reads the CLI's commands and proposes the three to five workflows you actually repeat. You pick two.
• It writes those two skills, then, if you have a second CLI, one skill that combines skills from two CLIs. Each one is announced first.
• It adds the pointer line and the two skills that make more skills, then sharpens the new descriptions once.
• You run each workflow twice, in plain words, in a new session. Writes go to a test channel after a dry run, on your yes.
• It checks keys and identity, sets up how the account is picked if you use several, and fills in the maintenance note.

New skill: after-the-meeting
What: a summary and action items from a Zoom transcript, posted to Slack on your yes
Calls: zoom-latest-transcript, slack-post
Where: .claude/skills/after-the-meeting/SKILL.md
       .agents/skills/after-the-meeting/SKILL.md
Write it? yes / change something / no

What you can ask your agent, from now on

Five asks that work once it is set up.

Words you now own

• Skill. A workflow your agent can replay from plain words, saved as one SKILL.md file in its own folder.
• Description. The line at the top of a skill that says what it does and when to use it. Your agent picks skills by reading it.
• Combining skill. A skill that does a job across two or more CLIs by calling their skills by name. It holds no CLI commands.
• Meta-skill. A skill that works on other skills. Here: save-as-skill and sharpen-skill-description.
• Pointer line. One line in AGENTS.md or CLAUDE.md that says a CLI exists, how to run it and where its skills are.
• Profile. One saved account setup in a CLI, with a plain name. One per account.
• Bot identity. The named app or bot your agent's writes go out under, so people can tell what came from your agent.
• Fallback week. The first week with the CLI, when the MCP or connector stays on in case something breaks.

Before you point it at real work

Your agent checks these with you in checkpoint 8 and shows proof for each line. A line without proof is a no.

• No key in a skill, a file or a command. It searches the new skills and the work folder and lists only the names of files that match, never the matching line.
• Every write has a dry run or a preview, and has gone to a test channel or record at least once.
• Writes go out under a bot's name, and the bot reaches only the channels, folders or records it needs.
• Every workflow worked twice, from plain words, in a new session.
• With several accounts, every command names one, and a request that doesn't say gets a question, not a guess.
• Transcripts and exports stay in the work folder, never committed and never posted in full.

Fair questions