Developer extension: `LSTools`

[BayLee4]

Please explain the motivation behind the feature request.

A big challenge for AI programming assistants is to get a good understanding of the codebase they are working on. This is an open problem, and each project has its own way of tackling it: aider with its repository map , Cursor with its codebase indexing, and goose with its .goosehints.

Goose hints, while simple, can actually be extremely powerful. But they are currently underused. If you have used the goose CLI, you probably noticed that a large part of the LLM tool calls are just ls -la to get an idea of the directory structure of the repository, which causes some significant problems:

1. It does not respect .gooseignore, every private file can be seen.
2. It is terribly inefficient token wise, the -la option used for seing hidden files include a lot of irrelevant informations. Consider the line: drwxr-xr-x 639 user staff 192 Mar 14 00:31 . is 47 tokens (with ..) to give absolutely no information. And this is per ls -la call.
3. It doesn't respect .gitignore, which only exacerbates problem 2

To fix to these problems, a new LSTools could be given to the LLM. This is for instance what Claude Code does, and from their tests this is the method they got the best results with.

And this is exactly where the simple .goosehints system could be a game changer: for each directory on which the LSTools is called, if a .goosehints exists in that directory, automatically attach it to the context. The hints could, for example, give a small description of the important files contained in the directory for instance, which is exactly what the LLM is looking for when it calls the ls command. The strength of the .goosehints system is that it's flexible enough to contain any information the developer deem important for that directory, it's versatile. It would be a perfect complement to the goose cold start described in (https://github.com/block/goose/issues/1635).

This system has the potential to be give extremely good insights to the LLM, while keeping the system simple.

Describe the solution you'd like

Alternative to ls that respects .gitignore (and can respect any ignore format, like .goosignore) exists, one of them being eza, which is written in Rust. It could serve as the command of choice for LSTools. Regarding .goosehints, here the system already exists, no changements except reading them when the exists on the directory LSTools is called on.

Describe alternatives you've considered

None that fit the current .goosehints system, which is really great (but underused).

Additional context

Well, I could probably attach a session log where claude sonnet 3.7 thinking burns 5$ in ~15 minutes with ls -la calls on the goose repository if needed. It seems monorepos and modular repositories like goose would benefits the best from the recursive .goosehints and .gitignore files hidden.

• [x] I have verified this does not duplicate an existing feature request

[BayLee4]

In the same spirit but for a find alternative, fd (also written in Rust) is a really valuable tool, respecting .gitignore while being very fast.

[michaelneale]

we use ripgrep and other things now - there are a few MCPs which can do vectors + embeddings (goose has one built in now) which vary in results.

I think we should move this to a discussion https://github.com/block/goose/discussions if interested in continuing conversation there (tag me!)