Yesterday somebody dropped 44 MIT-licensed AI and prompt tools online, free to grab and free to fork. That’s already a nice haul, the kind of link you bookmark and never open again. But step 2 is the part that made me stop scrolling: u/greentide008 over on r/PromptEngineering didn’t just list the tools, they ran the whole set through their own system and generated five real, buildable compositions, then proved each pipeline actually holds together before anyone writes a line of glue code. That last part is the whole reason this post is worth your ten minutes instead of a bookmark you forget about.
What’s new
Forty-four small, single-purpose tools (source, transform, filter, fold, sink) built to snap together like Lego bricks. Each one does exactly one job and does nothing else, which is the opposite of the bloated all-in-one frameworks most of us are used to fighting with. The post walks through five example builds that fall out of combining them:
- The Refusal Engine: a gate that says no and names exactly which rule stopped you, so you’re not stuck debugging a silent rejection.
- The Pocket Republic: a tiny serverless nation you can fork, hand to a friend, and merge back together, rules and all.
- The Reading Oath: forces an AI to prove it actually read your whole codebase instead of skimming three files and bluffing its way through a summary.
- The Customs House: an intake gate that parses hostile files, email, PDFs, themes, without trusting a single byte that crosses the border.
- The Amber Ledger: turns your git history into a tamper-evident timesheet, no manual logging required.
None of these are built yet. The original poster is upfront about that: these are designs, not shipped products. What makes them credible anyway is the twist.
The twist
Every one of the 44 tools declares itself as exactly one of five roles: source, transform, filter, fold, or sink. Sounds like typing-system trivia until you see what it buys you. A small crew of the tools, `typecheck`, `declare`, `conductor`, `map`, `port`, can check that a pipeline’s data actually flows before you ever run it. A source feeding two folds checks out clean. A sink expecting a filtered stream that never got filtered does not, and you get told exactly where the mismatch sits. You catch the broken composition on paper, not in production, which means no 2am debugging session because two tools quietly disagreed about the shape of the data between them. That’s the twist!
Most “here’s my toolkit” posts skip that part entirely. This one ships the verifier along with the parts, so you’re not just trusting the author’s word that the pieces fit.
How to build the easiest one (Amber Ledger) in an afternoon
This is the one clean pipe in the whole set, a source feeding two folds, so it’s the fastest way to see the idea work, and you don’t need to write a single adapter to get it running:
- 🔧 Point `gitlog` at your repo. It’s a source: turns your commit history into one JSON object per commit, timestamps and all.
- ⚙️ Pipe that into `worklog`. It’s a fold: groups commits by day or by author, with counts and subjects, so you get a readable daily digest instead of a raw commit dump.
- 📊 Pipe that into `timesheet`. Another fold: estimates worked hours as the day’s span minus any gap longer than your break threshold, tunable to however your team actually works.
- 🔒 Seal the finished report with `amber` + `sha256`. Now the number you hand a client is tamper-evident, change any input and the seal breaks and names what moved, so there’s no arguing about whether the report was edited after the fact.
Pro tips
- Start with the Amber Ledger, not the Pocket Republic. It type-checks with zero adapters. The Republic is the coolest idea in the post, but you still have to write the merge algebra yourself, and that’s the genuinely hard part, easily a multi-day project instead of an afternoon one.
- Read the “honest edge” this contributor wrote for each build before you ship anything. `amber` proves nobody edited your report, not that your estimate is the truth. `timesheet` is floor-biased on purpose, don’t bill a client to the minute with it, treat it as a conservative estimate and sanity check it against your own memory of the week.
- The Refusal Engine, Reading Oath, and Customs House all lean on the same idea: the tools hand you provable facts, you still write the rulebook that decides what those facts mean. That’s the real engineering work in every one of these builds. Budget your time there, not on wiring, because the wiring is the part these 44 tools already solved for you.
Go build one
Five blueprints, 44 free tools, zero of them built so far. If you’ve got the technical chops, this is a genuinely fun weekend project, and this Redditor said they want to see it if you ship one. Head to the original thread for the full toolkit and the complete technical breakdown on each build, pick the Amber Ledger, and go turn your commit history into something you can actually hand a client. 🚀
Frequently Asked Questions
Q: These haven’t been built yet, so how real are they?
The author validated that data actually flows between tools and pipelines check out structurally. You’re building the custom logic that ties everything together. Think of it like having a blueprint that’s been checked for structural integrity, you’re still doing the renovation work, but at least the bones are sound.
Q: Why does ‘naming the rule’ matter for refusal engines?
Black-box moderation just says no and leaves you guessing. This one tells you exactly which rule hit and why. Saves insane amounts of debugging time and actually lets users understand what went wrong instead of just being angry at an invisible wall.
Q: How do I adapt one of these to my own workflow?
Every design has “the one piece you build yourself”, the custom logic that fits your use case. In Customs House (file validation), the toolkit throws on bad bytes, but you decide what happens next (reject, alert, log, retry). That’s your part to customize.
Q: Won’t wiring these tools together just break things?
Each tool declares what it does (source/transform/filter/fold/sink), so the system can prove a pipeline works *before* you run it. Catches wiring mistakes upfront instead of crashing mid-execution. It’s like type-checking for data pipelines.
Five very real, very cool, prompt-focused compositions of the 44 MIT-licensed tools I created that you can build yourself
by u/greentide008 in PromptEngineering