When I see a task handed to an AI system, I keep asking the same question: is this a skill, an agent, or a skill being used inside an agent?

That sounds simple, but it matters a lot. The answer changes who owns the process, what the system is allowed to decide on its own, how reusable the work is, and what kind of failure you're willing to tolerate.

A skill is usually the reusable playbook: a clear procedure, good examples, and a well-defined outcome. An agent is the specialist working through a task with its own boundaries, tools, and decision-making. A combined design uses both: the agent owns the goals and coordination, while the skill supplies the detailed procedure.

The real problem is that this is easy to describe in theory and hard to judge in practice. So if I wanted to build an evaluator for this boundary, I would make it compare the same task through several candidate designs and then score them using the same evidence.

The evaluator treats the same task as the same input problem, then measures which design yields the best fit without just guessing from the naming alone.

Why a boundary evaluator helps​

The confusion usually starts because people use the words "agent" and "skill" interchangeably. That creates a few predictable mistakes.

• A skill becomes a giant catch-all prompt because the author wants to avoid making a real architectural decision.
• An agent gets used for work that is really a reusable procedure and should be a skill.
• A task is over-engineered by combining everything into a custom agent when a smaller reusable skill would be easier to test and maintain.
• The team ends up with a mix of helpful behavior and hard-to-explain custom logic that no one can confidently support.

An evaluator helps because it forces the decision to be evidence-based. Instead of arguing semantics, it compares the task across candidate designs and asks: which one has the best mix of correctness, maintainability, reusability, and safety?

The evaluation model I would use​

I would design it around one core idea: run the same task under a few candidate architectures and compare the results with the same standards.

The candidate set should not be broad or magical. It should be small and explicit:

• Skill-only: a reusable playbook that executes the workflow.
• Agent-only: an autonomous specialist that handles the task directly.
• Agent + skill: the agent coordinates and selects the skill for the mechanical or reusable steps.

This gives me three real design options, not just an opinionated label.

I would also separate two different concerns:

1. Ownership of the work — skill, agent, or combined design.
2. Execution topology — local execution, MCP-backed execution, or some external connector.

Those are different axes. A task can be owned by a skill and still run locally, or be coordinated by an agent while the actual data access happens through an MCP tool. The topology does not decide whether work belongs in a skill or an agent.

What the evaluator should measure​

Any serious evaluator needs to capture more than "the model liked the output." It needs structured evidence.

I would score the candidate designs on a few dimensions:

• Correctness: Did it perform the task accurately and safely?
• Reusability: Can the workflow be used again without rewriting the instructions?
• Clarity of ownership: Is the role boundary clear enough for a human to maintain?
• Operational burden: Is the process too fragile to repeat?
• Safety and guardrails: Does it avoid the wrong tool, wrong scope, or wrong automation boundary?
• Explainability: Can the owner understand why this design was chosen?

The output should say something like: "This task is better as a skill because the process is repeatable and reusable; this task is better as an agent because it needs context, judgment, and tool switching; this task is best as an agent plus skill because the agent owns goals but the skill owns the repeatable method."

That is far more useful than a vague verdict like "use a skill" or "use an agent." The point is to explain the tradeoff, not hide it.

The evaluator architecture​

I would keep the evaluator intentionally simple and grounded.

This is the kind of pipeline I would want: intake the source, normalize it, generate the design options, score them, and attach evidence to the final recommendation.

1. Intake the source​

A task or capability can come from several places:

• a repository-level agent definition
• a skill file such as SKILL.md
• a custom prompt or workflow doc
• a plugin package with a mix of agents and skills
• a task description from a human owner

The evaluator should record the original source and whether it is a supplied file or a generated counterfactual. This matters because a real file and a synthetic generated version are not the same thing.

2. Normalize the source​

The evaluator should parse only the parts that matter: the description, persona, workflow intent, tools, and any explicit operating constraints. I would avoid making up capabilities that are not stated. If the source is a skill, I would read the activation description and route it from there. If the source is an agent, I would read the persona and procedure boundaries. If there is no matching counterpart, the evaluator can generate a small counterfactual for comparison, but it should clearly label that produced content as generated and lower-confidence.

3. Build the candidate designs​

Then I would create three realistic versions of the same capability:

• S: skill-first design
• A: agent-first design
• H: hybrid design (agent + skill)

The important part is that they are not arbitrary. They are grounded in the source task and the available tool or procedural context. The generated counterparts should be small, deterministic, and explicitly marked as synthetic.

4. Score against outcome and operating constraints​

This is where the evaluator becomes useful. I would grade each design against a fixed rubric:

• How well does it match the task's real need?
• Is the output reusable or highly specialized?
• Does the institution understand who owns the procedure?
• Can the design be safely repeated without hidden coupling?
• Does it create a fragile, over-privileged agent or a narrowly scoped reusable skill?

This score should be transparent. The evaluator should not just say "the agent wins." It should explain why the hybrid design is better because the work is goal-driven, but repeated steps are stable enough to become a skill.

A practical rule of thumb​

I still want a few simple heuristics for human owners because the evaluator should not create more complexity than it solves.

Use a skill when the work is:

• reusable and repeatable
• procedure-driven
• easy to validate with a known output
• best run by a known sequence of steps

Use an agent when the work is:

• highly contextual
• decision-heavy
• sensitive to shifting goals or partial information
• dependent on tool selection and stateful iteration

Use an agent plus skill when the work is:

• goal-driven in the agent
• procedural in the skill
• reusable enough to deserve a playbook but context-rich enough to require a coordinator

This is the design pattern I come back to most often.

The local-vs-MCP distinction​

One subtle but important point is that the execution location is not the same as the ownership model.

A skill can run locally. An agent can also run locally. An MCP-backed tool can still be called by either one. The question is not "where is it running?" The question is "what is the durable responsibility boundary?"

This separation matters because a lot of bad design comes from collapsing separate concerns into a single abstraction. A local workflow is not automatically better or worse than an MCP-backed one. It is simply a different runtime topology.

The responsibility boundary is different from the execution topology. The decision about role ownership should remain stable even when the runtime changes.

The evaluator should therefore treat runtime topology as a separate axis from role ownership. The recommendation should state something like: "This workflow belongs in a skill, regardless of whether it is executed locally or behind an MCP layer; the connector is a runtime detail, not the architectural owner."

What makes this trustworthy​

The evaluator should be explicit about what is evidence and what is guesswork.

A trustworthy system should:

• record the source file and version
• keep the original source immutable
• label generated counterfactuals as generated
• avoid inventing missing capabilities
• compare only equivalent tasks
• use deterministic scoring for structural checks
• reserve model-based grading for softer judgments like clarity or maintainability

This prevents the evaluator from becoming a style guessing machine that only mirrors whatever the model thought sounded best.

The output I would want​

The final report should not be a vague verdict. It should identify:

• the recommended design
• the evidence that supported it
• the alternative designs that were considered
• the exact tradeoff and the owner guidance
• the confidence level and any limits of the evidence

A final output should read like a design recommendation, not a slogan.

If the recommendation says "better as a skill,” it should tell the owner why the process is stable, reusable, and testable. If it says "agent + skill,” it should explain that the agent owns the goal and the skill owns the procedure. If it says "agent-only,” it should explain why the problem needs judgment, state, or improvisation that a skill would hide.

The practical value​

This does not create a universal rule for every AI workflow. It creates a repeatable decision-making process.

That is the real win. It turns a fuzzy design argument into a reusable evaluation loop.

Instead of someone asking, "Should this be a skill or an agent?" and getting a hand-wavy answer, the owner gets a grounded recommendation with evidence attached. That changes the conversation from tribal preference to architecture.

And once you can evaluate the boundary consistently, you can start improving the boundary itself. The result is better routing, less accidental complexity, and stronger habits for building AI systems that are maintainable rather than just impressive.

My practical checklist​

Before I decide on a design, I ask these questions:

1. Is the task essentially a reusable procedure or a specialist role?
2. Do we need one clear sequence of steps or a flow that keeps changing based on context?
3. Is this something that should be reusable by other workflows or only used in one context?
4. Does the owner need a strong boundary, or is this a flexible orchestrator problem?
5. Will the result be easier to maintain if the procedure is separated from the coordinator?

If I can answer those clearly, the architecture decision becomes much easier.

When the answer is still messy, I do not force a binary decision. I treat it as a hybrid design until the evidence proves otherwise.

One thing I have learned is that good AI design is rarely about choosing one magical abstraction. It is about making the ownership boundaries visible and honest enough that a human can maintain them.

That is why I would build the evaluator this way: not to replace judgment, but to make the judgment easier to explain, reuse, and improve.

I wanted a better way to create skills for an agent plugin, so I read six public skill creators to see what they agreed on. A plugin is the top-level package. It can contain several skills, with each skill providing one reusable capability. A portable skill can also stand alone.

My quick recommendation​

• For one portable skill, start with .NET create-skill, then use the Anthropic skill-creator evaluation loop.
• For a Codex skill, use the OpenAI skill-creator as the design guide.
• For deep operational knowledge, borrow the vocabulary and anti-pattern techniques from the Forge skill-creator.
• For a plugin containing a family of skills or a publication pipeline, look at Skill Forge by AgriciDaniel or SkillForge by tripleyak.

What makes a useful SKILL.md​

The description does the routing​

The agent often sees the skill name and description before it loads the full file. Write the description in the words a person would use when asking for help. Include the artifacts, symptoms, or tasks that should trigger the skill.

Also say when the skill should not run. If two skills both claim "GitHub help," the router has little reason to choose the right one. "Review a pull request" and "repair a failing GitHub Actions workflow" are easier to route.

A narrow description can carry both the positive and negative routing signals:

---
name: workflow-repair
description: Diagnoses and repairs failing CI workflows. Use for failed jobs, logs, or workflow YAML. Do not use for pull request reviews or feature development.
---

The main file stays lean​

Put the instructions needed for most runs in SKILL.md. Move long examples, schemas, and domain references into files the agent can open when needed. Put repeatable or fragile operations in scripts.

A lean main file protects the shared context. Every line of background material competes with the task, conversation, and source files the agent also needs.

The main file can name the common path and disclose details only when needed:

---
name: release-notes
description: Drafts release notes from completed changes.
---

## Workflow

1. Identify user-visible changes.
2. Draft the summary.
3. Check [the style guide](references/style.md) when wording is unclear.
4. Run `scripts/check-notes.py` before returning the result.

The instructions match the risk​

Some work needs judgment. Give the agent principles and room to choose. Other work must happen the same way every time. Give that work a script or a strict sequence.

The OpenAI creator frames this as choosing the right degree of freedom. I find that more useful than treating every skill as a prose prompt. If a missed step can damage data or publish the wrong thing, do not rely on the agent remembering a suggestion buried in a paragraph.

The skill defines a finish line​

Say what the output should contain, how to represent partial success, and when to stop. Include the smallest question the agent should ask when it cannot continue safely.

Without a finish line, a skill can produce a plausible answer while skipping the check that mattered. "Update the file" is weaker than "update the file, run the existing validator, and report any failed checks without hiding them."

The finish line should make output, validation, and stopping conditions explicit:

## Finish

- Return the updated file and a short change summary.
- Run `scripts/validate.py`.
- Report every failed check; do not claim completion if validation fails.
- If the target file is unknown, ask for its path and stop.

Activation and execution get separate tests​

A skill can work perfectly when you force the agent to use it and still fail in normal conversation because the description never attracts the right prompts.

Test both:

1. Does the skill activate for several realistic requests?
2. Does it stay out of nearby requests owned by another skill?
3. Once selected, does it complete the task and produce the expected result?

Anthropic's creator is especially useful here because it treats skill authoring as a loop: draft, test, review the results, revise, and add the failures to the test set.

Microsoft and Azure skill examples​

These Microsoft-owned repositories provide strong Agent Skill examples for Azure and developer workflows. They are not ranked by usage. Each one demonstrates a pattern worth borrowing:

• The Azure AI skill routes requests across several AI services while keeping service-specific details in supporting references.
• The Azure Cost Management skill defines positive and negative routing, required roles, separate workflows, and safety guidance.
• The Azure SDK pipeline troubleshooting skill follows a focused identify, analyze, reproduce, fix, and verify sequence with fallback behavior.
• The Azure Policy external evaluation authoring skill shows how permissions, rejection criteria, validation, and stop conditions belong in safety-sensitive work.
• The ASP.NET Core Web API skill combines precise exclusions and deep domain guidance with security checks, examples, and a verification checklist.

A simple way to start​

I would create the next skill in this order:

1. Write three prompts that should activate it and three that should not.
2. Draft the description from the words used in those prompts.
3. Write only the instructions needed to complete the common path.
4. Move reusable facts into references and deterministic work into scripts.
5. Test routing and results separately, then revise from the failures.

The Agent Skills specification provides the portable base. Platform guidance, such as the GitHub Copilot agent skills overview, adds its own locations and runtime behavior. When skills are packaged in a plugin, keep plugin discovery and runtime rules separate from the portable skill instructions.

I came away with a practical test: can the agent find this skill from a normal request, and can it finish the work without guessing? If both answers are yes, SKILL.md is doing its job.

Two years ago seems like decades in the world of AI. AI slop wasn't a term I was familiar with, and the project I started with AI was meant to be short-lived—a stopgap until systems and people caught up to support the work.

Stage 1 - time-savings over process design​

Because it was meant to be a short-term solution, I didn't care about the what or how as much as the output and time savings. I didn't spend much time on it and certainly didn't architect it in any meaningful way. It was a markdown file - a prompt.

Back then, there was little concern for context size and the only harnesses were custom-made or 3rd party like LangChain.

It read source code and output what I asked it to based on my ever-growing prompt file. I fiddled with it when I had time but usually just took the output and made manual edits as needed.

Stage 2 - shifting sands of source code​

There were a few bumps in the road that caused the prompt file to sputter and halt. The related source code repo moved. That was just one place in the prompt file - an easy change. Then the source code repo completely refactored into a monorepo - that was much harder. The prompt file was looking at specific folders, files, classes and property names. A much bigger change to the prompt file. And of course, I still had other things to do.

Then the source project became much more popular and the feature set grew. Lots of changes and additions. This resulted in a short cycle of my wondering if AI, or my prompt file needed another rewrite.

At this point, I thought regex and a script might be faster. Leave any LLM decision/transition until later.

This was becoming an experiment in how to gain efficiency in a rapidly changing AI world.

Stage 3 - back to reality​

While I was considering shifting to a code-based solutions, the source repo created a CLI to reveal its features. That was exactly what I needed: a dependable input to my process.

The AI SDKs had also progressed, so instead of regex and a script, I switched to .NET and the OpenAI SDK for chat completions. This time I designed the process deliberately, and Copilot Chat in VS Code was available, which helped accelerate development.

This time the architecture, project structure, maintainability, and testability were top considerations as I was still relying on this thing to help me.

There were a few iterations of this but it was beginning to hum along.

Stage 4 - the infrastructure​

Since I only had the OpenAI resource in Azure, I kept it live and never shut it down. However, I used keys instead of managed identity—not because I didn't know the best practices, but simply because I lacked the time to implement them.

I was doing a lot of Bicep work, not an expert but not a newbie either, so cooking up the ./infra and azure.yml for Azure Developer CLI wasn't hard. Adding the RBAC roles for managed identity helped. And then finally I had that repeatable infrastructure I told everyone else they should have.

Stage 5 - monkey on the keyboard​

The underlying project repo had matured significantly, the source code had stabilized, and my system was working well for its purpose too. However, as AI slop became an industry term, the underlying project matured alongside the industry specs it supported but my project had not.

I managed the project in chat one turn at a time, and the .NET app generated the output. However, every change to the system required several to many turns, redirections, and re-runs. AI kept making the same mistakes, and I spent my time minute by minute watching the output to see when it went off track. I needed a better process—a process to manage the process.

Stage 6 - hiring a squad​

It was around this time I started working with Brady Gaster's Squad. Having a team of agents accelerated progress and caught issues and inconsistencies I hadn't been able to spot before. I onboarded Squad to the repo and had them take on much of the work.

Stage 7 - industry grows up​

While I was learning Squad's inner workings, SKILL.md and agent.md specifications emerged. I dug into skills first to impose structure on my manual process management. I used WAZA and other frameworks to understand context size, triggers, and evaluations.

Building and maintaining skills locally gave me practical understanding of task boundaries, debugging, and chaining. Working with these units of AI many times a week gave me opportunities to fail.

Stage 8 - leaving Squad behind​

Squad is an amazing build and maintenance platform. However, I need skills that succeed independently. The plugin specification is now available, so I took my chained skills, wrapped them in an orchestrating agent to manage gates between skills and human review, and packaged everything as a plugin.

Stage 9 - the agent and the app​

What about the .NET app? It's now used only when the agent determines it needs that full pipeline. The agent and skills handle most of the work.

Conclusion​

You'll likely continue to hear a lot about AI slop. Just like any industry, AI is maturing and developing better specifications and expectations. Look for them and try them out.

Focus on the fundamentals available at the time. Build with principles and practices that support them. Grow with industry specifications that enable better results.