How to actually use these skills
Installing is one command, and the rest of this site already covers it. The part nobody mentions is what happens after: most skills fire without you asking for them, the ones that don’t you call by name, and a job bigger than one edit wants a different opening move than a small one. This is the first session, in the order you’ll actually hit it.
Install it, if you haven’t
Here it is — the same box the landing page leads with, repeated so this page does not send you elsewhere for the one thing you have to paste. It carries a prompt rather than a command: put it into whichever coding agent you use, and it works out which harness it’s in and takes that harness’s route. On Claude Code that route is a clone-or-pull into ~/.claude/skills/TBaguette, and nothing else on your machine is touched. Install verification is the page that proves that claim, with the actual test source rather than the claim restated in different words.
Install TBaguette’s Atelier
Install (or update) TBaguette’s Atelier — a skills library for coding agents — into whichever agent you are. Use your shell tool.
Before you start: confirm git is available (git --version). If it isn't, tell me and stop — there's nothing else to try.
It is a single git repo, https://github.com/LeSplooch/tbaguette-skills.git, shipping an integration for each harness it supports (Claude Code, Codex, Cursor, Devin, GitHub Copilot CLI, Copilot in VS Code, Copilot coding agent, Gemini CLI, Hermes, Kimi Code, OpenCode, Pi). Work out which one you are running in, then take the matching route — you know your own install mechanism better than this prompt does. If you genuinely can't tell which one you are, say so and ask me, rather than falling through to the first route below.
Route A — you read Claude Code's skills directory. Target: ~/.claude/skills/TBaguette (Windows: %USERPROFILE%\.claude\skills\TBaguette). Figure out which case applies:
1. <target>/.git exists — update in place: git -C <target> pull.
2. <target> doesn't exist, or exists and is empty — install fresh:
git clone https://github.com/LeSplooch/tbaguette-skills.git <target>.
3. <target> exists, has content, isn't a git repo, but contains CATALOG.md and skills/ — this is very likely a previous TBaguette install that lost its own git history. Say that plainly, not a "naming collision", and ask me whether to move it aside and re-clone, rather than doing that yourself.
4. Anything else already at that path — stop. Do not delete or modify it. Tell me there's a naming collision that needs a manual look.
Route B — you install plugins or extensions from a git URL with your own command. Use it, against this same repo: Hermes is `hermes plugins install LeSplooch/tbaguette-skills --enable`, where the flag is not optional — Hermes only prompts to enable a plugin when it has a terminal to prompt in, so run from a tool it would otherwise install disabled and load nothing. Hermes also security-scans what it installs, and this library trips that scan: a hundred skills about secrets, untrusted input and shell scripting read, to a pattern matcher, like the things they teach you to watch for. The findings are informational. If the scan stops the install because there is no terminal to confirm in, show me the report and the command and let me decide — do not re-run it with --force on my behalf. Kimi Code is `/plugins install https://github.com/LeSplooch/tbaguette-skills` from inside a session or `kimi plugin install https://github.com/LeSplooch/tbaguette-skills.git` from a shell, Gemini CLI is `gemini extensions install https://github.com/LeSplooch/tbaguette-skills`, Codex is `codex plugin marketplace add LeSplooch/tbaguette-skills` and then installing tbaguette-atelier from it. GitHub Copilot CLI takes two steps rather than one, because the install command needs a marketplace to name first: `copilot plugin marketplace add LeSplooch/tbaguette-skills`, then `copilot plugin install tbaguette-atelier@tbaguette-dev`. In VS Code it is not a shell command at all — tell me to run **Chat: Install Plugin From Source** from the Command Palette and paste https://github.com/LeSplooch/tbaguette-skills.git when it asks; don't clone anything yourself in place of that. If it's a command only I can type, print me the exact line instead of substituting a filesystem clone for it.
Route C — you load plugins from a config file. Show me the exact entry and ask before editing — never edit my config silently. On OpenCode that entry is "tbaguette-skills@git+https://github.com/LeSplooch/tbaguette-skills.git", added to the "plugin" array in opencode.json. If you are the Copilot coding agent, the file is .github/copilot/settings.json in the repository you are working on, and both fields are objects rather than arrays: "extraKnownMarketplaces" gets {"tbaguette-dev": {"source": {"source": "github", "repo": "LeSplooch/tbaguette-skills"}}} and "enabledPlugins" gets {"tbaguette-atelier@tbaguette-dev": true}. That edits a repository I share with other people, so show it to me and wait, the same as any other config.
Route D — none of those. Don't invent a path. Find the directory your harness actually reads: its own dotdir in my home directory, or an existing skills/, plugins/, or extensions/ folder — confirmed to be there, not assumed. Clone-or-pull into a TBaguette-named directory inside it, following Route A's four cases. If nothing you find is clearly right, clone nothing: tell me what you checked and ask.
Whichever route: never delete, move, or overwrite anything to make room. If the clone or pull command itself fails (network, permissions, auth), show me the actual error rather than retrying blindly or guessing why.
After a successful install, verify rather than assume. For a clone you placed yourself:
- <target>/.git exists and git -C <target> rev-parse HEAD succeeds.
- <target>/CATALOG.md exists and <target>/skills/ is non-empty.
- Read <target>/.claude-plugin/plugin.json's "version" field, if present, so you can tell me which version I'm now on.
For a harness-managed install, verify it the way your harness reports installed plugins — on Hermes that is `hermes plugins list`, and the row has to say enabled, not just present.
Then tell me what happened (installed fresh, updated, or already current), which version, and the reload step for my agent specifically — restarting it, Claude Code's /reload-plugins, Kimi Code's /new, Hermes' `hermes gateway restart`. Skills then invoke as tbaguette-atelier:skill-name.
Flag one more thing, because it applies to this very conversation: this session started before the install, so it is still running on the skill list it had at startup, and nothing you just did changes that. Tell me to open a new conversation to pick up the latest — or, if I want to stay in this one, to invoke tbaguette-atelier:using-tbaguette here (if you have no skill tool, read skills/using-tbaguette/SKILL.md from the install instead).
Paste into whichever coding agent you use — it works out which harness it's in and installs the right way for it. It needs a shell tool, which rules out Claude Desktop; on Claude Code it's been exercised against Claude Sonnet (Max).
Only ever touches this folder — verified against your other skills, not just claimed. See how.
Restart your agent (in Claude Code, /reload-plugins), then invoke a skill as tbaguette-atelier:skill-name. On Claude that means Claude Code specifically — the Claude Desktop app and claude.ai chat load skills from your account instead of this folder, so cloning here won’t make them appear there.
A conversation that was already open when you installed or updated — including the one you installed from — is still running on the skill list it started with. Open a new conversation to pick up the latest, or invoke tbaguette-atelier:using-tbaguette in the old one.
Reload — and know that the conversation you installed from won’t
A running agent holds the skill list it started with. Restart it — in Claude Code, /reload-plugins does it without a restart — and every new conversation picks the library up.
The conversation you ran the install from is the exception worth naming, because it’s the one you’re most likely to test in. It started before the install, so it still has the old list, and nothing you just did changes that. Open a new conversation, or invoke tbaguette-atelier:using-tbaguette in the old one to load the entry point by hand.
One more place this bites, on Claude specifically: this is Claude Code. The Claude Desktop app, claude.ai and Cowork don’t read ~/.claude/skills/ at all — they install plugins on your account, from Anthropic’s plugin directory — so cloning here will never make these show up there. The Atelier isn’t listed in the directory yet; until it is, those apps also take a marketplace you add yourself from GitHub, and this repository is one: LeSplooch/tbaguette-skills.
Confirm it landed
Ask your agent to invoke tbaguette-atelier:using-tbaguette. If the install worked, it comes back with a short notice about checking skills before every response — that notice is the library’s entry point, and seeing it is proof the whole thing is loaded and callable, not just present on disk. If you get “no such skill” instead, the clone isn’t where your agent reads from, and the install prompt’s own verification steps will say which case you’re in.
Most of the time you won’t invoke anything
Every skill carries a trigger description — the situations it is for, written out at length rather than summarized into a category. Your agent matches what you are doing against those, and tbaguette-atelier:using-tbaguette is the piece that makes that check habitual rather than occasional.
So the ordinary experience is that you never type a skill name. You say fix this bug, and diagnosing-before-fixing arrives before a patch does — a reproduction first, then the cause, then the fix. You ask for an interface, and formidable turns up with the questions a designer would have asked. You do not have to memorize 102 names, and you should not try.
When you do want one by name
Invoke it directly — tbaguette-atelier:formidable, tbaguette-atelier:knowing-when-to-stop, whichever one you mean. There are two honest reasons to override the automatic path. The first is that you know your own situation better than a trigger description can: the work does not look like the skill’s trigger, but the discipline still applies. The second is timing — you want it before your agent has decided this task is simple enough to skip it, which is reliably the moment it is not.
Six worth trying on purpose
Not a ranking, and not the six that matter most — the six whose effect you can watch inside a single session, which makes them the fastest way to find out whether any of this is for you.
formidable— The flagship, and the one with the most visible before-and-after. Design craft for every stack there is — web, terminal, native, game HUD, print, voice — so it applies to the interface you actually have rather than the one a web tutorial assumed you had. Ask it for nothing in particular and it goes looking for the best shipped work in your domain first, then builds past what you asked for.diagnosing-before-fixing— Turns fix this into a reproduction before a patch. The fastest way to see the difference: hand it a bug whose obvious fix you already have in mind, and watch where it goes first.writing-the-failing-test-first— The most concrete behavior change on this list. One test that fails for the right reason before any production code exists — a different thing from a test written afterwards that has never once been red.confirming-before-claiming-done— For anyone who has been told something was finished and found out otherwise. It replaces this should work with a command that was actually run, and treats a tool’s own success report as a claim rather than as evidence.orchestrating-work-end-to-end— The entry point for anything bigger than a single edit — which is the next section, because it is the one piece of this that changes how a whole run is shaped rather than how one response is.knowing-when-to-stop— The counterweight to everything above. Bounded passes, diminishing returns, and naming what is being left undone instead of quietly polishing until the context runs out.
Anything bigger than one edit starts somewhere else
One skill covers one stretch of work. A feature, a bug with no known cause, a migration, an audit — those take several of them, in an order, and that order is its own skill: orchestrating-work-end-to-end. It routes the request to the lightest track that fits, says which phase the work is in, and names the evidence that has to exist before the next phase is allowed to open.
The practical version, for you: describe what you want, and let it open with scoping rather than with an editor. What comes back first is a design to say yes or no to — which is a great deal cheaper to argue with than a finished implementation of the wrong thing.
Keeping it current
Run the same install prompt again — it takes whichever route it took the first time. On the Claude Code route that route is a clone-or-pull, so a second run updates in place rather than erroring, duplicating anything, or touching whatever else lives beside it. On a harness with its own plugin command, the prompt hands back to that command, and updating is whatever that harness already does.
Mostly you will not have to remember. keeping-tbaguette-current runs that check at the start of a conversation and reports what changed in readable terms rather than as a commit log. This site’s own header carries the published version and the moment it was last built, if you would rather compare by hand.
Living beside your other skills
Installing TBaguette adds exactly one directory, ~/.claude/skills/TBaguette, and touches nothing else — not another library’s skills, not a plugin you already run, not your settings. If that one path is already occupied by something unrelated, the install refuses outright rather than merging into it, so a name collision fails loudly instead of quietly costing you whatever was there. Install verification is where that is proved against the real command rather than asserted.
Skill names can repeat across libraries, and that is fine, because TBaguette’s are called with its prefix. tbaguette-atelier:naming-things is always this library’s; the same name without the prefix is whoever else’s. Two skills that share a name stay separately reachable and neither one shadows the other — so nothing has to be uninstalled to make room.
If you also run a library that injects its own check-the-skills-first notice — Superpowers is the one you are most likely to have — both fire, and both apply. They are not competing for the same job: using-tbaguette speaks only for TBaguette’s own skills and says nothing about anyone else’s. When the other library has the better answer for the job in front of you, that is the one to use. The rule here is to check what is available before answering, never to prefer this library’s skill because it is this library’s.
And if it does get in your way, removing it is deleting that one directory. There is no uninstaller, no settings entry to unpick, and nothing else on your machine to unwind — on Windows, delete the same folder.
rm -rf ~/.claude/skills/TBaguetteNot on Claude Code?
TBaguette’s Atelier ships an integration for Codex, Cursor, Devin, GitHub Copilot — the CLI, VS Code, and the coding agent — Gemini CLI, Hermes, Kimi Code, OpenCode, and Pi as well. Those installs differ in kind rather than just in path — a plugin command here, an extension there, a line in a config file somewhere else — which is exactly why the install box carries one prompt instead of ten recipes. It identifies its own harness and takes the matching route, and when it cannot identify one it stops and asks rather than inventing a path. PORTING.md has the harness-by-harness breakdown of what each one loads.
If nothing seems to be happening
Roughly in the order worth checking, cheapest first:
- The conversation predates the install — including the one you installed from. Open a new one, or invoke
tbaguette-atelier:using-tbaguetteto load the entry point by hand. - You are in Claude Desktop or claude.ai chat, not Claude Code. Those load plugins from your account rather than from
~/.claude/skills/, so nothing you cloned is visible to them. - Your agent has them and simply is not reaching for them. Invoke one by name. If that works, the install is fine and what you are watching is trigger matching — say what you are doing in plainer terms, or name the skill yourself.
- The clone is not where your agent reads from. Check that
~/.claude/skills/TBaguette/CATALOG.mdexists. If that directory is there but has no.gitinside it, what you have is a previous install that lost its own history rather than a fresh one — the install prompt recognizes that case and asks before moving anything aside.
Where to go from here
Every skill on this site is readable in full and searchable by name, summary, or category, grouped into categories on the landing page. CATALOG.md is that same catalog as a single file, which is the better one to hand your agent when you want it to read rather than search.