x uralys/web * M www

then you go work with your modifications on your project. https://github.com/rupa/z is perfect to go from projects to projects.

  ls | xargs -I % sh -c 'cd %; pwd; [[ $(git status -s) ]] && echo WIP || echo clean'

I do not need a CLI tool. I can come up with a very simple script or even an one-liner (like you just did) to achieve what I want.

Worth noting that neovim shows some git status when editing a file inside a git repository, and there are ways to do the same from your shell.

FWIW, I think this project was vibe coded with an LLM, but if it works, it works, so it makes no difference to me. The only reason I mentioned it is that "vibe coding" is not inherently bad. I do not even like the term. If you "vibe code" without knowledge, then yeah, it is bad, just as bad as a shitty developer writing code is.

This sort of response to complex solutions used to be more prevalent on HN. When I got downvoted I was like "..this is the end isn't it" :P Maybe the unix way is a dying strategy IDK, but you give me hope.

> FWIW, I think this project was vibe coded with an LLM, but if it works, it works, so it makes no difference to me.

I did not realise that, I'd be far more worried about running it than most human coded projects out of fear of it doing something destructive. Not that humans don't make mistakes, but at least they have a mental model and intent. I suppose it depends on the definition of "vibe coded" I've heard some people talk about sending the LLM off into a loop and then trying to use the result, whereas if you are just using it as a more powerful autocomplete and playing captain then that's a lot better.

As for the LLM part: I have written a couple of projects with the help of LLMs and it works perfectly! I know what I wanted it to do and how, and I did extensive testing, and I am familiar with the whole code, of course. The problem arises when people who "vibe code" do not have the knowledge to begin with. It ended up writing code that I would write because of me. :D It just wrote it quicker, that is all. Ultimately I would have written the same code, but it would have taken me a bit more time because I would have had to read documentation first (which I do not mind, I love doing it).

  sh: 1: [[: not found

  ls | xargs -I % bash -c 'cd %; pwd; [[ $(git status -s) ]] && echo WIP || echo clean'

the aim of check-projects is just to keep track of the work still not fully done and pushed.

My first usage to test out claude code was to generalize this script: cople hours later it was entirely rewritten with Go and and CI on github actions you see now here.

Run check-projects to see which of your projects have uncommitted changes, are ahead of remote, or have other git status indicators.

The latest one is about React state management and my workflow for creating screens.

that was the first step for Fox CLI, and I added assets creation for ios/android stores;

Next step is to provide a helpful prompting to build debug/release versions

# libs: here this is pretty much sandbox for now: I gather sharable code for my games:

- an Animate API

- static functions like the ones I uses with lodash.js for example

I still need to write lots of doc for those parts, I'll do it alongside my game dev

The unreal engine equivalent of this would be a few small c++ plugins extending the editor which already provides prompts for necessary rebuilds. I thought godot had a project aware editor, why aren’t you extending that to minimise the amount of work involved? What genuine need is there for a let’s be clear HUGE dependency like NodeJS for this small of a utility?

I've picked it because I work with js on my daily basis and found http://yargs.js.org/ very handy to create beautiful CLI.

Another possibility could be to extract a binary to provide the CLI as an executable instead of the node project with yargs in dev-deps

And the other part of the project is are libs, not very well documented as of today, but real shortcuts for gdscript projects: Example the Animate functions based on the tween API;

WIP!

zustand inspired me a lot to create the custom hooks for La Taverne, and you can also create your {store, dispatch} to use anywhere without React (and providers)

The goal is to keep Redux original power and simplicity, removing the headaches of addons like Redux-thunks or Reselect.

But Redux Toolkit is precisely among the reasons that led me to this new lib `La Taverne`:

Redux core has this awesome Flux basics, but it's deliberately unopinionated: you need addons and toolsets to complete your needs (Toolkit, Thunks, Reselect, Saga etc)

All of them add more setup, specific API, weight to your project...

I wanted a lighter solution to handle my Flux architecture.

La Taverne means to be standalone, providing essential Flux tools: async actions, immutable reducing, isolated external state.