A plugin is a single installable bundle that adds slash commands, skills, agents, MCP tool connections, and automation hooks - all at once. Install it once and every capability inside it becomes available across your sessions, ready to enable or disable whenever you like. Plugins are the fastest way to extend 100xprompt: one command brings in a whole workflow instead of wiring up each piece by hand.

​
How a plugin works

Think of a plugin as a labeled box of capabilities. It carries a manifest that names the bundle and declares what it contributes, plus the files that make up each contribution. When you enable the plugin, 100xprompt merges those capabilities into your workspace as if you had authored them yourself.
One plugin can contribute many capability types at once. A single “Reviewer” plugin might add a /review command, a code-review skill, a dedicated review agent, and a hook that runs your linter before every edit - from one install.

​
What a plugin can add

Every capability below can ship inside the same bundle. A plugin author picks whichever ones fit. You get all of them when you enable it.
CapabilityWhat it addsHow you use it
CommandsReusable slash commands with prompts and argumentsType /name in any session
SkillsOn-demand instructions and playbooks 100xprompt loads when relevantApplied automatically when the task matches
AgentsPurpose-built agents with their own instructions and tool accessInvoke or delegate to them by name
MCP connectionsConnections to external tools and data sourcesTheir tools appear in the model’s toolset
Automation hooksCommands that react to events in your workflowFire automatically as you work
Permission defaultsSensible default allow/ask rules for the tools it shipsApplied under your own rules, which always win
Plugin permission defaults are layered beneath your own configuration. Your rules always take precedence, so an installed plugin can never loosen a boundary you set.

​
Install a plugin

Suppose a teammate points you at a plugin that automates your review workflow. You install it from a marketplace name, a Git repository, or a local folder. The <source> can be a marketplace plugin name, github:owner/repo[/subdir][@ref], a Git URL, or a local path.
1

Add a marketplace (optional)

Marketplaces are catalogs of installable plugins. Add one, then browse what’s available.
100xprompt plugin marketplace add github:your-org/plugins
100xprompt plugin marketplace browse
2

Install the plugin

Point install at a marketplace name or any supported source.
# From an added marketplace, by name
100xprompt plugin install reviewer --from-marketplace

# Directly from a repository, subdirectory, or ref
100xprompt plugin install github:your-org/reviewer-plugin@v1

# From a local folder you're developing
100xprompt plugin install ./my-plugin
3

Activate it

Restart 100xprompt (or reload your configuration) so the new capabilities load. Newly installed plugins are enabled by default.
4

Confirm it's live

List everything you’ve installed and see which plugins are enabled.
100xprompt plugin list
Enabled plugins show a filled marker; disabled ones show a hollow marker.

​
Enable, disable, and remove

Turn a plugin off without losing it, turn it back on later, or remove it entirely. Every installed plugin moves through the same lifecycle.
Keep the plugin installed but stop its capabilities from loading.
100xprompt plugin disable reviewer
Disabling is reversible and instant - a great way to isolate whether a plugin is responsible for some behavior. Removing is permanent and deletes the bundle from disk.

​
Author a plugin manifest

The manifest is the one file that makes a folder installable. Name it 100xprompt-plugin.json (or plugin.json) at the root of your bundle. It carries the plugin’s identity plus the contributions that aren’t discovered from folders on their own - MCP connections, hooks, and permission defaults. 
{
  "name": "reviewer",
  "version": "1.2.0",
  "description": "Adds a review command, a review agent, and a pre-edit lint hook.",
  "author": "Your Team",
  "homepage": "https://example.com/reviewer",
  "license": "MIT",
  "mcp": {
    "linter": {
      "type": "local",
      "command": ["linter-server", "--stdio"]
    }
  },
  "hooks": {
    "PreToolUse": [
      { "matcher": "edit|write", "hooks": [{ "command": "./lint-check.sh" }] }
    ]
  },
  "permission": {
    "bash": { "linter *": "allow" }
  }
}

​
Manifest fields

FieldRequiredPurpose
nameYesUnique, lowercase kebab-case identifier - also the install folder name
versionNoVersion string shown when listing plugins
descriptionNoOne-line summary shown in listings and marketplaces
authorNoWho maintains the plugin
homepageNoLink to docs or the source repository
licenseNoLicense identifier for the bundle
mcpNoMCP connections the plugin contributes
hooksNoAutomation hooks the plugin registers
permissionNoDefault permission rules, layered beneath the user’s own

​
What a plugin bundles

Alongside the manifest, a plugin ships its commands, skills, and agents as ordinary files in dedicated folders at the bundle root. 100xprompt picks these up when the plugin is enabled. You write them exactly as you would for your own workspace. 
reviewer/
├── 100xprompt-plugin.json   # the manifest
├── command/                 # slash commands
│   └── review.md
├── skill/                   # skills
│   └── code-review/
│       └── SKILL.md
├── agent/                   # agents
│   └── reviewer.md
└── lint-check.sh            # a script a hook can call
The manifest declares only what can’t be inferred from folders (MCP, hooks, permissions). Commands, skills, and agents are discovered from their folders - so adding one is as simple as dropping in a file.

​
React to your workflow with hooks

Hooks let a plugin respond to events as you work - before a tool runs, after it finishes, when you submit a prompt, when a session starts, and more. Each hook points at a command that receives the event and can add context, adjust behavior, or block an action.

​
Events a hook can react to

EventFires whenA hook can
SessionStartA new session beginsSet up context or state
UserPromptSubmitYou submit a promptInject extra context before the model responds
PreToolUseBefore a tool runsAllow, adjust the input, or block the action
PostToolUseAfter a tool runsAdd follow-up notes to the result
PermissionRequestA permission is requestedApprove or deny it automatically
StopThe agent is about to finish its turnAsk it to keep working
Hooks can target specific tools with a matcher, so a lint check only runs before edits, or a formatter only runs after writes.
Hooks run commands on your machine in response to your activity. Only install plugins whose hooks you trust - review what a plugin’s scripts do before enabling it, just as you would any code you run locally.
Hooks are the same mechanism you can configure yourself in 100xprompt.json. A plugin simply packages a proven set of them so you don’t have to wire each one by hand. See Hooks for the full event payloads and options.

​
Best practices

Add a marketplace and use 100xprompt plugin marketplace browse to find vetted plugins with install counts and descriptions, rather than tracking down repositories by hand.
A plugin that does one thing well - one workflow, its command, its agent, and its hook - is easier to trust, enable, and reason about than a grab-bag of unrelated capabilities.
If behavior changes unexpectedly, disable recently added plugins one at a time. Because disabling is instant and reversible, it’s the quickest way to isolate a cause.
Installing from a repository with an explicit ref (@v1) gives you a stable, reproducible bundle across machines and teammates.

Marketplace

Browse and install curated plugins from catalogs you add.

Skills

Package reusable instructions and playbooks 100xprompt loads on demand.

Commands

Author slash commands with prompts, arguments, and tool access.