Hacker Newsnew | past | comments | ask | show | jobs | submit | jdxcode's commentslogin

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?


I always like to mention rcm. It's not a popular one but I tried probably 10 managers before it and much prefer it to the competition: https://github.com/thoughtbot/rcm


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: