一开始看帖子没看明白是做什么用的，看了手册才反应过来这是做了一套类似 IPC 的规范，外加一个注册中心。
有一点我觉得 OP 做得非常好，schema 自动生成。但是就如 #5 @
w568w 所说的，这套规范化的做法是和写脚本这个行为的初衷天然互斥的，一个追求复用，一个追求敏捷。而且楼主在文章里也说，为了这个工具重写了大量脚本，着实有一种为了这碟醋包了一顿饺子的意味。
正好借这个帖子我想探讨一下 IPC 和工作流的话题，不知楼主是否了解过 dmenu ？
鉴于很多人可能从来没有听说过 dmenu ，我就简单介绍一下。它原本是为 dwm 窗口管理器设计的动态菜单（ dynamic menu ）应用，常常用作 Linux 环境的启动器。
和其他所谓效率工具最大的不同在于，dmenu 的哲学是它仅仅只负责从 stdin 读取输入生成菜单，然后向 stdout 输出用户的选择。整个过程的交互全部是纯文本。如果有必要上一个 dmenu 的输出也可以作为下一个 dmenu 的输入。
我个人认为 dmenu 设计思想的优秀之处在于：将写脚本和写工作流恰当地分离开，写脚本依然是那个能跑就行的随手工作，当需要将脚本集成进工作流的时候，适配所需的代价非常小，关键是并不需要刻意改动脚本。
单纯这样说可能依旧看不出 dmenu 设计思路的巧妙之处，我举几个例子说明。
比如我希望命令行将 wifi 切换至手机热点。需要准备两个脚本，一个是调用 nmcli 扫描当前可用网络，然后字符串处理一下生成 wifi 列表；另一个是从命令行读入一个字符串，调用 nmcli 连接该字符串所代表的 wifi 网络。
这个过程里 dmenu 的作用是，调用第一个脚本得到输出结果，以列表的形式供用户选择，并将用户的选择输出，传递给第二个脚本使用。写成命令行就是 `script1 | dmenu | script2`，通过管道的形式传递。
从这个例子可以看出，两个脚本本身就是实现功能用的，原本怎么写就怎么写，不需要预先考虑去适配某种输出。即便是别人写的脚本，只要它是文本输出，完全可以套一层 wrapper 使用 awk/sed 等工具转换成需要的输出。脚本不支持命令行输入，也可以使用 xargs 等方式将 stdin 转换为命令行参数。
至于工作流，无非就是扩展之前的命令行 `script1 | dmenu | script2 | xargs ... script3 | dmenu | script4` 这样，在有需要用户输入或者选择的地方加入 dmenu 即可。更进一步的话，将脚本都放在 ~/.local/bin 然后设计一个“入口”工作流，让用户首先选择所需要调用的脚本，那就变成了万能入口的效率工具了。
我不记得是什么时候接触到 dmenu 了，15 年应该是有了，现在我早已不用 dmenu ，但是依旧在用基于 dmenu 思路的替代品。写这个回复的时候突然想起了很早之前比较流行的一篇文章《开发人员为何应该使用 Mac OS X 兼 OS X 小史》，链接在
https://blog.youxu.info/2010/02/28/why-mac-os-x-for-programmers/从时代的发展来看，即便是 macOS 这么理想化的 IPC 设计（图形化界面基于 Mach 的 Service 服务概念），依旧是推广不开的。抛开技术层面统一 runtime 不靠谱这一点，更重要的应该是人性，想要别人主动去适配实在过于困难。
万能入口、启动器这种工具的生态其实挺有意思的：Linux 用户似乎从来不关心，估计是都有自己手搓的方案； Windows/macOS 平台上的实现几乎看不到基于 dmenu 思想的实现，虽然可以解释为这些工具面向的都是没有编程能力的群体，那适配脚本的工作就显得更加难以实现了。