I am continuing to work on Kan [0], a dev-focused kanban board that works via plain text files in your repository. I am finding it really useful for solo projects, giving a really simple way to get per-project Kanban boards that I can sync via Git. Since it's local only, it's really snappy, and given the dev-focus, it can offer some pretty nice workflows with local hooks, customization, etc.
The other project I am continuing to work on is Rad [1], a programming language tailor made for writing CLI scripts. It's not for enterprise software, it specializes specifically in CLI, offering all the essentials built-in, such as a declarative approach to arguments and generated help (as opposed to Bash where you have to roll your own arg parsing and help strings each time).
I've been working on Kan [0] which is a CLI written in Go that can serve a Kanban board ( `kan serve` ). Serving the Kanban board means opening up a localhost page for a Kanban board which acts on files stored locally on your machine, in your repo. Just plaintext JSON & TOML files. The Kanban board is written in TypeScript. You commit Kanban board changes like any other files.
I use it for all my personal projects. Any new project where I will have todo lists, I'll run `kan init` and `kan serve`, and begin tracking tasks. Because it's a CLI, you can interact with the board thru the CLI with commands like `kan add` and `kan edit`, so I've even included a SKILL markdown file in the repo which I use to let Claude read and interact with my boards. You can also navigate all your boards from a single `kan serve`, so it's convenient and snappy cross-project too.
Really appreciated this perspective. Much more tempered and less hype than a lot of other articles I see.
I thought the "dont let agents finishing interrupt you" workflow was an interesting point. I've set up chime hooks to basically do the opposite, and this gives me pause to wonder if I'm underestimating the cost of context switching. I'll give it a go.
This is exactly the frustration that lead me to write Rad [0] (the README leads with an example). I've been working on it for over a year and the goal is basically to offer a programming language specifically for writing CLIs. It aims for declarative args (no Bash ops parsing each time), automatic --help generation, friendly (Python-like) syntax, and it's perfect for dev build scripts. I'll typically have something like this:
#!/usr/bin/env rad
---
Dev automation script.
---
args:
build b bool # Build the project
test t bool # Run tests
lint l bool # Run linter
run r bool # Start dev server
release R bool # Release mode
filter f str? # Test filter pattern
filter requires test
if build:
mode = release ? "--release" : ""
print("Building ({release ? 'release' : 'debug'})...")
$`cargo build {mode}`
if lint:
print("Linting...")
$`cargo clippy -- -D warnings`
if test:
f = filter ? "-- {filter}" : ""
print("Running tests{filter ? ' (filter: {filter})' : ''}...")
$`cargo test {f}`
if run:
bin = release ? "target/release/server" : "target/debug/server"
$`./{bin}`
Usage: ./dev -b (build), ./dev -blt -f "test_auth" (build, lint, test auth), ./dev -r (just run).
I am working on Rad [0], a programming language built specifically for CLI scripts, so you don't need to write Bash, and it offers CLI-tailored features which make it a better choice than Python.
Lately I've mainly been working on stability and bug fixes. I've released some big features the past few months so I'm doing a big push on polish, before I again tackle some larger features that I'd like to implement.
If CLI scripts is something you're interested in at all, give it a go! We have docs and a guide [1] for getting started, feedback very welcome :)
Oh, until the URL part, I assumed you were the creator of Red [1]. I vaguely remembered reading about it a couple years ago, and thought "I don't remember it being positioned as for CLI scripts shrug".
Even seeing 'rad' in the URLs, at first I thought you'd misspelt them there :)
I'm currently using Material for MkDocs but was thinking of switching off it, in part due to the lack of options around having custom highlighting in code blocks (my docs website is for a programming language I am working on). What are Zensical's plans here? Tree sitter highlighting would be perfect in my case.
Zensical team here – right now it's still Python/Pygments under the hood, as we're using the same toolchain for rendering for compatibility reasons, but we'll be rethinking language support from the ground up, and tree sitter is something we're experimenting with. Ideally, we'll be able to unify code highlighting with language support with API reference docs.
Rad is built specifically for writing CLI scripts and is perfect for these sorts of small to medium scripts, takes a declarative approach to script arguments, and has first-class shell command integration. I basically don't write scripts in anything else anymore.
Working hard on Rad, which is aiming to be a Bash-replacement for writing CLI scripts. The goal is to allow users to write maintainable scripts with declarative argument parsing, built-in JSON processing, HTTP requests, and interactive
prompts - all in a familiar, readable syntax (Python-like!). Here's an example of the declarative approach to script args:
args:
username str # Required string
password str? # Optional string
token str? # Optional auth token
age int # Required integer
status str # Required string
username requires password // If username is provided, password must also be provided
token excludes password // Token and password cannot be used together
age range [18, 99] // Inclusive range from 18 to 99
status enum ["active", "inactive", "pending"]
Rad does all the arg parsing for you (unlike Bash), including validation for those constraints you wrote, and you can get on with writing the rest of your script is a nice, friendly syntax!
Very keen for feedback so if any of that sounds interesting, feel free to give it a go!
Work continues for me on Rad[0]. It's a programming language designed specifically for CLI scripts. I was sick of writing Bash scripts and thought we could do much, much better, so that's the goal with this project.
Been working on it for a bit over a year now, and I'm using it every day! Still have many big features in mind, such as commands, I suspect I'm still only at the beginning at this journey!
