A Skill is reusable, on-demand expertise you author once and reach for whenever a task calls for it. Instead of pasting the same checklist, house style, or step-by-step playbook into every conversation, you capture it in a single SKILL.md file. 100xprompt discovers it, matches it to the work in front of you, and pulls in the full instructions only at the moment they matter. The result is an agent that knows how your team does things - how you review code, cut a release, write migrations, or run an audit - without you re-explaining it every time.

​
Understand what a Skill is

A Skill is a named unit of expertise with three parts:
  • A description that tells 100xprompt what the Skill is for, so it can decide when to reach for it.
  • A set of guardrails (which tools it may use, which model or agent runs it, how much reasoning to apply) that shape how the Skill executes.
  • An instruction body - the actual playbook, checklist, or procedure - that gets loaded into the working context when the Skill is invoked.

On-demand

The instruction body stays out of context until a task actually needs it. No permanent prompt bloat.

Reusable

Author once, invoke anywhere - across sessions, projects, and teammates who share the file.

Governed

Declare the tools a Skill may touch and it is held to them for the duration of its work.

​
Know when to reach for a Skill

If you keep pasting the same “here’s how we do X” preamble into chats, that preamble is a Skill.
Security reviews, release checklists, migration steps, incident runbooks - anything with a defined sequence benefits from being captured once.
A Skill encodes your standards so every run - yours or a teammate’s - follows the same rules.
When a job should only read files, or should run on a specific model, a Skill lets you pin those constraints in one place.
Reach for a Skill when you’re packaging knowledge and procedure. Reach for a Command when you want a typed shortcut that expands into a prompt, and an Agent when you want a persona with its own model and tool profile. Skills, commands, and agents compose - a Skill can even hand its work to a specific agent.

​
See how a Skill is discovered and run

You never wire a Skill into a conversation by hand. 100xprompt keeps an index of every available Skill and its description. As you work, it matches the task in front of you against those descriptions and, when there’s a fit, loads the full instruction body just-in-time.
There are two ways a Skill gets invoked:
100xprompt reads each Skill’s description (and optional when-to-use) and selects a Skill on its own when your task matches. Only the description sits in context up front - the heavier instruction body loads at the moment of use, so a large library of Skills costs you almost nothing until one is actually needed.
Tips:
  • Give every Skill a sharp, specific description. It’s the single most important field for accurate just-in-time selection.
  • Write it in terms of when the Skill should fire (“Use when adding authentication, handling user input, or creating API endpoints”), not just what it contains.

​
Write the SKILL.md file

A Skill is a Markdown file named SKILL.md with a YAML frontmatter block on top and your instructions below it. Place it in its own folder under a .100xprompt/skill/ directory (either skill or skills works): 
.100xprompt/
  skill/
    security-review/
      SKILL.md
    release-checklist/
      SKILL.md
Only name and description are required. Everything else is optional and lets you tighten how the Skill runs.

​
Frontmatter fields

FieldTypeDescription
namestringRequired. The Skill’s identifier. This is what you type as /name and how 100xprompt refers to it. Keep it lowercase and hyphenated.
descriptionstringRequired. One or two sentences on what the Skill does and when to use it. Drives just-in-time selection - make it specific.
when-to-usestringExtra guidance surfaced alongside the description to sharpen automatic selection.
allowed-toolslistRestricts the Skill to only these tools (e.g. read, grep, glob). Any tool not listed is blocked for the duration of the Skill’s work.
modelstringRun this Skill on a specific model instead of the session default.
agentstringRun this Skill as a particular agent, inheriting that agent’s persona and tool profile.
argument-hintstringA short hint about the arguments the Skill expects, shown when you invoke it (e.g. <path> [focus-area]).
effortlevel or numberHow much reasoning to apply: low, medium, high, xhigh, max, or a number.
contextinline | forkinline (default) runs the Skill in the current turn. fork runs it in a dedicated sub-run so its work stays isolated.
pathslistGlob patterns that scope the Skill to matching projects - it’s only offered for automatic selection when at least one file matches.
disable-model-invocationbooleanHide the Skill from automatic selection while keeping it available as a /skill-name command.
user-invocablebooleanSet to false to remove the Skill from the slash-command menu (automatic selection still applies).

​
The instruction body

Below the frontmatter, write the actual playbook in plain Markdown - checklists, code snippets, do’s and don’ts, links, whatever the task needs. This is what loads into context when the Skill fires. Treat it like the briefing you’d give a sharp new teammate: clear, ordered, and opinionated.

​
Pass arguments to a Skill

Skills accept arguments. Place them in the body using the same placeholders as commands:
PlaceholderExpands to
$ARGUMENTSThe entire raw argument string.
$1, $2, $3, …Positional arguments. The highest-numbered placeholder absorbs everything that remains.
Wrap arguments that contain spaces in quotes. For example, invoking: 
/audit-endpoint "src/api/users.ts" "check rate limiting"
against a body that references $1 and $2 substitutes src/api/users.ts for $1 and check rate limiting for $2 before the instructions run.
Skill bodies are treated as instructions, not scripts - placeholders are substituted as text and the guidance is followed by the agent. When a step needs to run a command, the agent uses its normal tools, subject to the Skill’s allowed-tools.

​
Author your first Skill

Suppose your team has a fixed release checklist you run every version bump. Capture it once as a Skill so any run - yours or a teammate’s - follows the same steps.
1

Create the folder and file

Inside your project’s .100xprompt/skill/ directory, make a folder named for your Skill and add a SKILL.md:
.100xprompt/
  skill/
    release-checklist/
      SKILL.md
2

Write the frontmatter

Start with name and description, then add whatever guardrails fit. The name must match the folder’s intent and is what you’ll type as /release-checklist.
---
name: release-checklist
description: Use when cutting a release or preparing a version bump. Walks through the pre-release verification steps and drafts release notes.
when-to-use: Invoke before tagging a version or publishing a build.
allowed-tools: read, grep, glob, bash
argument-hint: <version> [notes-focus]
effort: high
---
3

Write the instruction body

Below the frontmatter, spell out the procedure. Use $1, $2, and $ARGUMENTS wherever the Skill should pick up what you pass on the command line.
# Release Checklist

You are preparing release **$1**. Additional focus: $2

Work through these steps in order and report the outcome of each:

## 1. Verify the tree is clean
- Confirm there are no uncommitted changes.
- Confirm the branch is up to date with its remote.

## 2. Run the gates
- Run the test suite and the type checker.
- Do not proceed if either fails - surface the failures instead.

## 3. Confirm the version
- Check that the version number matches **$1** everywhere it appears.

## 4. Draft release notes
- Summarize the changes since the last release into a short, user-facing
  changelog. Keep it scannable - group by feature, fix, and breaking change.

Finish with a checklist of anything still outstanding before the release
can be tagged.
4

Invoke it

The Skill is now available two ways. Let 100xprompt pick it up automatically when you talk about cutting a release, or invoke it directly and pass the version:
/release-checklist 2.4.0 "highlight the new export flow"
5

Refine the guardrails

If the Skill should never modify files, drop bash and edit-family tools from allowed-tools. If it deserves its own isolated run, add context: fork. Tighten description until automatic selection fires exactly when you want it to.
Your first Skill is live - reusable across every session in this project.

​
Compare built-in Skills with your own

100xprompt ships with a set of ready-made Skills, so useful capabilities are available out of the box. It blends them seamlessly with the ones you author.

Built-in Skills

Curated Skills that come with 100xprompt. They’re always available and require no setup - just invoke them or let them fire automatically.

Your own Skills

The SKILL.md files you author. These layer on top of the built-ins and are the way you encode your team’s specific standards and workflows.
If one of your Skills shares a name with a built-in, yours takes precedence - so you can override a default with your own version simply by naming it the same.

​
Scope where a Skill applies

You control both where a Skill lives and when it’s offered:
  • Project vs. global. A SKILL.md under a project’s .100xprompt/skill/ directory is available in that project. Placing it under .100xprompt/skill/ in your home directory makes it available everywhere you work.
  • Path scoping. Add paths globs to auto-scope a Skill to relevant projects. A Skill with paths: ["**/*.tf"], for example, is only offered for automatic selection when the project actually contains Terraform files. It stays loadable by name regardless.
  • Visibility. Use disable-model-invocation: true to keep a Skill out of automatic selection while leaving it available as a /command, or user-invocable: false to do the reverse.
  • Agent permissions. When a Skill runs under a specific agent, that agent’s permissions apply - an agent that isn’t allowed a given Skill won’t be offered it.
The two visibility flags are independent switches - together they place every Skill in one of four states:
allowed-tools is a real boundary, not a suggestion. Once a Skill declares its allowed tools, anything outside that list is blocked while the Skill’s work is in progress. Scope it to exactly what the task needs - a read-only audit Skill should not list write or edit tools.
  • Commands: typed shortcuts that expand into prompts - pair them with Skills for fast, repeatable workflows.
  • Plugins: bundle Skills, commands, and agents into shareable packages your team can install.
  • Agents: personas with their own model and tool profile - a Skill can hand its work to one.

Commands

Typed shortcuts that expand into prompts. Pair them with Skills for fast, repeatable workflows.

Plugins

Bundle Skills, commands, and agents into shareable packages your whole team can install.

Agents

Personas with their own model and tool profile - a Skill can hand its work to one.