Create and configure custom slash commands and skills

Put universal standards in a skill so they are organised and easy to find.

A skill is invoked on demand, so a standard that must always hold applies only when somebody remembers to call it.

Always-on conventions belong in memory; skills carry task-specific workflows you deliberately invoke.

Let a codebase-analysis skill run in the main conversation so its findings stay available.

Its verbose output consumes the window that the actual task needs, and the useful conclusion ends up buried in the discovery log.

Fork the context for verbose or exploratory work and return the summary, not the transcript.

Leave tool access unset in a skill — the surrounding session already limits it.

Nothing in the skill's own definition then says what it may reach, so its scope is a property of wherever it happened to be invoked rather than of the skill.

Declare allowed-tools in the frontmatter so the skill's tool access is scoped by the skill itself.

Edit the shared skill when you want it to behave differently for you.

It is version-controlled, so a personal preference ships to the whole team and changes their behaviour without their knowledge.

Create a differently-named personal variant at user scope and leave the shared one alone.

Add argument-hint so the skill will not run without its parameter.

argument-hint only shows the expected arguments during autocomplete. It validates nothing and blocks nothing — an unsupplied placeholder expands to an empty string and the skill proceeds.

Use argument-hint to tell the invoker what to pass, and make the skill body's first instruction check for the value and stop without it.

what allowed-tools does

Answer this: allowed-tools in skill frontmatter restricts tool access during skill execution.

The docs now say: allowed-tools pre-approves tools so they run without a permission prompt, and explicitly does not restrict what is callable; disallowed-tools is the field that removes tools from the pool. Read it