Describe a task; Mang proposes a terminal command. Inspect it and explicitly confirm before execution. Use local Ollama or OpenRouter. Built in Rust. MIT-licensed.
1/4 · I made Mang for the moment when you know what you want to do but can't remember the shell syntax.
Describe the task in ordinary language and Mang proposes a terminal command.
You inspect it, then explicitly confirm before anything runs. It works with local Ollama or OpenRouter, so you choose your own trade-offs on data, capability and cost. I like that the proposed command comes with an explanation, because the aim is to help you understand the terminal a little better each time, not to hide it from you.
That last pause is the point. A plausible command can still be wrong, destructive or simply wrong for your machine. Mang helps with the terminal; it isn't permission to stop reading it.
This is day three of the Weekathon, seven free and open-source launches in seven days, and I wanted a small, repeatable workflow rather than another all-purpose AI subscription. The code is MIT-licensed, so you can adapt it to the way you work and share improvements back.
Try a task you actually do. Was the proposed command easy to understand, and what would help you review it with more confidence?
The yo command takes a plain-language request, proposes a command and gives an explanation. You confirm before execution. It can route through local Ollama or OpenRouter, depending on your setup.
I see it as help with translation, not a reason to stop reading commands. Destructive operations, private paths and a wrong working directory still have consequences. Please test unfamiliar suggestions in a safe environment.
Local inference requires suitable hardware; remote inference has provider costs and data-handling implications. Those belong in the decision, not in the footnotes after deployment.
My wall of fame includes complicated lives as well as celebrated contributions. The practical lesson I bring to Mang is simple: encourage curiosity, make consequences legible, and keep permission with the person at the keyboard.
The third Weekathon release therefore has a different design question from the first two: where should the software explicitly wait for its user?
Mang makes one CHO decision tangible: choose a model and workflow against the job, rather than asking every colleague to rediscover the same setup. Local Ollama and hosted OpenRouter have different cost and data boundaries. A small self-hosted model might suit a narrow command task; representative tests must establish that.
Keep those tests, permissions and operating notes with the code. Hardware, maintenance, model licensing and mistakes belong in the comparison. Central ownership of a tool does not remove the user's decision to approve a command.
The repository is MIT-licensed, including the right to adapt or commercialise it with the notices retained. A useful contribution might be a poorly explained command, an ambiguous request or a better test for a risky edge case.
If you use an AI to work on it, give it that specific case, a budget and an acceptance test. Check the actual command behaviour, not just the prose explaining it. I'll use the same approach when prioritising public reports and funding manageable follow-up changes.
The CHO (Chief Hacking Officer) title is deliberately playful; the role is serious. I'm open to a CHO brief of up to 30h/week with a great company or startup, a worthwhile product, trust and a modest budget.
Outside this open-source release, I'm also raising funds for Openline (openline.com), my main startup: the aim is to reshape the eSIM market, with a deep pipeline of ideas ready to execute. Angels and VCs interested in the founder's work are welcome to start a separate conversation via paulfleury.com/contact, no need to wait for the 1 December launch.
Enki (enki.ngo), a public-good, local-first AI initiative with open blueprints, launches on Product Hunt on Tuesday 24 November. It's too big for me alone, and needs people with more talent, connections and resources than I can bring alone.
I'm at Web Summit in Lisbon today (its last day), where I live, shipping Mang between conversations. Happy to meet today or later around Lisbon, if you're interested in the work or want to help with Enki: X (@paulfxyz) or paulfleury.com/contact.
Report
does it warn harder when the command has rm or sudo in it?
@leoheo No, it's the standard confirmation flow like with any other command. What do you have in mind? You'd like Mang to make you confirm twice when it's a root-level command? I'm wary of any redundancy here, but I also get what you mean. I'd love to hear your argument here. Thanks.
Report
@paulfxyz just for rm -rf and sudo, everything else one confirm is plenty
This is the exact gap I keep hitting — I know what I want the terminal to do, I just can't remember the exact flags. The confirm-before-it-runs step is the part that matters most to me, and local Ollama support is a big plus since it keeps everything on my machine. Going to try it on my usual git and cleanup chores and see how the suggestions hold up.
@jcbuilds Thanks buddy for the heartwarming comment. And yes, please give it a try, let me know how it goes and what's your feedback. I'll try my best to implement it. @leoheo has already suggested perhaps a double confirmation when a command involves root-level; I'd love to know if you agree with him too as it's something I too consider.
Replies
1/4 · I made Mang for the moment when you know what you want to do but can't remember the shell syntax.
Describe the task in ordinary language and Mang proposes a terminal command.
You inspect it, then explicitly confirm before anything runs. It works with local Ollama or OpenRouter, so you choose your own trade-offs on data, capability and cost. I like that the proposed command comes with an explanation, because the aim is to help you understand the terminal a little better each time, not to hide it from you.
That last pause is the point. A plausible command can still be wrong, destructive or simply wrong for your machine. Mang helps with the terminal; it isn't permission to stop reading it.
This is day three of the Weekathon, seven free and open-source launches in seven days, and I wanted a small, repeatable workflow rather than another all-purpose AI subscription. The code is MIT-licensed, so you can adapt it to the way you work and share improvements back.
Try a task you actually do. Was the proposed command easy to understand, and what would help you review it with more confidence?
2/4 · Execution, model choice and safety
The yo command takes a plain-language request, proposes a command and gives an explanation. You confirm before execution. It can route through local Ollama or OpenRouter, depending on your setup.
I see it as help with translation, not a reason to stop reading commands. Destructive operations, private paths and a wrong working directory still have consequences. Please test unfamiliar suggestions in a safe environment.
Local inference requires suitable hardware; remote inference has provider costs and data-handling implications. Those belong in the decision, not in the footnotes after deployment.
Get started: https://mang.sh
Read the source: https://github.com/paulfxyz/mang
Weekathon context: https://ph.paulfleury.com/
3/4 · Where the tool should wait for you
My wall of fame includes complicated lives as well as celebrated contributions. The practical lesson I bring to Mang is simple: encourage curiosity, make consequences legible, and keep permission with the person at the keyboard.
The third Weekathon release therefore has a different design question from the first two: where should the software explicitly wait for its user?
Mang makes one CHO decision tangible: choose a model and workflow against the job, rather than asking every colleague to rediscover the same setup. Local Ollama and hosted OpenRouter have different cost and data boundaries. A small self-hosted model might suit a narrow command task; representative tests must establish that.
Keep those tests, permissions and operating notes with the code. Hardware, maintenance, model licensing and mistakes belong in the comparison. Central ownership of a tool does not remove the user's decision to approve a command.
4/4 · Take it further
The repository is MIT-licensed, including the right to adapt or commercialise it with the notices retained. A useful contribution might be a poorly explained command, an ambiguous request or a better test for a risky edge case.
If you use an AI to work on it, give it that specific case, a budget and an acceptance test. Check the actual command behaviour, not just the prose explaining it. I'll use the same approach when prioritising public reports and funding manageable follow-up changes.
The CHO (Chief Hacking Officer) title is deliberately playful; the role is serious. I'm open to a CHO brief of up to 30h/week with a great company or startup, a worthwhile product, trust and a modest budget.
Outside this open-source release, I'm also raising funds for Openline (openline.com), my main startup: the aim is to reshape the eSIM market, with a deep pipeline of ideas ready to execute. Angels and VCs interested in the founder's work are welcome to start a separate conversation via paulfleury.com/contact, no need to wait for the 1 December launch.
Enki (enki.ngo), a public-good, local-first AI initiative with open blueprints, launches on Product Hunt on Tuesday 24 November. It's too big for me alone, and needs people with more talent, connections and resources than I can bring alone.
I'm at Web Summit in Lisbon today (its last day), where I live, shipping Mang between conversations. Happy to meet today or later around Lisbon, if you're interested in the work or want to help with Enki: X (@paulfxyz) or paulfleury.com/contact.
does it warn harder when the command has rm or sudo in it?
@leoheo No, it's the standard confirmation flow like with any other command. What do you have in mind? You'd like Mang to make you confirm twice when it's a root-level command? I'm wary of any redundancy here, but I also get what you mean. I'd love to hear your argument here. Thanks.
@paulfxyz just for rm -rf and sudo, everything else one confirm is plenty
@leoheo I am pleased to announce https://github.com/paulfxyz/mang/releases/tag/v3.1.0 — it's handling your suggestion and confirming twice on root-level commands.
This is the exact gap I keep hitting — I know what I want the terminal to do, I just can't remember the exact flags. The confirm-before-it-runs step is the part that matters most to me, and local Ollama support is a big plus since it keeps everything on my machine. Going to try it on my usual git and cleanup chores and see how the suggestions hold up.
@jcbuilds Thanks buddy for the heartwarming comment. And yes, please give it a try, let me know how it goes and what's your feedback. I'll try my best to implement it. @leoheo has already suggested perhaps a double confirmation when a command involves root-level; I'd love to know if you agree with him too as it's something I too consider.