If you’ve ever debugged a broken CI pipeline at 2 AM, you probably know this feeling: “It works locally, but fails in CI” “What changed since last deploy?” “Why does this script behave differently on another machine?” Shell workflows are powerful, but they have a fundamental problem: not reproducible, not observable, and not structured by default. I kept running into the same issues across different projects, so I decided to experiment with a small tool to fix this at the CLI level. Bash and CLI tools are great, but they share a few weaknesses: Once a command runs, it disappears unless you explicitly log everything. Two developers running the same script can still get different outcomes. YAML configs, scripts, and environment assumptions slowly diverge. You reconstruct what happened instead of observing it directly. I wanted something simple: every command is logged workflows are reproducible pipelines are predictable debugging is deterministic instead of reactive So I started building a small CLI toolkit called OLS (Open Linux Shell). OLS is not a shell replacement. toolkit layer on top of CLI workflows. It focuses on three things: Every action is recorded so you can trace what actually happened. Instead of “it works on my machine”, you can validate setups explicitly. Tools are designed to work cleanly in CI/CD environments. Instead of manually configuring GitHub Actions or copying templates: cicd init This generates a ready-to-use CI/CD pipeline. ols doctor Checks your system and highlights issues like: missing dependencies misconfigured environment potential runtime problems Most teams don’t fail because of code. They fail because of: inconsistent environments unclear system state missing visibility into what actually happened OLS tries to reduce that gap by making CLI workflows more observable and reproducible. The design is based on a few principles: All actions should leave a clear trace so debugging becomes deterministic. Commands should be simple and predictable, without unnecessary flags or complexity. Every tool should work naturally in CI/CD environments and support stdin/stdout workflows. Packages are downloaded once and cached locally for reuse. OLS is an early-stage MVP. It is: experimental evolving quickly open to feedback and contributors The goal is to explore whether adding a lightweight “observability layer” to CLI workflows actually improves developer experience in practice. Right now, I’m mainly interested in: feedback from DevOps / backend engineers real-world edge cases ideas for improving CLI observability whether this approach is useful beyond personal workflows We already have observability for systems, logs for applications, and metrics for infrastructure. But our terminal workflows are still mostly invisible. OLS is an attempt to change that — starting with something simple. If you’ve worked with CI/CD, bash automation, or messy shell scripts, I’d really appreciate