Aside from the fact that Matt Pocock spends a lot of time with LLMS (only Claude really), he has a hand-wavy approach to engineering in a silo. He then uses that output as a foundation for other tools, while touting them as the best way to do things on youtube. Claude promotes this kind of developer and it's harmful.

Anyone who uses LLMs notices (intrinsically or through investigation) that there are a small number of useful instructions for LLMs, which is distilled from the language.

* Invariants (always/must, never)

* Precedence

* Guidelines/Opportunistic Inspection (softest instruction)

* Patterns

* Concrete commands/actions

- all of which can be mixed and matched.

The prose he writes often has very little utility, wrapped up in a ball of wax. I would at least expect that an engineer would run AI skill files through an impartial LLM to look for cruft.

eg "if this document is for an LLM to consume, is there any noise in the instructions? https://github.com/mattpocock/skills/blob/main/skills/engine..."

In my experience, it’s just easier to build it as you go. Every time the bot stumbles, make sure it’s a teachable moment and the lesson is learned. Every once in a while, do some house cleaning.

Trying to start with these preset banks of instructions just never seems like it works out in the long run. It’s also unsettling catching it behaving in an odd way, and realizing that it was taking a cue from instructions you never wrote, but imported from elsewhere. Like playing a game of pretend with someone else’s rules.

To each his own, but it seems like all this could be one moderately-sized AGENTS.md/CLAUDE.md, and much of it doesn’t need to be detailed at all.

For example, you could just put “always follow TDD” in there. If you want to be very complete you could add “first write tests and make sure they’re red before continuing to code. Make sure tests are green on completion”.

Skills are useful for calling specific scripts, adding specific data (like branding info) or detailing truly unusual, bespoke workflows (like the use of cutting-edge machine learning algorithms you’ve developed yourself or something). If you’re detailing something like TDD, you’re probably hampering the model by giving it a definition that is less accurate than the one it has learned in training.

If I had a nickel for every dev who has written a "productivity suite" of skills, and shared it with others as if it was a burst of innovation that everyone can benefit from (when it's really extremely specific to that dev and their workflow) ... well I'd have a lot of nickels.

It turns out productivity skill sets for Claude are a bit like opinions and assholes (everyone has one, and ...)

I mean, just to give you an idea of how common this is, my CEO made a suite like this ... although he had the self-awareness to realize what he made was very specific to him.

Matt Pocock really needs an AI sidekick that tells him what to do and what not to do. And give the AI the ability to electrocute him whenever he tries to overcomplicate things. Of course the device has to be around his groin area.

The second skill has this before/after example:

> BEFORE: "There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)"

> AFTER: "There's a problem with the materialization cascade"

It claims the second is easier reading. Is it just me, or does anyone else prefer the first?

Christ, this is exhausting.

Do Real Engineers use AI agents ?