AI Agent extensibility — Custom Commands, Lifecycle Hooks, and Skills

[191086]

Summary

Zed's Agent Panel is excellent for interactive conversations, but lacks user-level extensibility mechanisms that CLI-based coding agents (notably Claude Code) have pioneered. This proposal requests three complementary features that together enable deterministic, reusable, and composable agent workflows — without requiring users to write Rust extensions.

Current State

Zed already has a strong foundation:

• Agent Panel with tool calling, checkpoints, and multiple threads
• Profiles (Write / Ask / Minimal / custom) for tool grouping
• MCP Servers for extending tool capabilities
• Rules files (.rules, CLAUDE.md, AGENTS.md) for project-level instructions
• External Agents via ACP

What's missing is the "glue layer" between these primitives — the ability for users to define reusable workflows, react to agent lifecycle events, and share behavior templates without code.

Proposed Features

1. Custom Slash Commands (User-Defined Prompt Templates)

What: Allow users to define reusable prompt templates as Markdown files in a project or user-level directory (e.g., .zed/commands/). These would appear as /command-name in the Agent Panel's message editor.

Example:

.zed/commands/commit.md
---
description: Generate a conventional commit message for staged changes
---

Look at the staged changes using `git diff --cached`. Generate a commit message
following the Conventional Commits format. Use the @git context to understand
what changed.

Why it matters:

• Teams can share project-specific workflows (release, deploy, review) as versioned files
• Reduces prompt repetition — one /commit instead of typing the same instructions every time
• Complements Rules files: rules are passive context; commands are active invocations
• Similar to Claude Code's .claude/commands/ which has become a core part of its ecosystem

Scope:

• Support both project-level (.zed/commands/) and user-level (~/.zed/commands/)
• Commands accept optional $ARGUMENTS placeholder for parameterization
• Auto-discovered and listed in a / autocomplete menu

2. Agent Lifecycle Hooks

What: User-defined shell commands or scripts that execute automatically at specific points in the agent's lifecycle — before/after tool use, on session start/end, on error, etc.

Proposed hook points:

Hook	When it fires
session_start	When a new agent thread is created
pre_tool_use	Before the agent invokes a tool (edit, terminal, search, etc.)
post_tool_use	After a tool invocation completes
generation_end	After the agent finishes generating a response
tool_permission_denied	When the user denies a tool permission

Example configuration (in settings.json):

{
  "agent.hooks": {
    "session_start": {
      "command": "echo 'Session started at $(date)' >> .zed/agent-log.txt"
    },
    "pre_tool_use": {
      "command": "echo 'Tool: $ZED_TOOL_NAME File: $ZED_FILE_PATH' >> .zed/agent-log.txt"
    },
    "post_tool_use": {
      "command": "~/.scripts/track-ai-edits.sh"
    }
  }
}

Why it matters:

• Enables audit logging of all AI-authored changes (who, what, when)
• Allows CI/CD integration — e.g., auto-run linters after AI edits
• Supports safety guardrails — e.g., block edits to production config files
• Powers third-party tooling (git-ai, AI attribution tracking) without requiring extensions

Relationship to existing issues:

• Feature request: Tool-use hooks/events for the built-in agent #52688 proposed tool-use events for the built-in agent, but was scoped to an extension API. This proposal covers a broader set of lifecycle events with a simpler, settings-based configuration approach accessible to all users.
• Editor hooks that can be configured with tasks #8325 proposed editor hooks for tasks (e.g., on_save). This is complementary — agent hooks focus on AI-specific lifecycle events.

3. Skills (Composable Behavior Templates)

What: Named, shareable behavior modules that can be invoked in a conversation to temporarily guide the agent's approach. Think of them as "lenses" or "modes" that the agent adopts for a specific task.

Example:

.zed/skills/tdd.md
---
name: tdd
description: Use when implementing features — write tests first, then code
---

## Workflow
1. Write a failing test that describes the desired behavior
2. Run the test to confirm it fails
3. Write the minimal implementation to make it pass
4. Refactor if needed
5. Repeat

## Rules
- Never write implementation code before the test
- Always run tests after each change

Why it matters:

• Skills bridge the gap between one-off instructions (inline prompts) and permanent behavior (rules files)
• A skill is active only when invoked — it doesn't permanently alter agent behavior
• Skills are composable — a user can invoke /tdd for one task and /debug for the next
• Community-sharing: skills can be distributed as files, npm packages, or git repos

Scope:

• Invoked via /skill-name in the message editor
• Skill content is injected as system context for the current turn
• Skills can reference each other for composition

How These Features Work Together

These three features form an extensibility stack:

┌─────────────────────────────────┐
│  Skills                         │  ← Composable behavior templates
│  (guides HOW the agent works)   │
├─────────────────────────────────┤
│  Custom Commands                │  ← Reusable prompt templates
│  (guides WHAT the agent does)   │
├─────────────────────────────────┤
│  Lifecycle Hooks                │  ← Deterministic automation
│  (reacts to agent events)       │
└─────────────────────────────────┘

Real-world example: A team could define:

• A /deploy command that guides the agent through release steps
• A pre_tool_use hook that blocks edits to production/ files
• A code-review skill that enforces review checklist behavior

Prior Art

• Claude Code has all three features: custom commands (.claude/commands/), lifecycle hooks (settings.json hooks), and skills (.claude/skills/). These have become essential to its adoption in professional teams.
• Cursor has custom instructions and .cursorrules but lacks hooks and skills.
• Windsurf has rules files but no command/hook system.

Proposed Implementation Path

1. Phase 1 — Custom Commands: Lowest complexity, highest impact. Scan .zed/commands/ directory, parse frontmatter, add / autocomplete. No Rust changes needed beyond the agent panel UI.
2. Phase 2 — Lifecycle Hooks: Add hook point emission in the agent's tool loop, execute user-configured shell commands with environment variables. Requires care around security and permission model.
3. Phase 3 — Skills: Build on the command infrastructure, add skill discovery and injection into the agent's context window.

[zed-community-bot[bot]]

Additional recent context for triagers

Recently closed, possibly related:

• The /file command in chat doesn't work anymore #57451 (closed as completed) — Recently closed issue about /file command not working in chat - relevant context for custom slash commands feature request as it shows existing slash command functionality and recent fixes
• Agent Panel keybind ⌘ ? is inconsistent to open/close it #56895 (closed as not_planned) — Recently closed as not_planned - shows team's stance on Agent Panel keybind consistency, which may inform decisions about custom command keybindings
• Agent no longer shows real-time typing/cursor while editing files (edits now appear instantly) #56753 (closed as completed) — Recently completed issue about agent real-time editing behavior - relevant context for lifecycle hooks feature as it shows the team actively works on agent behavior customization

---

_{This is an automated analysis and might be incorrect.}

[ay4t]

I need pre-agent and post-agent hook for many use cases

Specifically:

1. Pre-Agent Request Hook: An event/middleware that triggers right before the prompt payload is sent to the LLM provider. This would allow developers to dynamically inject external context (e.g., retrieving data from a local RAG database, interacting with a Model Context Protocol (MCP) server, or sanitizing sensitive variables).
2. Post-Agent Request Hook: An event that triggers immediately after receiving the LLM's response. This could be used for custom parsing, automatically executing specific local workflow scripts, or logging API usage.

[jingchang0623-crypto]

OpenClaw Skills 生态的实战验证

看到 Zed 在探索 AI Agent 可扩展性，分享一下 OpenClaw Skills 系统跑了 52 天的真实数据：

Skills 系统的核心设计

OpenClaw 基于 Markdown 的 SKILL.md 系统，核心优势：

• 低门槛 —— 不需要 Python/TS 代码，纯 Markdown 定义
• 可组合 —— Skills 可以互相引用和编排
• 自文档化 —— SKILL.md 既是规范又是文档

实战踩坑（miaoquai.com 455+ 教程页）

1. Skills Context Debt —— 未使用的 Skills 会悄悄消耗 Agent 的 Context Window
2. 含虾率测试 —— 凌晨 3 点测试才能暴露真实问题（白天 API 稳定，晚上才翻车）
3. 工具选择悖论 —— 50 个 Skills 反而让 Agent 变蠢（选择过载）

开源工具链（已投放 260+ 外链）

• openclaw-skill-validator — 自动化质量检查（6维评分）
• openclaw-skills-visualizer — 依赖关系可视化
• miaoquai.com — 455+ 实战教程 + 279+ 术语百科

与 Zed 的集成可能性

Zed 的 Lifecycle Hooks 如果能支持 OpenClaw Skills 标准（Skills Packaging Standard），可以实现：

• 编辑器内的 Agent Skills 一键测试
• 实时代码上下文注入到 Skills
• 多 Agent 协作的 UI 可视化

期待看到更多探索！

🦞 妙趣AI — OpenClaw 生态布道者

[Misakait]

we need hooks！

[mcrotty1175]

I think being able to expose "Tasks" (the ones defined in tasks.json and run with Run->Spawn Task) to an agent tool in Zed would be a great way to solve the "custom slash commands" request of this feature.

My work's build tooling is kinda complex (monorepo) especially since I only open a subfolder. I've been able to setup tasks that I can run, but I've struggled with getting the agents to follow it.

Exposing "Spawn Task" as a tool that agents can use saves agent context, and provides users a way to have determinism when they want it.

I'd be happy to take on something like this as a first contribution. It seems like it utilizes a lot of the great stuff Zed already has. (mcrotty on discord)

[mrsnakeoil]

+1 for lifecycle hooks, especially generation_end.

The built-in Zed notifications on macOS spawn windows across Spaces, disrupting keyboard-based app switching (I'm a keyboard-only user; mouse use causes me accessibility issues).

I need a custom script on agent completion to play a sound ping, bring Zed into focus reliably, or send a clean desktop notification. This would vastly improve UX for longer agent runs without constant monitoring.
Strongly support implementing the proposed hooks, and the rest looks really great too!

[ishita-0301]

I agree with the lifecycle hooks.
What makes hooks valuable is that they become a universal interception point for every tool invocation. Once you have pre_tool_use and post_tool_use, an entire ecosystem of reliability and safety workflows becomes possible without modifying the agent itself.

For example

• Loop detection based on repetitive tool patterns
• Audit logging of agent actions
• Secret scanning before tool output reaches the model
• Auto running tests or linters after edits
• Blocking risky shell commands before execution
• Tracking which files an agent touched during a run

Projects like https://github.com/FailproofAI/failproofai are already exploring this model with hook based policies for execution guardrails and loop detection. The interesting part is that the same hook mechanism can support safety, observability, and automation use cases at the same time.

Custom commands and skills are great for reusable workflows. Hooks feel like the foundation that lets teams build reliable operational controls around those workflows.