Skip to content
Mastering Claude

Home / A structured installation

A structured installation9 minApplication

Curating your skills and closing out the setup

A skill is installed one at a time, against a need you have already encountered, never in a batch, and closing out the setup means proving each of the module's seven map elements with an executable action rather than assuming it is in place.

Installing ten skills at once because a list recommends them amounts to stacking settings without knowing which ones actually earn their keep. Every installed skill competes lexically with the others at the moment of automatic routing: a skill set up against a need that has not yet arisen costs nothing but context, with no return at all. The right question before installing is never how many skills this repository offers, but which precise action, already repeated in your own work, this skill would replace.

One skill at a time, two possible locations

A skill lives in a personal folder when it serves every project, or in a project folder when it serves only the one currently open. On a name conflict between the two locations, the personal skill wins. Custom slash commands and skills have also merged: a command file and a SKILL.md file sharing the same name now produce the same command and behave the same way, a structural change worth knowing before moving on to creating your own skill or your own command.

Two distinct repositories exist. The first, claude-plugins-official, is a set curated by Anthropic, not a community repository: it registers itself on the very first interactive launch, and a manual addition goes through the CLI subcommand claude plugin marketplace add anthropics/claude-plugins-official, not a slash command. The second, claude-community, is indeed the community's public repository, and is added with:

/plugin marketplace add anthropics/claude-plugins-community

No fixed figure honestly measures the size of these libraries, curated or community: they are versioned continuously by their maintainers, a count taken on a given day already diverges from the same repository checked the next day. The correct action is to check the repository at the moment of installation, never to remember a total learned once and for all.

Closing out means proving, not assuming

The map of a structured setup counted seven elements at the opening of this module: engine, CLAUDE.md constitution, file memory, git transport, hooks, skills, heartbeat. Closing out the setup means closing each of these seven elements with an executed proof, never with a memory of a configuration you assume is still true. This lesson's figure details the seven expected proofs, one per element of the map, before considering the setup complete.

Figure 1

The seven proofs that close out the setup

Phase 1
Engine
A first simple request gets a response in the terminal, proof that the connection and the subscription are working.
Phase 2
Global CLAUDE.md
A newly opened session cites, in its response, a rule written in the file, proof that it has indeed been loaded.
Phase 3
File memory
A commit appears in the memory vault's history after a work session.
Phase 4
Git transport
The memory vault's private remote responds to a push without an authentication error.
Phase 5
Hooks
A success marker written by the SessionEnd hook does indeed exist after the session closes.
Phase 6
Skills
The folder of installed skills contains exactly the expected SKILL.md files, no more and no fewer.
Phase 7
Heartbeat
The last recorded run of the scheduled task matches the expected time, not an older date.
The timeline takes the seven elements from the module's opening map and pairs each with the concrete action that proves it is genuinely in place, rather than a memory of a setting.
Calibrate it yourself

A developer installs a diagram generation skill in the personal folder of their account, uses it on three requests about network diagrams during the month, then checks the folder of installed skills and finds fourteen entries accumulated over six months.

Write, in one sentence, what this situation establishes, and in one sentence what it does not establish.

What to remember
  • A skill is installed against a need you have already encountered, never in a batch in anticipation, because every installed skill competes lexically with the others at the moment of routing.
  • On a name conflict between a personal skill and a project skill, the personal skill wins.
  • Custom slash commands and skills now produce the same result under a different file, a structural change compared with older versions of the product.
  • No fixed figure honestly describes the size of a community skills repository, the only valid proof is checking the repository at the moment of installation.
  • Closing out a structured setup means proving each of its elements with an executable action, not assuming it is in place.
Do this now

List your seven elements installed since the start of the module, and for each one, run the corresponding proof from this lesson's figure before ticking the setup off as complete.

What still needs checking

These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.

  • The exact number of skills and agents available in the ECC and superpowers community repositories is not stable, no figure has been cited in this lesson for that reason.
Check the source

Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.