So feature suggestions:
* Pipe data into qq ("cat /tmp/stacktrace | qq What is wrong with this: "),
* Profiles (qq -profile legal-analysis Please checkout document X and give feedback)
* Conversations (this is simply appending a new message to a previous query)
[0]: https://github.com/baalimago/clai/blob/main/EXAMPLES.md
A little anecdote: a few years ago I published an open source library that for many years would go completely underappreciated. For a few years I did not even check it - and then one day I realized it had over 500 stars on GH (+700 today). Good things take time.
Appreciate the ideas!
https://github.com/pmarreck/dotfiles/blob/master/bin/ask
I have a local version of ask that works with ollama: https://github.com/pmarreck/dotfiles/blob/master/bin/ask_loc...
And here is "please" as in "please rename blahblahblah in this directory to blahblah": https://github.com/pmarreck/dotfiles/blob/master/bin/please
https://gist.github.com/rbitr/bfbc43b806ac62a5230555582d63d4...
OpenAI-compatible endpoint: https://ch.at/v1/chat/completions (supports streamed responses)
Also accessible via HTTP/SSH/DNS for quick tests: curl ch.at/?q=… , ssh ch.at Privacy note: we don’t log anything, but upstream LLM providers might...
How do you guys pay for this? I guess the potential for abuse is huge.
https://github.com/pchalasani/claude-code-tools?tab=readme-o...
It’s pretty basic, and could be improved a lot. E.g make it use Haiku or codex-CLI with low thinking etc. Another thing is have it bypass reading CLAUDE.md or AGENTS.md. (PRs anyone? ;)
Oh genius, that's the best UX idea for the situation of asking an LLM to flesh out the CLI command without relying entirely on blind faith.
Even better if we can have that kind of behavior in the shell itself. For example if we started typing "cat list | grep foo | " and then suddenly realized we want help with the awk command so that it drops the first column.
https://github.com/sigoden/aichat
Nevertheless it’s good to see more tools with the Unix philosophy!
I believe the best “worker” agents of the future are going to be great at following instructions, have a fantastic intuition but not so much knowledge. They’ll be very fast but will need to retain their learnings so they can build on it, rather than relearning everything in every request - which is slow and a complete waste a resources. Much like what Claude is trying to achieve with skills.
I’m not suggesting that every tool reinvent this paradigm in its own unique way. Perhaps we a single system that can do all the necessary state keeping so each tool can focus on doing its job really well.
Unfortunately, this is more art than science - for example, asking each model to carry out handoff in the expected way will be a challenge. Especially on current gen small models. But many people are using frontier models, that are slowly converging in their intuition and ability to comprehend instructions. So it might still be worth the effort.
Since I launched it yesterday, I added a few new features - check out the latest version on Github!
Here is what we have now:
* added support for OpenRouter
* added support for local LLMs (Ollama)
* qqqa can be installed via Homebrew, to avoid signing issues on MacOS
* qq/qa can ingest piped input from stdin
* qa now preserves ANSI colors and TTY behavior
* hardened the agent sandbox - execute_command can't escape the working directory anymore
* history is disabled by default - can be enabled at --init, via config or flag
* qq --init refuses to override an existing .qq/config.json
- it puts the command in the shell editor line so you can edit it (for example to specify filenames using the line editor after the fact and make use of the shell tools like glob expansion etc.)
- it goes into the history.
- It can use a binding so you can start writing something without remembering to prefix it with a command and invoke the cmd completion at any place in the line editor.
- It also allows you to refine the command interactively.
qqqa uses history - although in a very limited fashion for privacy reasons.
I am taking note of these ideas though, never say never!
Copying and pasting tends to be a very tedious operation in the shell, which usually requires moving your hands away from the keyboard to the mouse (there are terminals which allow you to quick-select and insert lines but they are still more tedious than simply pressing enter to have the command on the line editor). Maybe try using llm-cmd-comp for a while.
> I do not see how editing the command is a good tradeoff here in terms of complexity+UI.
I don't find it a tradeoff, I think it's strictly superior in every way including complexity. llm-cmd-comp is probably the way I most often interface with llms (maybe second to basic search-engine-replacement) and I almost always either 1. don't have the file glob or the file names themselves ready (they may not exist yet!) at the time when I want to start writing the command or they are easier to enter using a fuzzy selector like fzf 2. don't want the llm to do weird things with globs when I pass them directly and having the shell expand them is usually difficult because the prompt is not a command (so the completion system won't do the right thing).
But even in your own demo it is faster to use llm-cmd-comp and you also get the benefit that the command goes into the history and you can optionally edit it if you want or further revise the prompt! It does require pressing enter twice instead of "y" but I don't find that a huge inconvenience especially since I almost always edit the command anyway.
Again, try installing llm-cmd-comp and try out your demo case.
it's inspired on F.R.I.D.A.Y. from the Marvel Cinematic Universe, a digital assistant with access to all of the (fictional) hardware.
I personally use "claude -p" for this
I have no interest in adding too many complex features. It is supposed to be fast and get out of your way.
Different philosophies.
https://github.com/github/gh-copilot/commit/c69ed6bf954986a0...
Why is there a flag to not upload my terminal history and why is that the default?
It does not support chaining multiple tool calls - if it did, it would not be a lightweight assistant anymore, I guess.
The history is there to allow referencing previous commands - but now that I think about it, it should clearly not be on by default.
Going to roll out a new version soon. Thanks for the feedback!
Is it possible to use an OpenAI-compatible API locally, or how does that work?
That said, I rather use claude in headless mode https://code.claude.com/docs/en/headless
Also, groq + gpt-oss is so much faster than Claude.
I published an open source library, it is not even v1.0 yet.
I kindly ask you to delete this comment.
But there’s nothing suspicious about having multiple nicknames. I don’t really get what they are talking about there.
Especially since it's looking and sharing for something as irrelevant as "HN name doesn't check out!"
This was to correct the doubt that the HN poster was not the same person as the GitHub user.
Conceding to you that a search can be useful, GP could've stopped at "The github is old and the person has other reputable projects". There was no reason to expand to the LinkedIn.
Only LinkedIn showed the link between the HN profile and the Github profile, because it lists both the project mentioned on the HN profile as well as the project listed in the Github profile.
That may tell more about the beholder than you think.
> Only LinkedIn showed the link between the HN profile and the Github profile, because it lists both the project mentioned on the HN profile as well as the project listed in the Github profile.
What if there was no link between the HN profile and GitHub, then? Would you conclude that, because you can't reliably link the HN profile to the GitHub profile (that was independently already trustworthy), this would make the project seem suspicious?
In other words -- Would your projects be more suspicious, if I, a total stranger, made Show HNs about them?
You're seeing my point, don't you?
I disagree with the idea that having multiple nicknames is suspicious, though. But, if that is something the poster believes, I guess I can see why they’d share it.
After the latest fun incidents with NPM and others, I just wanted to make a point how the way the project is currently "marketed" and distributed — and again, PERFECTLY fine for a first draft and "look what I built" — might stand in the way of it getting further traction.
And I did so in a very stream-of-consciousness way, trying to illustrate what I mean by "Trust & Safety issue".
All of the other aspects of identity are on the other side, the GitHub account with the real name, other projects, a reputation. So then, consider the Hackernews account to be some random, start the check-out at the GitHub, and you don’t see anything particularly suspicious.
I'm not sure how extensive your search was to find OP's LinkedIn, but it's clearly not in his HN profile, and that's enough to be unwarranted imho.
It was YOU, iagooar, who posted a "Show HN" here with a link to the following URL: https://github.com/matisojka/qqqa
This is a public web site hosted on Github, and it belongs to the Github user matisojka, whose public Github profile is at https://github.com/matisojka, containing, in public, the full name "[name-redacted]" — put there by no other than yourself!
You came here to promote your tool, asking for feedback ("Curious if the HN crowd finds it useful"), so YOU expect me to download and run YOUR software on MY system, and therefore trusting your software to not wreck havoc on my personal computer system.
And then flip out if I dare to do a quick, superficial cross-check on whose software I'm installing? Using only public information that you yourself put onto the Internet on public pages yourself?
Are you seriously suggesting that I broke into private web sites or computer systems in order to illegally retrieve information that was not meant for public eyes? Like, seriously?
"go through my private profiles" -> can you point at a SINGLE private profile that I went through? Just ONE?
You asked for feedback. Your literally wrote "AMA" — "Ask me anything".
And all I did was just that: asking you to understand that if you want this project to gain traction, that the nature of the way it is currently distributed, and the way that the Apple ecosystem treats it, might be a roadblock for this.
A roadblock for a project that I love and want to see succeed.
I don't see your point, and I squinted very hard.
That is not the point of my original comment.
The point of my original comment was that downloading and using software from the Internet is a process that requires trust, at least if you want your project to gain traction, and that this specific project might have — at least to some people — road blocks in this regard.
I really want to see this project succeed, and thus gave feedback on this — what else is a "Show HN" good for, then?
For them to avoid that Gatekeeper warning, they would have to pay Apple $100 and then notarize their executable through Apple for their hobby project with 30 commits.
This isn't something we'd expect OP to do for this project.
Also the Gatekeeper warning is kind of a norm among developer tools. You can see it in much more popular projects. Just today `brew install --cask syncthing` triggered it when I went to open it. You're trying to be helpful but I hope you find this comment helpful as well.
Finally, all of that is beside the issue of digging up someone's linkedin profile and pseudonyms for the crime of sharing a tool with us that wasn't notarized with a $100 Apple permission slip.
I don't see an option for removal on the HN ui.
Same for 45834692 if possible, as this also contains the name.