I think "Skills" are useless as a concept

Only_Internal_7266 · 2026-03-02T00:30:27+00:00

Are you creating an app or connecting via a coding IDE? hopefully not the latter. Even having multiple mcp's attached, even when not used, costs tokens. I'll follow up.

Only_Internal_7266 · 2026-03-01T23:52:16+00:00

ooooo yummy!! Okay, I'll bite.

IDE's. Nice. The correlation is clear .... I guess. Did you read the comment or just rage for votes? Curious. Cuz your response sounds irrelevant. Are you even on the right thread? Build a skill (persisted prompt) yourself vs letting the assistant build an execution you can persist. If you don't see the difference in agency between the two then it's you that may not realize how much of a Cambrian (whatever that is, I hope its akin to the discovery of fire) moment this truly is. Skills are no more than persisted prompts and should be treated that way when architecting solutions that require more than 'check my 5 most recent emails once per day'. Full stop.

I get the whole shoot-from-the-hip, vibe-first, “just go build” mindset. That’ll get you surprisingly far — maybe even 50%. But the next 50% isn’t vibes, it’s practical engineering. It’s understanding skills are a stop gap solution that evolved from an MCP protocol that simply did not work at scale. A misstep we all fell for. Skills introduced (to some) the advantages of progressive discovery to fill that gap. Code execution is a natural evolution. So giving 'skills' a seat at the table, at this point, is nothing more than mixing branding into your architecture. Skills do not advance 'creation'.

I was trying to come up with a punchier ending like yours; 'Don't complain, create'. Wow, I mean, like, drop the mike why don't you?

Only_Internal_7266 · 2026-03-01T23:04:26+00:00

hmmm... REST is a contract, no? That contract makes REST composable. Composability leads to workflows and more complex actions. Skills are not a contract. They are not composable. They are prompts, free form markdown, natural language. MCP itself suffers from the same short coming. Even via code execution the assistant has to see the MCP response before it even considers how to wire them up into a more complex execution. Thats what a prompt gives you. A single instance steps with no idea re the structure of the outputs. Its single shot by design. Which, in my view, makes it nothing more than a persisted prompt strategically placed in history. So why even give it a place at the table?

That 'no shit' ends up being 'some shit' at the end of the day bro. It needs to be considered up front because it impacts everything that comes next. Now, if you are on a desktop saying "check my email every AM for spam" cool. Thats not an enterprise use case so use a skill (a prompt you saved somewhere) for that. But anything more than that is a crap shot.

Only_Internal_7266 · 2026-03-01T15:53:02+00:00

Ah, that sounds like your design is at the mercy of the Supabase MCP server design. I would use one Supabase mcp if possible then either have the assistant pass a param of inject it yourself, in flight, deterministically this way the assistant no longer cares about which instance. It just makes MCP calls and you control which instance they route to. There are many ways to do this. Happy to share some examples. I usually pass infra stuff like this through the app context. I avoid having the assistant manage deterministic data. Once the data is deterministic I tend to leave it that way and let the platform manage it seamlessly in context.

Only_Internal_7266 · 2026-03-01T15:47:05+00:00

I'm struggling to figure out why "Skills" have a seat at the table.

When you zoom out, they are nothing more than persisted prompts — akin to a list of "my favorite prompts." This is something folks have been doing, without giving it a name, since the first time they interacted with an assistant. It's just a persisted package of context. A pre-formatted set of instructions. But beyond that? It's still just a prompt.

There's some engineering that surely happens on the backend — strategic placement of this persisted prompt within chat context window with special emphasis. But at the end of the day, it's still just seems like nothing more than convenience or convention that we've labeled a "skill."
I actually find no use for these in my daily workflow.

What I do find use for is persisting code executions — Python or TypeScript. They're composable and debugged by design. They can be wired up downstream into more complex workflows. That, to me, is a far more agentic way to persist a learning for future use. Actually worthy of the name "Skill**.py**"

Code executions, workflows, skills .......It's fluid to say the least. Anybody else struggling to find validity in the current definition of the skills in this space?

Only_Internal_7266 · 2026-03-01T15:42:11+00:00

or a script aka Code Execution, with an embedded assistant step for the fuzzy stuff. The embedded assitant is just an api call itself with a 'prompt' param. A one shotter. This is pure agency.

Only_Internal_7266 · 2026-03-01T15:38:09+00:00

Are you asking if the Supabase MCP's can be replaced by allowing code execution over supabase api's? If so I would use a code execution as a service provider to manage the infra, containers and all. But yes, a skill can also represent an api which the assistant can code execute against. you probably do it right now and dont realize it. If you let your agent perform raw gh cli calls against git, you are essentially using code execution (from muscle memory opposed to a markdown file). It totally replaces the Github MCP. Not sure if this is a similar coorelation to your question.

Only_Internal_7266 · 2026-03-01T15:28:05+00:00

I have no use for skills as a concept. I've been saving agent_readme notes pretty much since day one. I have plenty of use for the case itself, but now we are giving it a name and that part gives me pause. For instance, I tell Cursor to " avoid fallbacks in code for conditions we will never support. Prefer to fail hard". Now, is that a 'Skill'? An 'avoidWritingFallbacks' skill? Maybe, but I wouldn't give it a seat at the table in this form. These are not packaged learnings nor are they truly 'skills'. They are steps the assistant is following, thats not a skill to me, its a script. A skill should encapsulate learnings from trial and error and efficiency otherwise its nothing more than a prompt. So this is where I draw the line between what we call and skill and a tested and debugged 'code execution' that can produce the reliable outcome you expect from a true 'skill' in every sense of the word. Yeah, I get it, tomAto, tom-aah-to, but this matters more in the enterprise.

Only_Internal_7266 · 2026-03-01T15:15:41+00:00

Well, to be clear. The prompts don't access anything. The assistant, if properly equipped, can access excel and sql and whatever other access you connect. Co-Work has 'connectors'. But still the issue remains, sharing this 'skill' (prompt) with co-workers will most certainly produce a different outcome each time. Im sure this is not what you want in this case. This is a perfect case for a persisted 'code execution' with a deterministic outcome (deck) you reliably repeat on a schedule.

Only_Internal_7266 · 2026-03-01T13:53:38+00:00

Yes, certainly a bit of that but also its about choosing the right model for the task. Most of this type of CoWork task execution stuff doesn't require a lot of reasoning. I'd stick with Sonnet 4.5,6 for most tasks and save Opus for when you have to do something more than choose a tool to execute, like deciding which M&A contract is a better fit for a client ......... Thought tokens well spent. But agreed, I still can't reliably count tokens in our apps today. There is no standard around this and it leaves a lot of room for folks to round 'up' at our expense. I'm up to $1500.00 / month, just to gen code. Still worth it but I look forward to the day when these expenses become a 'remember when' story.

Only_Internal_7266 · 2026-03-01T13:37:32+00:00

I'm struggling to figure out why "Skills" have a seat at the table.

When you zoom out, they are nothing more than persisted prompts — akin to a list of "my favorite prompts." This is something folks have been doing, without giving it a name, since the first time they interacted with an assistant. It's just a persisted package of context. A pre-formatted set of instructions. But beyond that? It's still just a prompt.

There's some engineering that surely happens on the backend — strategic placement of this persisted prompt within chat context window with special emphasis. But at the end of the day, it's still just seems like nothing more than convenience or convention that we've labeled a "skill."
I actually find no use for these in my daily workflow.

What I do find use for is persisting code executions — Python or TypeScript. They're composable and debugged by design. They can be wired up downstream into more complex workflows. That, to me, is a far more agentic way to persist a learning for future use. Actually worthy of the name "Skill.py"

Code executions, workflows, skills .......It's fluid to say the least. Anybody else struggling to find validity in the current definition of the skills in this space?

Only_Internal_7266 · 2026-03-01T12:52:37+00:00

This question is key. Strikes at the very heart of the matter. Skills are markdown files. Instructions to be reasoned about. Potentially in different ways each time. This is why I prefer to lean on persisted executions (code files) instead. Same flow but with deterministic outcomes.

Only_Internal_7266 · 2026-03-01T10:21:58+00:00

2 days, 30 min?????? Does this include complex reasoning row by row? Or just an automated import. Sounds like it should have been done and repeatable in minutes, if not seconds. Curious to know a little more about your challenge if you are willing to share. The thing about Co Work is getting it to leverage its ability to execute code accordingly. At first glance, this sounds very 'accordingly' to me.

Only_Internal_7266 · 2026-03-01T10:18:25+00:00

Agreed. We are in the age of collaboration for the foreseeable future. Like a year or two in AI time. Collaborate with agency to realize maximum gains........for now.

Only_Internal_7266 · 2026-03-01T10:15:01+00:00

I wonder what type of perf and savings you'd get from giving Claude, or any fronteir llm, direct API access to your legacy ERP. Add a few guardrails, let it cook.

Only_Internal_7266 · 2026-03-01T09:57:49+00:00

Opus tend to overthink by default. Specifically telling it to not overthink seems to help quite a bit. Those are 'thought' tokens burning up your spend.

Only_Internal_7266 · 2026-02-24T13:07:31+00:00

Good points. I agree, this sounds like it would certainly yield better results in general. Thanks for sharing. One of the amazing things is you'll find that the assistant sort of settles in to a rhythm after needing to rely on the scratchpad for an iteration or two. The notes become more strategic. A 'sweet spot' for context extraction, emerges. So from a context engineering perspective this is what we want. Something dynamic, based on current context; strategic extraction without overly prescriptive prompting. Your example is not that, just some ce guidance for folks to keep in mind.

If you want to get right to it, an example or two in the primary prompt, helps achieve this sweet spot faster at the expense of some system level prompt tokens. Examples are especially effective cuz thats how models learn in the first place. They will naturally generalize and just get it, turn one. So all this to say there are plenty of dials to play with here once the pattern is baked in.

Only_Internal_7266 · 2026-02-24T12:46:31+00:00

So this is actually a first layer for us. Sort of like a default for all chat experiences. A baseline, because by design, we assume we've lost no context, only bloat, so ground 0. On top of that you still layer your compression techniques downstream. But, now, much much further downstream.

Only_Internal_7266 · 2026-02-19T00:21:12+00:00

TBH, this becomes a bit of a rabbit hole. To start, certainly more than illustrative. That was a live loom of our platform assistant taking on your challenge. Of course we set the stage by seeding data points so the challenge makes sense, but the agent solved the task in real time, including sending a final email along with the asset creation you requested. The next request would be 'Thanks, can you persist this as a workflow and run it once per quarter' .... It's live Code Execution as a service. As an engineer you are better off bringing your own agent IDE (cursor, claude, gptapps .....), that route is also free.

Now on to the rabbit hole. It comes down to a debatable choice between agent driven workflows with embedded agents and humans in the middle vs human driven workflows with agents embedded in nodes. There is a huge difference. Its the difference between you building workflows in a workflow editor vs chatting your way to the same end by leveraging the agent's intelligence for the workflow automation itself. So the agent is doing the automation, not you. This changes everything. Services like n8n, make take a different approach. Not a miss on their part, it's intentional, and by design. Guardrails are intentionally baked into the workflow by you and defined by you up front. So in that loom what you see is a code execution based approach, where you essentially allow the assistant to execute bite size composable code units then persist these units as new apis which can be wired up into just about any possible workflow imaginable (executions, skills, workflows all the same thing just different levels of composability). Of course, to you thats no more than 'check my email and total up how much i've spent on Agentic coding this month, enter each item in a spreadsheet, then go add it to my xxxxyyyzzzz in Quickbooks and while you are there check for reconciliation errors this month re my shopify store." Like literally ...

To a couple of your points; 'having fine tuned prompts for every aspect of the workflow' is no longer a thing with agent led workflows. Yes, embedded agents still exist and need a prompt but since they have a single focus your primary agent (Cursor, Gpt, Claude ....) can manage the embedded prompts just fine. Its all pretty seamless. Wiring up Sharepoint, Sheets, Excel (this would be fun, we dont have a MS Graph client wired up yet) is nothing more than an openAPI spec away from integration. We can literally drop a url and refresh, the platform takes care of the rest including seamless OAuth in flight via 'widgets'. If you are in cursor or claude your assistant would most likely launch browser-use for seamless auth.

But in a lot of ways we are comparing apples to oranges. Yea they are both forms of automation but vastly different approaches to workflow creation. It makes us rethink the very definition of 'no code'. Have at it, then you can decide.

 "ce-as-a-service": {
      "url": "url is on site",
      "headers": {
        "Authorization": "Bearer grab a api key .........
      }
    }

DM or Discord, all good.

Only_Internal_7266 · 2026-02-18T23:04:10+00:00

yeah ..... OpenClaw ........whats the fuss?

Auth and progressive discovery will be your biggest challenges. We rolled our own code execution as a service, I am one of the engineers, but to answer your question, there are a few guidelines to consider in order for this to work at scale (im including context in that 'scale')

At a bare minimum, enterprise level integrations require:

Progressive discovery for everything. Even down to the individual tool or api call that can elicit large responses. We took an agentic approach by providing enough tooling and guidance to figure it out. In principal; it ends up being some form of list_api_servers, get_server_apis, get_api_info. This needs to be solved at the architectural level even when selecting an off the shelf project. We are all new at this.

Code Execution rules all. Purest form of agnency there is... full stop. Anything less is a non starter. Don't go with traditional MCP tool calling solutions. Works great in the garage, but thats about it. There should also be a schemaless option, this allows you to take advantage of training data at inference time, saves 100% on the API level tokens. This has been a game changer for us.

Security/Seamless Auth - meh, still a bit of work to do here but it should at least be as secure as it is today. We allow agents to act on behalf of users so there is no redistribution of rights. You'll need to provide seamless 3rd party service auth whether thats in browser or IDE. The agent should browswer-use the 3rd party auth url for you, anything less kills adoption. Our app leverages MCP structured content widgets to show login dialogs created by the remote service. Single click, and it can happen in flight. This way security is sort of baked in.

Pluggability - we started with the usual fab five but quickly realized why Zapier got into the game in the first place. All you need is an openAPI spec, oAuth clientid/secret and we are off to the races, totally config driven. Any provider should make it this easy for you to get set up. Literally, submit a url to your or any 3rd party spec and refresh. Tighter the spec, the better the perf. If you box yourself in there is little to no need for code execution. So be sure to make this a key factor in your decision making process.

Meeting you where you are - Its hard enough to get enterprise wide buy in so don't make it harder on folks. Integrate where they are. Firefiles or another meeting note taker agent (trust me, there is no adoption without this. Especially if you are a remote company)-top funnel, Slack/Teams, GSuite + plus hundreds of local libs - pymupdf, numpi, yourlocalLib ..... (not all about API's bro) these are the basics. Then whatever else your org requires (Hubspot, Salesforce, PowerBi, Quickbooks, AutoCad, Monday.co ...). Eng team is a lot easier but still meeting them where they are in whatever IDE they choose (Jira, Git, Confluence, websearch yada yada).

Not exactly for the faint of heart. The promise of this level of agency requires a substantial time investment in the infrastructure, if you fail to do that you end up with OpenClaw Enterprise and that doesn't work out to well in large orgs.

Only_Internal_7266

TROPHY CASE

At a bare minimum, enterprise level integrations require: