Create fully complete .gitignore files from the cli

Isaac AR — Sat, 30 May 2026 10:21:35 +0000

There are a gazillion packages in pypi.org that "build" your .gitignore files.

The problem is, all download templates from a repository or another, and you need to instruct them to do so.

You could also ask your LLM to do it claude -p "update the .gitignore make it complete" or codex -p "update the .gitignore make it complete" but why would you waste tokens on something so simple?

So as far as I can tell we all still do it pretty much manually, piercing things from here and then, and then reusing them.

I build gitignorio-cli (command: gi) which does the .gitignore for your system, your project languages and the editor you are using automatically.

You don't need to do anything other than installing it with:
pipx install gitignorio-cli

Once installed, you run:
gi create

or if you are updating the file for a project that already has one
gi update
This leaves all your changes in, and appends in the end.

Or if you are adding something else, and you want to feel like you are contributing to it (but it is unnecessary) you can run gi add LANG/SYSTEM/EDITOR

The way this works is:
(1) It uses Linguist which is the same thing Github uses to show you the languages in a package.
(2) Then runs magika in case Linguist has missed anything.
(3) Creates the .gitignore for the languages it has found, the system it is in, and any other files/folders that should be ignored.

And that is it.

Now you can also pass it into a tool caller as a default for your project setup, so if an LLM is building the whole project just needs to use the tool-call with gi as the parameter and can do this with using almost no tokens.

As a last note, the package also ships with hooks you can install so it runs automatically and your .gitignore is always up to date.

gitignorio-cli · PyPI

Create and update .gitignore files using gitignore.io with automatic language detection

pypi.org

Happy (less annoying) coding/prompting!

Seeding folder structures

Isaac AR — Thu, 22 Jan 2026 11:45:48 +0000

the problem

I have been using LLMs a lot lately.

And as part of working with claude, chatgpt, etc., is I get a lot of ideas, and most of those ideas produce folders with structures.

I'm sure you will recognize this type of output instantly...

I'm sure you get them too.

But now this is a problem. If I want to try these structures, I have to go and create all these files and folders manually.

And if I later decide on another structure, I need to go back and delete some files and folders, then go back and create, move or do whatever is needed to get the llm's suggested structure. And so on and so forth over and over again.

I have a project called WhatzNew.ai, which has been through 5 complete rewrites in 2025. It has been through 12 or so different top-level structures and then 20 or so different structures for different paths...set now at around 300K lines of code.
This last year, I have written one way or another close to 1M for this project alone.

And this is not the first time I have built SW, I have built systems used in the military, the government, small startups that became large companies and so on. Usually from the ground up, as a tech lead or CTO. Which is to say I should know.

But what LLMs have done is show the wider picture, and allowed a lot more iteration that yields better software in general.

What I realised during all this activity is that I don't have a way to document a structure (programatically) and enforce it at a later date.

Which is #bad

But not anymore. As Alan Kay says, (paraphrasing)

"If you can roll your own tools, do so"

the solution

A cli package that does exactly that - seeds projects from tree-like specs.

The package seed-cli installs in your terminal via pip install seed-cli, and you can use it by just calling seed thereafter.

Why is it useful?

(1) Allows you to test multiple project structures
(2) It lets you move from one project structure to the next (and back if you want to)
(3) Allows you to lock a structure
(4) Shows what differs from the desired structure (hint: useful on deployments to enforce consistency)
(5) Allows you to create subfolders with the same structure from your programs; e.g.

.src
├── <id>
|   ├── A/
|   ├── B/
|   ├── C/
|   ├── D/
|   └── E/
...

Also, it solves deployment consistency and infrastructure consistency:

No more files that shouldn't be on the server.
No more manually modifying CI/CD pipelines to match new structures.
Locked structures to match the spec.

But I am not trying to sell you anything, is free to use (MIT license) and in beta for you to try.

Why does it matter?

Because a project structure is important.

A structure can optimise the codebase
Make it easier to understand (if semantically organised)
Make it easier to get on with (for contributors, developers, etc.)

And maintaining it is even more important.

Because any project that grows, grows in complexity.
And complexity is all good and well to solve something.
But becomes a hindrance as a project grows, and our capacity as humans to process complexity doesn't grow with it.

The more new functionality being added (easier these days with ai!), the more difficult it is to keep a project lean
And even more so that the project still makes sense after a few sessions of codex, or claude code, or whatever other LLMs you use.

And that you can navigate to the right place by just following the logical structure is even more rare and more difficult to get to.

So - to make this rarity a commonality, and this to not be a problem anymore - seed-cli was born.