Thanks!

Currently, savvy doesn't record commands in an ssh session.

For now, you can install Savvy's CLI (curl -fsSL https://install.getsavvy.so | sh) into the machine you've sshed into and then run savvy record history. You can do this after the issue is over.

If you share more details about your set up I may be able to suggest other workarounds to get you set up. Feel free to email me at shantanu@getsavvy.so

I agree with what a lot of folks here are saying around knowledge transfer is a continuous/on-going process.

Any one-off knowledge transfer will most likely fail. People can't learn actionable knowledge with doing the actions. - That's why we need continuous sharing and doing.

People only look for the artifacts of a knowledge transfer when they need it. When resolving unfamiliar issues, people's first question is: "Has this happened before? How did we resolve it the last time?" It's a simple question but most often its very hard to answer.

The knowledge needed to answer questions like the one above, is mostly manually compiled together and often from memory.

Finally, actionable knowledge is hosted in the same tools as product specs, meeting notes, press releases etc. As a result, creating, finding and following such knowledge is quite hard.

Disclosure: I'm building Savvy(getsavvy.so) to fix a lot of these issues for developers.

Ell is really cool!

I'm building a similar product called Savvy(https://github.com/getsavvyinc/savvy-cli) and considered an approach similar to yours (writing in pure bash) but ultimately decided to use Go for a few reasons:

- charmbracelet makes it super easy to build rich TUI - Go produces a single binary that's compatible across many platforms and keeps installation simple - It's simpler to support multiple shells.

Thanks!

Another user[1] also mentioned Savvy but I misunderstood its purpose. Now I understand it does have a similar functionality of analyzing a record of terminal! Your approach allows more chances to let LLM explain what happens, while in my case, asking ell will immediately destroy the original context (the user may have to rerun the falsy command again and cause more damage). However, exiting and reentering recording mode also feels tedious. I must find a better way to interact.

https://news.ycombinator.com/item?id=41139040

You're right, to counteract the friction I also allow users to create runbooks from their shell history.

Here's the source code: https://github.com/getsavvyinc/savvy-cli/blob/8c6a834c5a140b...

Just checked out Savvy; is the runbook-generating code (‘savvy record’) also in that repository? The one hosted at api.getsavvy.

Very interesting idea! Your terminal screenshots are excellent as well, very compelling imagery. Love the font.

Here's the code for savvy record: https://github.com/getsavvyinc/savvy-cli/blob/8c6a834c5a140b...

Lot of users typically find that they realize they should have recorded something after they've done it. That's why savvy also allows you to select commands from your shell history with savvy record history

The API source code is in a different repo.

Thanks! All credit to the dracula theme for tmux and Kitty terminal emulator.

If you have any questions or feedback feel free to email me at shantanu@getsavvy.so

I'm currently using GPT4-o via OpenAI's API.

I've been looking at ollama for a bit and I think I will ship an integration with Savvy at some point.

For enterprises, I think it makes sense to support a company approved LLM API endpoint in addition to local LLMs.

I'm happy to answer any questions you have around privacy too.

Savvy doesn't have SSH support, but I'm working to add it soon.

I think we can make SSH support work without installing Savvy on the remote machine, but I'm still working through the details.

I'm laser-focused on nailing the DX and making sure it delivers a lot of value to our users.

If you're up for it, I'd love to chat and learn more about how Savvy can help you personally and at work - my email is shantanu@getsavvy.so

You're right. My post assumes too much prior knowledge.

A runbook is a set of precise commands that you can use to resolve or diagnose anything from a complete production outage to helping a developer debug their local environment.

Most developers manually create runbooks - Savvy's CLI changes that and allows you to create runbooks in seconds.

Here's an example runbook that shows how you can extract an x509 cert from a config map and verify its validity: https://app.getsavvy.so/runbook/rb_72e6b7d29ae70abe/How-To-V...

> A runbook is a set of precise commands...

Not really? That's a shell script. A runbook includes context, prerequisites, and troubleshooting steps, not just commands. Also, it's generally considered manual.

FWIW, replying to one of your other comments, a playbook is generally considered a more automated runbook, with branching plays based on conditionals, bridging from a runbook world to an automation word; that's why Ansible used the term.

What makes a runbook a runbook are the detailed instructions, including prerequisites, step-by-step procedures, screenshots, and even troubleshooting tips, to help the user run the `precise commands` with consistency and reliability in operational use on systems that are never quite right and when the user who needs to perform these specific tasks reliably doesn't have enough technical knowledge to even know if they're doing them right.

I like the idea -- but what if you rethought it to check in with the user step by step, telling them what they're about to do next, then co-looking at the results they get to see if it's working or if they've lost the plot and need to replan?

You're right. A runbook is more than just a list of commands.

I plan to add support for setting up and validating prerequisites for running a runbook with Savvy. For example, Savvy can ensure that all environment variables are automatically set up and removed as part of a `savvy run.`

A while ago, I built Flowshare, which is similar to Savvy but works in the browser. I will integrate that tech within Savvy to support capturing runbooks that involve steps in the browser and the terminal.

I like your suggestion on troubleshooting. Savvy can offer a great experience here as the cli will know when a command has failed or returned a nonzero exit code.

> but what if you rethought it to check in with the user step by step, telling them what they're about to do next

IIUC, your thoughts align with how Savvy Run currently works. Savvy suggests the next step, but devs can edit or ignore it. Providing troubleshooting help, as you suggested, will definitely improve the DX.

So it’s a bash script?

Runbooks or playbooks are often used interchangeably.

I went with Runbooks since a playbook is usually something more abstract. For e.g

A playbook might say: "restart the ec2 server," but a Runbook will list the exact sequence of commands you can run to restart a server.

(Savvy's founder here) Nope, we don't train any models on user data.

Let me know how it goes!

I had the same question. What do you do with user data? Are my commands, output, or other data sent to your database? I work with PHI so have to be careful with tools like this. At the same time it looks incredibly useful and easy to use!

We don't see or store the output of your commands at all.

Your commands and the AI generated text for runbooks created using savvy record and savvy record history are stored in the database.

All data in the DB is encrypted at rest and during transit.

Any runbook, commands, or explanations generated with savvy ask/explain are ephemeral and not stored in our DB.

Thanks for all the feedback so far!

I think you hit the nail on the head when you say, "get a pulse on the developer zeitgeist on a particular topic." I really enjoyed using it to get a sense of what developers feel about a particular topic. I also learned about new products I wasn't aware of.

Yay! Thank you for trying it out, so glad it's been useful!