Extensions: Skills, Plugins, Hooks, and Commands

RenX agents are extensible through four systems that work together: Skills, Plugins, Hooks, and Commands. This guide explains what each one does and how to use them.

Who this is for: Advanced users who want to customize agent behavior beyond the default desktop experience.

Overview

All four systems share a scope hierarchy — each can be configured at the system, user, agent, or workspace level. Higher scopes override lower ones when names collide.

If you are new to RenX, start with Skills first. The other systems are progressively more advanced.

Skills

Skills are reusable step-by-step instructions stored as SKILL.md files. They teach your agent how to perform common tasks like committing code, reviewing pull requests, or debugging issues.

Using Skills

Type a slash command in the chat input:

/commit -m "Add authentication"

Or let the agent invoke skills automatically when they match the task at hand.

Creating a Skill

Create a SKILL.md file with YAML frontmatter:

---
name: commit
description: Create a well-organized git commit
allowed-tools: git, bash
---

# Commit Instructions

1. Review all staged and unstaged changes with `git diff`.
2. Group related changes logically.
3. Write a clear, concise commit message that explains why the change was made.
4. Stage the relevant files and create the commit.

Where to Put Skills

Skills are discovered automatically from these locations (in priority order):

Skill Modes

• Simple mode — When invoked without additional context, the skill’s instructions are used directly. Fast and deterministic.
• Smart mode — When invoked with a prompt (e.g., /commit -m "focus on auth"), the agent refines the skill instructions based on your codebase context.

Managing Skills per Agent

In the agent editor’s Advanced tab, you can disable specific skills for an agent. This is useful when you want different agents to have different capabilities.

Plugins

Plugins are packages that bundle multiple extensions together — skills, commands, hooks, MCP servers, and subagent definitions — in a single directory.

Plugin Structure

my-plugin/
├── .renx-plugin/plugin.json    # Plugin metadata
├── .mcp.json                   # MCP server configurations
├── commands/                   # Slash commands
│   └── deploy.md
├── skills/                     # Skills
│   └── review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json              # Hook configurations
└── agents/                     # Subagent definitions
    └── reviewer.md

Plugin Metadata (plugin.json)

{
  "name": "my-plugin",
  "description": "A plugin that adds deployment and review capabilities",
  "version": "1.0.0"
}

Installing Plugins

From the marketplace:

Go to the plugin marketplace within the app and click Install.

From a Git repository:

The server can clone and install plugins from Git URLs.

Manually:

Drop the plugin directory into one of the discovery locations:

Plugins are auto-discovered — no install step needed if the directory is in the right place.

Plugin Priority

If the same skill, command, or hook name exists in multiple plugins or scopes, the higher scope wins:

Workspace > Agent > User > System

Managing Plugins per Agent

In the agent editor’s Advanced tab, you can disable specific plugins for an agent.

Hooks

Hooks intercept your agent’s execution at specific events, allowing you to enforce rules, modify behaviour, or require approval before an action proceeds.

Hook Events

Configuring Hooks

Hooks are defined in a hooks.json file:

{
  "PreToolUse": [
    {
      "matcher": "bash",
      "hooks": [
        {
          "type": "command",
          "command": "/path/to/validate.sh",
          "timeout": 30
        }
      ]
    }
  ]
}

This example runs validate.sh before every Bash tool execution. The script can:

• Allow the action to proceed.
• Deny the action and stop the agent.
• Ask the user for confirmation.
• Modify the tool’s arguments before execution.
• Inject context as a system reminder.

Hook Output

Hook scripts output JSON with a decision:

{
  "hookSpecificOutput": {
    "permissionDecision": "allow"
  },
  "continue": true
}

Possible decisions:

• "allow" — Proceed with the action.
• "deny" — Block the action.
• "ask" — Prompt the user for approval.

Matchers

The matcher field supports glob patterns to target specific tools:

• "*" — Match all tools.
• "bash" — Match the Bash tool only.
• "file_*" — Match tools starting with file_.

Where to Configure Hooks

Hooks can be configured per-scope via the API or by placing hooks.json files in the appropriate directory:

• User scope — Applies to all your agents.
• Agent scope — Applies to a specific agent only.

In the agent editor’s Advanced tab, you can disable specific hooks for an agent.

Commands

Commands are slash shortcuts that expand into full prompts when you type them in the chat input. They’re the simplest extension type — just a name and a template.

Using Commands

Type a slash followed by the command name:

/commit
/review
/compact

Some commands accept arguments:

/commit -m "Fix authentication bug"

Built-in Commands

RenX includes several built-in commands:

Creating Custom Commands

Create a markdown file in a plugin’s commands/ directory:

---
description: Deploy the application to staging
argument-hint: --env <environment>
---

Deploy the application to the specified environment.

1. Run the test suite first.
2. Build the production bundle.
3. Deploy to the target environment.
4. Verify the deployment is healthy.

The argument-hint field tells users what arguments the command accepts.

How Commands Work

When you type /deploy --env staging:

1. The server detects the /deploy prefix.
2. It looks up the deploy command from built-in commands and active plugins.
3. The command’s content replaces your message, with --env staging passed as arguments.
4. The expanded prompt is sent to the agent as if you had typed the full instructions.

Commands are discovered from the same scope hierarchy as other extensions — system, user, agent, and workspace plugins.

Scope Hierarchy

All four extension types follow the same priority order:

Workspace (highest priority)
    ↑
  Agent
    ↑
  User
    ↑
 System (lowest priority)

• System — Built-in, ships with RenX.
• User — Personal extensions in ~/.renx/users/{userId}/.
• Agent — Specific to one agent in ~/.renx/users/{userId}/agents/{slug}/.
• Workspace — Specific to a project in {project}/.renx/.

If the same name exists at multiple scopes, the highest scope wins. This lets you override system defaults with your own versions.

Managing Extensions per Agent

In the agent editor’s Advanced tab, you can:

• View all discovered skills, hooks, plugins, and MCP servers.
• Disable specific items for that agent without removing them.
• Configure permission scopes (allow/deny/ask lists).

This gives you fine-grained control over what each agent can do.

Next Step

• Start with Built-in agents if you have not yet created the agent you want to customize.
• Go to MCP if you specifically need external tool or service integration.