Show HN：支援 Unix 管道的可執行 Markdown 檔案

task.md:

A script that runs your tests and reports results (run_tests.md):

One thing we didn't expect is that these are more auditable (and shareable) than shell scripts. Install scripts like curl -fsSL https://bun.com/install | bash could become:

The (really cool) executable markdown idea and auditability examples are from Pete Koomen (@koomen on X). As Pete says: "Markdown feels increasingly important in a way I'm not sure most people have wrapped their heads around yet."

We implemented it and added Unix pipe semantics. Currently works with Claude Code - hoping to support other AI coding tools too. You can also route scripts through different cloud providers (AWS Bedrock, etc.) if you want separate billing for automated jobs.

GitHub: https://github.com/andisearch/claude-switcher

What workflows would you use this for?

reply

1. Carefully test your markdown scripts interactively first

2. Be careful with the permissions granted based on the script.

This is also true with bash scripts. And you'll see in the example that before a markdown script can perform tasks like executing shell commands, you have to explicitly set the permissions for it to do so (--permission-mode bypassPermissions).

For a task requiring judgement or evaluation (e.g. "Analyze this codebase and summarize the key architecture decisions"), you're fairly safe especially if you don't add the explicit permissions.

But you're 100% right that care is needed. You definitely want to ONLY use --dangerously-skip-permissions in a sandboxed environment.

reply

How does it help?

You run it once, the thing is not deterministic so the next time it could shoot you on the foot.

reply

So you're using the appropriate tools for the task at hand embedded within both traditional scripts and markdown scripts.

Examples:

• A bash script summarizes text files from a path in a loop
• A markdown script runs ./test/run_tests.py and summarizes the results.

Tools like Claude code combined with executable scripts and pipes open up a genuinely new way of doing tasks that are traditionally hard with scripting languages alone. I expect we will see a mix of borth approaches where each gets used based on its strengths, as we're seeing with application development too.

It is a new world and we're all figuring this out.

reply

reply

I built https://github.com/brandonkal/inkjet to make building CLIs super simple. All of my private repos have an inkjet.md file for common tasks and documentation. I use code blocks for the executable section and the language determines the runtime. I realize now inkjet could be extended to support an LLM executor by default. PRs welcome.

reply

reply

I was excited in the possibly extravagant implementation idea and... when I read enough to realize it's based on some yet another LLM... Sorry, no, never. You do you.

reply

The default permissions are to not allow execution. Which means that you can use the eval and text-generation capabilities of LLMs to perform assessments and evaluations of piped-in content without ever executing code themselves.

The script shebang has to explicitly add the permissions to run code, which you control. It supports the full Claude Code flag model for this.

reply

That’s entirely what Claude Code does.

reply

reply

One of the key things we realized starting to use it is that the approach allows you to mix deterministic and non-deteministic tools together as part of a composable chain.

So you can, for example, use LLMs for their evaluation capabilities with a natiural language script as part of a broader chain that wraps it in deterministic code, and that also can include and run deterministic code nested within the plain language script.

So it allows us to create pipelines that combine the best of both approaches as appropriate based on the sub-task at hand.

reply

Which means your entire pipeline is tainted.

If your process is fine with that, whatever, but don't pretend that the result can be controlled.

reply

I agree that this is a choice by each person using tools like this, and that it is up to each of us as developers whether a tool like this suits the use case at hand.

My own view is that the world is rapidly moving to more human language programming tools, and that system automation and shell scripting will be part of this. There is a wide array of sensible potential use cases I can see between the two polarized views of "never use an LLM' and "let's vibe code system automation".

reply