There is one particular GitHub repo that

I've been eyeing for a long time and

just never took the time to dive into.

It's by a person that I've interacted

with a bunch in the past who if you've

been around for a while I am sure you're

familiar with. I've often called myself

the second best TypeScript YouTuber and

the reason is because of this

individual, the number one Matt HCO. He

published a set of AI skills for real

engineers that I honestly kind of

dismissed initially, but over time he

has continued to refine them and be

realistic with them. And what he's

created is a set of small and simple

markdown files that have racked up over

200,000 stars on GitHub, making it one

of the 10 most starred projects on all

of GitHub. Truly insane. All for

markdown files. I've wanted to see what

the hype was about for a while here, and

I've seen people saying really good

things about them, especially the grill

me skill. And this has also been a video

I've planned for a while to the point

where my whole Twitch chat is freaking

out. Thank you. I stayed up till 3:00

a.m. for this. Long overdue. Finally,

three streams ago. Since this was put in

Notion, Matt's updated the skills

multiple times. Yeah, you guys have

wanted to get my honest thoughts on

these skills for a while. In order to do

that, I had to use them. So, I did. Over

the last week, I installed a bunch of

the skills from Matt Poco's skills repo,

which is full of gems that are worth

talking about, from his process to the

actual skills themselves. If I only

covered Matt's skills, though, I'd be

doing this ecosystem a disservice. The

vast majority of these skill repos are

absolute slop and should be ignored. But

there is one other I'm excited about. PA

stack created by Lauren, otherwise known

as Potato, one of my old favorite React

core team members, who is now at Cursor,

and built a wild set of skills that are

really fun and surprisingly powerful. I

have went through and audited the

majority of the skills in both of these

suites, pulled in my favorites, and I've

been using them actively. I cannot wait

to show you everything I've learned

after a real quick break for today's

sponsor. Let's be honest with ourselves.

We've moved past the era of doing one

thing at a time. And as great as this

is, there's a lot of random problems

it's caused. Things like knowing where

to run your code when you're working on

it. Things like making sure your CI is

actually running performantly and well,

and that it's doing things in parallel.

And just knowing what's going on across

all of the projects that are shipping at

your company. All of this is obnoxious

to do by hand, and it's becoming more

and more of my work. Well, it was before

I started using today's sponsor. You

probably already heard me talk about

Depot. They're the best place for your

GitHub CI and for your Docker builds,

which makes everything way faster, up to

55 times faster for a lot of real world

use cases. Their best-in-class runners

make everything faster, and their cache

helps everyone on the team get started

quicker, too. The cache is shared across

your entire team and your CI for your

Docker builds, which helps a ton with

speed. GitHub actions are also way

faster, too, up to 10 times faster when

you use them on Depot than with

traditional GitHub action CI. And if you

add the depot CI runners, things go even

faster because they can do actual

parallelism. But that's not what I

promised. I was talking about working in

parallel, not just building in parallel.

Well, that's where's remote agent

sandboxes come in, making it trivial to

spin up your real images and your real

projects in the cloud with your cloud

code. If you already have depot set up,

you can just run depot cloud instead of

cloud directly and is now running in a

remote sandbox instead. Ship faster and

unblock yourself at soyv.link/depo.

Couple things I want to say upfront

before we go too deep into all of these

skills that have been provided by these

different places. The first thing, and I

really want to emphasize this, you do

not get anything out of blindly copying

other people's setups. You should treat

these things not as a set of steps to

take, rather as a set of information to

consider as you build your own systems

for coding with AI. If you just copy

paste my codebase and change things,

you're not a very good engineer. But if

you use my codebase as a reference point

to learn and build your skills as you

craft your own code bases, then you're a

good engineer. The same difference

applies here. If you just blindly copy

my exact setup, it's like paying a bunch

of money for a code template. It's

cringe and bad and it means you suck at

engineering. Period. So, don't just

blindly install all the skills here. At

the very least, start with a slightly

better entry point. I see my chat

realizing that Potato was one of the

builders of the React compiler. She's

one of the biggest contributors there.

She's unbelievably talented. Yeah,

Pstack is going to be the underrated gem

in this and I think you guys will like

it a lot. I want to start first with how

I set this all up. I started with a

prompt. I want to figure out which

potato pack skills would map well to the

work that I do. I want you to audit my

usage across my main machines which were

this MacBook, Leftbook, and BB1. Compare

my usage against the skills in Pstack.

Make a nice list ranking all of them by

how well they fit me and how much they

could benefit me. Pull history here

first, then break up sub agents to do

auditing. Opus 5 for all. I had a bunch

of Opus 5 to burn at the time, so that's

why I was testing this. and I linked to

Pstack. It then created this document

for me where it pulled in all the skills

and then ranked them based on how strong

of a fit they were as well as how

beneficial they would be to my work and

then a little brief why. So, it

immediately called out the interrogate

skill, blast radius, technical writing

arena, the prove it work skill, and a

few others. I will say that this deep

dive was inspired by one particular

thing. It was the interest I had in the

unslop skill because I had seen Lauren

posting some of the pros that her agents

wrote. I was like, "Oh, that looks

significantly less cringe than I'm used

to Claude writing." So, I quickly

grabbed this unslop skill, which is

very, very simple. There's also some fun

prompting details here in the

descriptions Potato uses because again,

as I mentioned before in my like

Markdown overhaul video, the

description's role isn't to accurately

describe everything the skill does

because it's just Markdown. The

only point of the description is to

trigger the skill when it should

trigger. You should treat the

description as the thing that gets the

model to do this rather than as an

accurate description of everything the

model can do with the skill. I see it

kind of similar to a YouTube video

thumbnail where the role of the

thumbnail isn't to accurately

encapsulate everything that the video

has in it. It is to get the right person

to stop scrolling and click it and watch

it. The goal of the description is

similar. It's to get the right agent for

the right task to decide, "Oh, that

skill is useful. I should pull that in."

It shouldn't be called a description. It

should be called a trigger. All of these

standards were written in the old

anthropic days before anyone knew what

the they were doing. We're stuck

with it. It is what it is. Anyways,

let's take a look at what the skills

actual content is. So, again, if you're

not familiar with how skills work, they

have a name and a description. The

models have access to all of your

skills. They just see the name in the

description and then they decide, "Oh,

that skill could be useful to me right

now based on its description. I'm going

to pull it in now." And then what it

does is it just reads this markdown file

into context. So when it pulls in the

unslop skill, here's what it reads. Edit

text to remove AI patterns and add a

human voice. The process is simple. Scan

for the patterns, rewrite, preserve

meaning, match intended tone, add some

soul, and then self audit. Quote, "What

makes this obviously AI generated?" Then

you go and fix the remaining tells.

Adding soul. Removing patterns is half

the job. Sterile voiceless writing is

just as obvious. Have opinions. React to

facts instead of neutrally listing pros

and cons. Very rhythm. Short sentences

then longer ones that take their time.

Mix it up. Acknowledge complexity. Quote

impressive but also kind of unsettling

beats impressive. Use I when it fits.

First person isn't unprofessional. Let

some mess in. Perfect structure looks

machineade. Be specific. Not this is

concerning, rather, there's something

unsettling about agents churning away at

3:00 a.m. Don't call me out like this.

Patterns to detect and fix. This is one

of the things LM are really good at is

if you give them an example of bad and

then show them good, they will follow

good very well. But if you don't have

certain things in those examples, they

will continue to do them bad. So you got

to find the balance there. The patterns

to detect and fix. The first is in

content puffery. So, lots of these

phrases. Pivotal moment, testament to

evolving landscape. Setting the stage,

cut the puffery, say what happened,

named dropping, listing media outlets

without context, just pick one and say

what was said. Superficial ing phrases

like highlighting, ensuring, reflecting,

showcasing, delete them. Promotional

language as well, vague, you get the

idea. It also calls out M- overuse.

Somehow, I still see a lot of M dashes

coming out of Opus. The others have

followed this much better. Chat's saying

that it's a good thing to point out how

good the semantic density is here. I

agree. This is not slop. This is very

easy to read and the info is

communicated very effectively. It's just

well written. And when you have good

writing in your history, the models are

more likely to follow it. And if you

tell said models to follow it, they're

much more likely to. There's also a

whole section here to remove chatbot

phrases like, "I hope this helps. Let me

know if found the smoking gun." all

those types of things. No mention of

loadbearing. Sadly, there's a whole

section about jargon. This is my

favorite piece though. Say what it does,

not how it feels. Instead of the

database stays close at hand, say

something much more direct. SQL returns

the exact string sent to the database.

That's so much better. Ask what the

sentence tells the reader to do or know.

Then write that. If you can't restate it

as a concise instruction, fact, or

number, cut it. One more check. If the

sentence could appear unchanged in

another project's docs, it says nothing

about this one. Cut it. So, let's see

how this works. I will just ask with

GPT56 high. You know what? We'll give it

something harder. I'll use Opus 5. It's

going to take too long. I'm going to

stick with Soul for this just because it

will be done faster. What is this

project? Help me understand it and why

someone would be interested in using it.

Or I can just grab like any of my other

existing codeex threads and you'll see

the difference. Here is one where I

asked it to update my Swift UI app.

Build 26 is uploaded to App Store

Connect and processing also completed.

Bullet point list of the exact things

done. Public distribution cannot yet be

verified because the app store connect

browser session expired. Sign in at

link. Then I can assign build 26 to the

public beta group if automatic

distribution does not handle it. This is

so easy to read. It's so much better.

And you'll notice when I make new

prompts, one of the first things that

happen is implying of the unslop skill.

I'm also applying the required unslop

writing skill so the answer stays direct

and easy to scan. And then it did. And

now it wrote a very simple, easy to read

blob of text. T3 code an open source

control center for coding agents.

Instead of using codeex, cloud code,

cursor, grock or open code through

separate terminal tools, you control

them through one desktop web or mobile

app. I'll show you the comparison in the

easiest way I can think to do it. I'm

going to ask in chat GPT directly where

I don't have my skills to look at T3

code. Same rough prompt just like said

what it was specifically to make it

easier. Let's see how it does here

without these skills. The core idea is

already clear. T3 code is not another

coding model and not mainly an editor.

God, I didn't realize how quickly I

adjusted to unslopped text and now when

I read the sloped text, it hurts me.

It's actually insane how much of a

difference I can already see just from

that. Again, T3 code is an open source

control center for coding agents. The

core idea is already clear. What using

it looks like. A normal workflow is run

the command, open a project, start a

thread, ask it to inspect or change the

project, review messages and code

changes, continue from your desktop

browser or phone. T3 code also manages

terminal terminals, agent sessions, git

diffs, and checkpoints. Each turn can

have a checkpoint which lets you inspect

or revert what the agent changed. Short

version, T3 codes across plate control

center. This is the like quote from the

docs. It turns these providers from

separate terminal programs into one

coherent agent workspace mdash with

desktop web, iOS, and Android clients.

There's a T3 code is and T3 code is not.

The strongest pitch is not chat with AI

and nicer windows. It is operating

several autonomous developers without

living in several terminal tabs. Remote

agents become practical. One interface

across providers. It's designed for

parallel work. The especially compelling

use case for your setup

versus why someone would use it. One

interface works with several providers.

Threads persist so works easier to

resume. You can control agents on

another computer from your phone or

browser. Your files and provider

credentials remain on the machine during

running the server. It's insane. These

both came from the same model for adding

one markdown file. It's so much more

readable. I have been enjoying coding so

much more since I saw this one stupid

skill. Thank you, Potato, and thank you

Pstack for providing me this wonderful

unslop skill. Hopefully, you can now

understand why I so quickly went down

this rabbit hole. It's because I was

really impressed with that skill once I

installed it. So, I then went through

all the Pstack skills to see which other

ones might fit me, too. And as I was

doing this, I had the realization that

I'm sure you guys could have predicted

that I also should probably look at the

Matt Pocco skills. So, I linked that as

well and ended up getting another

document of all of Matt's skills and

which ones fit my use case as well. Now,

it's time to dive in to all of these

skills and what value they can bring

you. I have been focused on Pstack for a

bit too long. So, let's hop over to

Matt's skills instead. The main

directory that we care about is

skillskillsengineering.

There's ask Matt, code review, codebase

design, diagnosing bugs, domain

modeling, grill with docs, which is an

update to his grill me one, implement,

improve codebase architecture,

prototype, research, resolving merge

conflicts, set up Matt PCO skills as a

skill itself, TDD, dissect, tickets,

triage, wayfinder, and wizard. I want to

start by playing with a few of these.

I'm going to grab the improve codebase

architecture in Grill with Docs. If

you're ever curious about a skill and

how it behaves, the easiest thing to do

isn't to install it and then hope for

the best. It's actually quite simple.

You can usually just copy paste it. In

this case, this skill is calling for

other skills. It's actually hilarious

how simple the grill with docs is. It's

a relentless interview to sharpen a

planner design, which also creates docs,

ADRs, and glossery as we go. He also has

disable model invocation on for a lot of

his skills, which means the model won't

enable it itself. You have to manually

pull it in with a slash command or a

dollar sign command or something like

that, which I think is a very good call,

especially with how some of his skills

work. But some of them that isn't

necessarily the case. Like when I'm

going through the diagnosing bugs skill,

this one I probably shouldn't have to

manually pull in. And sure as hell, he

doesn't have this as a manually pull in

skill. This is a skill that will

invocate itself when it's helping debug

issues. And I've had this skill fire and

help with a lot of my debugging stuff

over the last few days, and it's been

pretty solid. It seems like my agents

find the root cause and can communicate

what's wrong much more effectively. So,

let's look at the new grill me and

grilling skills because these are the

ones that are referenced there. Here is

the grilling skill. Grill the user

relentlessly about a plan, decision, or

idea. Use when the user wants to stress

test their thinking or use any grill

trigger phrases. Interview the user

relentlessly until you reach a shared

understanding. Map this as a design

tree. Every decision branches into the

decisions that hang off it. Work the

tree in rounds. The frontier is every

decision whose prerexs are already

settled. God, why is he using M dashes

in his skills? Matt. Matt.

How many are on this? There's nine M

dashes in this page. Matt, I was

wondering why I was getting M dashes

again. It might be Matt's skills.

There's at least one per paragraph for

most paragraphs. Oh, this hurts me. I'm

still going to try it. And I told you

guys there's an easy way to try skills.

You copy the text, go to your agent, you

do whatever you want to do, and then you

paste it. So, I'm going to ask it to

grill, not me. Ask it to grill Lake Bed.

Lake bed. Paste. Pick machine. I want

you to grill me about Lakebed, the

project itself and its goals, everything

in the agents MD, Claude MD, etc. I want

to make sure we are on the same page

about what we are building. I want to

use Matt PCO's

grill skill. Don't have it installed. I

will paste the text below. And now I

have successfully used the skill without

installing anything by just copy pasting

the text. Obviously this will not work

with skills that have other things like

scripts associated and whatnot, but you

can copy the script over. It's fine. Or

just tell the model about it. It can go

find the script and download it. It's

fine. This is the easiest way to test

out a texton skill. Literally just copy

paste the text. And now we have this

Opus 5 run on my remote Linux box

running and it will grill the out

of me momentarily. It took almost two

minutes, but it has its first pass here.

Cloud MD is badly stale. The repo

countries its own vzero rule and there

are two competing execution models in

the tree.

Question one, who is the user and who

pays? As well as example answers we

could give. Question two, what is the

actual next milestone? because there's a

mess of like launch prep files, HTML

files with like random plans. The to-do

MD that's in organized from a PR cleanup

program, not as launch Q3, is the

capsule format a spec or just our

implementation.

What is the ceiling of one capsule?

These are actually good questions. And

now I'm curious, do we get similarly

good questions if I ask a different

model? Let's switch over to soul with

the exact same thing. Oh, I already have

the grilling skill installed. Yeah, I

did carry that over. God, the 56 autism

is so real. The grilling skill requires

me to find repo facts instead of asking

you. I just realized I use this on low

and slow. I should be using this on high

and fast. Get better answers faster. I

will stop that because I don't care

anymore.

Oh wow, it finished before the stop even

persisted. That's hilarious. What is

LakeBed? Who is the primary customer?

What does full autonomy mean? And what

is a capsule? All good questions. Let's

see how the high version does. Oh, and

Hi, it spun up some sub agents in the

background to do more hunting to get

more data for future questions. Start

with the same what's the primary user

all with like quick answers which makes

it really easy to go through just like 1

A, 2B, 3A, etc. Again, like the question

asking tools in a lot of these harnesses

and agents just aren't good enough to

have the like question asking UI come

up. This is a lot quicker to just blast

through. So, one, I'm gonna say it's the

autonomous app platform. Two, I'm going

to say these two are the users that

matter. Three, doesn't give me a simple

answer, but I can just tell it what I

don't want, which is uh agents should do

everything other than payment details.

Four, how much should lake bed own? Uh,

own everything as needed. Five, which

rule wins? The current guidance contains

principles that will conflict. I want

simple where possible but also rewrite

where beneficial. Six. What's the

product boundary? Should lake bed remain

a real open and useful system while the

hosted cloud platform is the production

path? Uh local is only dev sim. That's

nice and easy. And I'm already realizing

that I need to clean up this project

based on the simple quick start of this

grilling section. Okay, I'm seeing the

light. This is useful. I should have

tried this before. Let's keep going

through these skills. Teach is one I've

heard really good things about. This one

is also disable model invocation. So you

have to trigger this with /each. The

users asked you to teach them something.

This is a stateful request. They intend

to learn the topic over multiple

sessions. Interesting. Treat the current

directory as a teaching workspace. The

state of their learning is captured in

this directory in several files. Very

interesting. So, you're supposed to use

the teaching skill in like its own

folder. Huh. I want to read more from

the top level. I feel like I am not

going through this the right way.

Interesting. One of the skills is ask

Matt, which is specifically meant to

help you figure out what skills or flows

fit your situation. There's grill with

docs, as we talked about before. Triage,

which helps move issues through a state

machine of triage roles. Improve

codebase architecture. This is one I

actually wanted to try.

A lot of these are self-referential

where like the codebase architecture one

will say to run the codebase design

skill in order to get the vocabulary

present candidates as an HTML report.

Nice. Somebody likes HTML skills. I like

this a lot. Condexmd vocabulary for the

domain.

Then it calls out grilling as well as

domain modeling. Wayfinder is a fun one

too for planning huge chunks of work. I

also really like the separation in the

docs between user invoked and model

invoked because these are very

different. Like these are effectively

plugins that you call when you want them

yourself. Model invoked is more steering

the model to do different things in

different ways. And these ones are very

useful. Like I said mentioned before,

the diagnosing bugs one has helped me a

ton already. Wizard seems really cool

too to walk human through steps only

they can perform. This is super cool

when like an agent can't access some

dashboard it needs to or there's a

pseudo call that it can't run. Wizard is

a guide to help the agent set things up

so that you can just run the one script

and then handle things from there. Uh do

I have this one? Because if I don't, I'm

going to go add it now. I don't. I guess

here I'll give you the spoiler of how I

actually set up all of these things. I

did all of this in a thread in T3 code

in a repo that I already made called

fleet where I manage all of my like

skill files and things. So in here I'm

going to do this specifically. I'm going

to ask uh did we set up the wizard skill

from Matt's repo? If not, set it up now.

Note that we have one more machine in

the fleet to deal with. Well, cuz since

I last worked on this, I added my new

Mac Mini. So, I want to just give it a

quick little hint that the new Mac Mini

exists so that it will touch that as

well. Apparently, I should have been

reading the docs the whole time. My bad.

Yeah, the getting started is the setup

skills command which helps you like set

up issue tracking and whatnot in a way

that the skills will handle it. The main

flow is to start with grill with docs,

get interviewed about a plan and record

the decisions. Then to spec, to turn

into a spec, then to cut that into

tickets for Jira, linear, GitHub issues,

whatever you want to use, implement for

actually building it. and then code

review for reviewing it after. Shaping

is fun for turning vague ideas into real

executable plans. Wayfinder helps you

chart a large effort as a map of

decisions and settle them. Prototype is

for actually like making designs and

mocking things to see what you really

want before you ship it. Just deletable

code. And the research skill for getting

cited answers from primary sources. I

don't know if I would ever need that. I

feel like the agents are pretty good at

verifying their claims if you just ask.

Then we have improve codebase

architecture. This one seems fun.

Diagnosing bugs, resolving merge

conflicts, triage, and wizard. I am

excited to try out wizard. Productivity

skills like grill me, handoff, two

questionnaire, teach, wait what, and

writing for agents. Then the reference

skills like codebased design vocabulary

for deep or designing deep modules,

interpreting the words a project uses

and writing them down. Domain modeling I

think is a really helpful one. I've been

in like writing down my own grammarss

and like glosseries with agents in every

project on like what terms we use to do

different things. The idea of it being a

skill does make sense to me. I am

increasingly tempted to just install all

of them, but I'm very happy with my

current setup and I don't want to muddy

it too much more. So, I'll continue

doing what I normally do, which is just

telling my agent to rip the parts I want

and keep them in my fleet directory.

This little fleet repo saved my ass so

many times. While that is running, let's

see the followup here. Okay, we got a

bunch more questions.

Which form of simplicity matters most?

Oh, this is brutal because I want all of

these types of simplicity. God, this is

this gets deep. I don't want to answer

these questions. That's the point, isn't

it? I I really don't want to have to

answer this because my answer is all

three of these. I want them all. Okay, I

said I will begrudgingly pick a even

though I want them all. What apps must

lake bed support? A and B, not C. How do

the two primary users divide control? If

the developer and agent are both

primary, what does each one own? So like

who chooses architecture, data models,

deploy timing, etc. Dev chooses nothing

but app functionality. Cool. That's it.

That is answered 10. Does everything

include irreversible actions? Authorized

agents be able to delete production

data? Uh, yes. They should be able to do

whatever. Where is the payment boundary

will be sub plus monthly limits. Agents

can use them as they please. 12. What

must the local simulation preserve be?

Cool. This is great. I'm actually

disagreeing with the recommended answers

pretty often, too. This is

actually going to help me. I'm annoyed.

Now, this skill is on all my machines.

Cool.

Opus caught all the changes to my

systems.

I know it's silly, but like all this

text is so much more readable than older

agentic stuff I was doing in like the

same project with the same codebase and

the same agents and models and

everything. I asked a question and it

gave me a direct answer. No, wizard was

never set up. It ranked seventh in the

previous report, but you only picked

seven skills and it wasn't among them.

It's installed now. Whereas like if I

scroll back far enough to things from

before I had these set up just like any

old thread. Here's a recent changes

summary. Here's a ready to share

writeup. I treated landed as changes

that reach main T3 code the last three

days. Oh, this is it trying to like

match my tone. Release publication now

uses the job scoped GitHub token instead

of competing for the ra the shared

release app API quota fixing repeated

nightly failures. Oh god, the M dash

hell, I said push straight to his

branch. Done. The follow-up commit is

now on his PR branch directly. M dash

5561 shows us it's the fifth commit and

the review bots are rerunning against

the new head. His PR is still based on

one merge behind the thread pageination

PR landed since. It's still mergeable

per GitHub, so no action needed.

Rebasing his branch under him felt more

intrusive than the situation called for

worth watching whether the effect

service convention check goes green now.

M dash that was the hard blocker and my

context.reference reference approach is

a light lighter remedy. Oh God, I can't

even like read this and I'm trying to

like read it out loud for you guys in a

video. It's so much worse. God, life

post slop is unbelievably cool. Oh god,

I got another like 10 plus questions for

me. I'm going to do this off stream, but

I'm actually going to do it because

these are good questions. This does

remind me that I have a branch I was

working on in T3 code that I'm I have

new ideas for now, too. I was working on

a skill manager feature in T3 code.

Yeah, this cross computer skill manager

page that I was working on to make it

easy to just manage skills on your

machines through like one layer. What I

want is now is the ability to disable

them and mass like to have groups of

skills like the Pstack skills and the

Matt PCO skills and be able to turn them

all on and off or just turn on the ones

I want. That would be so nice. Yep. The

wizard skill has now appeared on all of

my machines. Yay. I don't have anything

that needs wizard right now, but I am

very excited to try that one. It makes a

ton of sense to me. I will say most of

these skills feel more like prescribing

like mental workflows and like giving

you an easy entry point to try them out.

Especially stuff like the main flow

section here with the grill with docs to

spec to ticket implement code review. I

don't necessarily want this much

prescription on how I go step by step.

Like I've been building my own workflows

and they don't map quite as well to

traditional stuff. There's a ton of good

things that I'm grabbing from here. Like

the wizard skill, the grilling skill is

clearly super super useful. I'm going to

play more with the codebased design and

the like followup cleanup ones. I have

heard wait what is really good as well

as the writing for agents. The writing

for agents one I've actually been using

a bunch. Writing great skills was turned

into writing for agents. This is useful

because agents are really bad at writing

instructions to other agents. If you let

your agents write skills for you, write

markdown for you, write prompts to sub

agents for you, all those types of

things, it can do a very bad job. So

giving it better instructions on how to

do it right sounds very compelling to

me. Wait, what's another one that I'm

really excited about? It pulls in

simplify technical English which a

dedicated video on this bit coming in in

the near future. It's a simple skill

that's user invoked and three lines

long. The point is to get a simpler,

easier to digest description of

something when you get a response that

makes no sense. He does call out that

this only repairs one message. It

doesn't prevent the next sloppy one. The

solution and the cure for this type of

jargon is a shared language built up

front using the grill me with docs

skill. Reach for wait what when you

don't have that setup done yet. I am

very excited for wizard. I'm going to be

using that a ton. I I I can think of

like four things I should have used it

for yesterday. I really like how he's

documenting all of this stuff. Like this

is a good docs page. There's a lot to

learn from here in the best sense. Here

we are. Wait, what? Super simple. And

again, it disable invocation. It means

you just type in the one skill

invocation with the slash command,

dollar sign, whatever. Wait, not m dash.

Ah, I almost want to make a dm d-ashed

Matt Pocco skills fork where it's just

the exact same repo but all the m dashes

removed the description. Stop that last

did not land. M dash repitch it. God, I

I almost want to see how many m dashes

are in this project. Yes, it's just one

reject move at all. I know. This is one

I was actually really excited about. The

the writing for agents. Oh, this one's

long. Good. It should be reference for

writing any document that an agent

consumes. a skill, an agent or clot MD,

a dock reached by a pointer. I've mostly

been using this for prompting sub aents

and it's been very helpful there. Too

many M dashes still. When the document

you're writing is a skill, read the

skill mechanics MD file for front

matter, invocation choice, and router

skills. Context pointers. Context

pointers are reference held in the

agents context that names some out of

context material and encodes the

condition for reaching it. The skills

description is one. A line in agent MD

naming a dock is the same object. A

pointer's wording, not its target.

Decides when an agent reaches the

material and how reliably. A must-have

target behind a weakly worded pointer is

a variance bug. This is unreadable. I

mean, I'm not surprised, but god damn.

Ow. Versus unslopped. Just a chunk of

it. No.

No.

I don't trust these anymore. Does it

just see markdown as AI generated? Is

that my problem here? Cool. I passed

100% human written. Yeah, very likely

all of these were written by AI, which

is annoying because I have had not great

luck with AI written stuff. I'm amazed

that the unslop one is allegedly AI

though because that skill read very

easily and was very dense and well

written. I will say regardless of if

they're both AI generated, I find Pstack

writing to be a lot more readable and

also the behaviors from these skills to

be a lot more applicable for my

day-to-day. The arena one has been super

fun. Fan out parallel attempts at the

same task. Read every candidate end to

end. Pick the strongest as the base.

Graph the best ideas from the others

into it. Verify the synthesized results.

This has been a very fun skill for those

of us who are uh token burners because

we have a bunch of usage to get through.

Start a to-do list with one entry per

phase before launching anything. The

arena runs autonomously and the list

keeps phases from silently disappearing.

Frame, fan out, cross judge, pick,

graft, verify, then descriptions of each

phase. Surprisingly little text for how

much this does. Like this one scale has

cost me hundreds of dollars of inference

because it just does the same thing

multiple times. This writeup is very

much tied to cursor specifically, which

is the biggest issue with Pstack. I

honestly would be pumped if somebody

like cloned all the Pstack skills in a

generic not cursor specific way because

there's so much gold in here, but a

handful of these are just a little too

cursory. She did also pull the bro skill

from uh I believe it was originally

Dylan Moy, the effect and functional

programming JavaScript guy. Restate your

me last message. Stop using jargon and

speak coherently. State it more simply

and concisely like one human talking to

another. I think this is basically

identical to wait what? Yep, pretty much

identical. Also, one of the few that

potato has is disable in vacation, which

is interesting. She normally just lets

the model do its thing. Blast radius is

awesome, too. I've been using this one a

ton. Find what a change breaks somewhere

else before it chips. Use blast radius

of X. What could this break? Or

reviewing a small diff that you don't

trust. comparison or companion to how

and why. How tells you what the code

does. Why tells you why it's shaped that

way. Blast radius tells you what it

breaks somewhere else. I hope this calls

out you can't trust your own writeup.

Specifically saying that like the

history of this thread is not

trustworthy. So don't hand back the

write up. Find the one or two facts the

whole thing depends on and prove them by

running code. This one is great and has

cpped a couple things that would have

been miserable if I didn't have it. It

also calls out that it should write the

response through unslop to make sure

that it's not a mess. This is great. I

didn't want this to be like a one or the

other thing where it's like P stack

versus poc skills. I didn't intend for

it to be that at all, but I am much more

philosophically aligned with what Potato

is cooking over here. Oh yeah, she also

has the show me your work skill, which

is really cool if you ever want to

understand why an agent did something to

like keep track of what's going on. Keep

a reviewable decision trail for long

running and unattended work. A TSV log

with one row per decision. What? Why?

Evidence and result. Local by default.

Commit it when a reviewer needs the

trail to trust the result. Use for/ow

your work. Autonomous or multi-phase

runs or work a human reviews after

stepping away. Gives it a format on how

to log its work and its decision-making

process all in a simple TSV format that

is easy to like read and do in other

things. One row is one decision or

checkpoint. If it doesn't fit one line,

the decision isn't crisp yet. Append

only. A wrong call gets a new row that

supersedes it. Refer evidence produced

by committed scripts over handmade

one-offs so reviewer can rerun it.

Interesting. This one seems really cool.

Actually, I'm going to play with this

more later. This video is supposed to be

an overview, but what you're getting

instead is my actual process. I did

pretty much exactly everything you're

seeing here, but with slightly less

depth a few days ago, and that's how I

found the cool skills that I did find.

And this is what you should be doing as

well. You shouldn't just blindly install

a bunch of when you could take the

time to read the things that map up to

the work you do and how you do things

and pull over the parts that you

actually want. And it all should start

with something small like grab the one

you like. I think everyone should have

unslop at this point. This skill has

fundamentally changed my willingness to

read the things that my agents say to

me. It's been great. God, this video

could be hours long or it could be a

45se secondond short. It could be a lot

of different things. It isn't quite what

I expected it or wanted it to be, but I

hope you can get some good takeaways

from it still. The first thing you

should do is you should grab your agent

and you should open it up and tell it

about Pack and tell it about Matt Poclls

and ask it to look through them and then

look through your histories and figure

out what makes sense based on what you

do. Maybe you should install the unslop

skill before that though because then

you'll actually want to read the

responses you get. Afterwards, you

should look through that. You should

read the markdown for the skills you're

installing before you install them. Then

you should decide which ones you want.

You can tell your agent to set it up.

You can do a single repo that represents

all your skills like I do. I think it's

really powerful. You have a lot of

options here for how you choose to

manage all of this, but you should be

managing it. You shouldn't be blindly

copying someone else's setup. You

shouldn't be running commands that

install 500 skills you don't know

anything about. You should take this

opportunity to refine your toolbox based

on what you see working for others and

what you try setting up yourself. You

should, based on your own history and

your own usage, make subtle adjustments

and changes. And you shouldn't be scared

of editing these files. I've noticed a

lot of people are scared of opening up

their Claude files and like the Claude

and the agents directory on their

machines. That's silly and you have to

get over it because there is so much

cool you can do the moment you

start digging in and playing with these

things. You got to be willing to edit

those files. I joke now that the only

time I open my code editor is to edit

markdown files, but like it's barely a

joke at this point. It's markdown files

and environment variables at this point.

And it has helped a ton. It's one of the

biggest shifts that has allowed me to do

way more parallel agent work. It's a

huge part of why I was able to ship so

many PRs with so little breakage over

the last weekend. The way I work is

really different now. And it's largely

because I took the time to go deeper in

these directories and pull together

skills for myself and others that make

sense for the work that I do. And I hope

this inspires you to go do the same.

Explore these collections of skills

people have published. Don't blindly

install them. Poke around at them. Try

them out. Pull the parts you like,

ignore the parts you don't. Play. I

think I've said all I have to here.

There's some really good stuff in Matt

Skills and even more good stuff in

potato skills. Check both out and maybe

make some of your own, too. I'm curious

how this affects your workflows. Let me

know. And until next time, peace nerds.