i thought the same thing but i bought a model y a few months ago and turns out that's exactly what I want. 90% self driving and really the 10% is entirely the last part of a drive because it picks stupid parking spots and doesn't know how to enter my driveway, other than that it's driven perfectly

well, perfectly is a bit much, it doesn't know how to dodge potholes yet and it sometimes misses exits/turns, but it's never done anything i would call dangerous

for skills related to specific cli tools, i just wrote a standard for this! it's obviously not widely used yet, but since mise will support installing the skills alongside the tool, i suspect it will have decent adoption

i used to be a bit bearish on skills—thinking that llms should just use --help, but i've come around on that. i think skills are a great way to describe higher level workflows that use multiple commands.

https://jdx.dev/posts/2026-09-05-introducing-packslip/

I'm biased but I think it's silly to think either one is going away anytime soon

well mise uses dotenvy right now (for env._file anyhow), it may be worth switching to dotenv-ng but I haven't looked into it yet https://github.com/jdx/mise/blob/fc441787fe52b46be1245046758...

I assume you just mean normal [env] in mise.toml which is different, but this still is relevant to mise

Yes - I think .env files are not a good idea (works for one person but even then it's not great)

90% of australians live in 0.22% of the country's land

Whole the us has different numbers, but the same point applies. Most of the people in the US live in dense enough areas. The Mid west has similar size and population as France for example.

i think that sentence is taken out of context a bit, the problem with those pkg binaries is that they're not portable—which the post describes

EDIT: actually no, I think charlie is wrong on that point, he said the installers compile python but that only happens with python-build-based installers like pyenv. still, the fact those binaries lack portability is the real problem.

mise uses these as well and adopting them has been a massive improvement in the user experience for my python users. y'all have been doing a fantastic job maintaining them.

i'm also doing the same for ruby—maintaining the binaries myself which is becoming the default in mise next week: https://github.com/jdx/ruby

i'm a firm believer that pre-compiled, portable binaries are the best way to distribute runtimes and clis.

The combo of mise + UV has made my development environment setup/recreation so seamless. We've come a long way.

(Props to your work on mise)

I think node already does this (sans AI), idk where the code lives but deno could probably just use the same list of repos

I agree that it sucks not being able to have comments in package.json, but I think it's the right call to not adopt something like jsonc. It would break so much tooling at this point I don't think it would be worth it.

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise)

In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

why not both?