Slash Commands, Checkpoints, MCP, Skills, Plugins, Ralph Loops

The six terms live at different distances from the model. Slash commands are user-invoked entry points. Checkpoints are recoverable state markers. MCP connects the host to external tools and data. Skills package reusable instructions and procedures. Plugins distribute those procedures, agents, hooks, and MCP servers across projects or teams. Ralph loops are a workflow pattern: run the agent in short fresh-context cycles, verify externally, then commit.

The mistake is treating them as peers. They answer different design questions: how do I trigger the workflow, how do I recover, how does the agent reach tools, how do I reuse knowledge, how do I distribute the setup, and how do I keep long work from rotting the context window?

A slash command is a named entry point for a workflow you invoke deliberately, such as /review, /summarize-changes, /debug, or /deploy. In many modern agent hosts, custom commands have converged with skills: the command name loads a prepared instruction file, optional dynamic context, and a defined task shape. That means a slash command is not just a prompt shortcut; it is an interface contract between you and the agent.

Use slash commands for tasks with a clear start, input, and output. In the running notification-service example, /fix-duplicate NOT-88 can load the ticket, state the test command, require a plan first, and forbid secret reads. Skip a command when the task is rare or ambiguous; a brittle command for a once-a-quarter migration becomes stale faster than it saves time.

A checkpoint is a recoverable point before the next agent step. Some hosts checkpoint the session automatically; git gives you durable code checkpoints through commits, branches, and stashes. Treat both as recovery tools with different scopes. A session checkpoint can rewind conversation and tool state; a git commit can recover the repository after the agent or host is gone.

For notification-service, create a checkpoint before the first edit, after the minimal failing test, and after the fix passes. If the agent deletes an assertion or wanders into unrelated refactors, rewind the session or reset to the last clean commit. The failure mode is false confidence: a checkpoint that exists only in the agent UI may not preserve external side effects, generated files, database changes, or deployed state.

MCP (Model Context Protocol) is the tool and resource boundary. The coding host creates an MCP client connection to a server; the server exposes tools, resources, or prompts; the server then calls the real system such as GitHub, Slack, Postgres, a browser, or an internal API. MCP does not make a workflow agentic by itself and does not remove the need for authentication.

Use MCP when several AI hosts need reusable access to the same capability, or when you want a clean permission boundary around a tool. In notification-service, an issue-tracker MCP server can expose read_ticket as read-only while a separate GitHub server exposes create_pr behind confirmation. Skip MCP when a local typed function is simpler, especially for one fixed integration inside the same process.

A skill packages reusable know-how: instructions, examples, templates, scripts, and a description that helps the host decide when to load it. It is the right home for procedures you keep pasting into chat: review this diff, write a migration plan, summarize failing CI, generate release notes, or inspect a flaky test. Compared with always-on memory, a skill can stay out of the context window until the workflow is actually needed.

In notification-service, a email-dedupe-fix skill can teach the agent how this repo handles duplicate-emails, which tests prove the behavior, and what failure summary the team expects. A skill should not become a bag of every team preference. Put facts the agent always needs in AGENTS.md or CLAUDE.md; put repeatable procedures in skills; put tool access behind MCP or host permissions.

A plugin is a distribution unit. Instead of copying .claude/skills, hooks, agents, MCP config, binaries, and settings by hand into every repo, a plugin packages them with a manifest and a versioned install path. The important difference from a standalone skill is sharing and lifecycle: install, update, namespace, audit, and remove.

Use plugins when a workflow is useful across multiple projects or teams. For notification-service, a notifications-quality plugin might ship an email-dedupe-fix skill, a read-only ticket MCP server, and a pre-commit hook for risky delivery-retry files. Skip a plugin while you are still experimenting in one repo; start standalone, prove it on real work, then package it when duplication becomes the pain.

A Ralph loop is a practical antidote to context rot in long agent sessions. Instead of one giant conversation that accumulates stale assumptions, run the agent in short cycles: read the current plan from disk, perform one bounded task, write results back to files, run external verification, commit or revert, then start the next cycle with fresh context. The name is less important than the mechanism: durable state outside the chat and proof before promotion.

For notification-service, the loop file can hold the current objective, allowed files, test command, and done criteria. The agent gets one iteration: reproduce bug, add failing test, or implement fix. If the test fails, the loop records the failure and the next run starts from a clean summary rather than a bloated transcript. This is the rung-two discipline in Agentic Engineering Roadmap and the workflow-control idea in Evolution of Workflows.