By Tom Watson in ai — 27 Mar 2026

Is This Just a Skill?

At one point everything was an app, or at least someone said it should be an app. Now I wonder, is everything a SKILL? And what's the difference between a skill and an actual product. I consider this with something I built and then decided...I think this is a skill.

Photo by Leonie Clough / Unsplash

I built an app a few months ago. It's called ImpactPath. You can sign up, log in, have a conversation with an AI that guides you through creating a theory of change for your organisation, and at the end you get professional outputs: a logic model, executive summary, visual diagram. It works. It's a genuine product if a little unfinished.

I stopped building it, partly because I need to make choices about where I spend my time and I think there are more interesting and valuable ways of helping people thinking about impact and learning. But also... I started wondering: is this just a skill?

Are you just a .md file?

There's a tongue-in-cheek website doing the rounds called Death by Clawd — the "SaaSpocalypse Survival Scanner." You enter a SaaS company and it rates the probability of being replaced by a Claude Skill. It's a joke, maybe, but within every joke, isn't there a semblance of truth?

A lot of software is essentially packaged expertise with a billing system attached. And if the expertise can be written down, if it's procedural knowledge, decision trees, best practices, structured processes, then maybe it can be a skill instead of a subscription.

Now that AI can produce things at speed, we can make so many more things. The cost of building has collapsed, an idea in the morning can be a deployed app by evening.

But for many of those things, maybe most of them, should they be apps at all? Or are they just a SKILL.md file waiting to happen?

There's now an open standard for packaging expertise in a format that AI agents can use. It's called Agent Skills, and the specification lives at agentskills.io. Originally developed by Anthropic, it's been adopted across Claude, OpenAI Codex, GitHub Copilot, VS Code, Cursor, and over twenty other platforms.

A skill is a folder containing instructions, scripts, and resources. The core is a SKILL.md file: metadata describing what it does and when to trigger, then markdown with the actual guidance. You can include reference files, templates, executable scripts. The agent loads what it needs, when it needs it.

So now, every time I start building something, I find myself asking: is this just a skill?

What I actually built for ImpactPath

Before I could build the app, I had to build the expertise layer:

A data schema for capturing organisational context: mission, beneficiaries, activities, resources, geographic scope
A structured conversation flow that moves through stages: context gathering, activity mapping, outcome definition, assumption surfacing, measurement planning
Methodology for moving from vague impact language ("we help people") to specific outcome statements ("participants report increased confidence in managing their finances within 3 months")
Guidance on surfacing assumptions: what has to be true for this theory to hold?
Indicator selection logic: qualitative vs quantitative, primary vs secondary sources, realistic collection frequency
Output templates for different audiences: funder-facing, board-facing, community-facing

The app wraps all this in authentication, saved progress, a nice interface, export buttons. But the real core of it is the methodology, the schema, the process, the examples.

And that could all live in a SKILL.md file.... in fact I DID extract all this into a skill which you can see here!

So when is something just a skill?

A skill is enough when the value is in the knowledge, not the infrastructure.

If what you're building is essentially "here's how to do this thing well", a methodology, a process, a set of decision rules, a framework for thinking through a problem that's probably a skill. The AI agent provides the interface. The skill provides the expertise.

Where does a creating a Theory of change sit on this? It's the expertise, the questions to ask, the order to ask them, the way to structure the outputs. A skill can encode all of that.

Brand guidelines? I have skills for The Good Ship brand. Colours, fonts, layout patterns, tone of voice. From here I can create slides or documents or use it in HTML and CSS for websites

I think a skill is enough when:

The value is procedural knowledge that can be written down
The user already has access to an AI agent
The outputs are documents, decisions, or structured data rather than ongoing services
There's no need to persist state across sessions (or the user's own systems handle that)
Security and access control aren't critical differentiators

When something goes beyond a skill

But sometimes a skill isn't enough. Here's when you probably need more:

Scale and concurrency. A skill runs in one person's conversation, but if you need to handle thousands of simultaneous users, coordinate between them, or maintain shared state, you need infrastructure.

Observability and analytics. Skills are somewhat opaque, meaning you don't easily get aggregate data on how they're being used, where people get stuck, what outputs they're generating. If understanding usage patterns is core to the value proposition, for improvement, for reporting, for demonstrating impact, you probably need an app layer that captures this.

Repeatability and consistency. Skills depend on the underlying model, which updates, changes, has different behaviours across platforms. If you need guaranteed consistent outputs, the same input always* produces the same output, for compliance or contractual reasons then you need to control more of the stack.

Services, not just outputs. A skill produces outputs: documents, recommendations, structured data. But what if the value is ongoing service? Monitoring, alerting, scheduled tasks, integrations that run without human prompting. That's not a skill.

Security and access control. Skills inherit the security model of wherever they run. If you need fine-grained access control, audit trails, data residency guarantees, or compliance certifications, you need infrastructure that provides these. A skill for handling sensitive health data is risky if you can't control where it runs.

Identity and payment. If you need to know who's using it, limit access, or charge money, you need infrastructure around authentication and billing.

Network effects. Some products get more valuable as more people use them. Shared databases, community contributions, aggregated insights. A skill is individual. There's no mechanism for one person's use to improve another person's experience, unless you actually build that mechanism.

*always is an interesting concept when using LLM's for most anything

The honest assessment of ImpactPath

So is ImpactPath just a skill? Would Death by Clawd give it a high mortality rating?

100%, yes. The core value, guiding someone through theory of change creation could absolutely be a skill. Someone with Claude Pro could get 80% of the value by loading an impact-framework skill and having the same conversation.

What the app adds:

Saved progress (you can come back tomorrow)
Polished visual outputs (the diagram generation is fiddly)
A front door for people who don't use AI tools directly
Eventually: funder-specific templates, organisational accounts, portfolio views for funders

Is that enough to justify the app? Honestly, I'm don't think so. The saved progress is nice but not essential for a process most people complete in one sitting. The visual outputs could arguably be skill-generated. The front door matters if your users aren't already in AI-native workflows, which admittly many users still aren't yet.

The portfolio view for funders might be the thing that actually requires an app. That's aggregate data across multiple organisations, shared state, access control. There's probably collaborative infrastructure potential, but realising that means people investing in this as a concept.

What this means for building

I'm not saying don't build apps. I'm saying ask the question first.

When you have an idea, before you spin up a repo and start scaffolding authentication, ask: is this just a skill? Could I write a SKILL.md that captures the expertise, test it in Claude or Cursor, and see if it actually delivers the value?

If yes, maybe that's the product. Maybe that's enough.

And if it turns out you need more, scale, observability, services, security, network effects, you can build the infrastructure later. But you'll be building it on top of a skill that already works, that already encodes the expertise, that you've already validated.

The skill becomes the foundation with the app becoming the distribution and interface layer on top.

What this means for domain expertise

Here's where it gets interesting for organisations, not just builders.

Every organisation has embedded expertise. Previously, that expertise stayed trapped unless you built a product around it which requires funding, technical capability, ongoing maintenance, commercial ambition. Most organisations quite reasonably said "that's not our core mission" and the expertise stayed local.

Skills could potential change this.

What if packaging your expertise as a skill became a normal thing organisations did? Not as a product to sell, but as a contribution to a commons. The way you might write a guide or share a template, but machine-readable, executable, actually usable by anyone with an AI agent.

I wrote a piece called The Interface: Building Blocks for Just-in-Time Software which takes this a new level, but perhaps skills are enough.

The value isn't in the delivery mechanism but in the knowledge about how to do something well. Skills make that knowledge portable.

I wonder if there is value in skills discovery, either automated or workshopped, understanding the various ways across an organisation that people encode expertise naturally in their everyday. Could these be skills that could be adopted across an organisation?

Not every idea needs to be an app. Not every workflow needs a SaaS. Not every piece of expertise needs infrastructure wrapped around it. Sometimes a SKILL.md file is the product. Sometimes the answer to "are you just a .md file?" is: yes, and that's fine.

So next time you're about to build something, ask yourself: is this just a skill?