Stop Re-Prompting the Same Thing: How to Pick Between Prompts, Skills, Plugins, and MCP in 5 Minutes
Conflating prompts, skills, plugins, and MCP connectors wastes 40%+ of your AI time. Use this decision tree to pick the right scaffolding primitive every time.
You’re Probably the Human Plugin Right Now
If you’ve ever copied text from one app, pasted it into Claude, asked it to reason about something, gone to fetch more data, checked the result, and then repeated the whole cycle — you are the human plugin. That loop is eating somewhere north of 40% of your AI time, and the fix isn’t a better prompt. It’s knowing which scaffolding primitive to reach for.
This post is built around a single decision tree: prompt vs. skill vs. plugin vs. MCP connector vs. hook vs. script. Work through it once, and you’ll stop second-guessing yourself every time you start a new AI task. The tree is simple enough to fit in your head. The hard part is understanding why each branch exists — which is what the rest of this post covers.
Why Getting This Wrong Is Expensive
The cost isn’t obvious at first. You write a long prompt, it works, you move on. But then you write it again next week, slightly differently. You paste it into Slack for a colleague who rewrites it. You spend twenty minutes re-explaining context that you already explained last Tuesday.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
OpenAI describes GPT-5.5 (and its Codex variant) as “better at messy multi-part work like planning, using tools, checking its work, and navigating ambiguity.” That description is doing a lot of work. The model got better at operating inside a harness — the scaffolding around it. If you’re still treating every task as a one-off prompt, you’re using a more capable engine with the same undersized chassis.
The four-level framework from the agentic AI world makes this concrete: Level 1 is chatbots, Level 2 is AI workflows (N8N, Zapier, Make.com), Level 3 is agentic workflows (Claude Code, Codex, Cursor), and Level 4 is full agentic AI systems. Each level gives the model more autonomy. But autonomy without the right scaffolding is just chaos with extra steps. The primitives — prompt, skill, plugin, MCP, hook, script — are how you build that scaffolding deliberately.
What You Need Before You Start
You don’t need to be an engineer to use this framework. You do need:
- A clear sense of whether a task is one-off or repeated
- Some familiarity with markdown (skills are just
.mdfiles with YAML front matter) - A rough map of which external systems your workflow touches
- An honest answer to: “Would I want my whole team to use this the same way?”
That last question is the fastest shortcut through the decision tree.
The Decision Tree, Branch by Branch
Branch 1: Is this task happening once, right now?
Use a prompt.
A prompt is what you reach for when the task is temporary, small, and specific to this moment. One-off note to a client. A quick analysis of a document you’ll never see again. A brainstorm that doesn’t need to be reproducible.
The mistake most people make is over-investing here. They write elaborate prompts for things they’ll do again next week. They paste in context that should live somewhere permanent. They treat the prompt as the whole system when it’s really just the entry point.
Prompts don’t carry permissions. They don’t travel with tools. They don’t share well across a team without friction. If you catch yourself copy-pasting the same prompt more than twice, you’ve already left prompt territory.
Branch 2: Is this a process your team does repeatedly?
Use a skill.
A skill is a markdown file — specifically a .md file with YAML front matter — that describes a reusable process in enough detail that any LLM can follow it consistently. Your house style for pull request reviews. The structure of a strong cold outbound email. The criteria for an editorial first pass.
The YAML front matter is what makes it machine-readable for progressive disclosure — the agent loads the skill when it’s relevant, not all at once. This keeps your context window clean and your token costs sane.
Skills are tool-agnostic. You write the skill once and it works with Codex, Claude Code, Cursor, or whatever harness you’re using next year. You don’t have to worry about portability. For a practical example of this in action, the post on automating social media content repurposing with Claude Code skills walks through exactly how a skill file gets structured for a real content workflow.
The failure mode with skills is proliferation. Once people understand them, they write dozens. Apply a power law filter: 20% of your skills will deliver 80% of the value. Find the ones that are repeated often, have high sensitivity to quality, and are currently eating the most manual time. Start there.
Branch 3: Does the workflow need to travel, or does it need tools?
Use a plugin.
A plugin is a bundle. It can contain skills, app integrations, MCP servers, hooks, assets, commands, and metadata. It takes a whole workflow, gives it a name, and makes it installable. The key word is installable — your team can use it without manually reconstructing the setup.
The outbound email example makes the distinction clear. A skill says: here is how to write a strong cold email — the paragraphs, the data to pull in, the close. A plugin says: here is the whole workflow, including a live connector to Salesforce that pulls the right contact details, a script that validates the output format, and the skill that governs the writing. Install the plugin, and all of that is ready to go.
Claude Design — Anthropic’s design product — is essentially a fancy plugin with a UI. The plugin was important enough that they made it a product. That’s a useful calibration for how much leverage is sitting in a well-built plugin.
If you’re building something that multiple people need to run the same way, or that requires live data, or that has more than two or three distinct steps — it’s a plugin. The comparison between Claude Code skills and plugins goes deeper on where exactly the boundary sits.
Branch 4: Does the workflow need access to a live external system?
Use an MCP connector (or app connector).
MCP stands for Model Context Protocol. Think of it as a universal plug to live data. When your workflow needs to pull from Salesforce, read from a GitHub repo, check a Figma file, or query an analytics dashboard, that’s an MCP connector doing the work.
The confusion here is that a plugin can contain an MCP connector. They’re not the same thing. An MCP connector is one brick. A plugin is the structure built from multiple bricks, which may include an MCP connector alongside skills, scripts, and hooks.
Most SaaS tools are aggressively building their own MCP servers right now. You often don’t need to build one — you need to know which one to install. The mental model: if the data is live and lives in another system, you need an MCP. If the workflow just needs that data as one input among many, the MCP sits inside a plugin.
Platforms like MindStudio handle this orchestration layer directly — 200+ models, 1,000+ integrations, and a visual builder for chaining agents and workflows — which means you can wire up MCP-style connections without writing the plumbing yourself.
Branch 5: Does part of the workflow need to be verified deterministically?
Use a hook or script.
This is the branch most people skip, and it’s where agentic workflows fall apart in production.
Not a coding agent. A product manager.
Remy doesn't type the next file. Remy runs the project — manages the agents, coordinates the layers, ships the app.
The rule is blunt: if the code needs formatting, run a formatter. If the schema needs validation, actually validate the schema. If the tests need to pass, run the tests. Don’t ask the model to imagine running the test.
Hooks and scripts are for the parts of your workflow where you cannot rely on the model remembering to be careful. JSON output that has to be valid JSON? Check it with a script. A review that must happen before the agent stops? Build that review into the loop as a hook. A generated file that has to meet a structural contract? Validate it deterministically.
This matters because a good agentic workflow is designed so that the deterministic parts are correctly framed as deterministic. The model handles ambiguity well. It handles “is this valid JSON” badly — not because it’s wrong, but because asking it to self-verify is the wrong tool for that job.
Hooks and scripts live inside plugins. They’re not a separate category of thing you install separately. They’re the part of the plugin that runs without asking the model’s opinion.
The post on Claude Code agentic workflow patterns covers several patterns where this hook/script boundary shows up in real engineering tasks — schema migrations and test loops are the clearest examples.
The Decision Tree, Collapsed
Here it is as a single pass:
- Once, right now, no repetition needed? → Prompt.
- Repeated process, same team, no live data needed? → Skill.
- Workflow needs to travel, be installed, or bundle multiple components? → Plugin.
- Needs live data from an external system? → MCP connector (often inside a plugin).
- Part of the workflow must be verified without model judgment? → Hook or script (inside the plugin).
Most real workflows end up at step 3 or 4. The plugin is the right unit of work for anything that has repeatable structure, involves more than one tool, and needs to be shared. The skill is the right unit for the process knowledge inside that plugin.
Where People Get Stuck
Treating plugins like App Store downloads. The App Store mental model makes you a passive consumer — you browse, you install, you wait for someone else to build what you need. The plugin mental model makes you an active designer — you look at your work, find the repeatable structures, and package them. These are different postures. The second one is where the leverage is.
Writing skills that are too broad. A skill called “write good marketing copy” is not a skill. A skill called “write a cold outbound email for a B2B SaaS product, structured as: hook paragraph, specific pain point, one-line value prop, soft CTA” is a skill. The specificity is the whole point.
Conflating MCP connectors with plugins. An MCP connector is a plug. A plugin is the appliance. You need both, but they’re not interchangeable, and installing an MCP connector doesn’t give you a workflow — it gives you access to data that a workflow can use.
Leaving deterministic checks to the model. This one causes silent failures. The model will confidently tell you the JSON is valid when it isn’t. The model will tell you the test passed when it didn’t run. Scripts don’t have opinions. Use them for the parts of your workflow that shouldn’t have opinions.
Making one plugin for everything. Customer success is not one plugin. It’s a refund workflow, an activation workflow, an upgrade workflow, and probably three more. Each plugin should have one job with clear edges. If you can’t describe what the plugin does in one sentence, it’s doing too much.
The ReAct Loop and Why Scaffolding Matters More Than Model Intelligence
At Level 3 — agentic workflows in tools like Claude Code, Codex, or Cursor — the technical name for what’s happening is the ReAct loop: Reason, Act, observe the result, iterate. The model decides the execution path, not you. That’s the meaningful difference from N8N or Zapier, where you define every step.
But here’s the thing: the ReAct loop is only as good as the scaffolding around it. A generic model without skills, without plugins, without hooks — it can say something useful at a high level. A scaffolded agent with the right skills loaded, the right MCP connectors wired up, and deterministic checks in place can review your work to your standards, use the right tools, and produce output you can actually ship.
Same intelligence. Different chassis.
This is also why the jump from Level 3 to Level 4 — full agentic AI systems, the territory of tools like Hermes and OpenClaw — is about harness engineering more than model capability. You’re building a system of files and instructions that loads the right context at the right time, carries memory between sessions, and coordinates multiple agents toward a shared goal. The Hermes agent framework takes this further with a built-in learning loop that improves skills from experience — worth understanding if you’re building at that level.
For teams building spec-driven applications on top of this kind of agent infrastructure, Remy offers a different angle: you write your application as annotated markdown — a spec where prose carries intent and annotations carry precision — and it compiles into a complete TypeScript backend, SQLite database, auth, and deployment. The spec is the source of truth; the code is derived output. It’s a useful reference point for how the “write instructions, generate artifacts” pattern scales beyond agent workflows into full application development.
What to Do With This Today
Pick one workflow you run manually more than twice a week. Ask yourself which branch of the decision tree it falls on.
If it’s a repeated process with no live data needs, write the skill. It’s a markdown file. You can do it in twenty minutes. If it needs live data or has to travel across your team, sketch the plugin boundary — what’s the one job this plugin does? What are its edges?
The goal isn’t to turn your workspace into a museum of plugins you never use. The goal is to find the parts of your work that are repeated, structured, and valuable enough to package — and then package them correctly so you stop being the human plugin.
How Remy works. You talk. Remy ships.
The multi-agent team patterns in Paperclip with Claude Code show what this looks like when you take it further — coordinated agents with heartbeat scheduling, each with a defined role and clear handoffs. That’s the direction this all points. But it starts with knowing whether your next task is a prompt or a skill.
